draft-ietf-sip-refer-feature-param-00.txt   draft-ietf-sip-refer-feature-param-01.txt 
SIP Working Group O. Levin SIP Working Group O. Levin
Internet-Draft Microsoft Corporation Internet-Draft Microsoft Corporation
Updates: 3515 (if approved) A. Johnston Expires: July 17, 2006 A. Johnston
Expires: January 6, 2006 MCI Tello Corporation
July 5, 2005 January 13, 2006
Conveying Feature Tags with Session Initiation Protocol REFER Method Conveying Feature Tags with Session Initiation Protocol REFER Method
draft-ietf-sip-refer-feature-param-00 draft-ietf-sip-refer-feature-param-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 6, 2006. This Internet-Draft will expire on July 17, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document extends the SIP REFER method, defined in RFC 3515, to This document extends the REFER method, defined in RFC 3515, to
convey feature parameters defined in RFC 3840. convey feature parameters defined in RFC 3840.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. isfocus Feature Tag Usage . . . . . . . . . . . . . . . . . 4
4.2. Voice and Video Feature Tags Usage . . . . . . . . . . . . 4
4.3. Example with URI parameters and multiple feature tags . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
8. Normative References . . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . . . 7
1. Terminology 1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
To simplify discussions of the REFER method and its extensions, three To simplify discussions of the REFER method and its extensions, three
new terms are being used throughout the document: new terms are being used throughout the document:
o REFER-Issuer: the UA issuing the REFER request o REFER-Issuer: the UA issuing the REFER request
o REFER-Recipient: the UA receiving the REFER request o REFER-Recipient: the UA receiving the REFER request
o REFER-Target: the UA designated in the Refer-To URI o REFER-Target: the UA designated in the Refer-To URI
2. Introduction 2. Introduction
This document extends the SIP [2] REFER method defined in RFC 3515 This document extends REFER method defined in RFC 3515 [3] to be used
[3] to be used with feature parameters defined in RFC 3840 [4]. with feature parameters defined in RFC 3840 [4].
Feature tags are used by a SIP User Agent (UA) to convey to another Feature tags are used by a UA to convey to another UA information
UA information about capabilities and features. This information can about capabilities and features. This information can be shared by a
be shared by a UA using a number of mechanisms including registration UA using a number of mechanisms including registration requests,
requests, OPTIONS responses, or shared in the context of a dialog by OPTIONS responses, or shared in the context of a dialog by inclusion
inclusion with a remote target URI (Uniform Resource Identifier), with a remote target URI (Contact URI).
such as a Contact URI.
Feature tag information can be very useful to another UA. It is Feature tag information can be very useful to another UA. It is
especially useful prior to the establishment of a session. For especially useful prior to the establishment of a session. For
example, if a UA knows (through an OPTIONS query, for example) that example, if a UA knows (through an OPTIONS query, for example) that
the remote UA supports both video and audio, the calling UA might the remote UA supports both video and audio, the calling UA might
call offering video in its session description. Another example is call offering video in the SDP. Another example is when a UA knows
when a UA knows that a remote UA is acting as a focus and hosting a that a remote UA is acting as a focus and hosting a conference. In
conference. In this case, the UA might first subscribe to the this case, the UA might first subscribe to the conference URI and
conference URI and find out details about the conference prior to find out details about the conference prior to sending an INVITE to
sending an INVITE to join. join.
This extension to the REFER method provides a mechanism by which the This extension to the REFER method provides a mechanism by which the
REFER-Issuer can provide this useful information about the REFER- REFER-Issuer can provide this useful information about the REFER-
Target capabilities and functionality to the REFER-Recipient by Target capabilities and functionality to the REFER-Recipient by
including feature tags in the Refer-To header field in a REFER including feature tags in the Refer-To header field in a REFER
request. request.
3. Definitions 3. Definitions
The Refer-To BNF from RFC 3515: The Refer-To BNF from RFC 3515:
skipping to change at page 2, line 46 skipping to change at page 4, line 4
Target capabilities and functionality to the REFER-Recipient by Target capabilities and functionality to the REFER-Recipient by
including feature tags in the Refer-To header field in a REFER including feature tags in the Refer-To header field in a REFER
request. request.
3. Definitions 3. Definitions
The Refer-To BNF from RFC 3515: The Refer-To BNF from RFC 3515:
Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec ) Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec )
*(SEMI generic-param) *(SEMI generic-param)
is extended to: is extended to:
Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec ) Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec )
*(SEMI refer-param) *(SEMI refer-param)
refer-param = generic-param / feature-param refer-param = generic-param / feature-param
where feature-param is defined in Section 9 of RFC 3840 [4]. where feature-param is defined in Section 9 of RFC 3840 [4].
Note that if any URI parameters are present, the entire URI must be Note that if any URI parameters are present, the entire URI must be
enclosed in "&lt;" and ">". If no "<" and ">" are present, all enclosed in "&amp;lt" and "&gt". If no "&lt" and "&gt" are present, all
parameters after the URI are header parameters, not URI parameters. parameters after the URI are header parameters, not URI parameters.
4. Examples 4. Examples
4.1 isfocus Feature Tag Usage 4.1. isfocus Feature Tag Usage
The example below shows how the "isfocus" feature tag can be used by The example below shows how the "isfocus" feature tag can be used by
REFER-Issuer to tell the REFER-Recipient that the REFER-Target is a REFER-Issuer to tell the REFER-Recipient that the REFER-Target is a
conference focus and, consequently, sending an INVITE will bring the conference focus and, consequently, sending an INVITE will bring the
REFER-Recipient into the conference: REFER-Recipient into the conference:
Refer-To: <sip:conf44@example.com>;isfocus Refer-To: sip:conf44@example.com;isfocus
4.2 Voice and Video Feature Tags Usage 4.2. Voice and Video Feature Tags Usage
The example below shows how a REFER-Issuer can tell the REFER- The example below shows how a REFER-Issuer can tell the REFER-
Recipient that the REFER-Target supports audio and video and, Recipient that the REFER-Target supports audio and video and,
consequently, that a video and audio session can be established by consequently, that a video and audio session can be established by
sending an INVITE to the REFER-Target: sending an INVITE to the REFER-Target:
Refer-To: "Alice's Videophone" <sip:alice@vphone.example.com> Refer-To: "Alice's Videophone" <sip:alice@videophone.example.com>
;audio;video ;audio;video
4.3 Example with URI parameters and multiple feature tags 4.3. Example with URI parameters and multiple feature tags
The example below shows how the REFER-Issuer can tell the REFER- The example below shows how the REFER-Issuer can tell the REFER-
Recipient that the REFER-Target is a voicemail server. Note that the Recipient that the REFER-Target is a voicemail server. Note that the
transport URI parameter is enclosed within the "<" and ">" so that it transport URI parameter is enclosed within the "&lt" and "&gt" so
is not interpreted as a header parameter. that it is not interpreted as a header parameter.
Refer-To: <sip:alice-vm@example.com;transport=tcp> Refer-To: <sip:alice-vm@example.com;transport=tcp>
;actor="msg-taker";automata;audio ;actor="msg-taker";automata;audio
5. IANA Considerations 5. IANA Considerations
This document requires no actions by IANA. Note that this document None.
does not define any elements in the SIP Header Parameter Registry
[5], since it incorporates media feature parameters instead of SIP
header parameters.
6. Security Considerations 6. Security Considerations
Feature tags can provide sensitive information about a user or a UA. Feature tags can provide sensitive information about a user or a UA.
As such, RFC 3840 cautions against providing sensitive information to As such, RFC 3840 cautions against providing sensitive information to
another party. Once this information is given out, any use may be another party. Once this information is given out, any use may be
made of it, including relaying to a third party as in this made of it, including relaying to a third party as in this
specification. specification.
As a result, it is NOT RECOMMENDED that all feature tag information A REFER-Issuer MUST NOT create or guess feature tags - instead a
be passed using the mechanism described in this specification. feature tag included in a REFER SHOULD have been discovered in an
Instead, only feature tags that directly relate to a requested authenticated and secure method (such as an OPTIONS response or from
operation should be used. For example, the "isfocus" feature tag has a remote target URI in a dialog) directly from the REFER-Target.
clear operation semantics and utility. However, the "mobility" or
"class" feature tags have no obvious use in a REFER scenario and It is RECOMMENDED that the REFER-Issuer includes in the Refer-To
should not be included unless their application is defined in the header field all feature tags that were listed in the most recent
future. Contact header field of the REFER-Target.
A feature tag provided by a REFER-Issuer can not be authenticated or A feature tag provided by a REFER-Issuer can not be authenticated or
certified directly from the REFER request. As such, the REFER- certified directly from the REFER request. As such, the REFER-
Recipient MUST treat the information as hint. If the REFER-Recipient Recipient MUST treat the information as hint. If the REFER-Recipient
application logic or user's action depends on the presence of the application logic or user's action depends on the presence of the
expressed feature, the feature tag can be verified. For example, in expressed feature, the feature tag can be verified. For example, in
order to do so, the REFER-Recipient can directly send an OPTIONS order to do so, the REFER-Recipient can directly send an OPTIONS
query to the REFER-Target over a secure (e.g. mutually authenticated query to the REFER-Target over a secure (e.g. mutually authenticated
and integrity protected) connection. This protects the REFER- and integrity protected) connection. This protects the REFER-
Recipient against incorrect or malicious feature tags being sent. Recipient against incorrect or malicious feature tags being sent.
A REFER-Issuer MUST NOT create or guess feature tags - instead a
feature tag included in a REFER SHOULD have been discovered in an
authenticated and secure method (such as an OPTIONS response or from
a remote target URI in a dialog) directly from the REFER-Target.
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Jonathan Rosenberg for providing The authors would like to thank Jonathan Rosenberg for providing
helpful guidance to this work. helpful guidance to this work.
8. References 8. Normative References
8.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[3] Sparks, R., "The Session Initiation Protocol (SIP) Refer [3] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003. Method", RFC 3515, April 2003.
[4] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User [4] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User
Agent Capabilities in the Session Initiation Protocol (SIP)", Agent Capabilities in the Session Initiation Protocol (SIP)",
RFC 3840, August 2004. RFC 3840, August 2004.
8.2 Informative References
[5] Camarillo, G., "The Internet Assigned Number Authority (IANA)
Header Field Parameter Registry for the Session Initiation
Protocol (SIP)", BCP 98, RFC 3968, December 2004.
Authors' Addresses Authors' Addresses
Orit Levin Orit Levin
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA USA
Phone: 425-722-2225 Phone: 425-722-2225
Email: oritl@microsoft.com Email: oritl@microsoft.com
Alan Johnston Alan Johnston
MCI Tello Corporation
100 South 4th Street 999 Baker Way, Suite 250
St. Louis, MO 63102 San Mateo, CA 94404
Email: alan.johnston@mci.com Email: ajohnston@tello.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 6, line 41 skipping to change at page 7, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 26 change blocks. 
60 lines changed or deleted 59 lines changed or added

This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/