Internet DRAFT - draft-hilt-sip-ext-neg

draft-hilt-sip-ext-neg




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]