SIP Working Group G. Camarillo Internet-Draft Ericsson Expires: November 24, 2007 May 23, 2007 Message Body Handling in the Session Initiation Protocol (SIP) draft-camarillo-sip-body-handling-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 24, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document clarifies how message bodies are handled in SIP. Additionally, it discusses to which degree SIP user agents need to support MIME (Multipurpose Internet Mail Extensions)-encoding of body parts. Camarillo Expires November 24, 2007 [Page 1] Internet-Draft Message Body Handing in SIP May 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Message-Body and Body-Part Disposition . . . . . . . . . . . . 3 4. Multipart Message Bodies . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Camarillo Expires November 24, 2007 [Page 2] Internet-Draft Message Body Handing in SIP May 2007 1. Introduction 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. 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. Section 3 discusses issues related to the disposition of message bodies and body parts in SIP. Section 4 discusses issues related to the handling of multipart message bodies in SIP. 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]. 3. Message-Body and Body-Part Disposition 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] defines the 'handling' parameter for the Content- Disposition header field. From Section 6 of [RFC3204]: "This document also defines a Content Disposition parameter, "handling". The handling parameter, handling-parm, describes how the UAS should react 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 MUST ignore the message body; if it has the value "required", the UAS MUST return 415 (Unsupported Media Type). If the handling parameter is missing, the value "required" is to be assumed." [RFC3204] identifies two situations where a UAS (User Agent Server) Camarillo Expires November 24, 2007 [Page 3] Internet-Draft Message Body Handing in SIP May 2007 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 (User Agent Server) did not understand the content type of the body part, it can add an Accept header field to its 415 (Unsupported Media Type) response listing the content types that the UAS does understand. Nevertheless, there is no mechanism for a UAS that does not understand the disposition type of a body part to inform the UAC (User Agent Client) 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 (User Agent) may not support the disposition type. For example, a UA may 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 may support the 'render' disposition type for 'text/plain' and 'text/html' body parts in MESSAGE requests. Additionally, the UA may support the 'session' disposition type for 'application/sdp' body parts in INVITE and UPDATE requests and their responses. However, the UA may not support the 'render' disposition type for 'application/sdp' body parts in MESSAGE requests, even if, in different contexts, the UA supported all 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. 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). The previous two rules are to be followed by authors of new SIP extensions. In any case, if a UAS cannot process a request because, in the given Camarillo Expires November 24, 2007 [Page 4] Internet-Draft Message Body Handing in SIP May 2007 context, it 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. Content-ID URLs (Uniform Resource Locators) are another tool to describe how a body part should be handled. Some extensions use a Content-ID URL [RFC2392] that points to a body part. The way to handle that body part is defined by the header field the Content-ID URL appears in and by the disposition type of the body part. For example, the extension to refer to multiple resources in SIP [I-D.ietf-sip-multiple-refer] places a Content-ID URL in a Refer-To header field. Such a Content-ID URL points to a body part whose disposition type is supposed to be 'recipient-list'. If a UAS receives a request with a body part whose disposition type is not compatible with the way the body part should 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. OPEN ISSUE: we could define a new response code (Content or Disposition Type not Supported in this Context) to report known content and disposition types appearing in an unsupported context in order to be more explicit than always using 415. It would avoid receiving a 415 response with an Accept header field containing all the content types used in the request. How useful would this really be? 4. Multipart Message Bodies [RFC3261] did not mandate support for multipart message bodies in MIME format [RFC2046]. However, since [RFC3261] was written, many SIP extensions relay on them. Therefore, this specification updates [RFC3261]'s recommendation regarding support for multipart MIME bodies. It is expected that most SIP UAs will implement extensions that require them to generate 'multipart/mixed' MIME bodies. An example of such an extension would be the inclusion of location information in an INVITE request. Such an INVITE request would use the 'multipart/mixed' MIME type to carry two body parts: a session description and a location object. Another MIME type a number of SIP UAs will need to generate is 'multipart/alternative'. Each body part within a 'multipart/ Camarillo Expires November 24, 2007 [Page 5] Internet-Draft Message Body Handing in SIP May 2007 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. This way, the recipient of a 'multipart/alternative' body chooses the last body part it understands. Therefore, 'multipart/alternative' body parts MUST all have different content types. That is, no body part within a 'multipart/alternative' can have the same content type as another body part within the same 'multipart/alternative'. Note that within a body part encoded in a given format (i.e., of a given content type), there may be optional elements that may 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. It is expected that the transition from SDP to new session description protocols is implemented using 'multipart/alternative' bodies. INVITE requests would 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 UASs would use the session description written in SDP. New UASs would use the one written in the newer format. A number of SIP UAs will also need to generate nested MIME bodies. 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. For all MIME-based extensions to work, the recipient needs to, of course, be able to decode the multipart bodies. Therefore, SIP UAs SHOULD be able to parse 'multipart' MIME bodies, including nested body parts. In particular, UAs SHOULD support the 'multipart/mixed' and 'multipart/alternative' MIME types. Note that, by default, unknown 'multipart' subtypes are treated as 'multipart/mixed'. If a UAS does not support multipart bodies and receives one, the UAS SHOULD return a 415 (Unsupported Media Type) response. OPEN ISSUE: do we need to talk about encrypted body parts? Camarillo Expires November 24, 2007 [Page 6] Internet-Draft Message Body Handing in SIP May 2007 5. Security Considerations TBD. 6. Acknowledgements The ideas in this document were discussed with Paul Kyzivat. Christer Holmberg provided comments on this document. 7. IANA Considerations This document does not contain any IANA actions. 8. 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. [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. [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. [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 Expires November 24, 2007 [Page 7] Internet-Draft Message Body Handing in SIP May 2007 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [I-D.ietf-sip-multiple-refer] Camarillo, G., "Referring to Multiple Resources in the Session Initiation Protocol (SIP)", draft-ietf-sip-multiple-refer-01 (work in progress), January 2007. Author's Address Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Gonzalo.Camarillo@ericsson.com Camarillo Expires November 24, 2007 [Page 8] Internet-Draft Message Body Handing in SIP May 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. 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. 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Camarillo Expires November 24, 2007 [Page 9]