Media Type Extension Negotiation in the Session Initiation Protocol (SIP) Accept Header Field

The Accept header field in the Session Initiation Protocol (SIP) 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) . 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 . 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) but cannot indicate that it is also capable of handling the Location Object Extension to PIDF and the location format GML 3.0 . The capability to negotiate support for a language extension or variation is in particular useful in the following cases: The interpretation of the content by the receiver depends on understanding the extension or language variation used. 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, and 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 .

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, and indicate requirement levels for compliant implementations.

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:

This extends the existing definition of the Accept header field parameters in , so that its BNF now looks like:

Example:

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 not support that extension.

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 .

Security considerations for the Accept header field also apply here.

This document adds a parameter to the SIP header field parameter registry : 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