Packaging and Negotiation of INFO Methods for the Session Initiation Protocol (SIP)

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

The SIP INFO Method is defined in RFC 2976. The purpose of INFO, as described therein, is The purpose of the INFO message is "to carry application level information along the SIP signaling path." This purpose is further clarified as "The INFO method is not used to change the state of SIP calls, or the parameters of the sessions SIP initiates. It merely sends optional application layer information, generally related to the session." However, RFC 2976 is restrained in its discussion of the semantics and usage of info. Particularly, it says "There are no specific semantics associated with INFO. The semantics are derived from the body or new headers defined for usage in INFO." RFC 2976 further says "Handling of INFO messages that contain message bodies is outside the scope of this document. The documents defining the message bodies will also need to define the SIP protocol rules associated with those message bodies." This lack of specificity has given rise to concerns such as those defined in draft-rosenberg-sip-info-harmful that poorly documented uses of INFO might become commonplace, and that the lack of a negotiation mechanism for uses of INFO might make determining when and how two communication applications should use INFO dificult. This situation would not provide favorable conditions for the reliable interoperability expected of Internet protocols. The SIP Events specification RFC 3265 dealt with a similar problem of documentation and negotiation problem through the use of a registration template called an "event package", an accompanying IANA registray, and the use of a SIP extension header field "allow-events". This document uses a similar approach, specifying a registration template called an "info package", an accompanying IANA registry, and the SIP extension header field "Allow-Info". An options tag "info-package" is also provided to enable the negotiation of this capability using SIP options negotiation. The extension header field "Info-Type" is used in INFO requests to identify the type of information being transmitted in the request.

The info package mechanism is applicable whenever an application makes use of the SIP INFO method. Any pre-existing usage of the INFO method will require publictaion and usage of an appropriate INFO package for conformance with thsi document.

The Allow-Info header field is a SIP extension header field. It is used in conjunction with SIP requests to which the response may instantiate a dialog (e.g., INVITE, SUBSCRIBE) and with responses to the SIP OPTIONS request to indicate support for a set of info packages by the application issuing the request or response. Multiple instances of the Allow-Info header field may be present in a request or response, in which case the value is equivalent to the unordered union of all values in the set of Allow-Info header fields. The syntax for Allow-Info is defined as follows: Allow-Info = "Allow-Info" HCOLON info-value * (COMMA) info-value ) info-value = token Note that the value specified MUST be registered in the IANA-maintained INFO Packages Namespace registry specified in this document. Support for the Allow-Info header field MUST be indicated by the inclusion of the "info-package" option tag as a value in the Supported header field of the request or reponse containing the Allow-Info header field. Implementations conformant with this specification MUST include the options tag "info-package" in all "Supported" header fields, and SHOULD include a "Supported" header field in all requests. Furthermore, whenever "info-package" is indicated as supported in a request or response, conformant implementations MUST include an "Allow-Info" header field containing as values the registered info package names of all info packages supported by that implementation in the context of that specific request or response. The allowable usage of header fields is described in tables 2 and 3 of RFC 3261. The following additions to this table are required:

Addition of Allow-Info to SIP Table 2:

The Info-Type header field is a SIP extension header field. It is used in conjunction with SIP INFO requests to indicate the specific Info Package relevant to the containing INFO request. The syntax for Info-Type is defined as follows: Info-Type = "Info-Type" HCOLON info-value info-value = token Note that the value specified MUST be registered in the IANA-maintained INFO Packages Namespace registry specified in this document. Support for the Info-Type header field MUST be indicated by the inclusion of the "info-package" option tag as a value in the Supported header field of the request or reponse containing the Allow-Info header field. Implementations conformant with this specification MUST include the options tag "info-package" in all "Supported" header fields, and SHOULD include a "Supported" header field in all requests. Imeplementations MUST include an "Info-Type" header field conatining as a )singular) value the registered Info Package na. The allowable usage of header fields is described in tables 2 and 3 of RFC 3211. The following additions to this table are required:

Addition of Info-Type to SIP Table 2:

This document does not define any info packages. Such packages will be defined by additional documents, published a standard, informational, experimental, or best-current-practice RFCs. In accordnance with the SIP Change process as documented in draft-tsvarea-sipchange, such documented shoud be accorded expert review by the SIP Working Group or its successor under that process.

The Info Package framework provides both for negotiating which info packages may be applied, and for declaring which INFO package is being applied to a specific INFO message.

A SIP UA that understands Info Packages inserts the allow-info option tag as a value in a Supported header field. A UA receiving a message containing an all-info option tag (that understands this option tag) therefore knows that the sender understands Info Packages and is prepared to receive an Info request qualified by the Info-Type headerfield. A SIP UA that understands Info=Packages and sends a request or response including an allow-info option tag also includes an Allow-Info header field listing as values the info packages it is willing to support. Consequently, usage of the allow-info option tag and the Allow-Info header field and associated values allows each UA in a dialog to positively discover that which of its peers in the dialog support Info Packages,and specifically which Info Packages they are willing to support. .

A SIP UA sending an INFO request indicates the Info Package applicable to that request by including an Info-Type header field that contains a value indicating the specific Info Package being applied.

There are few security considerations for this draft beyond those in RFC 3261. In particular, the threat model and defenses specified therien apply. However, special guidance may be necessary for particular usages of INFO which may be specified in INFO packages documented and registered as described in this document. Where appropriate, such packages must document any security considerations that apply to the associated usage of INFO.

This document defines the SIP extension header field "Allow-Info", which IANA will add to the registry of SIP header fields defined in RFC 3261. This document also defines a new SIP option tag "info-package" which IANA will add to the registry of SIP option tags defined in RFC 3261. The following is the registration for the Allow-Info header field: RFCXXXX [Note to IANA: Fill in with the RFC number of this specification.] Allow-Info none The following is the registration for the info-package option tag: RFCXXXX [Note to IANA: Fill in with the RFC number of this specification.] info-package

This document defines a new registry for "SIP Info Packages Namespace" to be maintained by IANA. This registry shall include the following fields: Package Name: The assigned name of the package. Contact: The name and email address of the registering party. Reference: The number of the RFC documenting the package. This document defines no packages to be added to this regisry, so this registry will initially be blank. IANA is instructed to add packages to this registry upon publication of an RFC that defines the package name and its usage and directs IANA to add a package name to this registry. Such RFCs MUST be reviewed by the SIP Working Group or its successor in accordance with the SIP Change Process defined in draft-tsvarea-sipchange.