One document matched: draft-willis-sip-infopackage-00.txt
SIP -- Session Initiation Protocol D. Willis
Working Group dynamicsoft Inc.
Internet-Draft January 15, 2002
Expires: July 16, 2002
Packaging and Negotiation of INFO Methods for the Session Initiation
Protocol (SIP)
draft-willis-sip-infopackage-00
Status of this Memo
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 Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
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.
Willis Expires July 16, 2002 [Page 1]
Internet-Draft SIP INFO Packaging and Negotiation January 2002
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4
4. Allow-Info Header Field Definition and Syntax . . . . . . . . 4
5. Info-Type Header Field Definition and Syntax . . . . . . . . . 5
6. Registration of Info Packages . . . . . . . . . . . . . . . . 6
7. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1 Usage in Negotiation . . . . . . . . . . . . . . . . . . . . . 6
7.2 Usage in INFO Deliveries . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9.1 Additions to Existing SIP Registries . . . . . . . . . . . . . 7
9.2 INFO Package Registry . . . . . . . . . . . . . . . . . . . . 8
Normative References . . . . . . . . . . . . . . . . . . . . . 8
Non-Normative References . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 10
Willis Expires July 16, 2002 [Page 2]
Internet-Draft SIP INFO Packaging and Negotiation January 2002
1. Terminology
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].
2. Background
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.
Willis Expires July 16, 2002 [Page 3]
Internet-Draft SIP INFO Packaging and Negotiation January 2002
3. Applicability Statement
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.
4. Allow-Info Header Field Definition and Syntax
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:
Willis Expires July 16, 2002 [Page 4]
Internet-Draft SIP INFO Packaging and Negotiation January 2002
Addition of Allow-Info to SIP Table 2:
Header field where proxy ACK BYE CAN INV OPT REG PRA
_______________________________________________________________
Allow-Info - - - - o o o -
Figure 1
5. Info-Type Header Field Definition and Syntax
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:
Willis Expires July 16, 2002 [Page 5]
Internet-Draft SIP INFO Packaging and Negotiation January 2002
Addition of Info-Type to SIP Table 2:
Header field where proxy ACK BYE CAN INV OPT REG PRA
_______________________________________________________________
Info-Type INFO - - - - - - - -
Figure 2
6. Registration of Info Packages
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.
7. Usage
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.
7.1 Usage in Negotiation
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.
Willis Expires July 16, 2002 [Page 6]
Internet-Draft SIP INFO Packaging and Negotiation January 2002
7.2 Usage in INFO Deliveries
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.
8. Security Considerations
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.
9. IANA Considerations
9.1 Additions to Existing SIP Registries
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.]
Willis Expires July 16, 2002 [Page 7]
Internet-Draft SIP INFO Packaging and Negotiation January 2002
Option Tag: info-package
9.2 INFO Package Registry
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].
Normative References
[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.
[3] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC
2223, October 1997.
[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.
Non-Normative References
[8] Rosenberg, JDR., "The Session Initiation Protocol (SIP) INFO
Method Considered Harmful", draft-rosenberg-sip-info-harmful-00
(work in progress), January 2003.
Willis Expires July 16, 2002 [Page 8]
Internet-Draft SIP INFO Packaging and Negotiation January 2002
Author's Address
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/
Willis Expires July 16, 2002 [Page 9]
Internet-Draft SIP INFO Packaging and Negotiation January 2002
Intellectual Property Statement
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.
Full Copyright Statement
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
Willis Expires July 16, 2002 [Page 10]
Internet-Draft SIP INFO Packaging and Negotiation January 2002
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Willis Expires July 16, 2002 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 21:25:19 |