Session Initiation Protocol V. Hilt Working Group Bell Labs/Lucent Technologies Internet-Draft J. Rosenberg Expires: July 20, 2005 Cisco Systems G. Camarillo Ericsson January 19, 2005 Media Type Extension Negotiation in the Session Initiation Protocol (SIP) Accept Header Field draft-hilt-sip-ext-neg-00 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 July 20, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This specification defines the profile parameter for the SIP Accept header field. This parameter is used to negotiate support for MIME media type extensions. Hilt, et al. Expires July 20, 2005 [Page 1] Internet-Draft MIME Extension Negotiation January 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Profile Accept Header Field Parameter . . . . . . . . . . . . 4 4. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 4 5. Applicability to Other Protocols . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . 8 Hilt, et al. Expires July 20, 2005 [Page 2] Internet-Draft MIME Extension Negotiation January 2005 1. Introduction The Accept header field in the Session Initiation Protocol (SIP) [11] provides a mechanism for user agents to negotiate the media types they can accept in message bodies. With this mechanism, a user agent can announce the MIME media types it supports to another user agent. Many media types used in SIP message bodies are based on the Extensible Markup Language (XML) [13]. XML features a powerful extension mechanism that enables the use of multiple vocabularies in a single XML document. Components from different vocabularies can be uniquely identified using XML namespaces [5]. The extensibility of XML poses a problem for MIME media type based content negotiation. The negotiation only covers major media types and does not include language extensions and variations. For example, a user agent can indicate its support for the media type 'application/pidf+xml' (Presence Information Data Format) [12] but cannot indicate that it is also capable of handling the Location Object Extension to PIDF [10] and the location format GML 3.0 [9]. The capability to negotiate support for a language extension or variation is in particular useful in the following cases: 1. The interpretation of the content by the receiver depends on understanding the extension or language variation used. 2. Different versions of the content can be made available depending on the extensions or language variations supported by the receiver. Unsupported extensions can be omitted by the sender to avoid, for example, transmission overhead or costs associated with gathering the information. In this specification, we propose a new parameter for the Accept header field that enables the negotiation of extensions to MIME media types. The problem of negotiating support for language extensions and variations has been addressed for a number of specific MIME media types. For example, [1] and [6] define a profile parameter for the MIME media types XHTML and SMIL respectively. However, these solutions are limited to a specific media type and require the registration of a new MIME parameter for each media type that is extended. An abstract framework for content negotiation has been defined in [7]. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", Hilt, et al. Expires July 20, 2005 [Page 3] Internet-Draft MIME Extension Negotiation January 2005 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, [2] and indicate requirement levels for compliant implementations. 3. Profile Accept Header Field Parameter The profile parameter is a new parameter for the Accept header field. It MAY appear multiple times (including zero) in an Accept header field. The profile parameter contains a URI that identifies an extension or a variation of the underlying MIME media type. Currently, the profile parameter is only defined for XML-based media types, which are registered with a '+xml' suffix. For these media types, the URI in the profile parameter identifies an XML namespace. This URI is identical to the URI that would be used in an XML document (e.g. in the XMLNS tag) to identify the same namespace. The syntax of the 'profile' Accept header field parameter is: profile-param = absoluteURI This extends the existing definition of the Accept header field parameters in [11], so that its BNF now looks like: accept-param = ("q" EQUAL qvalue) / profile-param / generic-param Example: Accept: application/pidf+xml; profile=urn:ietf:params:xml:ns:pidf:geopriv10; profile=urn:opengis:specification:gml:schema-xsd:feature:v3.0 4. User Agent Behavior A user agent, which supports an extension or variation of a MIME media type, SHOULD list this extension or language variation in a profile parameter inserted into the Accept header field of the MIME media type. A user agent SHOULD identify all supported extensions and language variations. It SHOULD NOT list items (e.g. XML namespaces) that are by default part of the media type. A user agent receiving an Accept header field with a profile parameter can assume that the sender supports the listed extensions and variations and MAY use them to create message bodies. Note: The absence of an extension in the profile parameter (or the absence of the profile parameter) does not mean the sender does Hilt, et al. Expires July 20, 2005 [Page 4] Internet-Draft MIME Extension Negotiation January 2005 not support that extension. 5. Applicability to Other Protocols Although this extension has been developed for the SIP Accept header field, it is applicable to the Accept header field of other protocols such as HTTP. Note: For this broader use, the profile parameter needs to be registered for the respective protocols or in the registry defined in [8]. 6. Security Considerations Security considerations for the Accept header field also apply here. 7. IANA Considerations This document adds a parameter to the SIP header field parameter registry [4]: Header field in which the parameter can appear: Accept Name of the parameter: profile The parameter only accepts a set of predefined values: No Reference: this document 8 References [1] Baker, M. and P. Stark, "The 'application/xhtml+xml' Media Type", RFC 3236, January 2002. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004. [4] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004. [5] Hollander, D., Bray, T. and A. Layman, "Namespaces in XML", W3C REC REC-xml-names-19990114, January 1999. [6] Hoschka, P., "The application/smil and application/smil+xml Hilt, et al. Expires July 20, 2005 [Page 5] Internet-Draft MIME Extension Negotiation January 2005 Media Types", draft-hoschka-smil-media-type-12 (work in progress), August 2004. [7] Klyne, G., "Protocol-independent Content Negotiation Framework", RFC 2703, September 1999. [8] Klyne, G., Nottingham, M. and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004. [9] OpenGIS, "Open Geography Markup Language (GML) Implementation Specification", OGC 02-023r4, January 2003. [10] Peterson, J., "A Presence-based GEOPRIV Location Object Format", draft-ietf-geopriv-pidf-lo-03 (work in progress), September 2004. [11] 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. [12] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004. [13] Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T. and E. Maler, "Extensible Markup Language (XML) 1.0 (Third Edition)", W3C REC REC-xml-20040204, February 2004. Authors' Addresses Volker Hilt Bell Labs/Lucent Technologies 101 Crawfords Corner Rd Holmdel, NJ 07733 USA EMail: volkerh@bell-labs.com Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 USA EMail: jdrosen@cisco.com Hilt, et al. Expires July 20, 2005 [Page 6] Internet-Draft MIME Extension Negotiation January 2005 Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland EMail: Gonzalo.Camarillo@ericsson.com Hilt, et al. Expires July 20, 2005 [Page 7] Internet-Draft MIME Extension Negotiation January 2005 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 (2005). 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. Hilt, et al. Expires July 20, 2005 [Page 8]