SIP Working Group G. Camarillo Internet-Draft Ericsson Expires: June 2, 2005 December 2, 2004 The Session Initiation Protocol (SIP) Accept-Disposition Header Field draft-camarillo-sip-accept-disposition-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 June 2, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document defines the SIP Accept-Disposition header field. User agents use this header field to indicate the disposition types they support. Camarillo Expires June 2, 2005 [Page 1]
Internet-Draft Accept-Disposition Header Field December 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. The Accept-Disposition Header Field . . . . . . . . . . . . . 4 4. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Normative References . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . 7 Camarillo Expires June 2, 2005 [Page 2]
Internet-Draft Accept-Disposition Header Field December 2004 1. Introduction SIP [5] 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 of a SIP message can be divided into various body parts and is encoded using the MIME (Multipurpose Internet Mail Extensions) [1] format. Body parts are described using header fields such as Content-Disposition, Content-Encoding, and Content-Type, which provide information on the contents of a particular body part. In particular, the Content-Disposition header field, defined in RFC 2183 [3] and extended by RFC 3261 [5], describes how to handle an individual body part. Examples of disposition types used in SIP in the Content-Disposition header field are 'session' and 'render'. RFC 3204 [4] defines the 'handling' parameter for the Content-Disposition header field. From Section 6 of RFC 3204: "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." RFC 3204 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, it can add a Accept header field to its 415 (Unsupported Media Type) response listing the content types that the UAS does understand. Nevertheless, there is no way for a UAS that does not understand the disposition type of a body part to inform the UAC (User Agent Client) about the disposition types that are understood by the UAS. This document defines the Accept-Disposition header field, whose semantics and associated protocol behavior is similar to those of the Accept header field, but applies to disposition types instead of to content types. Camarillo Expires June 2, 2005 [Page 3]
Internet-Draft Accept-Disposition Header Field December 2004 Note that the same content type can be associated to different disposition types in different body parts. A UAS may support a particular content type but only a subset of all the disposition types that are associated to it. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant implementations. 3. The Accept-Disposition Header Field The Accept-Disposition header field can appear in requests and in responses. When it appears in a request, this header field contains the disposition types supported by the UAC. When it appears in a response, this header field contains the disposition types supported by the UAS. The following is the ABNF (augmented Backus-Naur Form) for the Accept-Disposition header field: Accept-Disposition = "Accept-Disposition" HCOLON [ disposition-type *(COMMA disposition-type) ] disposition-type = disp-type *( SEMI disp-param ) Section 25.1 of RFC 3261 provides the ABNF for 'disp-type' and 'disp-param'. The IANA registers values for these parameters under the registry for Mail Content Disposition Values and Parameters. An empty Accept-Disposition header field means that no disposition types are acceptable. The following is an example of an Accept-Disposition header field: Accept-Disposition: render, session 4. User Agent Behavior UACs and UASs MAY add an Accept-Disposition header field to their requests and responses to inform the other end of the disposition types they support. UASs generating a 415 (Unsupported Media Type) because a body whose handling was required and had an unknown disposition type MUST return a list of acceptable content types using the Accept-Disposition header field. Camarillo Expires June 2, 2005 [Page 4]
Internet-Draft Accept-Disposition Header Field December 2004 A UAC that receives a 415 (Unsupported Media Type) response with an Accept-Disposition header field SHOULD retry sending the request only using disposition types listed in the Accept-Disposition header field. 5. Security Considerations Attackers may attempt to add or remove Accept-Disposition header fields, or modify their contents. UAs receiving a request or a response modified in such a way by an attacker may be fooled to believe that the other end does not support a particular disposition type. In this case, the UA would refrain from using a service that is actually available. Receivers of such messages may also be fooled to believe that the other end supports a disposition type that is not really supported. In this case, the UA would attempt to use a server that is not available and therefore will fail, wasting resources unnecessary. It is therefore RECOMMENDED that integrity protection be applied to the contents of the Accept-Disposition header field. RFC 3261 describes how to integrity-protect header fields using S/MIME. 6. IANA Considerations This document defines a new SIP header field: Accept-Disposition. This header field needs to be registered by the IANA in the SIP Parameters registry under the Header Fields subregistry. 7 Normative References [1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997. [4] 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. [5] 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. Camarillo Expires June 2, 2005 [Page 5]
Internet-Draft Accept-Disposition Header Field December 2004 Author's Address Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland EMail: Gonzalo.Camarillo@ericsson.com Camarillo Expires June 2, 2005 [Page 6]
Internet-Draft Accept-Disposition Header Field December 2004 Intellectual Property Statement 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. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Camarillo Expires June 2, 2005 [Page 7]