diff options
Diffstat (limited to 'doc/rfc/rfc5621.txt')
| -rw-r--r-- | doc/rfc/rfc5621.txt | 1067 |
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc5621.txt b/doc/rfc/rfc5621.txt new file mode 100644 index 0000000..6dfc41d --- /dev/null +++ b/doc/rfc/rfc5621.txt @@ -0,0 +1,1067 @@ + + + + + + +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) + +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. + +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. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + 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. + + + + + + + + + + + + + + + + + + + +Camarillo Standards Track [Page 1] + +RFC 5621 Message Body Handling in SIP September 2009 + + +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 + + + + + + + + +Camarillo Standards Track [Page 2] + +RFC 5621 Message Body Handling in SIP September 2009 + + +1. Introduction + + 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. + +2. Terminology + + 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]. + + The following abbreviations are used in this document. + + UA: User Agent + + UAC: User Agent Client + + UAS: User Agent Server + + URL: Uniform Resource Locator + +3. Message Body Encoding + + This section deals with the encoding of message bodies in SIP. + +3.1. Background on Message Body Encoding + + 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: + + + + + + + + + +Camarillo Standards Track [Page 3] + +RFC 5621 Message Body Handling in SIP September 2009 + + + 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 + + Figure 1: SIP message carrying a body + + 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: + + + + + + + + + + + + + + + + + + + + + + + + + + + +Camarillo Standards Track [Page 4] + +RFC 5621 Message Body Handling in SIP September 2009 + + + INVITE sip:conf-fact@example.com SIP/2.0 + Content-Type: multipart/mixed;boundary="boundary1" + Content-Length: 619 + + --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 + + --boundary1 + Content-Type: application/resource-lists+xml + Content-Disposition: recipient-list + + <?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 + + 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. + +3.2. UA Behavior to Encode Binary Message Bodies + + 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). + + + +Camarillo Standards Track [Page 5] + +RFC 5621 Message Body Handling in SIP September 2009 + + +4. 'multipart' Message Bodies + + This section deals with 'multipart' message bodies and their + handling. + +4.1. Background on 'multipart' Message Bodies + + [RFC3261] did not mandate support for 'multipart' message bodies in + MIME format [RFC2046]. However, since [RFC3261] was written, many + SIP extensions rely on them. + + 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]. + + 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. + + 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. + + 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. + + + + + + + + +Camarillo Standards Track [Page 6] + +RFC 5621 Message Body Handling in SIP September 2009 + + +4.2. Mandatory Support for 'multipart' Message Bodies + + 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. + + 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. + + 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. + + 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. + +4.3. UA Behavior to Generate 'multipart' Message Bodies + + 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. + + Note that UAs receiving unnecessarily nested body parts treat them + as if they were not nested. + +5. 'multipart/mixed' Message Bodies + + This section does not specify any additional behavior regarding how + to generate and process 'multipart/mixed' bodies. This section is + simply included for completeness. + + + + +Camarillo Standards Track [Page 7] + +RFC 5621 Message Body Handling in SIP September 2009 + + +6. 'multipart/alternative' Message Bodies + + This section deals with 'multipart/alternative' message bodies and + their handling. + +6.1. Background on 'multipart/alternative' Message Bodies + + 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. + + 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. + +6.2. UA Behavior to Generate 'multipart/alternative' Message Bodies + + Section 8.2 mandates all the top-level body parts within a + 'multipart/alternative' to have the same disposition type. + + 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'. + + + + + + +Camarillo Standards Track [Page 8] + +RFC 5621 Message Body Handling in SIP September 2009 + + +6.3. UA Behavior to Process 'multipart/alternative' Message Bodies + + This section does not specify any additional behavior regarding how + to process 'multipart/alternative' bodies. This section is simply + included for completeness. + +7. 'multipart/related' Message Bodies + + This section deals with 'multipart/related' message bodies and their + handling. + +7.1. Background on 'multipart/related' Message Bodies + + 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]. + +7.2. UA Behavior to Generate 'multipart/related' Message Bodies + + This section does not specify any additional behavior regarding how + to generate 'multipart/related' bodies. This section is simply + included for completeness. + +7.3. UA Behavior to Process 'multipart/related' Message Bodies + + 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 + + + +Camarillo Standards Track [Page 9] + +RFC 5621 Message Body Handling in SIP September 2009 + + + 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'. + + 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. + +8. Disposition Types + + This section deals with disposition types in message bodies. + +8.1. Background on Content and Disposition Types in SIP + + 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'. + + [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: + + 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: + + 1. if it has an unknown content type. + + 2. if it has an unknown disposition type. + + 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 + + + +Camarillo Standards Track [Page 10] + +RFC 5621 Message Body Handling in SIP September 2009 + + + 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. + + 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. + + 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. + + 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. + + 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. + + 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). + + + + + + + + + + +Camarillo Standards Track [Page 11] + +RFC 5621 Message Body Handling in SIP September 2009 + + +8.2. UA Behavior to Set the 'handling' Parameter + + 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. + + 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'. + + 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'. + + 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. + + + + + +Camarillo Standards Track [Page 12] + +RFC 5621 Message Body Handling in SIP September 2009 + + + 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'. + + 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. + + 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'. + +8.3. UA Behavior to Process 'multipart/alternative' + + 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'. + +8.4. UAS Behavior to Report Unsupported Message Bodies + + 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. + + 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. + + + +Camarillo Standards Track [Page 13] + +RFC 5621 Message Body Handling in SIP September 2009 + + + 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. + +9. Message Body Processing + + This section deals with the processing of message bodies and how that + processing is influenced by the presence of references to them. + +9.1. Background on References to Message Body Parts + + 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. + +9.2. UA Behavior to Generate References to Message Bodies + + 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. + + 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. + +9.3. UA Behavior to Process Message Bodies + + 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 + + + +Camarillo Standards Track [Page 14] + +RFC 5621 Message Body Handling in SIP September 2009 + + + 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. + + 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. + + 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. + +9.4. The 'by-reference' Disposition Type + + 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. + + 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. + + 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. + + + +Camarillo Standards Track [Page 15] + +RFC 5621 Message Body Handling in SIP September 2009 + + +10. Guidelines to Authors of SIP Extensions + + 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. + + 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'. + + 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. + + 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. + +11. Security Considerations + + 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]. + + + + + +Camarillo Standards Track [Page 16] + +RFC 5621 Message Body Handling in SIP September 2009 + + +12. IANA Considerations + + This document contains two actions that have been completed by IANA. + +12.1. Registration of the 'by-reference' Disposition Type + + 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: + + 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. + +12.2. Update of the 'handling' Parameter Registration + + 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. + + Predefined + Header Field Parameter Name Values Reference + ------------------- --------------- --------- ------------------- + Content-Disposition handling Yes [RFC3204] [RFC3261] + [RFC3459] [RFC5621] + +13. Acknowledgements + + 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. + +14. References + +14.1. Normative References + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", RFC 2046, + November 1996. + + + + + +Camarillo Standards Track [Page 17] + +RFC 5621 Message Body Handling in SIP September 2009 + + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating + Presentation Information in Internet Messages: The + Content-Disposition Header Field", RFC 2183, August 1997. + + [RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", + RFC 2387, August 1998. + + [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource + Locators", RFC 2392, August 1998. + + [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. + + [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. + + [RFC3459] Burger, E., "Critical Content Multi-purpose Internet Mail + Extensions (MIME) Parameter", RFC 3459, January 2003. + + [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail + Extensions (S/MIME) Version 3.1 Message Specification", + RFC 3851, July 2004. + + [RFC3959] Camarillo, G., "The Early Session Disposition Type for the + Session Initiation Protocol (SIP)", RFC 3959, + December 2004. + + [RFC4483] Burger, E., "A Mechanism for Content Indirection in + Session Initiation Protocol (SIP) Messages", RFC 4483, + May 2006. + +14.2. Informative References + + [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. + + [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., + and D. Gurle, "Session Initiation Protocol (SIP) Extension + for Instant Messaging", RFC 3428, December 2002. + + + + + +Camarillo Standards Track [Page 18] + +RFC 5621 Message Body Handling in SIP September 2009 + + + [RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail + Extensions (MIME) Part Four: Registration Procedures", + BCP 13, RFC 4289, December 2005. + + [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session + Description Protocol", RFC 4566, July 2006. + + [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session + Initiation Protocol (SIP) Event Notification Extension for + Resource Lists", RFC 4662, August 2006. + + [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. + + [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. + +Author's Address + + Gonzalo Camarillo + Ericsson + Hirsalantie 11 + Jorvas 02420 + Finland + + EMail: Gonzalo.Camarillo@ericsson.com + + + + + + + + + + + + + + + + + + + + + +Camarillo Standards Track [Page 19] + |