| TOC |
|
This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.
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 16, 2002.
Copyright (C) The Internet Society (2002). All Rights Reserved.
The SIP INFO method (RFC 2976) establishes a method by which applications may transfer application-specific information within a SIP dialog. However, RFC 2976 does not provide a mechanism for describing and documenting an application of INFO, nor does it provide a mechanism by which applications may negotiate such uses. This document provides a framework for documenting and naming specific uses of INFO (called INFO packages), for registering those package names with IANA, and for negotiating the support for various INFO packages between applications using SIP.
| TOC |
| TOC |
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[2].
| TOC |
The SIP INFO Method is defined in RFC 2976[4]. 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[4] 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[4] 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[8] 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[6] 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.
| TOC |
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.
| TOC |
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 3162[5]. The following additions to this table are required:
Addition of Allow-Info to SIP Table 2:
Header field where proxy ACK BYE CAN INV OPT REG PRA
_______________________________________________________________
Allow-Info - - - - o o o -
| TOC |
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 3162[5]. The following additions to this table are required:
Addition of Info-Type to SIP Table 2:
Header field where proxy ACK BYE CAN INV OPT REG PRA
_______________________________________________________________
Info-Type INFO - - - - - - - -
| TOC |
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[7], such documented shoud be accorded expert review by the SIP Working Group or its successor under that process.
| TOC |
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.
| TOC |
There are few security considerations for this draft beyond those in RFC 3162[5]. 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.
| TOC |
This document defines the SIP extension header field "Allow-Info", which IANA will add to the registry of SIP header fields defined in RFC 3162[5].
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 3162[5].
The following is the registration for the Allow-Info header field:
- RFC Number:
- RFCXXXX [Note to IANA: Fill in with the RFC number of this specification.]
- Header Field Name:
- Allow-Info
- Compact Form:
- none
The following is the registration for the info-package option tag:
- RFC Number:
- RFCXXXX [Note to IANA: Fill in with the RFC number of this specification.]
- Option Tag:
- 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[7].
| TOC |
| [1] | Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. |
| [2] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [3] | Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997 (TXT, HTML, XML). |
| [4] | Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. |
| [5] | Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001. |
| [6] | Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. |
| [7] | Mankin, A., "SIP Change Process", draft-tsvarea-sipchange-03 (work in progress), December 2002. |
| TOC |
| [8] | Rosenberg, JDR., "The Session Initiation Protocol (SIP) INFO Method Considered Harmful", draft-rosenberg-sip-info-harmful-00 (work in progress), January 2003. |
| TOC |
| Dean Willis | |
| dynamicsoft Inc. | |
| 5100 Tennyson Parkway | |
| Suite 1200 | |
| Plano, TX 75028 | |
| US | |
| Phone: | +1 972 473 5455 |
| EMail: | dean.willis@softarmor.com |
| URI: | http://www.dynamicsoft.com/ |
| TOC |
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
Funding for the RFC Editor function is currently provided by the Internet Society.