Network Working Group G. Camarillo
Request for Comments: 5621 Ericsson
Updates: 3204, 3261, 3459 September 2009
Category: Standards Track
Network Working Group G. Camarillo
Request for Comments: 5621 Ericsson
Updates: 3204, 3261, 3459 September 2009
Category: Standards Track
Message Body Handling in the Session Initiation Protocol (SIP)
会话启动协议（SIP）中的消息体处理
Abstract
摘要
This document specifies how message bodies are handled in SIP. Additionally, this document specifies SIP user agent support for MIME (Multipurpose Internet Mail Extensions) in message bodies.
本文档指定如何在SIP中处理消息体。此外，本文档还指定了SIP用户代理对消息体中MIME（多用途Internet邮件扩展）的支持。
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Message Body Encoding . . . . . . . . . . . . . . . . . . . . 3
3.1. Background on Message Body Encoding . . . . . . . . . . . 3
3.2. UA Behavior to Encode Binary Message Bodies . . . . . . . 5
4. 'multipart' Message Bodies . . . . . . . . . . . . . . . . . . 6
4.1. Background on 'multipart' Message Bodies . . . . . . . . . 6
4.2. Mandatory Support for 'multipart' Message Bodies . . . . . 7
4.3. UA Behavior to Generate 'multipart' Message Bodies . . . . 7
5. 'multipart/mixed' Message Bodies . . . . . . . . . . . . . . . 7
6. 'multipart/alternative' Message Bodies . . . . . . . . . . . . 8
6.1. Background on 'multipart/alternative' Message Bodies . . . 8
6.2. UA Behavior to Generate 'multipart/alternative'
Message Bodies . . . . . . . . . . . . . . . . . . . . . . 8
6.3. UA Behavior to Process 'multipart/alternative' Message
Bodies . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. 'multipart/related' Message Bodies . . . . . . . . . . . . . . 9
7.1. Background on 'multipart/related' Message Bodies . . . . . 9
7.2. UA Behavior to Generate 'multipart/related' Message
Bodies . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.3. UA Behavior to Process 'multipart/related' Message
Bodies . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Disposition Types . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Background on Content and Disposition Types in SIP . . . . 10
8.2. UA Behavior to Set the 'handling' Parameter . . . . . . . 12
8.3. UA Behavior to Process 'multipart/alternative' . . . . . . 13
8.4. UAS Behavior to Report Unsupported Message Bodies . . . . 13
9. Message Body Processing . . . . . . . . . . . . . . . . . . . 14
9.1. Background on References to Message Body Parts . . . . . . 14
9.2. UA Behavior to Generate References to Message Bodies . . . 14
9.3. UA Behavior to Process Message Bodies . . . . . . . . . . 14
9.4. The 'by-reference' Disposition Type . . . . . . . . . . . 15
10. Guidelines to Authors of SIP Extensions . . . . . . . . . . . 16
11. Security Considerations . . . . . . . . . . . . . . . . . . . 16
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
12.1. Registration of the 'by-reference' Disposition Type . . . 17
12.2. Update of the 'handling' Parameter Registration . . . . . 17
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
14.1. Normative References . . . . . . . . . . . . . . . . . . . 17
14.2. Informative References . . . . . . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Message Body Encoding . . . . . . . . . . . . . . . . . . . . 3
3.1. Background on Message Body Encoding . . . . . . . . . . . 3
3.2. UA Behavior to Encode Binary Message Bodies . . . . . . . 5
4. 'multipart' Message Bodies . . . . . . . . . . . . . . . . . . 6
4.1. Background on 'multipart' Message Bodies . . . . . . . . . 6
4.2. Mandatory Support for 'multipart' Message Bodies . . . . . 7
4.3. UA Behavior to Generate 'multipart' Message Bodies . . . . 7
5. 'multipart/mixed' Message Bodies . . . . . . . . . . . . . . . 7
6. 'multipart/alternative' Message Bodies . . . . . . . . . . . . 8
6.1. Background on 'multipart/alternative' Message Bodies . . . 8
6.2. UA Behavior to Generate 'multipart/alternative'
Message Bodies . . . . . . . . . . . . . . . . . . . . . . 8
6.3. UA Behavior to Process 'multipart/alternative' Message
Bodies . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. 'multipart/related' Message Bodies . . . . . . . . . . . . . . 9
7.1. Background on 'multipart/related' Message Bodies . . . . . 9
7.2. UA Behavior to Generate 'multipart/related' Message
Bodies . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.3. UA Behavior to Process 'multipart/related' Message
Bodies . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Disposition Types . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Background on Content and Disposition Types in SIP . . . . 10
8.2. UA Behavior to Set the 'handling' Parameter . . . . . . . 12
8.3. UA Behavior to Process 'multipart/alternative' . . . . . . 13
8.4. UAS Behavior to Report Unsupported Message Bodies . . . . 13
9. Message Body Processing . . . . . . . . . . . . . . . . . . . 14
9.1. Background on References to Message Body Parts . . . . . . 14
9.2. UA Behavior to Generate References to Message Bodies . . . 14
9.3. UA Behavior to Process Message Bodies . . . . . . . . . . 14
9.4. The 'by-reference' Disposition Type . . . . . . . . . . . 15
10. Guidelines to Authors of SIP Extensions . . . . . . . . . . . 16
11. Security Considerations . . . . . . . . . . . . . . . . . . . 16
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
12.1. Registration of the 'by-reference' Disposition Type . . . 17
12.2. Update of the 'handling' Parameter Registration . . . . . 17
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
14.1. Normative References . . . . . . . . . . . . . . . . . . . 17
14.2. Informative References . . . . . . . . . . . . . . . . . . 18
Message body handling in SIP was originally specified in [RFC3261], which relied on earlier specifications (e.g., MIME) to describe some areas. This document contains background material on how bodies are handled in SIP and normative material on areas that had not been specified before or whose specifications needed to be completed. Sections containing background material are clearly identified as such by their titles. The material on the normative sections is based on experience gained since [RFC3261] was written. Implementers need to implement what is specified in [RFC3261] (and its references) in addition to what is specified in this document.
SIP中的消息体处理最初在[RFC3261]中指定，它依赖于早期的规范（例如MIME）来描述某些领域。本文件包含关于如何在SIP中处理尸体的背景材料，以及关于之前未指定或需要完成规范的领域的规范性材料。包含背景材料的章节由其标题明确标识。规范章节中的材料基于[RFC3261]编写以来获得的经验。除本文件中规定的内容外，实施者还需要实施[RFC3261]（及其参考文件）中规定的内容。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The following abbreviations are used in this document.
本文件中使用了以下缩写。
UA: User Agent
用户代理
UAC: User Agent Client
用户代理客户端
UAS: User Agent Server
用户代理服务器
URL: Uniform Resource Locator
统一资源定位器
This section deals with the encoding of message bodies in SIP.
本节讨论SIP中消息体的编码。
SIP [RFC3261] messages consist of an initial line (request line in requests and status line in responses), a set of header fields, and an optional message body. The message body is described using header fields such as Content-Disposition, Content-Encoding, and Content-Type, which provide information on its contents. Figure 1 shows a SIP message that carries a body. Some of the header fields are not shown for simplicity:
SIP[RFC3261]消息由初始行（请求中的请求行和响应中的状态行）、一组头字段和可选消息正文组成。消息体使用头字段（如内容配置、内容编码和内容类型）进行描述，这些头字段提供有关其内容的信息。图1显示了承载主体的SIP消息。为简单起见，未显示某些标题字段：
INVITE sip:conf-fact@example.com SIP/2.0
Content-Type: application/sdp
Content-Length: 192
INVITE sip:conf-fact@example.com SIP/2.0
Content-Type: application/sdp
Content-Length: 192
v=0
o=alice 2890844526 2890842807 IN IP4 atlanta.example.com
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 20000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 20002 RTP/AVP 31
a=rtpmap:31 H261/90000
v=0
o=alice 2890844526 2890842807 IN IP4 atlanta.example.com
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 20000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 20002 RTP/AVP 31
a=rtpmap:31 H261/90000
Figure 1: SIP message carrying a body
图1：承载主体的SIP消息
The message body of a SIP message can be divided into various body parts. Multipart message bodies are encoded using the MIME (Multipurpose Internet Mail Extensions) [RFC2045] format. Body parts are also described using header fields such as Content-Disposition, Content-Encoding, and Content-Type, which provide information on the contents of a particular body part. Figure 2 shows a SIP message that carries two body parts. Some of the header fields are not shown for simplicity:
SIP消息的消息体可以分为不同的主体部分。多部分邮件正文使用MIME（多用途Internet邮件扩展）[RFC2045]格式进行编码。正文部分还使用标题字段（如内容配置、内容编码和内容类型）进行描述，这些字段提供有关特定正文部分内容的信息。图2显示了携带两个主体部分的SIP消息。为简单起见，未显示某些标题字段：
INVITE sip:conf-fact@example.com SIP/2.0
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: 619
INVITE sip:conf-fact@example.com SIP/2.0
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: 619
--boundary1
Content-Type: application/sdp
--boundary1
Content-Type: application/sdp
v=0
o=alice 2890844526 2890842807 IN IP4 atlanta.example.com
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 20000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 20002 RTP/AVP 31
a=rtpmap:31 H261/90000
v=0
o=alice 2890844526 2890842807 IN IP4 atlanta.example.com
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 20000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 20002 RTP/AVP 31
a=rtpmap:31 H261/90000
--boundary1 Content-Type: application/resource-lists+xml Content-Disposition: recipient-list
--boundary1内容类型：应用程序/资源列表+xml内容处置：收件人列表
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list>
<entry uri="sip:bill@example.com"/>
<entry uri="sip:randy@example.net"/>
<entry uri="sip:joe@example.org"/>
</list>
</resource-lists>
--boundary1--
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list>
<entry uri="sip:bill@example.com"/>
<entry uri="sip:randy@example.net"/>
<entry uri="sip:joe@example.org"/>
</list>
</resource-lists>
--boundary1--
Figure 2: SIP message carrying a body
图2：承载主体的SIP消息
SIP uses S/MIME [RFC3851] to protect message bodies. As specified in [RFC3261], UASs that cannot decrypt a message body or a body part can use the 493 (Undecipherable) response to report the error.
SIP使用S/MIME[RFC3851]来保护消息体。如[RFC3261]所述，无法解密消息正文或正文部分的UAS可以使用493（不可解密）响应报告错误。
SIP messages can carry binary message bodies such as legacy signalling objects [RFC3204]. SIP proxy servers are 8-bit safe. That is, they are able to handle binary bodies. Therefore, there is no need to use encodings such as base64 to transport binary bodies in SIP messages. Consequently, UAs SHOULD use the binary transfer encoding [RFC4289] for all payloads in SIP, including binary payloads. The only case where a UA MAY use a different encoding is when transferring application data between applications that only handle a different encoding (e.g., base64).
SIP消息可以携带二进制消息体，如传统信令对象[RFC3204]。SIP代理服务器是8位安全的。也就是说，它们能够处理二进制体。因此，不需要使用诸如base64之类的编码来传输SIP消息中的二进制体。因此，UAs应该对SIP中的所有有效负载（包括二进制有效负载）使用二进制传输编码[RFC4289]。UA可以使用不同编码的唯一情况是在仅处理不同编码的应用程序之间传输应用程序数据时（例如，base64）。
This section deals with 'multipart' message bodies and their handling.
本节介绍“多部分”消息体及其处理。
[RFC3261] did not mandate support for 'multipart' message bodies in MIME format [RFC2046]. However, since [RFC3261] was written, many SIP extensions rely on them.
[RFC3261]未强制要求支持MIME格式的“多部分”消息正文[RFC2046]。然而，由于[RFC3261]是编写的，许多SIP扩展都依赖于它们。
The use of 'multipart/mixed' MIME bodies is a useful tool to build SIP extensions. An example of such an extension could be the inclusion of location information in an INVITE request. Such an INVITE request would use the 'multipart/mixed' MIME type [RFC2046] to carry two body parts: a session description and a location object. An example of an existing extension that uses 'multipart/mixed' to send a session description and a legacy-signalling object is defined in [RFC3204].
使用“多部分/混合”MIME主体是构建SIP扩展的有用工具。这种扩展的一个例子是在INVITE请求中包含位置信息。这样的INVITE请求将使用“multipart/mixed”MIME类型[RFC2046]携带两个主体部分：会话描述和位置对象。[RFC3204]中定义了使用“多部分/混合”发送会话描述和传统信令对象的现有扩展的示例。
Another MIME type that is useful to build SIP extensions is 'multipart/alternative' [RFC2046]. Each body part within a 'multipart/alternative' carries an alternative version of the same information.
另一种对构建SIP扩展有用的MIME类型是“多部分/可选”[RFC2046]。“多部分/备选方案”中的每个身体部位都包含相同信息的备选版本。
The transition from SDP to new session description protocols could be implemented using 'multipart/alternative' bodies. SIP messages (e.g., INVITE requests) could carry a 'multipart/alternative' body with two body parts: a session description written in SDP and a session description written in a newer session description format. Legacy recipient UAs would use the session description written in SDP. New recipient UAs would use the one written in the newer format.
从SDP到新会话描述协议的转换可以使用“多部分/备选”主体来实现。SIP消息（例如，INVITE请求）可以包含一个“多部分/备选”正文，正文由两部分组成：一部分是用SDP编写的会话描述，另一部分是用较新的会话描述格式编写的会话描述。遗留接收方UAs将使用SDP中编写的会话描述。新的收件人UAs将使用以较新格式编写的UAs。
Nested MIME bodies are yet another useful tool to build and combine SIP extensions. Using the extensions in the previous examples, a UA that supported a new session description format and that needed to include a location object in an INVITE request would include a 'multipart/mixed' body with two body parts: a location object and a 'multipart/alternative'. The 'multipart/alternative' body part would, in turn, have two body parts: a session description written in SDP and a session description written in the newer session description format.
嵌套MIME主体是构建和组合SIP扩展的另一个有用工具。使用前面示例中的扩展，支持新会话描述格式且需要在INVITE请求中包含location对象的UA将包含一个“多部分/混合”主体，该主体包含两个主体部分：一个位置对象和一个“多部分/备选方案”。“multipart/alternative”主体部分又有两个主体部分：一个是用SDP编写的会话描述，另一个是用较新的会话描述格式编写的会话描述。
For all MIME-based extensions to work, the recipient needs to be able to decode the multipart bodies. Therefore, SIP UAs MUST support parsing 'multipart' MIME bodies, including nested body parts. Additionally, UAs MUST support the 'multipart/mixed' and 'multipart/ alternative' MIME types. Support for other MIME types such as 'multipart/related' is OPTIONAL.
对于所有基于MIME的扩展，接收者需要能够解码多部分主体。因此，SIP UAs必须支持解析“多部分”MIME主体，包括嵌套的主体部分。此外，UAs必须支持“多部分/混合”和“多部分/替代”MIME类型。对其他MIME类型（如“多部分/相关”）的支持是可选的。
Note that, by default, unknown 'multipart' subtypes are treated as 'multipart/mixed'. Also note that SIP extensions can also include 'multipart' MIME bodies in responses. That is why both UACs and UASs need to support 'multipart' bodies.
请注意，默认情况下，未知的“multipart”子类型被视为“multipart/mixed”。还要注意，SIP扩展还可以在响应中包含“多部分”MIME主体。这就是UAC和UAS都需要支持“多部分”机构的原因。
Legacy SIP UAs without support for 'multipart' bodies generate a 415 (Unsupported Media Type) response when they receive a 'multipart' body in a request. A UAC sending a 'multipart' body can receive such an error response when communicating with a legacy SIP UA that predates this specification.
不支持“多部分”主体的传统SIP UAs在收到请求中的“多部分”主体时会生成415（不支持的媒体类型）响应。在与本规范之前的传统SIP UA通信时，发送“多部分”正文的UAC可以接收此类错误响应。
It has been observed in the field that a number of legacy SIP UAs without support for 'multipart' bodies simply ignored those bodies when they were received. These UAs did not return any error response. Unsurprisingly, SIP UAs not being able to report this type of error have caused serious interoperability problems in the past.
在现场观察到，许多不支持“多部分”实体的传统SIP UAs在收到这些实体时只是忽略了它们。这些UAs没有返回任何错误响应。毫不奇怪，SIP UAs无法报告此类错误在过去造成了严重的互操作性问题。
UAs SHOULD avoid unnecessarily nesting body parts because doing so would, unnecessarily, make processing the body more laborious for the receiver. However, [RFC2046] states that a 'multipart' media type with a single body part is useful in some circumstances (e.g., for sending non-text media types). In any case, UAs SHOULD NOT nest one 'multipart/mixed' within another unless there is a need to reference the nested one (i.e., using the Content ID of the nested body part). Additionally, UAs SHOULD NOT nest one 'multipart/alternative' within another.
UAs应避免不必要地嵌套身体部位，因为这样做会不必要地使接收器处理身体更加费力。但是，[RFC2046]指出，在某些情况下（例如，用于发送非文本媒体类型），具有单个主体部分的“多部分”媒体类型是有用的。在任何情况下，UAs都不应将一个“多部分/混合”嵌套在另一个“多部分/混合”中，除非需要引用嵌套的一个（即，使用嵌套身体部位的内容ID）。此外，UAs不应将一个“多部分/备选方案”嵌套在另一个“多部分/备选方案”中。
Note that UAs receiving unnecessarily nested body parts treat them as if they were not nested.
请注意，接收不必要嵌套的身体部位的UAs将其视为未嵌套。
This section does not specify any additional behavior regarding how to generate and process 'multipart/mixed' bodies. This section is simply included for completeness.
本节不指定有关如何生成和处理“多部分/混合”实体的任何其他行为。为了完整起见，仅包括本节。
This section deals with 'multipart/alternative' message bodies and their handling.
本节讨论“多部分/可选”消息体及其处理。
Each body part within a 'multipart/alternative' carries an alternative version of the same information. The body parts are ordered so that the last one is the richest representation of the information. The recipient of a 'multipart/alternative' body chooses the last body part it understands.
“多部分/备选方案”中的每个身体部位都包含相同信息的备选版本。身体部位是有序的，因此最后一个部位是信息最丰富的表示形式。“多部分/备选”主体的接收者选择其理解的最后一个主体部分。
Note that within a body part encoded in a given format (i.e., of a given content type), there can be optional elements that can provide richer information to the recipient in case the recipient supports them. For example, in SDP (Session Description Protocol) [RFC4566], those optional elements are encoded in 'a' lines. These types of optional elements are internal to a body part and are not visible at the MIME level. That is, a body part is understood if the recipient understands its content type, regardless of whether or not the body part's optional elements are understood.
请注意，在以给定格式（即，给定内容类型）编码的身体部位内，可以存在可选元素，这些元素可以在收件人支持的情况下向收件人提供更丰富的信息。例如，在SDP（会话描述协议）[RFC4566]中，这些可选元素用“a”行编码。这些类型的可选元素是主体部分的内部元素，在MIME级别不可见。也就是说，如果接收者理解其内容类型，则理解主体部分，而不管是否理解主体部分的可选元素。
Note as well that each part of a 'multipart/alternative' body represents the same data, but the mapping between any two parts is not necessarily without information loss. For example, information can be lost when translating 'text/html' to 'text/ plain'. [RFC2046] recommends that each part should have a different Content-ID value in the case where the information content of the two parts is not identical.
还要注意的是，“多部分/备选方案”主体的每个部分都表示相同的数据，但任何两个部分之间的映射不一定没有信息丢失。例如，将“text/html”翻译为“text/plain”时可能会丢失信息。[RFC2046]建议在两个部分的信息内容不相同的情况下，每个部分应具有不同的内容ID值。
Section 8.2 mandates all the top-level body parts within a 'multipart/alternative' to have the same disposition type.
第8.2节要求“多部件/备选方案”中的所有顶级车身部件具有相同的配置类型。
The 'session' and 'early-session' [RFC3959] disposition types require that all the body parts of a 'multipart/alternative' body have different content types. Consequently, for the 'session' and 'early-session' disposition types, UAs MUST NOT place more than one body part with a given content type in a 'multipart/alternative' body. That is, for 'session' and 'early-session', no body part within a 'multipart/alternative' can have the same content type as another body part within the same 'multipart/alternative'.
“会话”和“早期会话”[RFC3959]处置类型要求“多部分/备选”正文的所有正文部分具有不同的内容类型。因此，对于“会话”和“早期会话”处置类型，UAs不得在“多部分/备选”主体中放置具有给定内容类型的多个主体部分。也就是说，对于“会话”和“早期会话”，“多部分/备选方案”中的任何主体部分都不能与同一“多部分/备选方案”中的另一主体部分具有相同的内容类型。
This section does not specify any additional behavior regarding how to process 'multipart/alternative' bodies. This section is simply included for completeness.
本节未指定有关如何处理“多部分/备选”实体的任何其他行为。为了完整起见，仅包括本节。
This section deals with 'multipart/related' message bodies and their handling.
本节讨论“多部分/相关”消息正文及其处理。
Compound objects in MIME are represented using the 'multipart/ related' content type [RFC2387]. The body parts within a particular 'multipart/related' body are all part of a compound object and are processed as such. The body part within a 'multipart/related' body that needs to be processed first is referred to as the 'root' body part. The root body part of a 'multipart/related' body is identified by the 'start' parameter, which is a Content-Type header field parameter and contains a Content-ID URL pointing to the root body part. If the start parameter is not present, the root body part is, by default, the first body part of the 'multipart/related'. An example of a compound object is a web page that contains images. The html body part would be the root. The remaining body parts would contain the images. An example of a SIP extension using 'multipart/ related' is specified in [RFC4662].
MIME中的复合对象使用“多部分/相关”内容类型[RFC2387]表示。特定“多部分/相关”主体内的主体部分都是复合对象的一部分，并按此进行处理。“多部分/相关”主体中首先需要处理的主体部分称为“根”主体部分。“多部分/相关”正文的根正文部分由“开始”参数标识，该参数是一个内容类型标题字段参数，包含指向根正文部分的内容ID URL。如果start参数不存在，则默认情况下，根主体部分是“多部分/相关”的第一个主体部分。复合对象的一个示例是包含图像的网页。html主体部分将是根。其余的身体部位将包含图像。[RFC4662]中规定了使用“多部分/相关”的SIP扩展示例。
This section does not specify any additional behavior regarding how to generate 'multipart/related' bodies. This section is simply included for completeness.
本节不指定有关如何生成“多部分/相关”实体的任何其他行为。为了完整起见，仅包括本节。
Per [RFC2387], a UA processing a 'multipart/related' body processes the body as a compound object ignoring the disposition types of the body parts within it. Ignoring the disposition types of the individual body parts makes sense in the context in which 'multipart/ related' was originally specified. For instance, in the example of the web page, the implicit disposition type for the images would be 'inline', since the images are displayed as indicated by the root html file. However, in SIP, the disposition types of the individual body parts within a 'multipart/related' play an important role and, thus, need to be considered by the UA processing the 'multipart/ related'. Different SIP extensions that use the same disposition type for the 'multipart/related' body can be distinguished by the
根据[RFC2387]，处理“多部分/相关”主体的UA将主体作为复合对象进行处理，忽略其中主体部分的处置类型。在最初指定“多部分/相关”的上下文中，忽略单个身体部位的处置类型是有意义的。例如，在web页面的示例中，图像的隐式处置类型将为“inline”，因为图像显示为根html文件所指示的。然而，在SIP中，“多部分/相关”中单个身体部位的处置类型起着重要作用，因此，UA处理“多部分/相关”时需要考虑这些处置类型。对于“多部分/相关”主体使用相同处置类型的不同SIP扩展，可以通过
disposition types of the individual body parts within the 'multipart/ related'. Consequently, SIP UAs processing a 'multipart/related' body with a given disposition type MUST process the disposition types of the body parts within it according to the SIP extension making use the disposition type of the 'multipart/related'.
“多部分/相关”中单个身体部位的处置类型。因此，处理具有给定处置类型的“多部分/相关”主体的SIP UAs必须使用“多部分/相关”的处置类型，根据SIP扩展处理其中主体部件的处置类型。
Note that UAs that do not understand 'multipart/related' will treat 'multipart/related' bodies as 'multipart/mixed' bodies. These UAs will not be able to process a given body as a compound object. Instead, they will process the body parts according to their disposition type as if each body part was independent from each other.
请注意，不理解“多部分/相关”的UAs将把“多部分/相关”实体视为“多部分/混合”实体。这些UAs将无法将给定实体作为复合对象进行处理。相反，他们将根据处置类型处理身体部位，就像每个身体部位彼此独立一样。
This section deals with disposition types in message bodies.
本节介绍消息正文中的处置类型。
The Content-Disposition header field, defined in [RFC2183] and extended by [RFC3261], describes how to handle a SIP message's body or an individual body part. Examples of disposition types used in SIP in the Content-Disposition header field are 'session' and 'render'.
[RFC2183]中定义并由[RFC3261]扩展的内容处置头字段描述了如何处理SIP消息的正文或单个正文部分。SIP中内容处置头字段中使用的处置类型示例有“会话”和“呈现”。
[RFC3204] and [RFC3459] define the 'handling' parameter for the Content-Disposition header field. This parameter describes how a UAS reacts if it receives a message body whose content type or disposition type it does not understand. If the parameter has the value 'optional', the UAS ignores the message body; if the parameter has the value 'required', the UAS returns a 415 (Unsupported Media Type) response. The default value for the 'handling' parameter is 'required'. The following is an example of a Content-Disposition header field:
[RFC3204]和[RFC3459]定义内容处置标头字段的“处理”参数。此参数描述UAS在接收到其不了解其内容类型或处置类型的消息正文时的反应。如果参数值为“可选”，UAS将忽略消息正文；如果参数的值为“required”，UAS将返回415（不支持的媒体类型）响应。“handling”参数的默认值为“required”。以下是内容处置标题字段的示例：
Content-Disposition: signal; handling=optional
Content-Disposition: signal; handling=optional
[RFC3204] identifies two situations where a UAS (User Agent Server) needs to reject a request with a body part whose handling is required:
[RFC3204]确定了UAS（用户代理服务器）需要拒绝带有需要处理的主体部分的请求的两种情况：
1. if it has an unknown content type.
1. 如果它有未知的内容类型。
2. if it has an unknown disposition type.
2. 如果它具有未知的处置类型。
If the UAS did not understand the content type of the body part, the UAS can add an Accept header field to its 415 (Unsupported Media Type) response listing the content types that the UAS does
如果UAS不理解主体部分的内容类型，UAS可以向其415（不支持的媒体类型）响应添加Accept header字段，该响应列出了UAS所理解的内容类型
understand. Nevertheless, there is no mechanism for a UAS that does not understand the disposition type of a body part to inform the UAC about which disposition type was not understood or about the disposition types that are understood by the UAS.
懂然而，不了解身体部位处置类型的UAS没有机制通知UAC不了解的处置类型或UAS了解的处置类型。
The reason for not having such a mechanism is that disposition types are typically supported within a context. Outside that context, a UA need not support the disposition type. For example, a UA can support the 'session' disposition type for body parts in INVITE and UPDATE requests and their responses. However, the same UA would not support the 'session' disposition type in MESSAGE requests.
没有这种机制的原因是，在上下文中通常支持处置类型。在该上下文之外，UA不需要支持处置类型。例如，UA可以支持邀请和更新请求及其响应中身体部位的“会话”处置类型。但是，同一UA不支持消息请求中的“会话”处置类型。
In another example, a UA can support the 'render' disposition type for 'text/plain' and 'text/html' body parts in MESSAGE requests. Additionally, the UA can support the 'session' disposition type for 'application/sdp' body parts in INVITE and UPDATE requests and their responses. However, the UA might not support the 'render' disposition type for 'application/sdp' body parts in MESSAGE requests, even if, in different contexts, the UA supported all of the following: the 'render' disposition type, the 'application/sdp' content type, and the MESSAGE method.
在另一个示例中，UA可以支持消息请求中“text/plain”和“text/html”主体部分的“render”处置类型。此外，UA可以支持邀请和更新请求及其响应中“应用程序/sdp”主体部分的“会话”处置类型。但是，UA可能不支持消息请求中“应用程序/sdp”主体部分的“呈现”处置类型，即使在不同的上下文中，UA支持以下所有内容：“呈现”处置类型、“应用程序/sdp”内容类型和消息方法。
A given context is generally (but not necessarily) defined by a method, a disposition type, and a content type. Support for a specific context is usually defined within an extension. For example, the extension for instant messaging in SIP [RFC3428] mandates support for the MESSAGE method, the 'render' disposition type, and the 'text/plain' content type.
给定的上下文通常（但不一定）由方法、处置类型和内容类型定义。对特定上下文的支持通常在扩展中定义。例如，SIP[RFC3428]中的即时消息扩展要求支持消息方法、“呈现”配置类型和“文本/普通”内容类型。
Note that, effectively, content types are also supported within a context. Therefore, the use of the Accept header field in a 415 (Unsupported Media Type) response is not enough to describe in which contexts a particular content type is supported.
请注意，实际上，上下文中也支持内容类型。因此，在415（不支持的媒体类型）响应中使用接受报头字段不足以描述在哪些上下文中支持特定内容类型。
Therefore, support for a particular disposition type within a given context is typically signalled by the use of a particular method or an option-tag in a Supported or a Require header field. When support for a particular disposition type within a context is mandated, support for a default content type is also mandated (e.g., a UA that supports the 'session' disposition type in an INVITE request needs to support the 'application/sdp' content type).
因此，在给定上下文中对特定处置类型的支持通常通过在支持的或需要的标头字段中使用特定方法或选项标记来表示。当强制支持上下文中的特定处置类型时，也强制支持默认内容类型（例如，在INVITE请求中支持“会话”处置类型的UA需要支持“应用程序/sdp”内容类型）。
As stated earlier, the 'handling' Content-Disposition parameter can take two values: 'required' or 'optional'. While it is typically easy for a UA to decide which type of handling an individual body part requires, setting the 'handling' parameter of 'multipart' bodies requires extra considerations.
如前所述，“handling”内容处置参数可以采用两个值：“required”或“optional”。虽然UA通常很容易决定单个身体部位需要哪种类型的搬运，但设置“多部分”身体的“搬运”参数需要额外考虑。
If the handling of a 'multipart/mixed' body as a whole is required for processing its enclosing body part or message, the UA MUST set the 'handling' parameter of the 'multipart/mixed' body to 'required'. Otherwise, the UA MUST set it to 'optional'. The 'handling' parameters of the top-level body parts within the 'multipart/mixed' body are set independently from the 'handling' parameter of the 'multipart/mixed' body. If the handling of a particular top-level body part is required, the UA MUST set the 'handling' parameter of that body part 'required'. Otherwise, the UA MUST set it to 'optional'.
如果处理“多部分/混合”正文作为一个整体需要处理其封闭正文部分或消息，UA必须将“多部分/混合”正文的“处理”参数设置为“必需”。否则，UA必须将其设置为“可选”。“多部分/混合”主体内顶级主体部件的“处理”参数独立于“多部分/混合”主体的“处理”参数设置。如果需要搬运特定的顶级车身部件，UA必须将该车身部件的“搬运”参数设置为“必需”。否则，UA必须将其设置为“可选”。
Per the previous rules, a 'multipart/mixed' body whose handling is optional can contain body parts whose handling is required. In such case, the receiver is required to process the body parts whose handling is required if and only if the receiver decides to process the optional 'multipart/mixed' body.
根据前面的规则，处理为可选的“多部分/混合”主体可以包含需要处理的主体部分。在这种情况下，当且仅当接收者决定处理可选的“多部分/混合”车身时，要求接收者处理需要处理的车身部件。
Also per the previous rules, a 'multipart/mixed' body whose handling is required can contain only body parts whose handling is optional. In such case, the receiver is required to process the body as a whole but, when processing it, the receiver may decide (based on its local policy) not to process any of the body parts.
同样根据前面的规则，需要处理的“多部件/混合”车身只能包含可选处理的车身部件。在这种情况下，要求接收者整体处理身体，但在处理身体时，接收者可以决定（基于其本地政策）不处理身体的任何部分。
The 'handling' parameter is a Content-Disposition parameter. Therefore, in order to set this parameter, it is necessary to provide the 'multipart/mixed' body with a disposition type. Per [RFC3261], the default disposition type for 'application/sdp' is 'session' and for other bodies is 'render'. UAs SHOULD assign 'multipart/mixed' bodies a disposition type of 'render'.
“handling”参数是一个内容处置参数。因此，要设置此参数，必须为“multipart/mixed”主体提供处置类型。根据[RFC3261]，应用程序/sdp的默认处置类型为“会话”，其他主体的默认处置类型为“渲染”。UAs应为“多部分/混合”实体分配“呈现”的处置类型。
Note that the fact that 'multipart/mixed' bodies have a default disposition type of 'render' does not imply that they will be rendered to the user. The way the body parts within the 'multipart/mixed' are handled depends on the disposition types of the individual body parts. The actual disposition type of the whole 'multipart/mixed' is irrelevant. The 'render' disposition type has been chosen for 'multipart/mixed' bodies simply because 'render' is the default disposition type in SIP.
请注意，“多部分/混合”实体的默认处置类型为“呈现”，这并不意味着它们将呈现给用户。处理“多部分/混合”中的身体部位的方式取决于各个身体部位的处置类型。整个“多部分/混合”的实际处置类型无关。已为“多部分/混合”实体选择“呈现”处置类型，原因很简单，因为“呈现”是SIP中的默认处置类型。
If the handling of a 'multipart/alternative' body as a whole is required for processing its enclosing body part or message, the UA MUST set the 'handling' parameter of the 'multipart/alternative' body to 'required'. Otherwise, the UA MUST set it to 'optional'. The UA SHOULD also set the 'handling' parameter of all the top-level body part within the 'multipart/alternative' to 'optional'.
如果需要整体处理“多部分/备选方案”正文以处理其封闭正文部分或消息，UA必须将“多部分/备选方案”正文的“处理”参数设置为“必需”。否则，UA必须将其设置为“可选”。UA还应将“multipart/alternative”中所有顶级车身部件的“handling”参数设置为“optional”。
The receiver will process the body parts based on the handling parameter of the 'multipart/alternative' body. The receiver will ignore the handling parameters of the body parts. That is why setting them to 'optional' is at the "SHOULD" level and not at the "MUST" level -- their value is irrelevant.
接收器将根据“多部件/备选”车身的处理参数处理车身部件。接收器将忽略车身部件的操作参数。这就是为什么将它们设置为“可选”是在“应该”级别，而不是在“必须”级别——它们的值是无关的。
The UA MUST use the same disposition type for the 'multipart/ alternative' body and all its top-level body parts.
UA必须为“多部件/备选”车身及其所有顶级车身部件使用相同的配置类型。
If the handling of a 'multipart/related' body as a whole is required for processing its enclosing body part or message, the UA MUST set the 'handling' parameter of the 'multipart/related' body to 'required'. Otherwise, the UA MUST set it to 'optional'. The 'handling' parameters of the top-level body parts within the 'multipart/related' body are set independently from the 'handling' parameter of the 'multipart/related' body. If the handling of a particular top-level body part is required, the UA MUST set the 'handling' parameter of that body part to 'required'. Otherwise, the UA MUST set it to 'optional'. If at least one top-level body part within a 'multipart/related' body has a 'handling' parameter of 'required', the UA SHOULD set the 'handling' parameter of the root body part to 'required'.
如果需要整体处理“多部分/相关”正文以处理其封闭正文部分或消息，UA必须将“多部分/相关”正文的“处理”参数设置为“必需”。否则，UA必须将其设置为“可选”。“多部分/相关”主体内顶级主体部件的“处理”参数独立于“多部分/相关”主体的“处理”参数设置。如果需要搬运特定的顶级车身部件，UA必须将该车身部件的“搬运”参数设置为“必需”。否则，UA必须将其设置为“可选”。如果“多部分/相关”主体中至少有一个顶级主体部分的“处理”参数为“必需”，UA应将根主体部分的“处理”参数设置为“必需”。
The receiver of a 'multipart/alternative' body MUST process the body based on its handling parameter. The receiver SHOULD ignore the handling parameters of the body parts within the 'multipart/ alternative'.
“多部分/备选”主体的接收者必须根据其处理参数处理主体。接收器应忽略“多部分/备选方案”中身体部位的处理参数。
If a UAS cannot process a request because, in the given context, the UAS does not support the content type or the disposition type of a body part whose handling is required, the UAS SHOULD return a 415 (Unsupported Media Type) response even if the UAS supported the content type, the disposition type, or both in a different context.
如果UAS无法处理请求，因为在给定上下文中，UAS不支持需要处理的身体部位的内容类型或处置类型，则即使UAS在不同上下文中支持内容类型、处置类型或两者，UAS也应返回415（不支持的媒体类型）响应。
Consequently, it is possible to receive a 415 (Unsupported Media Type) response with an Accept header field containing all the content types used in the request.
因此，可以通过包含请求中使用的所有内容类型的接受报头字段接收415（不支持的媒体类型）响应。
If a UAS receives a request with a body part whose disposition type is not compatible with the way the body part is supposed to be handled according to other parts of the SIP message (e.g., a Refer-To header field with a Content-ID URL pointing to a body part whose disposition type is 'session'), the UAS SHOULD return a 415 (Unsupported Media Type) response.
如果UAS接收到一个请求，其主体部分的处置类型与根据SIP消息的其他部分处理该主体部分的方式不兼容（例如，一个引用头字段，其内容ID URL指向处置类型为“会话”的主体部分），UAS应返回415（不支持的媒体类型）回答
This section deals with the processing of message bodies and how that processing is influenced by the presence of references to them.
本节讨论消息体的处理，以及消息体引用的存在对处理的影响。
Content-ID URLs allow creating references to body parts. A given Content-ID URL [RFC2392], which can appear in a header field or within a body part (e.g., in an SDP attribute), points to a particular body part. The way to handle that body part is defined by the field the Content-ID URL appears. For example, the extension to refer to multiple resources in SIP [RFC5368] places a Content-ID URL in a Refer-To header field. Such a Content-ID URL points to a body part that carries a URI list. In another example, the extension for file transfer in SDP [RFC5547] places a Content-ID URL in a 'file-icon' SDP attribute. This Content-ID URL points to a body part that carries a (typically small) picture.
内容ID URL允许创建对身体部位的引用。给定的内容ID URL[RFC2392]可以出现在标题字段或主体部分（例如，在SDP属性中）中，指向特定的主体部分。处理身体部位的方式由内容ID URL显示的字段定义。例如，在SIP[RFC5368]中引用多个资源的扩展将内容ID URL放置在引用头字段中。这样的内容ID URL指向承载URI列表的主体部分。在另一个示例中，SDP[RFC5547]中的文件传输扩展名将内容ID URL放置在“文件图标”SDP属性中。此内容ID URL指向承载（通常较小）图片的身体部位。
UAs MUST only include forward references in the SIP messages they generate. That is, an element in a SIP message can reference a body part only if the body part appears after the element. Consequently, a given body part can only be referenced by another body part that appears before it or by a header field. Having only forward references allows recipients to process body parts as they parse them. They do not need to parse the remainder of the message in order to process a body part.
UAs只能在其生成的SIP消息中包含转发引用。也就是说，只有当主体部分出现在元素之后时，SIP消息中的元素才能引用主体部分。因此，给定的身体部位只能由出现在它前面的另一个身体部位或标题字段引用。只有转发引用允许收件人在解析身体部位时处理身体部位。他们不需要解析消息的其余部分来处理正文部分。
It was considered to only allow (forward) references among body parts that belonged to the same 'multipart/related' [RFC2387] wrapper. However, it was finally decided that this extra constraint was not necessary.
它被认为只允许在属于同一个“多部分/相关”[RFC2387]包装器的身体部位之间进行（正向）引用。然而，最终决定，这一额外的限制是没有必要的。
In order to process a message body or a body part, a UA needs to know whether a SIP header field or another body part contains a reference to the message body or body part (e.g., a Content-ID URL pointing to it). If the body part is not referenced in any way (e.g., there are
为了处理消息正文或正文部分，UA需要知道SIP头字段或另一正文部分是否包含对消息正文或正文部分的引用（例如，指向它的内容ID URL）。如果身体部位未以任何方式引用（例如
no header fields or other body parts with a Content-ID URL pointing to it), the UA processes the body part as indicated by its disposition type and the context in which the body part was received.
没有标题字段或内容ID URL指向的其他正文部分），UA根据其处置类型和接收正文部分的上下文处理正文部分。
If the SIP message contains a reference to the body part, the UA processes the body part according to the reference. If the SIP message contains more than one reference to the body part (e.g., two header fields contain Content-ID URLs pointing to the body part), the UA processes the body part as many times as references are.
如果SIP消息包含对身体部位的引用，则UA根据该引用处理身体部位。如果SIP消息包含对主体部分的多个引用（例如，两个头部字段包含指向主体部分的内容ID url），则UA处理主体部分的次数与处理引用的次数相同。
Note that, following the rules in [RFC3204], if a UA does not understand a body part whose handling is optional, the UA ignores it. Also note that the content indirection mechanism in SIP [RFC4483] allows UAs to point to external bodies. Therefore, a UA receiving a SIP message that uses content indirection could need to fetch a body part (e.g., using HTTP [RFC2616]) in order to process it.
请注意，按照[RFC3204]中的规则，如果UA不了解其处理为可选的身体部位，则UA将忽略该部位。还要注意，SIP[RFC4483]中的内容间接寻址机制允许UAs指向外部实体。因此，接收使用内容间接寻址的SIP消息的UA可能需要获取主体部分（例如，使用HTTP[RFC2616]）以便对其进行处理。
Per the rules in Section 9.3, if a SIP message contains a reference to a body part, the UA processes the body part according to the reference. Since the reference provides the context in which the body part needs to be processed, the disposition type of the body part is irrelevant. However, a UA that missed a reference to a body part (e.g., because the reference was in a header field the UA did not support) would attempt to process the body part according to its disposition type alone. To keep this from happening, we define a new disposition type for the Content-Disposition header field: by-reference.
根据第9.3节中的规则，如果SIP消息包含对身体部位的引用，UA将根据该引用处理身体部位。由于引用提供了需要处理身体部位的上下文，因此身体部位的处置类型是不相关的。但是，如果UA遗漏了对身体部位的引用（例如，因为引用位于UA不支持的标题字段中），则UA将尝试仅根据其处置类型处理身体部位。为了防止这种情况发生，我们为contentdispositionheader字段定义了一种新的处置类型：by reference。
A body part whose disposition type is 'by-reference' needs to be handled according to a reference to the body part that is located in the same SIP message as the body part (given that SIP only allows forward references, the reference will appear in the same SIP message before the body part). A recipient of a body part whose disposition type is 'by-reference' that cannot find any reference to the body part (e.g., the reference was in a header field the recipient does not support and, thus, did not process) MUST NOT process the body part. Consequently, if the handling of the body part was required, the UA needs to report an error.
处置类型为“按引用”的主体部分需要根据对主体部分的引用进行处理，该主体部分位于与主体部分相同的SIP消息中（假设SIP仅允许转发引用，则该引用将出现在主体部分之前的相同SIP消息中）。处置类型为“通过引用”的身体部位的接收者，如果找不到对身体部位的任何引用（例如，引用位于接收者不支持的标题字段中，因此未处理），则不得处理身体部位。因此，如果需要处理身体部位，UA需要报告错误。
Note that extensions that predate this specification use references to body parts whose disposition type is not 'by-reference'. Those extensions use option-tags to make sure the recipient understands the whole extension and, thus, cannot miss the reference and attempt to process the body part according to its disposition type alone.
请注意，本规范之前的扩展使用了对处置类型不是“按引用”的车身零件的引用。这些扩展使用选项标记来确保接收者理解整个扩展，因此，不能错过引用并试图仅根据其处置类型处理身体部位。
These guidelines are intended for authors of SIP extensions that involve, in some way, message bodies or body parts. These guidelines discuss aspects that authors of such extensions need to consider when designing them.
这些指南是为在某种程度上涉及消息主体或主体部分的SIP扩展的作者设计的。这些指南讨论了这些扩展的作者在设计它们时需要考虑的方面。
This specification mandates support for 'multipart/mixed' and 'multipart/alternative'. At present, there are no SIP extensions that use different 'multipart' subtypes such as parallel [RFC2046] or digest [RFC2046]. If such extensions were to be defined in the future, their authors would need to make sure (e.g., by using an option-tag or by other means) that entities receiving those 'multipart' subtypes were able to process them. As stated earlier, UAs treat unknown 'multipart' subtypes as 'multipart/mixed'.
本规范要求支持“多部分/混合”和“多部分/备选方案”。目前，没有使用不同“多部分”子类型（如并行[RFC2046]或摘要[RFC2046]）的SIP扩展。如果将来要定义此类扩展，则其作者需要确保（例如，通过使用选项标记或其他方式）接收这些“多部分”子类型的实体能够处理它们。如前所述，UAs将未知的“多部分”子类型视为“多部分/混合”。
Authors of SIP extensions making use of 'multipart/related' bodies have to explicitly address the handling of the disposition types of the body parts within the 'multipart/related' body. Authors wishing to make use of 'multipart/related' bodies should keep in mind that UAs that do not understand 'multipart/related' will treat it as 'multipart/mixed'. If such treatment by a recipient is not acceptable for a particular extension, the authors of such extension would need to make sure (e.g., by using an option-tag or by other means) that entities receiving the 'multipart/related' body were able to correctly process them.
使用“多部分/相关”主体的SIP扩展的作者必须明确处理“多部分/相关”主体中主体部分的处置类型。希望使用“多部分/相关”正文的作者应记住，不理解“多部分/相关”的UAs将其视为“多部分/混合”。如果收件人的此类处理不适用于特定扩展，则此类扩展的作者需要确保（例如，通过使用选项标签或其他方式）接收“多部分/相关”主体的实体能够正确处理它们。
As stated earlier, SIP extensions can also include 'multipart' MIME bodies in responses. Hence, a response can be extremely complex and the UAC receiving the response might not be able to process it correctly. Because UACs receiving a response cannot report errors to the UAS that generated the response (i.e., error responses can only be generated for requests), authors of SIP extensions need to make sure that requests clearly indicate (e.g., by using an option-tag or by other means) the capabilities of the UAC so that UASs can decide what to include in their responses.
如前所述，SIP扩展还可以在响应中包含“多部分”MIME主体。因此，响应可能非常复杂，接收响应的UAC可能无法正确处理它。由于接收响应的UAC无法向生成响应的UAS报告错误（即，只能为请求生成错误响应），SIP扩展的作者需要确保请求明确指示（例如，通过使用选项标记或其他方式）UAC的能力，以便UAS可以决定在其响应中包含哪些内容。
This document specifies how SIP entities handle message bodies. [RFC3261] discusses what type of information is encoded in SIP message bodies and how SIP entities can protect that information. In addition to the hop-by-hop security SIP can provide, SIP can also secure information in an end-to-end fashion. SIP message bodies can be end-to-end encrypted and integrity protected using S/MIME [RFC3851], as described in [RFC3261].
本文档指定SIP实体如何处理消息体。[RFC3261]讨论SIP消息体中编码的信息类型以及SIP实体如何保护该信息。除了SIP可以提供逐跳安全性之外，SIP还可以以端到端的方式保护信息。SIP消息体可以使用S/MIME[RFC3851]进行端到端加密和完整性保护，如[RFC3261]中所述。
This document contains two actions that have been completed by IANA.
本文件包含IANA已完成的两项行动。
This document defines a new Content-Disposition header field disposition type (by-reference) Section 9.4. This value has been registered in the IANA registry for Mail Content Disposition Values with the following description:
本文件第9.4节定义了新的内容处置标题字段处置类型（通过参考）。此值已在IANA注册表中注册为邮件内容处置值，描述如下：
by-reference The body needs to be handled according to a reference to the body that is located in the same SIP message as the body.
通过引用，需要根据与主体位于同一SIP消息中的对主体的引用来处理主体。
References to this specification, to [RFC3204], and to [RFC3459] have been added to the entry for the Content-Disposition 'handling' parameter in the Header Field Parameters and Parameter Values registry. The following is the resulting entry.
已将对本规范、[RFC3204]和[RFC3459]的引用添加到标题字段参数和参数值注册表中内容处置“处理”参数的条目中。以下是结果条目。
Predefined
Header Field Parameter Name Values Reference
------------------- --------------- --------- -------------------
Content-Disposition handling Yes [RFC3204] [RFC3261]
[RFC3459] [RFC5621]
Predefined
Header Field Parameter Name Values Reference
------------------- --------------- --------- -------------------
Content-Disposition handling Yes [RFC3204] [RFC3261]
[RFC3459] [RFC5621]
The ideas in this document were originally discussed with Paul Kyzivat. Christer Holmberg, Francois Audet, Dan Wing, Adam Roach, Keith Drage, and Dale Worley provided comments on it. Dave Crocker performed a thorough review on the whole document.
本文件中的想法最初是与Paul Kyzivat讨论的。Christer Holmberg、Francois Audet、Dan Wing、Adam Roach、Keith Drage和Dale Worley对此发表了评论。戴夫·克罗克对整个文件进行了彻底的审查。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[RFC2183]Troost，R.，Dorner，S.，和K.Moore，“在Internet消息中传递表示信息：内容处置头字段”，RFC 2183，1997年8月。
[RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.
[RFC2387]Levinson，E.“MIME多部分/相关内容类型”，RFC 2387，1998年8月。
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[RFC2392]Levinson，E.“内容ID和消息ID统一资源定位器”，RFC 2392，1998年8月。
[RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG Objects", RFC 3204, December 2001.
[RFC3204]Zimmerer，E.，Peterson，J.，Vemuri，A.，Ong，L.，Audet，F.，Watson，M.，和M.Zonoun，“ISUP和QSIG对象的MIME媒体类型”，RFC 32042001年12月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3459] Burger, E., "Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter", RFC 3459, January 2003.
[RFC3459]Burger，E.“关键内容多用途Internet邮件扩展（MIME）参数”，RFC 3459，2003年1月。
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[RFC3851]Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 38512004年7月。
[RFC3959] Camarillo, G., "The Early Session Disposition Type for the Session Initiation Protocol (SIP)", RFC 3959, December 2004.
[RFC3959]Camarillo，G.“会话启动协议（SIP）的早期会话处置类型”，RFC 3959，2004年12月。
[RFC4483] Burger, E., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006.
[RFC4483]Burger，E.“会话初始化协议（SIP）消息中的内容间接寻址机制”，RFC 4483，2006年5月。
[RFC2616] 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.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[RFC3428]Campbell，B.，Rosenberg，J.，Schulzrinne，H.，Huitema，C.，和D.Gurle，“即时消息的会话启动协议（SIP）扩展”，RFC 34282002年12月。
[RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 4289, December 2005.
[RFC4289]Freed，N.和J.Klensin，“多用途互联网邮件扩展（MIME）第四部分：注册程序”，BCP 13，RFC 4289，2005年12月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4662, August 2006.
[RFC4662]Roach，A.，Campbell，B.，和J.Rosenberg，“资源列表的会话启动协议（SIP）事件通知扩展”，RFC 4662，2006年8月。
[RFC5368] Camarillo, G., Niemi, A., Isomaki, M., Garcia-Martin, M., and H. Khartabil, "Referring to Multiple Resources in the Session Initiation Protocol (SIP)", RFC 5368, October 2008.
[RFC5368]Camarillo，G.，Niemi，A.，Isomaki，M.，Garcia Martin，M.，和H.Khartabil，“会话启动协议（SIP）中的多资源引用”，RFC 5368，2008年10月。
[RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., and P. Kyzivat, "A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer", RFC 5547, May 2009.
[RFC5547]Garcia Martin，M.，Isomaki，M.，Camarillo，G.，Loreto，S.，和P.Kyzivat，“启用文件传输的会话描述协议（SDP）提供/应答机制”，RFC 5547，2009年5月。
Author's Address
作者地址
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: Gonzalo.Camarillo@ericsson.com
EMail: Gonzalo.Camarillo@ericsson.com