Network Working Group W. Harold
Request for Comments: 3529 IBM
Category: Experimental April 2003
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)
在块中使用可扩展标记语言远程过程调用（XML-RPC）可扩展交换协议（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.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
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是一种可扩展的标记语言远程过程调用协议，可在Internet上工作。它为使用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.
本文档指定了如何使用块可扩展交换协议（BEEP）在客户端和服务器之间传输以XML-RPC格式编码的消息。
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
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
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].
此备忘录指定如何使用BEEP配置文件传输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规范定义的“methodCall”和“methodResponse”元素[1]。此外，术语“对等”、“客户端”、“服务器”和“一对一”在BEEP上下文中使用。具体而言，[2]的第2.1节和第2.1.1节讨论了BEEP角色和交换样式。
The BEEP profile for XML-RPC is identified as
XML-RPC的BEEP配置文件标识为
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.,
在BEEP中，当成功创建第一个通道时，“start”元素中的“serverName”属性标识与充当服务器角色的对等方关联的“虚拟主机”，例如。，
<start number='1' serverName='stateserver.example.com'>
<profile uri='http://iana.org/beep/transient/xmlrpc' />
</start>
<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的BEEP配置文件中有两种状态：“启动”、配置文件的初始状态和“就绪”：
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 在“boot”状态下，请求创建通道的对等方发送“bootmsg”（在通道初始化期间或在“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 在“就绪”状态下，发起方通过发送包含请求的“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
resource 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])
引导消息包含一个强制属性：“resource”，这与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>
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>
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的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: <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>
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的BEEP配置文件使用媒体类型“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: 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
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: 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的BEEP配置文件使用一对一的交换来实现这一点，其中客户端发送包含请求的“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的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.
此备忘录定义了两个URL方案，“xmlrpc.beep”和“xmlrpc.beeps”，用于标识通过TCP上的beep使用XML-RPC。请注意，目前还没有定义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 path组件映射到概要文件初始化期间发送的引导消息的“资源”组件（如果不存在，则默认为“/”。
The values of both the scheme and authority components are case-insensitive.
scheme和authority组件的值都不区分大小写。
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 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._tcp.stateserver.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地址。如果存在端口号，则直接使用该端口号；否则，IANA将为第6.4节中的注册分配使用的端口号。
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地址，但如果在“xmlrpc.beep”URL中使用文字IPv6地址，则该地址必须符合[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).
“xmlrpc.beep”URL方案在所有方面都与第5.1节中指定的“xmlrpc.beep”URL方案相同，但在启动XML-RPC的beep配置文件之前，必须对beep会话进行隐私调优。特别要注意的是，两种URL方案使用第5.1.1节中规定的相同算法和地址解析参数（例如，SRV查找使用相同的服务名称，TCP使用相同的端口号，等等）。
There are two ways to perform privacy tuning on a BEEP session, either:
有两种方法可以在蜂鸣音会话上执行隐私调整，或者：
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的授权组件是否与服务器证书中显示的服务器标识相匹配。[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: <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: <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
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
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
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
Profile Identification: 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
Messages in positive replies: bootrpy, methodResponse
正面回复中的消息：bootrpy、methodResponse
Messages in negative replies: error
否定回复中的消息：错误
Messages in one-to-many exchanges: none
一对多交换中的消息：无
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>
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的BEEP配置文件提供的XML-RPC资源
Applications using this scheme: c.f., "Intended usage", above
使用此方案的应用：c.f.，“预期用途”，如上
Interoperability considerations: 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>
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
预期用途：标识在BEEP会话被调优为隐私后，使用XML-RPC的BEEP配置文件提供的XML-RPC资源
Applications using this scheme: c.f., "Intended usage", above
使用此方案的应用：c.f.，“预期用途”，如上
Interoperability considerations: 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>
Contact Information: Ward Harold <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 注册：XML-RPC over BEEP的系统（众所周知）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 beep
Contact Information: Ward Harold <wharold@us.ibm.com>
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
for authentication: http://iana.org/beep/SASL/DIGEST-MD5
for confidentiality: http://iana.org/beep/TLS (using the
TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher)
for confidentiality: http://iana.org/beep/TLS (using the
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)
for both: http://iana.org/beep/TLS (using the
TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side
certificates)
Further, implementations may choose to offer MIME-based security services providing message integrity and confidentiality, such as OpenPGP [8] or S/MIME [10].
此外，实现可以选择提供基于MIME的安全服务，提供消息完整性和机密性，例如OpenPGP[8]或S/MIME[10]。
Regardless, consult [2]'s Section 9 for a discussion of BEEP-specific security issues.
无论如何，请参阅[2]的第9节，以讨论特定于BEEP的安全问题。
[1] Winer, D., "XML-RPC Specification", January 1999,
http://www.xmlrpc.com/spec
[1] Winer, D., "XML-RPC Specification", January 1999,
http://www.xmlrpc.com/spec
[2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[2] Rose，M.，“块可扩展交换协议核心”，RFC 30802001年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.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，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媒体类型”，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.和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.，Carpenter，B.和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.和T.Roessler，“OpenPGP的MIME安全性”，RFC 3156，2001年8月。
[9] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
[9] Newman，C.“将TLS与IMAP、POP3和ACAP一起使用”，RFC 25951999年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）中使用简单对象访问协议（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
本文档部分基于在BEEP[11]中使用SOAP，作者衷心感谢Marshall Rose的贡献
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)
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)
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)
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)
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
Phone: +1 512 838 3622
EMail: 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编辑功能的资金目前由互联网协会提供。