Network Working Group E. O'Tuathail
Request for Comments: 4227 Clipcode.com
Obsoletes: 3288 M. Rose
Category: Standards Track Dover Beach Consulting, Inc.
January 2006
Network Working Group E. O'Tuathail
Request for Comments: 4227 Clipcode.com
Obsoletes: 3288 M. Rose
Category: Standards Track Dover Beach Consulting, Inc.
January 2006
Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)
在块中使用简单对象访问协议（SOAP）可扩展交换协议（BEEP）
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This memo specifies a Simple Object Access Protocol (SOAP) binding to the Blocks Extensible Exchange Protocol (BEEP) core. A SOAP binding describes how SOAP messages are transmitted in the network.
此备忘录指定绑定到块可扩展交换协议（BEEP）核心的简单对象访问协议（SOAP）。SOAP绑定描述了SOAP消息在网络中的传输方式。
The SOAP is an XML-based (eXtensible Markup Language) messaging protocol used to implement a wide variety of distributed messaging models. It defines a message format and describes a variety of message patterns, including, but not limited to, Remote Procedure Calling (RPC), asynchronous event notification, unacknowledged messages, and forwarding via SOAP intermediaries.
SOAP是一种基于XML（可扩展标记语言）的消息传递协议，用于实现各种分布式消息传递模型。它定义了一种消息格式并描述了各种消息模式，包括但不限于远程过程调用（RPC）、异步事件通知、未确认的消息以及通过SOAP中介进行转发。
Table of Contents
目录
1. Introduction ....................................................3
2. BEEP Profile Identification .....................................3
2.1. Profile Initialization .....................................4
3. SOAP Message Packages ...........................................6
4. SOAP Message Patterns ...........................................8
4.1. One-Way Message ............................................8
4.2. Request-Response Exchange ..................................8
4.3. Request/N-Responses Exchange ...............................8
4.4. Error Handling .............................................9
5. SOAP Protocol Binding Framework Conformance .....................9
5.1. Binding Name ...............................................9
5.2. Base URI ...................................................9
5.3. Supported SOAP Message Exchange Patterns ...................9
5.4. Supported Features .........................................9
5.5. MEP Operation .............................................10
5.5.1. Behavior of Requesting SOAP Node ...................10
5.5.1.1. Init ......................................10
5.5.1.2. Requesting ................................10
5.5.1.3. Sending+Receiving .........................10
5.5.1.4. Success and Fail ..........................11
5.5.2. Behavior of Responding SOAP Node ...................11
5.5.2.1. Init ......................................11
5.5.2.2. Receiving .................................11
5.5.2.3. Receiving+Sending .........................11
5.5.2.4. Success and Fail ..........................11
6. URL Schemes ....................................................11
6.1. The soap.beep URL Scheme ..................................11
6.1.1. Resolving IP/TCP Address Information ...............12
6.2. The soap.beeps URL Scheme .................................13
7. Registration Templates .........................................13
7.1. SOAP Profile Feature Registration Template ................13
8. Initial Registrations ..........................................13
8.1. Registration: The SOAP Profile ............................13
8.2. Registration: The soap.beep URL Scheme ....................14
8.3. Registration: The soap.beeps URL Scheme ...................14
8.4. Registration: The System (Well-Known) TCP Port
Number for SOAP ...........................................15
9. Security Considerations ........................................15
10. IANA Considerations ...........................................16
11. Changes from RFC 3288 .........................................16
12. Acknowledgements ..............................................17
13. References ....................................................17
13.1. Normative References .....................................17
13.2. Informative References ...................................18
A. Appendix - SOAP with Attachments (Informative) .................19
1. Introduction ....................................................3
2. BEEP Profile Identification .....................................3
2.1. Profile Initialization .....................................4
3. SOAP Message Packages ...........................................6
4. SOAP Message Patterns ...........................................8
4.1. One-Way Message ............................................8
4.2. Request-Response Exchange ..................................8
4.3. Request/N-Responses Exchange ...............................8
4.4. Error Handling .............................................9
5. SOAP Protocol Binding Framework Conformance .....................9
5.1. Binding Name ...............................................9
5.2. Base URI ...................................................9
5.3. Supported SOAP Message Exchange Patterns ...................9
5.4. Supported Features .........................................9
5.5. MEP Operation .............................................10
5.5.1. Behavior of Requesting SOAP Node ...................10
5.5.1.1. Init ......................................10
5.5.1.2. Requesting ................................10
5.5.1.3. Sending+Receiving .........................10
5.5.1.4. Success and Fail ..........................11
5.5.2. Behavior of Responding SOAP Node ...................11
5.5.2.1. Init ......................................11
5.5.2.2. Receiving .................................11
5.5.2.3. Receiving+Sending .........................11
5.5.2.4. Success and Fail ..........................11
6. URL Schemes ....................................................11
6.1. The soap.beep URL Scheme ..................................11
6.1.1. Resolving IP/TCP Address Information ...............12
6.2. The soap.beeps URL Scheme .................................13
7. Registration Templates .........................................13
7.1. SOAP Profile Feature Registration Template ................13
8. Initial Registrations ..........................................13
8.1. Registration: The SOAP Profile ............................13
8.2. Registration: The soap.beep URL Scheme ....................14
8.3. Registration: The soap.beeps URL Scheme ...................14
8.4. Registration: The System (Well-Known) TCP Port
Number for SOAP ...........................................15
9. Security Considerations ........................................15
10. IANA Considerations ...........................................16
11. Changes from RFC 3288 .........................................16
12. Acknowledgements ..............................................17
13. References ....................................................17
13.1. Normative References .....................................17
13.2. Informative References ...................................18
A. Appendix - SOAP with Attachments (Informative) .................19
This memo specifies how SOAP envelopes [15] are transmitted using a BEEP profile [1]. Conforming implementations MUST support SOAP version 1.2 [15] and MAY support other versions, such as SOAP version 1.1 [17]. This memo specifies how SOAP envelopes [15] are transmitted using a BEEP profile [1]. Unlike its predecessor, RFC3288 [16], this memo does not mandate the use of SOAP version 1.1.
此备忘录指定如何使用蜂鸣配置文件[1]传输SOAP信封[15]。一致性实现必须支持SOAP版本1.2[15]，并可能支持其他版本，如SOAP版本1.1[17]。此备忘录指定如何使用蜂鸣配置文件[1]传输SOAP信封[15]。与其前身RFC3288[16]不同，本备忘录不强制使用SOAP版本1.1。
Throughout this memo, the term "envelope" refers to the top-level element exchanged by SOAP senders and receivers. For example, when referring to SOAP version 1.2, the term "envelope" refers to the "Envelope" element defined in Section 5.1 of [2]. Furthermore, the terms "peer", "client", "server", "one-to-one", and "one-to-many" are used in the context of BEEP. In particular, Sections 2.1 and 2.1.1 of [1] discuss BEEP roles and exchange styles.
在本备忘录中，术语“信封”指的是SOAP发送者和接收者交换的顶级元素。例如，当提到SOAP版本1.2时，术语“信封”指的是[2]第5.1节中定义的“信封”元素。此外，术语“对等”、“客户端”、“服务器”、“一对一”和“一对多”在BEEP上下文中使用。具体而言，[1]的第2.1节和第2.1.1节讨论了BEEP角色和交换样式。
The BEEP profile for SOAP is identified as
SOAP的蜂鸣声配置文件标识为
http://iana.org/beep/soap/VERSION
http://iana.org/beep/soap/VERSION
in the BEEP "profile" element during channel creation. where "VERSION" refers to the numeric version of the SOAP specification.
在频道创建过程中，在“配置文件”元素中。其中“版本”是指SOAP规范的数字版本。
For example,
例如
http://iana.org/beep/soap/1.2
http://iana.org/beep/soap/1.2
refers to version 1.2.
参考1.2版。
Note that RFC 3288 [16] used
请注意，使用了RFC 3288[16]
http://iana.org/beep/soap
http://iana.org/beep/soap
for the purposes of profile identification for SOAP version 1.1 envelopes [17]. If an implementation of this memo chooses to implement SOAP version 1.1, then it should support both this Uniform Resource Identifier (URI) for profile identification as well as "http://iana.org/beep/soap/1.1".
用于SOAP版本1.1信封的配置文件标识[17]。如果此备忘录的一个实现选择实现SOAP版本1.1，那么它应该支持配置文件标识的统一资源标识符（URI）以及“http://iana.org/beep/soap/1.1".
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='stockquoteserver.example.com'>
<profile uri='http://iana.org/beep/soap/1.2' />
</start>
<start number='1' serverName='stockquoteserver.example.com'>
<profile uri='http://iana.org/beep/soap/1.2' />
</start>
The "serverName" attribute is analogous to HTTP's "Host" request-header field (cf. Section 14.23 of [4]).
“serverName”属性类似于HTTP的“主机”请求头字段（参见[4]第14.23节）。
There are two states in the BEEP profile for SOAP, "boot" and "ready":
SOAP的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 an "RPY" message), then the "ready" state is entered
* 如果另一个对等方发送“bootrpy”（在通道初始化期间或在“RPY”消息中），则进入“就绪”状态
* Otherwise, the other peer sends an "error" (either during channel initialization or in an "ERR" message), then no state change occurs.
* 否则，另一个对等方发送“错误”（在通道初始化期间或在“ERR”消息中），则不会发生状态更改。
o In the "ready" state, either peer begins a SOAP message pattern by sending a "MSG" message containing an envelope. The other peer completes the message pattern either by
o 在“就绪”状态下，任一对等方通过发送包含信封的“MSG”消息开始SOAP消息模式。另一个对等方通过以下方式完成消息模式
* sending back an "RPY" message containing an envelope or
* 发送回包含信封或信封的“RPY”消息
* sending back zero or more "ANS" messages, each containing an envelope, followed by a "NUL" message.
* 发送回零条或多条“ANS”消息，每条消息包含一个信封，后跟一条“NUL”消息。
Regardless, no state change occurs.
无论如何，不会发生状态更改。
The boot message is used for two purposes:
启动消息用于两个目的：
resource identification: each channel bound to the BEEP profile for SOAP provides access to a single resource (a network data object or service).
资源标识：绑定到SOAP的BEEP配置文件的每个通道都提供对单个资源（网络数据对象或服务）的访问。
feature negotiation: if new features of SOAP (such as compression) emerge, their use can be negotiated.
特性协商：如果SOAP的新特性（如压缩）出现，可以协商它们的使用。
The DTD syntax for the boot message and its response are:
引导消息及其响应的DTD语法为：
<!ELEMENT bootmsg EMPTY>
<!ATTLIST bootmsg
resource CDATA #REQUIRED
features NMTOKENS "">
<!ELEMENT bootmsg EMPTY>
<!ATTLIST bootmsg
resource CDATA #REQUIRED
features NMTOKENS "">
<!ELEMENT bootrpy EMPTY>
<!ATTLIST bootrpy
features NMTOKENS "">
<!ELEMENT bootrpy EMPTY>
<!ATTLIST bootrpy
features NMTOKENS "">
The boot message contains a mandatory and an optional attribute:
启动消息包含一个强制属性和一个可选属性：
o the "resource" attribute, which is analogous to HTTP's "abs_path" Request-URI parameter (cf. Section 5.1.2 of [4]) and
o “resource”属性，类似于HTTP的“abs_path”请求URI参数（参见[4]第5.1.2节），以及
o the "features" attribute, which, if present, contains one or more feature tokens, each indicating an optional feature of the BEEP profile for SOAP that is being requested for possible use over the channel.
o “features”属性（如果存在）包含一个或多个feature标记，每个标记表示正在请求通过通道使用的SOAP的蜂鸣配置文件的可选功能。
Section 7.1 defines a registration template for optional features.
第7.1节定义了可选功能的注册模板。
If the peer acting in the server role recognizes the requested resource, it replies with the boot response that contains one optional attribute:
如果担任服务器角色的对等方识别请求的资源，它将使用包含一个可选属性的引导响应进行响应：
o The "features" attribute, if present, contains a subset of the feature tokens in the boot message, indicating which features may be used over the channel. (If not present or empty, then no features may be used.)
o “features”属性（如果存在）在引导消息中包含功能令牌的子集，指示哪些功能可以通过通道使用。（如果不存在或为空，则不能使用任何功能。）
Otherwise, if the boot message is improperly formed, or if the requested resource is not recognized, the peer acting in the server role replies with an error message (cf. Section 7.1 of [1]). Typically, the boot message and its response are exchanged during channel initialization (cf. Section 2.3.1.2 of [1]).
否则，如果启动消息格式不正确，或者请求的资源无法识别，则以服务器角色运行的对等方会回复错误消息（参见[1]第7.1节）。通常，引导消息及其响应在通道初始化期间交换（参见[1]第2.3.1.2节）。
For example, here the boot message and its response are exchanged during channel initialization:
例如，此处引导消息及其响应在通道初始化期间交换：
C: <start number='1' serverName='stockquoteserver.example.com'>
C: <profile uri='http://iana.org/beep/soap/1.2'>
C: <![CDATA[<bootmsg resource='/StockQuote' />]]>
C: </profile>
C: </start>
C: <start number='1' serverName='stockquoteserver.example.com'>
C: <profile uri='http://iana.org/beep/soap/1.2'>
C: <![CDATA[<bootmsg resource='/StockQuote' />]]>
C: </profile>
C: </start>
S: <profile uri='http://iana.org/beep/soap/1.2'>
S: <![CDATA[<bootrpy />]]>
S: </profile>
S: <profile uri='http://iana.org/beep/soap/1.2'>
S: <![CDATA[<bootrpy />]]>
S: </profile>
The channel bound to the BEEP profile for SOAP is now in the "ready" state.
绑定到SOAP的BEEP配置文件的通道现在处于“就绪”状态。
Alternatively, here is an example in which the boot exchange is unsuccessful:
或者，下面是引导交换失败的示例：
C: <start number='1' serverName='stockquoteserver.example.com'>
C: <profile uri='http://iana.org/beep/soap/1.2'>
C: <![CDATA[<bootmsg resource='/StockPick' />]]>
C: </profile>
C: </start>
C: <start number='1' serverName='stockquoteserver.example.com'>
C: <profile uri='http://iana.org/beep/soap/1.2'>
C: <![CDATA[<bootmsg resource='/StockPick' />]]>
C: </profile>
C: </start>
S: <profile uri='http://iana.org/beep/soap/1.2'>
S: <![CDATA[<error code='550'>resource not
S: supported</error>]]>
S: </profile>
S: <profile uri='http://iana.org/beep/soap/1.2'>
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 SOAP transmits envelopes encoded as UTF-8 and SHOULD use the media type "application/soap+xml" [5], e.g.,
SOAP的BEEP配置文件传输编码为UTF-8的信封，并应使用媒体类型“application/SOAP+xml”[5]，例如。，
MSG 1 1 . 0 284 Content-Type: application/soap+xml
味精1。0 284内容类型：应用程序/soap+xml
<env:Envelope
xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<m:GetLastTradePrice xmlns:m="Some-URI" />
</env:Header>
<env:Body>
<symbol xmlns:p="Some-URI" >DIS</symbol>
</env:Body>
</env:Envelope>
END
<env:Envelope
xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<m:GetLastTradePrice xmlns:m="Some-URI" />
</env:Header>
<env:Body>
<symbol xmlns:p="Some-URI" >DIS</symbol>
</env:Body>
</env:Envelope>
END
To provide compatibility with RFC 3288 [16], it MAY use the media type "application/xml" [6].
为了提供与RFC 3288[16]的兼容性，它可以使用媒体类型“application/xml”[6]。
In addition, an implementation of the BEEP profile for SOAP MAY support transmission of envelopes using the MTOM [7] / XOP [8] packaging technique, e.g.,
此外，SOAP的BEEP配置文件的实现可支持使用MTOM[7]/XOP[8]封装技术传输信封，例如。，
MSG 1 2 . 283 1436
MIME-Version: 1.0
Content-Type: Multipart/Related;boundary=MIME_boundary;
type="application/xop+xml";
start="<mymessage.xml@example.org>";
startinfo="application/soap+xml; action=
Content-Description: A SOAP message with my pic and sig in it
MSG 1 2 . 283 1436
MIME-Version: 1.0
Content-Type: Multipart/Related;boundary=MIME_boundary;
type="application/xop+xml";
start="<mymessage.xml@example.org>";
startinfo="application/soap+xml; action=
Content-Description: A SOAP message with my pic and sig in it
--MIME_boundary
Content-Type: application/xop+xml;
charset=UTF-8;
type="application/soap+xml; action=
Content-Transfer-Encoding: 8bit
Content-ID: <mymessage.xml@example.org>
--MIME_boundary
Content-Type: application/xop+xml;
charset=UTF-8;
type="application/soap+xml; action=
Content-Transfer-Encoding: 8bit
Content-ID: <mymessage.xml@example.org>
<soap:Envelope
xmlns:soap='http://www.w3.org/2003/05/soap-envelope'
xmlns:xmlmime='http://www.w3.org/2004/11/xmlmime'>
<soap:Body>
<m:data xmlns:m='http://example.org/stuff'>
<m:photo
xmlmime:contentType='image/png'><xop:Include
xmlns:xop='http://www.w3.org/2004/08/xop/include'
href='cid:http://example.org/me.png'/></m:photo>
<m:sig
xmlmime:contentType='application/pkcs7-signature'><xop:Include
xmlns:xop='http://www.w3.org/2004/08/xop/include'
href='cid:http://example.org/my.hsh'/></m:sig>
</m:data>
</soap:Body>
</soap:Envelope>
<soap:Envelope
xmlns:soap='http://www.w3.org/2003/05/soap-envelope'
xmlns:xmlmime='http://www.w3.org/2004/11/xmlmime'>
<soap:Body>
<m:data xmlns:m='http://example.org/stuff'>
<m:photo
xmlmime:contentType='image/png'><xop:Include
xmlns:xop='http://www.w3.org/2004/08/xop/include'
href='cid:http://example.org/me.png'/></m:photo>
<m:sig
xmlmime:contentType='application/pkcs7-signature'><xop:Include
xmlns:xop='http://www.w3.org/2004/08/xop/include'
href='cid:http://example.org/my.hsh'/></m:sig>
</m:data>
</soap:Body>
</soap:Envelope>
--MIME_boundary
Content-Type: image/png
Content-Transfer-Encoding: binary
Content-ID: <http://example.org/me.png>
--MIME_boundary
Content-Type: image/png
Content-Transfer-Encoding: binary
Content-ID: <http://example.org/me.png>
// binary octets for png
//png的二进制八位组
--MIME_boundary
Content-Type: application/pkcs7-signature
Content-Transfer-Encoding: binary
Content-ID: <http://example.org/my.hsh>
--MIME_boundary
Content-Type: application/pkcs7-signature
Content-Transfer-Encoding: binary
Content-ID: <http://example.org/my.hsh>
// binary octets for signature
//用于签名的二进制八位组
--MIME_boundary-- END
--MIME_边界—结束
Consult Section 4.1 of XOP [8] for guidance on MIME Multipart/Related usage. Because BEEP provides an 8-bit-wide path, a "transformative" Content-Transfer-Encoding (e.g., "base64" or "quoted-printable") should not be used. Note that MIME [9] requires that the value of the "Content-ID" header be globally unique. As stated in Section 4 of XOP [8], XOP may be used with diverse packaging mechanisms. When an implementation of BEEP in SOAP does support MTOM/XOP, it SHOULD support the MIME Multipart/Related XOP Package format, and MAY support others. Additional formats could, in the future, include XOP package formats specific to BEEP (e.g., sending the attachments on a different channel to the SOAP channel, which would avoid searching for the MIME boundary tags and allows lazy delivery of attachments, delivering them only when really needed.)
有关MIME多部分/相关用法的指导，请参阅XOP[8]的第4.1节。由于BEEP提供8位宽的路径，因此不应使用“转换”内容传输编码（例如，“base64”或“可打印引用”）。注意，MIME[9]要求“Content ID”头的值是全局唯一的。如XOP[8]第4节所述，XOP可与多种包装机制一起使用。当SOAP中的BEEP实现确实支持MTOM/XOP时，它应该支持MIME多部分/相关XOP包格式，并且可能支持其他格式。将来，其他格式可能包括特定于BEEP的XOP包格式（例如，将不同通道上的附件发送到SOAP通道，这将避免搜索MIME边界标记，并允许延迟交付附件，仅在真正需要时交付附件）
A one-way message involves sending a message without any response being returned.
单向消息包括在不返回任何响应的情况下发送消息。
The BEEP profile for SOAP achieves this using a one-to-many exchange, in which the client sends a "MSG" message containing an envelope, and the server immediately sends back a "NUL" message, before processing the contents of the envelope.
SOAP的BEEP配置文件使用一对多交换来实现这一点，其中客户端发送包含信封的“MSG”消息，服务器在处理信封内容之前立即发回“NUL”消息。
A request/response exchange involves sending a request, which results in a response being returned.
请求/响应交换涉及发送请求，从而返回响应。
The BEEP profile for SOAP achieves this using a one-to-one exchange, in which the client sends a "MSG" message containing an envelope, and the server sends back a "RPY" message containing an envelope.
SOAP的BEEP配置文件使用一对一的交换来实现这一点，在这种交换中，客户端发送包含信封的“MSG”消息，服务器发送回包含信封的“RPY”消息。
A request/N-responses exchange involves sending a request, which results in zero or more responses being returned.
请求/N-responses交换涉及发送请求，这将导致返回零个或多个响应。
The BEEP profile for SOAP achieves this using a one-to-many exchange, in which the client sends a "MSG" message containing an envelope, and the server sends back zero or more "ANS" messages, each containing an envelope, followed by a "NUL" message.
SOAP的BEEP配置文件使用一对多交换来实现这一点，在这种交换中，客户机发送一条包含信封的“MSG”消息，服务器发送回零条或多条“ANS”消息，每条消息包含一个信封，然后是一条“NUL”消息。
The BEEP profile for SOAP does not use the "ERR" message for SOAP faults. When performing one-to-one exchanges, whatever SOAP response (including SOAP faults) generated by the server is always returned in the "RPY" message. When performing one-to-many exchanges, whatever SOAP response (including SOAP faults) generated by the server is always returned in the "ANS" messages.
SOAP的BEEP配置文件不使用SOAP故障的“ERR”消息。在执行一对一交换时，服务器生成的任何SOAP响应（包括SOAP故障）总是在“RPY”消息中返回。在执行一对多交换时，服务器生成的任何SOAP响应（包括SOAP故障）总是在“ANS”消息中返回。
If there is an error with the BEEP message unrelated to the SOAP envelope (e.g., poorly formed MIME message or MIME Content-Type not supported), then the server responds with an ERR message (see Section 7.1 of [1]) with an appropriate reply code (e.g., see Section 8 of [1]).
如果与SOAP信封无关的BEEP消息出现错误（例如，格式错误的MIME消息或MIME内容类型不受支持），则服务器会以错误消息（参见[1]的第7.1节）和适当的回复代码（例如，参见[1]的第8节）进行响应。
This binding is identified by a URI that is exactly the same as the profile URI for BEEP in SOAP (see Section 2).
此绑定由一个URI标识，该URI与SOAP中BEEP的配置文件URI完全相同（请参见第2节）。
The Base URI for the SOAP envelope is the URI of the resource identified in the bootmsg.
SOAP信封的基本URI是bootmsg中标识的资源的URI。
An implementation of this binding MUST support the following SOAP Message Exchange Pattern (MEP):
此绑定的实现必须支持以下SOAP消息交换模式（MEP）：
o "http://www.w3.org/2003/05/soap/mep/request-response/" (see
Section 6.2 of [3])
o "http://www.w3.org/2003/05/soap/mep/request-response/" (see
Section 6.2 of [3])
An implementation of this binding MAY support the following feature: "http://www.w3.org/2003/05/soap/features/action/" (see Section 6.5 of [3].)
此绑定的实现可能支持以下功能：http://www.w3.org/2003/05/soap/features/action/“（见[3]第6.5节）
For binding instances conforming to this specification:
对于符合本规范的绑定实例：
o A SOAP node instantiated at the BEEP peer that initiates the message exchange may assume the role (i.e., the property http:// www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role ) of "RequestingSOAPNode".
o 在发起消息交换的BEEP对等点处实例化的SOAP节点可能承担“RequestingSOAPNode”的角色（即，属性http://www.w3.org/2003/05/SOAP/bindingFramework/ExchangeContext/role）。
o A SOAP node instantiated at the other BEEP peer may assume the role (i.e., the property http://www.w3.org/2003/05/soap/ bindingFramework/ExchangeContext/Role) of "RespondingSOAPNode".
o 在另一个BEEP对等点实例化的SOAP节点可以承担该角色（即属性）http://www.w3.org/2003/05/soap/ “RespondingSOAPNode”的bindingFramework/ExchangeContext/Role）。
The overall flow of the behavior of a requesting SOAP node follows a state machine description consistent with Section 6.2 of [3].
请求SOAP节点行为的整体流程遵循与[3]第6.2节一致的状态机描述。
In order to avoid deadlock during streaming (see Section 6.2.3 of [3]), the requesting SOAP node MUST be able to process incoming SOAP response information while the SOAP request is still being transmitted.
为了避免流传输期间出现死锁（参见[3]第6.2.3节），请求SOAP节点必须能够在SOAP请求仍在传输时处理传入的SOAP响应信息。
In the "Init" state, a BEEP message is formulated according to Section 3, transmission of the message begins, and then the state changes to "Requesting".
在“Init”状态下，根据第3节形成一条蜂鸣声消息，消息的传输开始，然后状态变为“请求”。
In the "Requesting" state, more of the request message is transmitted and the arrival of the response is awaited. When the beginning of the response message is received, if it is a BEEP ERR message, then the state transitions to "Fail"; otherwise, the state transitions to "Sending+Receiving".
在“请求”状态下，发送更多的请求消息，并等待响应的到来。当收到响应消息的开头时，如果是蜂鸣错误消息，则状态转换为“失败”；否则，状态转换为“发送+接收”。
In the "Sending+Receiving" state, the transmission of the request message and receiving of the response message are completed. The response message is assumed to contain a SOAP envelope serialized according to the rules for carrying SOAP messages in the media type given in the Content-Type header field. Once the receipt of the response is completed, the state transitions to "Success".
在“发送+接收”状态下，完成请求消息的发送和响应消息的接收。假设响应消息包含一个SOAP信封，该信封根据内容类型标头字段中给定的媒体类型中承载SOAP消息的规则进行序列化。收到响应后，状态将转换为“成功”。
"Success" and "Fail" are the terminal states for the state machine.
“成功”和“失败”是状态机的终端状态。
The overall flow of the behavior of a responding SOAP node follows a state machine description consistent with Section 6.2 of [3]
响应SOAP节点行为的整体流程遵循与[3]第6.2节一致的状态机描述
In the "Init" state, the binding awaits the start of the inbound request. In this state, it may only generate ERR messages (in accordance with Section 4.4).
在“Init”状态下，绑定等待入站请求的启动。在此状态下，它只能生成错误消息（根据第4.4节）。
The binding begins to receive the request message and prepares the start of the response, in accordance with Section 3. When ready to transmit the response, the state transitions to "Receiving+Sending".
根据第3节，绑定开始接收请求消息并准备开始响应。准备发送响应时，状态转换为“接收+发送”。
The binding completes the receiving of the request and sending of the response and then transitions to "Success" state.
绑定完成请求的接收和响应的发送，然后转换到“成功”状态。
"Success" and "Fail" are the terminal states that indicate completion of the message exchange.
“成功”和“失败”是表示消息交换完成的终端状态。
This memo defines two URL schemes, "soap.beep" and "soap.beeps", which identify the use of SOAP over BEEP over TCP. Note that, at present, a "generic" URL scheme for SOAP is not defined.
此备忘录定义了两个URL方案，“soap.beep”和“soap.beep”，它们标识了通过TCP使用soap over beep。请注意，目前尚未定义SOAP的“通用”URL方案。
The "soap.beep" URL scheme uses the "generic URI" syntax defined in Section 3 of [10], specifically:
“soap.beep”URL方案使用[10]第3节中定义的“通用URI”语法，具体如下：
o the value "soap.beep" is used for the scheme component and
o 值“soap.beep”用于scheme组件和
o the server-based naming authority defined in Section 3.2.2 of [10] is used for the authority component.
o [10]第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
soap.beep://stockquoteserver.example.com/StockQuote
soap.beep://stockquoteserver.example.com/StockQuote
might result in the example shown in Section 2.1.
可能导致第2.1节中所示的示例。
The "soap.beep" URL scheme indicates the use of the BEEP profile for SOAP running over TCP/IP.
“soap.beep”URL方案表示对通过TCP/IP运行的soap使用beep配置文件。
If the authority component contains a domain name and a port number, e.g.,
如果授权组件包含域名和端口号，例如。，
soap.beep://stockquoteserver.example.com:1026
soap.beep://stockquoteserver.example.com:1026
then the DNS is queried for the A Resource Records 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.,
如果授权组件包含域名而没有端口号，例如。，
soap.beep://stockquoteserver.example.com
soap.beep://stockquoteserver.example.com
the Service Record algorithm [11] is used with a service parameter of "soap-beep" and a protocol parameter of "tcp" to determine the IP/TCP addressing information. If no appropriate SRV RRs are found (e.g., for "_soap-beep._tcp.stockquoteserver.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 8.4.
服务记录算法[11]与服务参数“soap beep”和协议参数“tcp”一起使用，以确定IP/tcp寻址信息。如果未找到合适的SRV RRs（例如，对于“\u soap-beep.\u tcp.stockquoteserver.example.com”），则会查询DNS以查找对应于域名的RRs，并且IANA会为第8.4节中的注册分配所用的端口号。
If the authority component contains an IP address, e.g.,
如果授权组件包含IP地址，例如。，
soap.beep://192.0.2.0:1026
soap.beep://192.0.2.0: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 8.4.
然后不查询DNS，直接使用IP地址。如果存在端口号，则直接使用该端口号；否则，IANA将为第8.4节中的注册分配使用的端口号。
While the use of literal IPv6 addresses in URLs is discouraged, if a literal IPv6 address is used in a "soap.beep" URL, it must conform to the syntax specified in [12].
虽然不鼓励在URL中使用文字IPv6地址，但如果在“soap.beep”URL中使用文字IPv6地址，则该地址必须符合[12]中指定的语法。
The "soap.beeps" URL scheme is identical, in all ways, to the "soap.beep" URL scheme specified in Section 6.1, with the exception that prior to starting the BEEP profile for SOAP, 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 6.1.1 (e.g., the same service name for SRV lookups, the same port number for TCP, and so on).
“soap.beep”URL方案在所有方面都与第6.1节中指定的“soap.beep”URL方案相同，但在启动soap的beep配置文件之前，必须对beep会话进行隐私调整。特别要注意的是，两种URL方案使用第6.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 支持传输安全的用户身份验证配置文件可能已成功启动。
Regardless, upon completion of the negotiation process, a tuning reset occurs in which both BEEP peers issue a new greeting. Consult Section 3 of [1] for an example of how a BEEP peer may choose to issue different greetings based on whether privacy is in use.
无论如何，在协商过程完成后，会发生一次调整重置，其中两个BEEP对等方发出一个新的问候语。请参阅[1]第3节，了解蜂鸣节点如何根据是否使用隐私权选择发出不同问候语的示例。
When a feature for the BEEP profile for SOAP is registered, the following information is supplied:
注册SOAP的BEEP配置文件的功能时，将提供以下信息：
Feature Identification: specify a string that identifies this feature. Unless the feature is registered with the IANA, the feature's identification must start with "x-".
特征标识：指定标识此特征的字符串。除非该功能已向IANA注册，否则该功能的标识必须以“x-”开头。
Feature Semantics: specify the semantics of the feature.
特征语义：指定特征的语义。
Contact Information: specify the electronic contact information for the author of the feature.
联系信息：指定功能作者的电子联系信息。
Profile Identification: http://iana.org/beep/soap/VERSION
Profile Identification: http://iana.org/beep/soap/VERSION
Messages exchanged during Channel Creation: bootmsg, bootrpy
通道创建期间交换的消息：bootmsg、bootrpy
Messages starting one-to-one exchanges: bootmsg, a SOAP "envelope"
开始一对一交换的消息：bootmsg，一个SOAP“信封”
Messages in positive replies: bootrpy, a SOAP "envelope"
正面回复中的消息：bootrpy，一个SOAP“信封”
Messages in negative replies: error
否定回复中的消息：错误
Messages in one-to-many exchanges: a SOAP "envelope"
一对多交换中的消息：SOAP“信封”
Message Syntax: a SOAP envelope
消息语法：SOAP信封
Message Semantics: corresponds to the relevant SOAP specification, e.g., for SOAP version 1.2, cf. [2].
消息语义：对应于相关的SOAP规范，例如，对于SOAP版本1.2，参见[2]。
Contact Information: Eamon O'Tuathail <eamon.otuathail@clipcode.com>,
Marshall Rose <mrose@dbc.mtview.ca.us>
Contact Information: Eamon O'Tuathail <eamon.otuathail@clipcode.com>,
Marshall Rose <mrose@dbc.mtview.ca.us>
URL scheme name: soap.beep
URL方案名称：soap.beep
URL scheme syntax: cf. Section 6.1
URL方案语法：参见第6.1节
Character encoding considerations: cf. the "generic URI" syntax defined in Section 3 of [10]
字符编码注意事项：参见[10]第3节中定义的“通用URI”语法
Intended usage: identifies a SOAP resource made available using the BEEP profile for SOAP
预期用途：标识使用SOAP的BEEP配置文件提供的SOAP资源
Applications using this scheme: cf. "Intended usage", above
使用此方案的应用：参见上文“预期用途”
Interoperability considerations: n/a
互操作性注意事项：不适用
Security Considerations: cf. Section 9
安全考虑：参见第9节
Relevant Publications: cf. [2] for SOAP version 1.2
相关出版物：参考[2]了解SOAP版本1.2
Contact Information: Eamon O'Tuathail <eamon.otuathail@clipcode.com>,
Marshall Rose <mrose@dbc.mtview.ca.us>
Contact Information: Eamon O'Tuathail <eamon.otuathail@clipcode.com>,
Marshall Rose <mrose@dbc.mtview.ca.us>
Author/Change controller: the IESG
作者/变更控制员：IESG
URL scheme name: soap.beeps
URL方案名称：soap.beeps
URL scheme syntax: cf. Section 6.2
URL方案语法：参见第6.2节
Character encoding considerations: cf. the "generic URI" syntax defined in Section 3 of [10]
字符编码注意事项：参见[10]第3节中定义的“通用URI”语法
Intended usage: identifies a SOAP resource made available using the BEEP profile for SOAP after the BEEP session has been tuned for privacy
预期用途：标识一个SOAP资源，该资源在BEEP会话被调优为隐私之后，使用SOAP的BEEP配置文件可用
Applications using this scheme: cf. "Intended usage", above
使用此方案的应用：参见上文“预期用途”
Interoperability considerations: n/a
互操作性注意事项：不适用
Security Considerations: cf. Section 9
安全考虑：参见第9节
Relevant Publications: cf. [2] for SOAP version 1.2
相关出版物：参考[2]了解SOAP版本1.2
Contact Information: Eamon O'Tuathail <eamon.otuathail@clipcode.com>,
Marshall Rose <mrose@dbc.mtview.ca.us>
Contact Information: Eamon O'Tuathail <eamon.otuathail@clipcode.com>,
Marshall Rose <mrose@dbc.mtview.ca.us>
Author/Change controller: the IESG
作者/变更控制员：IESG
8.4. Registration: The System (Well-Known) TCP Port Number for SOAP over BEEP
8.4. 注册：SOAP over BEEP的系统（众所周知）TCP端口号
Protocol Number: TCP
协议编号：TCP
Message Formats, Types, Opcodes, and Sequences: cf. Section 2.1
消息格式、类型、操作码和序列：参见第2.1节
Functions: cf. [2] for SOAP version 1.2
功能：对于SOAP版本1.2，请参阅[2]
Use of Broadcast/Multicast: none
使用广播/多播：无
Proposed Name: SOAP over BEEP
建议名称：SOAP over BEEP
Short name: soap-beep
短名称：soap-beep
Contact Information: Eamon O'Tuathail <eamon.otuathail@clipcode.com>,
Marshall Rose <mrose@dbc.mtview.ca.us>
Contact Information: Eamon O'Tuathail <eamon.otuathail@clipcode.com>,
Marshall Rose <mrose@dbc.mtview.ca.us>
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_AES_EDE_CBC_SHA cipher)
for confidentiality: http://iana.org/beep/TLS (using the
TLS_RSA_WITH_AES_EDE_CBC_SHA cipher)
for both: http://iana.org/beep/TLS (using the
TLS_RSA_WITH_AES_EDE_CBC_SHA cipher supporting client-side
certificates)
for both: http://iana.org/beep/TLS (using the
TLS_RSA_WITH_AES_EDE_CBC_SHA cipher supporting client-side
certificates)
Furthermore, implementations may choose to offer MIME-based security services providing message integrity and confidentiality, such as OpenPGP [13] or S/MIME [14].
此外，实现可以选择提供基于MIME的安全服务，提供消息完整性和机密性，例如OpenPGP[13]或S/MIME[14]。
Regardless, consult [1]'s Section 9 for a discussion of BEEP-specific security issues.
无论如何，请参阅[1]的第9节，以讨论特定于BEEP的安全问题。
Previously, the IANA registered "http://iana.org/beep/soap" for use
with RFC 3288 [16]. This memo requires that the IANA register a
URI-prefix of
Previously, the IANA registered "http://iana.org/beep/soap" for use
with RFC 3288 [16]. This memo requires that the IANA register a
URI-prefix of
http://iana.org/beep/soap/VERSION
http://iana.org/beep/soap/VERSION
to correspond to the family of profiles defined Section 8.1.
与第8.1节定义的外形系列相对应。
The IANA has registered "soap.beep" and "soap.beeps" as URL schemes, as specified in Section 8.2 and Section 8.3, respectively.
IANA已将“soap.beep”和“soap.beep”分别注册为URL方案，如第8.2节和第8.3节所述。
The IANA has also registered "SOAP over BEEP" as a TCP port number, as specified in Section 8.4.
IANA还将“SOAP over BEEP”注册为TCP端口号，如第8.4节所述。
The IANA now broadens these three registries to support the family of BEEP profiles defined by this URI prefix.
IANA现在扩展了这三个注册中心，以支持由这个URI前缀定义的BEEP配置文件系列。
Finally, the IANA maintains a list of SOAP profile features, cf. Section 7.1. The IESG is responsible for assigning a designated expert to review the specification prior to the IANA making the assignment. Prior to contacting the IESG, developers of SOAP profile features must use the mailing list beepwg@lists.beepcore.org to solicit commentary.
最后，IANA维护一个SOAP配置文件特性列表，参见第7.1节。IESG负责指派一名指定专家在IANA做出指定之前审查规范。在联系IESG之前，SOAP概要文件特性的开发人员必须使用邮件列表beepwg@lists.beepcore.org征求评论。
This memo differs from RFC 3288 [16] in one substantive way: a URL prefix is defined to support a family of BEEP profiles corresponding to different versions of SOAP. Similarly, the IANA registrations in Section 8.1, Section 8.3, and Section 8.4 are updated to reflect this broadening.
此备忘录与RFC 3288[16]有一个实质性的不同之处：定义了一个URL前缀，以支持与不同版本的SOAP相对应的一系列BEEP配置文件。同样，第8.1节、第8.3节和第8.4节中的IANA注册也进行了更新，以反映这种扩展。
Support for W3C MTOM/XOP packaging has been added.
已添加对W3C MTOM/XOP打包的支持。
A new section was added to discuss the distributed state machine of the Request-Response MEP.
增加了一个新的部分来讨论请求-响应MEP的分布式状态机。
In non-substantive ways, a small number of typographical errors were corrected.
以非实质性的方式纠正了少数印刷错误。
The authors gratefully acknowledge the contributions of: Christopher Ferris, Huston Franklin, Alexey Melnikov, Bill Mills, and Roy T. Fielding.
作者衷心感谢克里斯托弗·费里斯、休斯顿·富兰克林、阿列克西·梅尔尼科夫、比尔·米尔斯和罗伊·T·菲尔丁的贡献。
[1] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[1] Rose，M.，“块可扩展交换协议核心”，RFC 30802001年3月。
[2] Nielsen, H., Mendelsohn, N., Gudgin, M., Hadley, M., and J. Moreau, "SOAP Version 1.2 Part 1: Messaging Framework", W3C REC REC-soap12-part1-20030624, June 2003.
[2] Nielsen，H.，Mendelsohn，N.，Gudgin，M.，Hadley，M.，和J.Moreau，“SOAP版本1.2第1部分：消息传递框架”，W3C REC REC-soap12-part1-200306242003年6月。
[3] Nielsen, H., Hadley, M., Moreau, J., Mendelsohn, N., and M. Gudgin, "SOAP Version 1.2 Part 2: Adjuncts", W3C REC REC-soap12-part2-20030624, June 2003.
[3] 尼尔森，H.，哈德利，M.，莫罗，J.，门德尔松，N.，和M.古金，“SOAP版本1.2第2部分：附件”，W3C REC REC-soap12-part2-20030624，2003年6月。
[4] 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.
[4] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[5] Baker, M. and M. Nottingham, "The "application/soap+xml" media type", RFC 3902, September 2004.
[5] 贝克，M.和M.诺丁汉，“应用程序/soap+xml”媒体类型”，RFC 3902，2004年9月。
[6] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[6] Murata，M.，St.Laurent，S.，和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
[7] Nottingham, M., Mendelsohn, N., Gudgin, M., and H. Ruellan, "SOAP Message Transmission Optimization Mechanism", W3C REC REC-soap12-mtom-20050125, January 2005.
[7] 诺丁汉，M.，门德尔松，N.，古德金，M.，和H.鲁兰，“SOAP消息传输优化机制”，W3C REC-soap12-mtom-200501252005年1月。
[8] Nottingham, M., Mendelsohn, N., Gudgin, M., and H. Ruellan, "XML-binary Optimized Packaging", W3C REC REC-xop10-20050125, January 2005.
[8] 诺丁汉，M.，门德尔松，N.，古德金，M.，和H.鲁兰，“XML二进制优化包装”，W3C REC REC-xop10-200501252005年1月。
[9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[9] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
[10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[10] Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[11] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[11] Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[12] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[12] Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[13] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
[13] Elkins，M.，Del Torto，D.，Levien，R.，和T.Roessler，“OpenPGP的MIME安全性”，RFC 3156，2001年8月。
[14] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[14] Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 3851，2004年7月。
[15] Mitra, N., "SOAP Version 1.2 Part 0: Primer", W3C REC REC-soap12-part0-20030624, June 2003.
[15] 米特拉，N.，“SOAP版本1.2第0部分：入门”，W3C REC-soap12-part0-20030624，2003年6月。
[16] O'Tuathail, E. and M. Rose, "Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)", RFC 3288, June 2002.
[16] O'Tuathail，E.和M.Rose，“在块可扩展交换协议（BEEP）中使用简单对象访问协议（SOAP）”，RFC 3288，2002年6月。
[17] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, N., Nielsen, H., Thatte, S., and D. Winer, "Simple Object Access Protocol (SOAP) 1.1", W3C NOTE NOTE-SOAP-20000508, May 2000.
[17] Box，D.，Ehnebuske，D.，Kakivaya，G.，Layman，A.，Mendelsohn，N.，Nielsen，H.，Thatte，S.，和D.Winer，“简单对象访问协议（SOAP）1.1”，W3C NOTE-SOAP-20000508，2000年5月。
[18] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.
[18] Levinson，E.，“MIME多部分/相关内容类型”，RFC 2387，1998年8月。
[19] Barton, J., Thatte, S., and H. Nielsen, "SOAP Messages with Attachments", W3C NOTE NOTE-SOAP-attachments-20001211, December 2000.
[19] Barton，J.，Thatte，S.，和H.Nielsen，“带附件的SOAP消息”，W3C NOTE-SOAP-Attachments-2000121112000年12月。
[20] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[20] Levinson，E.，“内容ID和消息ID统一资源定位器”，RFC 2392，1998年8月。
[21] Palme, J., Hopmann, A., and N. Shelness, "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2557, March 1999.
[21] Palme，J.，Hopmann，A.，和N.Shelness，“聚合文档的MIME封装，如HTML（MHTML）”，RFC2557，1999年3月。
Appendix A. SOAP with Attachments (Informative)
附录A.带附件的肥皂（资料性）
To provide compatibility with RFC3288 [16], a BEEP profile for SOAP MAY allow envelopes to be transmitted as the root part of a "multipart/related" [18] content, and with subordinate parts referenced using the rules of Section 3 of [19] (i.e., using either the "Content-ID:" [20] or "Content-Location:" [21] headers), e.g.,
为提供与RFC3288[16]的兼容性，SOAP的BEEP配置文件可允许将信封作为“多部分/相关”[18]内容的根部分传输，并使用[19]第3节的规则（即使用“内容ID:[20]或“内容位置：[21]头”）引用从属部分，例如。，
MSG 1 2 . 278 657
Content-Type: multipart/related; boundary="MIME_boundary";
type=application/xml;
start="<claim061400a.xml@claiming-it.com>"
MSG 1 2 . 278 657
Content-Type: multipart/related; boundary="MIME_boundary";
type=application/xml;
start="<claim061400a.xml@claiming-it.com>"
--MIME_boundary
Content-Type: application/xml
Content-ID: <claim061400a.xml@claiming-it.com>
--MIME_boundary
Content-Type: application/xml
Content-ID: <claim061400a.xml@claiming-it.com>
<?xml version='1.0' ?>
<env:Envelope
xmlns:env="http://www.w3.org/2003/05/soap-envelope">
..
</env:Header>
<env:Body>
<theSignedForm href="cid:claim061400a.tiff@claiming-it.com" />
..
</env:Body>
</env:Envelope>
<?xml version='1.0' ?>
<env:Envelope
xmlns:env="http://www.w3.org/2003/05/soap-envelope">
..
</env:Header>
<env:Body>
<theSignedForm href="cid:claim061400a.tiff@claiming-it.com" />
..
</env:Body>
</env:Envelope>
--MIME_boundary
Content-Type: image/tiff
Content-Transfer-Encoding: binary
Content-ID: <claim061400a.tiff@claiming-it.com>
--MIME_boundary
Content-Type: image/tiff
Content-Transfer-Encoding: binary
Content-ID: <claim061400a.tiff@claiming-it.com>
...binary TIFF image... --MIME_boundary-- END
…二进制TIFF图像--MIME_边界—结束
Consistent with Section 2 of [19], it is strongly recommended that the multipart contain a "start" parameter, and that the root part contain a "Content-ID:" header. However, because BEEP provides an 8bit-wide path, a "transformative" Content-Transfer-Encoding (e.g., "base64" or "quoted-printable") should not be used. Further note that MIME [9] requires that the value of the "Content-ID" header be globally unique.
与[19]第2节一致，强烈建议multipart包含一个“start”参数，根部分包含一个“Content ID:”标题。但是，由于BEEP提供8位宽的路径，因此不应使用“转换性”内容传输编码（例如，“base64”或“可打印引用”）。进一步注意，MIME[9]要求“Content ID”头的值是全局唯一的。
Authors' Addresses
作者地址
Eamon O'Tuathail Clipcode.com 24 Thomastown Road Dun Laoghaire Dublin IE
Eamon O'Tuathail Clipcode.com都柏林老挝海尔托马斯敦路24号
Phone: +353 1 2350 424
EMail: eamon.otuathail@clipcode.com
URI: http://www.clipcode.com/
Phone: +353 1 2350 424
EMail: eamon.otuathail@clipcode.com
URI: http://www.clipcode.com/
Marshall T. Rose Dover Beach Consulting, Inc. POB 255268 Sacramento, CA 95865-5268 US
马歇尔T.罗斯多佛海滩咨询公司POB 255268萨克拉门托，加利福尼亚州95865-5268美国
Phone: +1 916 483 8878
EMail: mrose@dbc.mtview.ca.us
Phone: +1 916 483 8878
EMail: mrose@dbc.mtview.ca.us
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。