Network Working Group W. Harold
Request for Comments: 3529 IBM
Category: Experimental April 2003
Using Extensible Markup Language-Remote Procedure Calling
(XML-RPC) in Blocks Extensible Exchange Protocol (BEEP)
Status of this Memo
このメモの位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
XML-RPC is an Extensible Markup Language-Remote Procedure Calling protocol that works over the Internet. It defines an XML format for messages that are transfered between clients and servers using HTTP. An XML-RPC message encodes either a procedure to be invoked by the server, along with the parameters to use in the invocation, or the result of an invocation. Procedure parameters and results can be scalars, numbers, strings, dates, etc.; they can also be complex record and list structures.
XML-RPCは、インターネット上で動作する拡張マークアップ言語、リモートプロシージャ呼び出しプロトコルです。これは、HTTPを使用して、クライアントとサーバー間で転送されるメッセージのXMLフォーマットを定義します。 XML-RPCメッセージは、プロシージャ呼び出しで使用するパラメータとともに、サーバによって呼び出される、または呼び出しの結果のいずれかをコードします。プロシージャパラメータと結果はスカラー、数字、文字列、日付、などすることができ;彼らはまた、複雑な記録とリスト構造することができます。
This document specifies a how to use the Blocks Extensible Exchange Protocol (BEEP) to transfer messages encoded in the XML-RPC format between clients and servers.
このドキュメントでは、クライアントとサーバの間でXML-RPC形式でエンコードされたメッセージを転送するブロック拡張可能交換プロトコル（BEEP）を使用する方法を指定します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. BEEP Profile Identification . . . . . . . . . . . . . . . . 2
2.1 Profile Initialization . . . . . . . . . . . . . . . . 3
3. XML-RPC Message Packages . . . . . . . . . . . . . . . . . . 4
4. XML-RPC Message Exchange . . . . . . . . . . . . . . . . . . 5
5. URL Schemes . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1 The xmlrpc.beep URL Scheme. . . . . . . . . . . . . . . 5
5.1.1 Resolving IP/TCP Address Information . . . . . . 6
5.2 The xmlrpc.beeps URL Scheme . . . . . . . . . . . . . . 7
6. Initial Registrations . . . . . . . . . . . . . . . . . . . 9
6.1 Registration: The XML-RPC Profile . . . . . . . . . . . 9
6.2 Registration: The xmlrpc.beep URL Scheme. . . . . . . . 9
6.3 Registration: The xmlrpc.beeps URL Scheme . . . . . . . 10
6.4 Registration: The System (Well-Known) TCP port number
for XML-RPC over BEEP . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
Appendix
A. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 13
B. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 15
This memo specifies how messages encoded in the XML-RPC [1] format are transmitted using a BEEP profile [2].
このメモは、XML-RPC [1]の形式でエンコードされたメッセージは、BEEPプロファイルを使用して送信される方法を指定する[2]。
Throughout this memo, the terms "request" and "response" refer to the "methodCall" and "methodResponse" elements defined by the XML-RPC specification [1]. Further the terms "peer", "client", "server", and "one-to-one" are used in the context of BEEP. In particular, Sections 2.1 and 2.1.1 of [2] discuss BEEP roles and exchange styles.
このメモ全体を通して、用語「要求」および「応答」は、「methodCallで」とXML-RPC仕様書[1]で定義される「methodResponse」要素を指します。さらに、用語「ピア」、「クライアント」、「サーバ」、および「1対1」BEEPの文脈で使用されています。特に、セクション2.1及び2.1.1 [2] BEEPロールと交換スタイルを議論します。
The BEEP profile for XML-RPC is identified as
XML-RPCのためのBEEPプロフィールは次のように識別されます
http://iana.org/beep/transient/xmlrpc
ｈっｔｐ：／／いあな。おｒｇ／べえｐ／ｔらんしえんｔ／ｘｍｌｒｐｃ
in the BEEP "profile" element during channel creation.
チャネルの作成中にBEEP「プロファイル」要素インチ
In BEEP, when the first channel is successfully created, the "serverName" attribute in the "start" element identifies the "virtual host" associated with the peer acting in the server role, e.g.,
最初のチャンネルが正常に作成されBEEPでは、「serverNameの」属性「スタート」要素は、例えば、サーバーの役割で行動するピアに関連付けられている「仮想ホスト」を特定するには
<start number='1' serverName='stateserver.example.com'> <profile uri='http://iana.org/beep/transient/xmlrpc' /> </start>
<開始番号= '1' サーバ名= 'stateserver.example.com'> <プロファイルのuri = 'のhttp：//iana.org/beep/transient/xmlrpc' /> </スタート>
The "serverName" attribute is analogous to HTTP's "Host" request-header field (c.f., Section 14.23 of [3]).
「serverNameの」属性は、HTTPの「ホスト」リクエストヘッダフィールド（C.F.、[3]のセクション14.23）に類似しています。
There are two states in the BEEP profile for XML-RPC, "boot", the profile's initial state, and "ready":
XML-RPCのためのBEEPプロファイルに2つの状態、「ブート」、プロファイルの初期状態、および「準備完了」があります：
o In the "boot" state, the peer requesting the creation of the channel sends a "bootmsg" (either during channel initialization or in a "MSG" message).
O「ブート」状態では、チャネルの作成を要求側ピアは、（チャネルの初期化中、または「MSG」メッセージのいずれかで）「bootmsg」を送信します。
* If the other peer sends a "bootrpy" (either during channel initialization or in a "RPY" message), then the "ready" state is entered
他のピアは、（チャネルの初期化中、または「RPY」メッセージのいずれかで）「bootrpy」を送信した場合*は、「準備完了」状態に入ります
* Otherwise, the other peer sends an "error" (either during channel initialization or in a "ERR" message), and no state change occurs.
*そうでない場合は、他のピアは、（チャネルの初期化中、または「ERR」メッセージのいずれかで）「エラー」を送信し、状態変化は生じません。
o In the "ready" state, the initiating peer begins an XML-RPC message pattern by sending a "MSG" message containing a request. The other peer completes the message pattern by sending back a "RPY" message containing a response.
O「準備完了」状態では、開始ピアが要求を含む「MSG」メッセージを送信することによって、XML-RPCメッセージパターンを開始します。他のピアは、応答を含む「RPY」メッセージを返送することにより、メッセージパターンを完了する。
The boot message is used to identify the resource accessed by the channel bound to the BEEP profile for XML-RPC.
ブートメッセージはXML-RPCのためのBEEPプロフィールに結合チャネルによってアクセスされたリソースを識別するために使用されます。
The DTD syntax for the boot message and its response are:
ブートメッセージとその応答のためのDTDの構文は以下のとおりです。
<!ELEMENT bootmsg EMPTY> <!ATTLIST bootmsg resource CDATA #REQUIRED>
<！ELEMENTのbootmsg EMPTY> <！ATTLISTのbootmsgリソースCDATA #REQUIRED>
<!ELEMENT bootrpy EMPTY>
<！ELEMENTのbootrpy EMPTY>
The boot message contains a single mandatory attribute: "resource", which is analagous to HTTP's "abs_path" Request-URI parameter (c.f., Section 5.1.2 of [3])
HTTPSに類似して、「リソース」、「腹筋_経路」のRequest-URIパラメータ（C.F.、[3]のセクション5.1.2）：起動メッセージは、単一の必須属性が含まれています
If the peer acting in the server role recognizes the requested resource, it replies with a boot response. Otherwise, if the boot message is improperly formed, or if the requested resource isn't recognized, the peer acting in the server role replies with an error message (c.f., Section 7.1 of [2]).
サーバーの役割で行動するピアが要求されたリソースを認識すると、それはブート応答で応答します。要求されたリソースが認識されない場合、起動メッセージが不適切に形成されるか、またはそうでない場合、サーバーの役割で作用するピアはエラーメッセージ（C.F.、[2]のセクション7.1）で応答します。
Typically, the boot message and its response are exchanged during channel initialization (c.f., Section 2.3.1.2 of [2]).
典型的には、ブート・メッセージ及びその応答は、チャネル初期化（C.F.、[2]のセクション2.3.1.2）の間に交換されます。
For example, here the boot message and its response are exchanged during channel initialization:
例えば、ここでブートメッセージおよびその応答は、チャネルの初期化中に交換されています。
C: <start number='1' serverName='stateserver.example.com'> C: <profile uri='http://iana.org/beep/transient/xmlrpc'> C: <![CDATA[<bootmsg resource='/NumberToName' />]]> C: </profile> C: </start>
C：<開始番号= '1' サーバ名= 'stateserver.example.com'> C：<プロファイルURIが= 'のhttp：//iana.org/beep/transient/xmlrpc'> C：<[CDATA [<bootmsg！リソース= '/ NumberToName' />]]> C </プロフィール> C </開始>
S: <profile uri='http://iana.org/beep/transient/xmlrpc'> S: <![CDATA[<bootrpy />]]> S: </profile>
S：<プロファイルのuri = 'のhttp：//iana.org/beep/transient/xmlrpc'> S：<！[CDATA [<bootrpy />]]> S：</プロフィール>
The channel bound to the BEEP profile for XML-RPC is now in the "ready" state.
XML-RPCのためのBEEPプロファイルにバインドされたチャネルは「準備完了」状態になりました。
Alternatively, here is an example in which the boot exchange is unsuccessful:
また、ここでブート交換が失敗した例は以下のとおりです。
C: <start number='1' serverName='stateserver.example.com'> C: <profile uri='http://iana.org/beep/transient/xmlrpc'> C: <![CDATA[<bootmsg resource='/NameToCapital' />]]> C: </profile> C: </start>
C：<開始番号= '1' サーバ名= 'stateserver.example.com'> C：<プロファイルURIが= 'のhttp：//iana.org/beep/transient/xmlrpc'> C：<[CDATA [<bootmsg！リソース= '/ NameToCapital' />]]> C </プロフィール> C </開始>
S: <profile uri='http://iana.org/beep/transient/xmlrpc'> S: <![CDATA[<error code='550'>resource not S: supported</error>]]> S: </profile>
S：<プロファイルのuri = 'のhttp：//iana.org/beep/transient/xmlrpc'> S：<！[CDATA [<エラーコード= '550'>リソースではないS：サポート</エラー>]]> S ：</プロフィール>
Although the channel was created successfully, it remains in the "boot" state.
チャンネルが正常に作成されたが、それは「ブート」状態のまま。
The BEEP profile for XML-RPC transmits requests and responses encoded as UTF-8 using the media type "application/xml" [4], e.g.,
XML-RPCのためのBEEPプロフィールは、例えば、[4]メディアタイプ「アプリケーション/ XML」を使用してUTF-8としてエンコードされた要求と応答を送信します
I: MSG 1 1 . 0 364 I: Content-Type: application/xml I: I: <?xml version="1.0"?> I: <methodCall> I: <methodName>examples.getStateName</methodName> I: <params> I: <param> I: <value><i4>41</i4></value> I: </param>
I：MSG 1 1。 0 364 I：のContent-Type：アプリケーション/ xmlのI：I：の<？xml version = "1.0"？> I：<methodCallで> I：<methodNameの> examples.getStateName </ methodNameの> I：<のparams> I < param>のI：<値> <I4> 41 </ I4> </ value>はI：</ param>の
I: </params> I: </methodCall> I: END
I：</のparams> I </ methodCallで> I：END
and its associated response
そして、その関連応答
L: RPY 1 1 . 201 100 L: Content-Type: application/xml L: L: <?xml version="1.0"?> L: <methodResponse> L: <params> L: <param> L: <value><string>South Dakota</string></value> L: </param> L: </params> L: </methodRespose> L: END
L：RPY 1 1。 201 100 L：コンテンツタイプ：アプリケーション/ XMLのL：L：の<？xml version = "1.0"？> L：<methodResponse> L：<のparams> L：<PARAM> L：<値> <文字列>サウスダコタ州</文字列> </ value>のL </ PARAM> L </ paramsは> L </ methodRespose> L：END
A request/response exchange involves sending a request, which results in a response being returned.
要求/応答交換は、応答が返されることになる要求を送信することを含みます。
The BEEP profile for XML-RPC achieves this using a one-to-one exchange, in which the client sends a "MSG" message containing an request, and the server sends back a "RPY" message containing an response.
XML-RPCのためのBEEPプロフィールは、クライアントが要求を含む「MSG」メッセージを送信し、サーバは応答を含む「RPY」メッセージを返信した1対1の交換を使用して、これを達成します。
The BEEP profile for XML-RPC does not use the "ERR" message for XML-RPC faults when performing one-to-one exchanges. Whatever response is generated by the server is always returned in the "RPY" message.
一対一のやり取りを行うときにXML-RPCのためのBEEPプロファイルは、XML-RPCの故障のための「ERR」メッセージを使用していません。サーバによって生成されるどのような応答は常に「RPY」メッセージで返されます。
This memo defines two URL schemes, "xmlrpc.beep" and "xmlrpc.beeps", which identify the use of XML-RPC over BEEP over TCP. Note that, at present, a "generic" URL scheme for XML-RPC is not defined.
このメモはTCP上でBEEPの上にXML-RPCの使用を特定する2つのURLスキーム、「xmlrpc.beep」と「xmlrpc.beeps」を、定義されています。現在では、XML-RPCのための「一般的な」URLスキームが定義されていない、ということに注意してください。
The "xmlrpc.beep" URL scheme uses the "generic URI" syntax defined in Section 3 of [5], specifically:
「xmlrpc.beep」URLスキームは具体的には、[5]のセクション3で定義された「一般的なURI」構文を使用します。
o the value "xmlrpc.beep" is used for the scheme component; and,
O値「xmlrpc.beepは」スキーム成分のために使用されます。そして、
o the server-based naming authority defined in Section 3.2.2 of [5] is used for the authority component.
O [5]のセクション3.2.2で定義されたサーバーベースの命名権限は権限コンポーネントのために使用されます。
o the path component maps to the "resource" component of the boot message sent during profile initialization (if absent, it defaults to "/").
プロファイルの初期化（「/」に存在しない場合は、デフォルト）中に送信された起動メッセージの「リソース」コンポーネントへのパス成分マップO。
The values of both the scheme and authority components are case-insensitive.
スキームと権限の両方の成分の値は、大文字と小文字を区別しません。
For example, the URL
例えば、URL
xmlrpc.beep://stateserver.example.com/NumberToName
xmlrpc.beep：//stateserver.example.com/NumberToName
might result in the example shown in Section 2.1.
2.1節で示した例になる可能性があります。
The "xmlrpc.beep" URL scheme indicates the use of the BEEP profile for XML-RPC running over TCP/IP.
「xmlrpc.beep」URLスキームは、TCP / IP上のXML-RPCの実行のためのBEEPプロファイルを使用することを示します。
If the authority component contains a domain name and a port number, e.g.,
権限コンポーネントは、例えば、ドメイン名とポート番号が含まれている場合は、
xmlrpc.beep://stateserver.example.com:1026
xmlrpc.beep：//stateserver.example.com：1026
then the DNS is queried for the A RRs corresponding to the domain name, and the port number is used directly.
その後、DNSは、ドメイン名に対応するA資源レコードを照会して、ポート番号をそのまま使用します。
If the authority component contains a domain name and no port number, e.g.,
権限コンポーネントは、例えば、ドメイン名なしポート番号が含まれている場合は、
xmlrpc.beep://stateserver.example.com
xmlrpc.beep：//stateserver.example.com
the SRV algorithm [6] is used with a service parameter of "xmlrpc-beep" and a protocol parameter of "tcp" to determine the IP/TCP addressing information. If no appropriate SRV RRs are found (e.g., for "_xmlrpc-beep._tcp.stateserver.example.com"), then the DNS is queried for the A RRs corresponding to the domain name and the port number used is assigned by the IANA for the registration in Section 6.4.
SRVアルゴリズム[6]は、「XML-RPC-ビープ」のサービスパラメータおよびIP / TCPアドレス情報を決定するために、「TCP」のプロトコルパラメータと共に使用されます。何の適切なSRV RRを（例えば、「_xmlrpc-beep._tcp.stateserver.example.com」のために）見つからない場合は、DNSは、ドメイン名に対応するAのRRのために照会され、使用されるポート番号は、IANAによって割り当てられています6.4節で登録。
If the authority component contains an IP address, e.g.,
権限コンポーネントは、例えば、IPアドレスが含まれている場合
xmlrpc.beep://10.0.0.2:1026
xmlrpc.beep：1026：//10.0.0.2
then the DNS is not queried, and the IP address is used directly. If a port number is present, it is used directly; otherwise, the port number used is assigned by the IANA for the registration in Section 6.4.
その後、DNSが照会されていない、とIPアドレスが直接使用されます。ポート番号が存在する場合、それが直接使用されます。そうでない場合は、使用するポート番号は、6.4節で登録のためにIANAによって割り当てられます。
While the use of literal IPv6 addresses in URLs is discouraged, if a literal IPv6 address is used in a "xmlrpc.beep" URL, it must conform to the syntax specified in [7].
URLでのリテラルIPv6アドレスの使用が推奨されますが、リテラルIPv6アドレスが「xmlrpc.beep」URLで使用されている場合、それは[7]で指定された構文に準拠する必要があります。
The "xmlrpc.beeps" URL scheme is identical, in all ways, to the "xmlrpc.beep" URL scheme specified in Section 5.1, with the exception that prior to starting the BEEP profile for XML-RPC, the BEEP session must be tuned for privacy. In particular, note that both URL schemes use the identical algorithms and parameters for address resolution as specified in Section 5.1.1 (e.g., the same service name for SRV lookups, the same port number for TCP, and so on).
URLスキームが前にXML-RPCのためのBEEPプロフィールを開始する、BEEPセッションが調整されなければならないことを除いて、セクション5.1で指定された「xmlrpc.beep」URLスキームに、すべての方法では、同じである「xmlrpc.beeps」プライバシーのため。特に、セクション5.1.1で指定されるように、両方のURLスキームは、アドレス解決のための同一のアルゴリズムおよびパラメータを使用することに注意してください（例えば、SRVルックアップのために同じサービス名、TCPに対して同じポート番号など）。
There are two ways to perform privacy tuning on a BEEP session, either:
どちらか、BEEPセッションにプライバシーのチューニングを実行する方法は2つあります。
o a transport security profile may be successfully started; or,
Oトランスポート・セキュリティ・プロファイルが正常に開始することができます。または、
o a user authentication profile that supports transport security may be successfully started.
Oトランスポート・セキュリティをサポートし、ユーザー認証プロファイルが正常に開始することができます。
In either case the client must present the authority component of the URL in the "serverName" attribute of the "start" element it uses to tune the session for privacy.
いずれの場合も、クライアントは、それがプライバシーのためにチューニングするためにセッションを使用して「開始」要素の「serverNameの」属性でURLの権限コンポーネントを提示しなければなりません。
When TLS is used for privacy the client must verify that the authority component of the URL matches the server's identity as presented in the server's certificate. Section 2.4 of [9] describes the matching process.
TLSは、プライバシーのために使用されている場合、クライアントは、サーバーの証明書で提示されるURLの権限コンポーネントは、サーバーのIDと一致していることを確認する必要があります。 [9]のセクション2.4は、マッチングプロセスが記載されています。
For the URL:
URLの場合：
xmlrpc.beeps://stateserver.example.com/NumberToName
xmlrpc.beeps：//stateserver.example.com/NumberToName
the whole process might look like:
全体のプロセスは次のようになります。
S: <wait for incoming connection @ stateserver.example.com>
C: <open connection to stateserver.example.com>
C: RPY 0 0 . 0 52
C: Content-Type: application/xml
C:
C: <greeting />
C: END
S: RPY 0 0 . 0 110
S: Content-Type: application/xml
S:
S: <greeting>
S: <profile uri='http://iana.org/beep/TLS' /> S: <profile uri='http://iana.org/beep/SASL/DIGEST-MD5' /> S: </greeting> S: END C: MSG 0 1 . 52 158 C: Content-Type: application/xml C: C: <start number='1' serverName='stateserver.example.com'> C: <profile uri='http://iana.org/beep/TLS'> C: <![CDATA[<ready />]]> C: </profile> C: </start> C: END S: RPY 0 1 . 110 121 S: Content-Type: application/xml S: S: <profile uri='http://iana.org/beep/TLS'> S: <![CDATA[<proceed />]]> S: </profile> S: END
S：<プロファイルURIが= 'のhttp：//iana.org/beep/TLS' /> S：<プロファイルのuri = 'のhttp：//iana.org/beep/SASL/DIGEST-MD5' /> S：</挨拶> S：ENDのC：MSG 0 1。 52 158 C：のContent-Type：アプリケーション/ xmlのC：C：<開始番号= '1' サーバ名= 'stateserver.example.com'> C：<プロファイルのuri = 'のhttp：//iana.org/beep/TLS 「> C：<！[CDATA [<レディ/>]]> C：</プロフィール> C：</スタート> C：ENDのS：RPY 0 1。 110 121 S：コンテンツタイプ：アプリケーション/ XMLのS：S：<プロファイルのuri = 'のhttp：//iana.org/beep/TLS'> S：<！[CDATA [<続行/>]]> S：< /プロフィール> S：END
... TLS negotiations ...
... TLS交渉...
S: RPY 0 0 . 0 88 S: Content-Type: application/xml S: S: <greeting> S: <profile uri='http://iana.org/beep/transient/xmlrpc'> S: </greeting> S: END C: RPY 0 0 . 0 52 C: Content-Type: application/xml C: C: <greeting /> C: END
S：RPY 0 0。 0 88 S：コンテンツタイプ：アプリケーション/ XMLのS：S：Sを<挨拶>：<プロファイルのuri = 'のhttp：//iana.org/beep/transient/xmlrpc'> S：</挨拶> S：END C ：RPY 0 0。 0 52 C：コンテンツタイプ：アプリケーション/ XMLのC：C：<グリーティング/> C：END
... use the server's certificate to verify that it is in fact stateserver.example.com ...
...それは実際にstateserver.example.comであることを確認するために、サーバーの証明書を使用して...
C: MSG 0 1 . 112 211 C: Content-Type: application/xml C: C: <start number='3' serverName='stateserver.example.com'> C: <profile uri='http://iana.org/beep/transient/xmlrpc'> C: <![CDATA[<bootmsg resource='/NumberToName' />]]> C: </profile> C: </start> C: END
C：MSG 0 1。 112 211 C：コンテンツタイプ：アプリケーション/ XMLのC：C：<開始番号= '3' サーバ名= 'stateserver.example.com'> C <プロファイルURI = 'HTTP：//iana.org/beep/transient / XMLRPC '> C：<！[CDATA [<bootmsgリソース=' / NumberToName」/>]]> C：</プロフィール> C：</スタート> C：END
S: RPY 0 2 . 341 402 S: Content-Type: application/xml S: S: <profile uri='http://iana.org/beep/transient/xmlrpc'> S: <![CDATA[<bootrpy />]]> S: </profile> S: END
S：RPY 0 2。 341 402 S：コンテンツタイプ：アプリケーション/ XMLのS：S：<プロファイルのuri = 'のhttp：//iana.org/beep/transient/xmlrpc'> S：<！[CDATA [<bootrpy />]]> S ：</プロフィール> S：END
Profile Identification: http://iana.org/beep/transient/xmlrpc
プロフィール同定：http://iana.org/beep/transient/xmlrpc
Messages exchanged during Channel Creation: bootmsg, bootrpy
メッセージはチャンネルの作成中に交換：bootmsg、bootrpyを
Messages starting one-to-one exchanges: bootmsg, methodCall
bootmsg、methodCallで：1対1の交換を開始するメッセージ
Messages in positive replies: bootrpy, methodResponse
正の返信のメッセージ：bootrpy、methodResponse
Messages in negative replies: error
負の返信のメッセージ：エラー
Messages in one-to-many exchanges: none
1対多の交換におけるメッセージ：なし
Message Syntax: methodCall, methodResponse as defined in [1]
メッセージ構文：methodCallで、methodResponse [1]で定義されるように
Message Semantics: c.f., [1]
メッセージの意味：C.F.、[1]
Contact Information: Ward Harold <wharold@us.ibm.com>
お問い合わせ先：区ハロルド<wharold@us.ibm.com>
URL scheme name: xmlrpc.beep
URLスキーム名：xmlrpc.beep
URL scheme syntax: c.f., Section 5.1
URLスキームの構文：C.F.、5.1節
Character encoding considerations: c.f., the "generic URI" syntax defined in Section 3 of [5]
文字エンコーディングの考慮事項：C.F.、の3節で定義された「一般的なURI」構文[5]
Intended usage: identifies a XML-RPC resource made available using the BEEP profile for XML-RPC
意図した使用方法は：XML-RPCのためのBEEPプロファイルを使用して利用できるようにXML-RPCのリソースを識別する
Applications using this scheme: c.f., "Intended usage", above
この方式を使用したアプリケーション：上記C.F.、「使用目的」、
Interoperability considerations: n/a
相互運用性に関する注意事項：N / A
Security Considerations: c.f., Section 7
セキュリティの考慮事項：C.F.、第7節
Relevant Publications: c.f., [1], and [2]
関連資料：C.F.、[1]及び[2]
Contact Information: Ward Harold <wharold@us.ibm.com>
お問い合わせ先：区ハロルド<wharold@us.ibm.com>
Author/Change controller: the IESG
著者/変更コントローラ：IESG
URL scheme name: xmlrpc.beeps
URLスキーム名：xmlrpc.beeps
URL scheme syntax: c.f., Section 5.2
URLスキームの構文：C.F.、5.2節
Character encoding considerations: c.f., the "generic URI" syntax defined in Section 3 of [5]
文字エンコーディングの考慮事項：C.F.、の3節で定義された「一般的なURI」構文[5]
Intended usage: identifies a XML-RPC resource made available using the BEEP profile for XML-RPC after the BEEP session has been tuned for privacy
意図した使用方法は：BEEPセッションはプライバシーのために調整された後、XML-RPCのためのBEEPプロファイルを使用して利用できるようにXML-RPCのリソースを識別する
Applications using this scheme: c.f., "Intended usage", above
この方式を使用したアプリケーション：上記C.F.、「使用目的」、
Interoperability considerations: n/a
相互運用性に関する注意事項：N / A
Security Considerations: c.f., Section 7
セキュリティの考慮事項：C.F.、第7節
Relevant Publications: c.f., [1], and [2]
関連資料：C.F.、[1]及び[2]
Contact Information: Ward Harold <wharold@us.ibm.com>
お問い合わせ先：区ハロルド<wharold@us.ibm.com>
Author/Change controller: the IESG
著者/変更コントローラ：IESG
6.4 Registration: The System (Well-Known) TCP port number for XML-RPC over BEEP
6.4登録：システム（ウェルノウン）BEEP上のXML-RPCのTCPポート番号
Protocol Number: TCP
プロトコル番号：TCP
Message Formats, Types, Opcodes, and Sequences: c.f., Section 2.1
メッセージフォーマット、タイプ、オペコード、およびシーケンス：C.F.、2.1節
Functions: c.f., [1]
機能：C.F.、[1]
Use of Broadcast/Multicast: none
ブロードキャスト/マルチキャストの利用：なし
Proposed Name: XML-RPC over BEEP
提案名：BEEP上のXML-RPC
Short name: xmlrpc-beep
短い名前：XMLRPC-ビープ音
Contact Information: Ward Harold <wharold@us.ibm.com>
お問い合わせ先：区ハロルド<wharold@us.ibm.com>
Although service provisioning is a policy matter, at a minimum, all implementations must provide the following tuning profiles:
サービスプロビジョニングは、ポリシーの問題ですが、最低でも、すべての実装は、以下のチューニングプロファイルを提供する必要があります。
for authentication: http://iana.org/beep/SASL/DIGEST-MD5
認証のために：http://iana.org/beep/SASL/DIGEST-MD5
for confidentiality: http://iana.org/beep/TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher)
機密保持のために：http://iana.org/beep/TLS（TLS_RSA_WITH_3DES_EDE_CBC_SHA暗号を使用して）
for both: http://iana.org/beep/TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side certificates)
（クライアント側の証明書をサポートするTLS_RSA_WITH_3DES_EDE_CBC_SHA暗号を使用して）http://iana.org/beep/TLS：両方のために
Further, implementations may choose to offer MIME-based security services providing message integrity and confidentiality, such as OpenPGP [8] or S/MIME [10].
さらに、実装は、OpenPGPのようなメッセージの完全性と機密性を提供するMIMEベースのセキュリティサービスを提供することを選択することができる[8]またはS / MIME [10]。
Regardless, consult [2]'s Section 9 for a discussion of BEEP-specific security issues.
かかわらず、BEEP固有のセキュリティ問題の議論のための[2]のセクション9を参照してください。
[1] Winer, D., "XML-RPC Specification", January 1999, http://www.xmlrpc.com/spec
[1]ワイナー、D.、 "XML-RPC仕様"、1999年1月、http://www.xmlrpc.com/spec
[2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[2]ローズ、M.、 "ブロック拡張可能交換プロトコルコア"、RFC 3080、2001年3月。
[3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[3]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、 RFC 2616、1999年6月。
[4] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[4]村田、M.、サンローラン、S.およびD.コーン、 "XMLのメディアタイプ"、RFC 3023、2001年1月。
[5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[5]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[6] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[6] Gulbrandsenの、A.、いるVixie、P.及びL. Esibov、 "（DNSのSRV）サービスの位置を特定するためのDNS RR"、RFC 2782、2000年2月。
[7] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
[7] HindenとR.、大工、B.およびL. Masinterを、 "リテラルIPv6アドレスのフォーマットURLの中に"、RFC 2732、1999年12月。
[8] Elkins, M., Del Torto, D., Levien, R. and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
[8]エルキンズ、M.、デルTorto、D.、Levien、R.とT.レスラー、 "OpenPGPの持つMIMEセキュリティ"、RFC 3156、2001年8月。
[9] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
[9]ニューマン、C.、 "IMAP、POP3、およびACAPとTLSの使用"、RFC 2595を、1999年6月。
[10] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[10] Ramsdell、B.、 "S / MIMEバージョン3メッセージ仕様"、RFC 2633、1999年6月。
[11] O'Tuathail, E. and M. Rose, "Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)", RFC 3288, June 2002.
[11] O'Tuathail、E.およびM.ローズ、 "ブロック拡張交換プロトコル（BEEP）にシンプルオブジェクトアクセスプロトコル（SOAP）を使用して"、RFC 3288、2002年6月。
Appendix A. Acknowledgements
付録A.謝辞
This document is based, in part, on Using SOAP in BEEP [11] and the author gratefully acknowledges the contributions of Marshall Rose
この文書は、BEEPにSOAPを使用に部分的に基づいている[11]著者は感謝マーシャルローズの貢献を認めます
Appendix B. IANA Considerations
付録B. IANAの考慮事項
The IANA has registered the profile specified in Section 6.1, and has selected an IANA-specific URI, e.g.,
IANAは、例えば、セクション6.1で指定されたプロファイルを登録しており、IANA固有のURIを選択しています
http://iana.org/beep/xmlrpc
ｈっｔｐ：／／いあな。おｒｇ／べえｐ／ｘｍｌｒｐｃ
The IANA has registered "xmlrpc.beep" and "xmlrpc.beeps" as URL schemes, as specified in Section 6.2 and Section 6.3, respectively. (See: http://www.iana.org/assignments/uri-schemes)
それぞれ、6.2節および第6.3節に指定されているIANAは、URLスキームとして「xmlrpc.beep」と「xmlrpc.beeps」を登録しました。 （参照：http://www.iana.org/assignments/uri-schemes）
The IANA has registered "XML-RPC over BEEP" as a TCP port number (602), as specified in Section 6.4. (See: http://www.iana.org/assignments/port-numbers)
IANAはセクション6.4で指定されているように、TCPポート番号（602）として「BEEP上のXML-RPC」を登録しました。 （参照：http://www.iana.org/assignments/port-numbers）
Author's Address
著者のアドレス
Ward K Harold IBM 11400 Burnet Road Austin, Texas 78759 US
ウォードKハロルドIBM 11400バーネット道路オースティン、テキサス州78759米国
Phone: +1 512 838 3622 EMail: wharold@us.ibm.com
電話：+1 512 838 3622 Eメール：wharold@us.ibm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。