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]