[要約] 要約：RFC 3529は、BEEPプロトコルでXML-RPCを使用する方法について説明しています。 目的：XML-RPCをBEEPプロトコルに統合することで、異なるプラットフォーム間でのリモートプロシージャコールを可能にします。
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)
ブロック拡張可能な交換プロトコル（BEEP）での拡張可能なマークアップ言語リモートプロシージャコール（XML-RPC）の使用
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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形式でエンコードされたメッセージを転送するために、ブロック拡張可能なExchangeプロトコル（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]形式でエンコードされたメッセージがビーププロファイル[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.
このメモを通して、「要求」と「応答」という用語は、XML-RPC仕様[1]で定義された「MethodCall」および「MethodSponse」要素を指します。さらに、「ピア」、「クライアント」、「サーバー」、「1対1」という用語がビープ音のコンテキストで使用されます。特に、[2]のセクション2.1および2.1.1は、ビープ音の役割と交換スタイルについて説明します。
The BEEP profile for XML-RPC is identified as
XML-RPCのビーププロファイルは、として識別されます
http://iana.org/beep/transient/xmlrpc
http://iana.org/beep/transient/xmlrpc
in the BEEP "profile" element during channel creation.
チャネル作成中のビープ音の「プロファイル」要素。
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.,
ビープ音では、最初のチャネルが正常に作成されると、「start」要素の「servername」属性は、サーバーの役割で行動するピアに関連する「仮想ホスト」を識別します。
<start number='1' serverName='stateserver.example.com'>
<profile uri='http://iana.org/beep/transient/xmlrpc' />
</start>
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のビープ音プロファイルには、プロファイルの初期状態「Boot」、および「Ready」の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」メッセージのいずれか）。
* If the other peer sends a "bootrpy" (either during channel initialization or in a "RPY" message), then the "ready" state is entered
* 他のピアが「bootrpy」（チャネル初期化中または「rpy」メッセージのいずれか）を送信する場合、「準備ができた」状態が入力されます
* 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 「Ready」状態では、開始ピアはリクエストを含む「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のビーププロファイルにバインドされたチャネルによってアクセスされるリソースを識別するために使用されます。
The DTD syntax for the boot message and its response are:
ブートメッセージのDTD構文とその応答は次のとおりです。
<!ELEMENT bootmsg EMPTY>
<!ATTLIST bootmsg
resource CDATA #REQUIRED>
<!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])
ブートメッセージには、HTTPの「ABS_PATH」リクエスト-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>
S: <profile uri='http://iana.org/beep/transient/xmlrpc'>
S: <![CDATA[<bootrpy />]]>
S: </profile>
The channel bound to the BEEP profile for XML-RPC is now in the "ready" state.
XML-RPCのビーププロファイルにバインドされたチャネルは、「準備が整った」状態にあります。
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>
S: <profile uri='http://iana.org/beep/transient/xmlrpc'>
S: <![CDATA[<error code='550'>resource not
S: supported</error>]]>
S: </profile>
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のビーププロファイルは、メディアタイプ「Application/XML」[4]を使用して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: </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
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のビーププロファイルは、1対1の交換を使用してこれを実現し、クライアントはリクエストを含む「MSG」メッセージを送信し、サーバーは応答を含む「RPY」メッセージを送信します。
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のビーププロファイルは、1対1の交換を実行するときに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よりもビープ音を介したXML-RPCの使用を特定する「XMLRPC.BEEP」と「XMLRPC.BEEPS」という2つのURLスキームを定義します。現在、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のビーププロファイルの使用を示しています。
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 RRSに対して照会され、ポート番号は直接使用されます。
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]は、「XMLRPC-BEEP」のサービスパラメーターと「TCP」のプロトコルパラメーターで使用され、IP/TCPアドレス指定情報を決定します。適切なSRV RRSが見つからない場合（例：「_xmlrpc-beep._tcateserver.example.com」）、DNSはドメイン名に対応するA RRSに照会され、使用されるポート番号はianaによって割り当てられますセクション6.4の登録用。
If the authority component contains an IP address, e.g.,
当局コンポーネントにIPアドレスが含まれている場合、
xmlrpc.beep://10.0.0.2:1026
xmlrpc.beep：//10.0.0.2：1026
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).
「xmlrrpc.beeps」URLスキームは、セクション5.1で指定された「xmlrrpc.beep.beep」URLスキームとあらゆる点で同一です。プライバシーのため。特に、両方のURLスキームは、セクション5.1.1で指定されているように、アドレス解像度の同一のアルゴリズムとパラメーターを使用していることに注意してください（たとえば、SRVルックアップの同じサービス名、TCPの同じポート番号など）。
There are two ways to perform privacy tuning on a BEEP session, either:
ビープセッションでプライバシーチューニングを実行するには、次の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.
いずれの場合も、クライアントは、プライバシーのためにセッションをチューニングするために使用する「start」要素の「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
... 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
... 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
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
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
1対1の交換を開始するメッセージ：bootmsg、methodcall
Messages in positive replies: bootrpy, methodResponse
肯定的な返信のメッセージ：bootrpy、methodesponse
Messages in negative replies: error
否定的な返信のメッセージ：エラー
Messages in one-to-many exchanges: none
1対Many交換のメッセージ：なし
Message Syntax: methodCall, methodResponse as defined in [1]
メッセージの構文：methodcall、methodesponse [1]で定義されているように
Message Semantics: c.f., [1]
メッセージセマンティクス：C.F。、[1]
Contact Information: Ward Harold <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。、[5]のセクション3で定義されている「ジェネリックURI」構文
Intended usage: identifies a XML-RPC resource made available using the BEEP profile for XML-RPC
意図された使用法：XML-RPCのビーププロファイルを使用して利用可能になった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 Relevant Publications: c.f., [1], and [2]
セキュリティ上の考慮事項：C.F。、セクション7関連する出版物：C.F。、[1]、および[2]
Contact Information: Ward Harold <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。、[5]のセクション3で定義されている「ジェネリックURI」構文
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
意図された使用法：ビープセッションがプライバシーのために調整された後、XML-RPCのビーププロファイルを使用して利用可能にされた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>
Author/Change controller: the IESG
著者/変更コントローラー：IESG
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
提案された名前：XML-RPCオーバービープ
Short name: xmlrpc-beep
短い名前：xmlrpc-beep
Contact Information: Ward Harold <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 cipherを使用）
for both: http://iana.org/beep/TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side certificates)
両方の場合：http：//iana.org/beep/tls（tls_rsa_with_3des_ede_cbc_sha ciphaを使用するクライアント側の証明書をサポートする）
Further, implementations may choose to offer MIME-based security services providing message integrity and confidentiality, such as OpenPGP [8] or S/MIME [10].
さらに、実装は、OpenPGP [8]やS/MIME [10]などのメッセージの完全性と機密性を提供するMIMEベースのセキュリティサービスを提供することを選択できます。
Regardless, consult [2]'s Section 9 for a discussion of BEEP-specific security issues.
とにかく、ビープ特有のセキュリティ問題の議論については、[2]のセクション9に相談してください。
[1] Winer, D., "XML-RPC Specification", January 1999, http://www.xmlrpc.com/spec
[1] Winer、D。、「XML-RPC仕様」、1999年1月、http：//www.xmlrpc.com/spec
[2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[2] Rose、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。and T. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[4] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[4] Murata、M.、St。Laurent、S。およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
[5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[5] Berners-Lee、T.、Fielding、R。and L. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、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。and 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.、Carpenter、B。and L. Masinter、「URLのリテラルIPv6アドレスの形式」、RFC 2732、1999年12月。
[8] Elkins, M., Del Torto, D., Levien, R. and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
[8] Elkins、M.、Del Torto、D.、Levien、R。and T. Roessler、「Mime Security with OpenPGP」、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. Rose、「ブロック拡張可能な交換プロトコル（BEEP）のSimple Object Access Protocol（SOAP）を使用」、RFC 3288、2002年6月。
This document is based, in part, on Using SOAP in BEEP [11] and the author gratefully acknowledges the contributions of Marshall Rose
このドキュメントは、一部はビープ音で石鹸を使用することに基づいており[11]、著者はマーシャルローズの貢献に感謝して認めています
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
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)
IANAは、セクション6.2とセクション6.3でそれぞれ指定されているように、「XMLRPC.BEEP」および「XMLRPC.BEEPS」をURLスキームとして登録しています。（参照：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で指定されているように、「XML-RPCオーバービープ」をTCPポート番号（602）として登録しています。（参照：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
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。