draft-ietf-sipcore-proxy-feature-03.txt   draft-ietf-sipcore-proxy-feature-04.txt 
SIPCORE Working Group C. Holmberg SIPCORE Working Group C. Holmberg
Internet-Draft I. Sedlacek Internet-Draft I. Sedlacek
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: December 13, 2012 H. Kaplan Expires: December 16, 2012 H. Kaplan
Acme Packet Acme Packet
June 11, 2012 June 14, 2012
Mechanism to indicate support of features and capabilities in the Mechanism to indicate support of features and capabilities in the
Session Initiation Protocol (SIP) Session Initiation Protocol (SIP)
draft-ietf-sipcore-proxy-feature-03.txt draft-ietf-sipcore-proxy-feature-04.txt
Abstract Abstract
This specification creates a new IANA registry, "Feature Cap This specification creates a new IANA registry, "Proxy-Feature
Registry", for registering "feature caps", which are used by SIP Feature Caps Trees", for registering "feature caps", which are used
entities not represented by the URI of the Contact header field to by SIP entities not represented by the URI of the Contact header
indicate support of features and capabilities, where media feature field to indicate support of features and capabilities, where media
tags cannot be used to indicate the support. feature tags cannot be used to indicate the support.
This specification also defines a new SIP header field, Feature-Caps, This specification also defines a new SIP header field, Feature-Caps,
to convey feature caps in SIP messages. to convey feature caps in SIP messages.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on December 13, 2012. This Internet-Draft will expire on December 16, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 21
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Feature Caps . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Feature Caps . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Registration Trees . . . . . . . . . . . . . . . . . . . . 5 4.2. Registration Trees . . . . . . . . . . . . . . . . . . . . 5
4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5
4.2.2. Global Tree . . . . . . . . . . . . . . . . . . . . . 5 4.2.2. Global Tree . . . . . . . . . . . . . . . . . . . . . 5
4.2.3. Feature Cap Registration Tree . . . . . . . . . . . . 6 4.2.3. SIP Tree . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Registration Template . . . . . . . . . . . . . . . . . . 6 4.3. Registration Template . . . . . . . . . . . . . . . . . . 6
4.4. Feature Cap Specification Requirements . . . . . . . . . . 8 4.4. Feature Cap Specification Requirements . . . . . . . . . . 8
4.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 8 4.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 8
4.4.2. Overall Description . . . . . . . . . . . . . . . . . 8 4.4.2. Overall Description . . . . . . . . . . . . . . . . . 8
4.4.3. Feature Cap Values . . . . . . . . . . . . . . . . . . 8 4.4.3. Feature Cap Values . . . . . . . . . . . . . . . . . . 8
4.4.4. Usage Restrictions . . . . . . . . . . . . . . . . . . 9 4.4.4. Usage Restrictions . . . . . . . . . . . . . . . . . . 9
4.4.5. Examples . . . . . . . . . . . . . . . . . . . . . . . 9 4.4.5. Examples . . . . . . . . . . . . . . . . . . . . . . . 9
5. Feature-Caps Header Field . . . . . . . . . . . . . . . . . . 9 5. Feature-Caps Header Field . . . . . . . . . . . . . . . . . . 9
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. User Agent and Proxy Behavior . . . . . . . . . . . . . . 10 5.2. User Agent and Proxy Behavior . . . . . . . . . . . . . . 10
skipping to change at page 2, line 50 skipping to change at page 2, line 50
5.3.4. SIP Stand-Alone Transactions . . . . . . . . . . . . . 13 5.3.4. SIP Stand-Alone Transactions . . . . . . . . . . . . . 13
6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Syntax: feature cap . . . . . . . . . . . . . . . . . . . 13 6.2. Syntax: feature cap . . . . . . . . . . . . . . . . . . . 13
6.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 13 6.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 13
6.2.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.3. Syntax: Feature-Caps header field . . . . . . . . . . . . 14 6.3. Syntax: Feature-Caps header field . . . . . . . . . . . . 14
6.3.1. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.3.1. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7.1. Registration of the Feature-Caps header field . . . . . . 14 7.1. Registration of the Feature-Caps header field . . . . . . 14
7.2. Global Feature Cap Registration Tree . . . . . . . . . . . 15 7.2. Proxy-Feature Feature Caps Trees . . . . . . . . . . . . . 15
7.3. Feature Cap Registration Tree . . . . . . . . . . . . . . 15 7.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 15
7.2.2. Global Feature Cap Registration Tree . . . . . . . . . 15
7.2.3. SIP Feature Cap Registration Tree . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The Session Initiation Protocol (SIP) [RFC3261] "Caller Preferences" The Session Initiation Protocol (SIP) [RFC3261] "Caller Preferences"
extension, defined in RFC 3840 [RFC3840], provides a mechanism that extension, defined in RFC 3840 [RFC3840], provides a mechanism that
allows a SIP message to convey information relating to the allows a SIP message to convey information relating to the
originator's features and capabilities, using the Contact header originator's features and capabilities, using the Contact header
field. field.
This specification creates a new IANA registry, "Feature Cap This specification creates a new IANA registry, "Proxy-Feature
Registry", for registering "feature caps", which are used by SIP Feature Caps Trees", for registering "feature caps", which are used
entities not represented by the URI of the Contact header field to by SIP entities not represented by the URI of the Contact header
indicate support of features and capabilities, where media feature field to indicate support of features and capabilities, where media
tags cannot be used to indicate the support. Such cases are: feature tags cannot be used to indicate the support. Such cases are:
o - The SIP entity acts as a SIP proxy. o - The SIP entity acts as a SIP proxy.
o - The SIP entity acts as a SIP registrar. o - The SIP entity acts as a SIP registrar.
o - The SIP entity acts as a B2BUA, where the Contact header field o - The SIP entity acts as a B2BUA, where the Contact header field
URI represents another SIP entity. URI represents another SIP entity.
This specification also defines a new SIP header field, Feature-Caps, This specification also defines a new SIP header field, Feature-Caps,
to convey feature caps in SIP messages. to convey feature caps in SIP messages.
NOTE: Unlike media feature tags, feature caps are intended to only be NOTE: Unlike media feature tags, feature caps are intended to only be
skipping to change at page 5, line 24 skipping to change at page 5, line 24
Section 5 defines how feature caps are conveyed using the Feature- Section 5 defines how feature caps are conveyed using the Feature-
Caps header field. Caps header field.
The feature cap ABNF is defined in Section 6.2.2. The feature cap ABNF is defined in Section 6.2.2.
4.2. Registration Trees 4.2. Registration Trees
4.2.1. General 4.2.1. General
The following subsections define registration "trees", distinguished The following subsections define registration trees, distinguished by
by the use of faceted names (e.g., names of the form "tree.feature- the use of faceted names (e.g., names of the form "tree.feature-
name"). name"). The registration trees are defined in the IANA "Proxy-
Feature Feature Caps Trees" registry.
The trees defined herein are similar to the global tree and sip tree The trees defined herein are similar to the global tree and sip tree
defined for media feature tags, in RFC 2506 [RFC2506] and RFC 3840 defined for media feature tags, in RFC 2506 [RFC2506] and RFC 3840
[RFC3840]. Other registration trees are outside the scope of this [RFC3840]. Other registration trees are outside the scope of this
specification. specification.
NOTE: In contrast to RFC 2506 and RFC 3840, this specification only NOTE: In contrast to RFC 2506 and RFC 3840, this specification only
defines a global tree and a sip tree, as they are the only trees defines a global tree and a sip tree, as they are the only trees
defined in those RFCs that have been used for defining SIP-specific defined in those RFCs that have been used for defining SIP-specific
media feature tags. media feature tags.
When a feature cap is registered in any registration tree, no leading When a feature cap is registered in any registration tree, no leading
"+" is used in the registration. "+" is used in the registration.
4.2.2. Global Tree 4.2.2. Global Tree
The feature cap global tree is similar to the media feature tag The global feature cap tree is similar to the media feature tag
global tree defined in RFC 2506 [RFC2506]. global tree defined in RFC 2506 [RFC2506].
A feature cap for the global tree will be registered by the IANA A feature cap for the global tree will be registered by the IANA
after review by a designated expert. That review will serve to after review by a designated expert. That review will serve to
ensure that the feature cap meets the technical requirements of this ensure that the feature cap meets the technical requirements of this
specification. specification.
A feature cap in the global tree will be distinguished by the leading A feature cap in the global tree will be distinguished by the leading
facet "g.". An organization can propose either a designation facet "g.". An organization can propose either a designation
indicative of the feature, (e.g., "g.blinktags") or a faceted indicative of the feature, (e.g., "g.blinktags") or a faceted
designation including the organization name (e.g., designation including the organization name (e.g.,
"g.organization.blinktags"). "g.organization.blinktags").
When a feature cap is registered in the global tree, it needs to meet When a feature cap is registered in the global tree, it needs to meet
the "Expert Review" policies defined in RFC 5226 [RFC5226]. A the "Expert Review" policies defined in RFC 5226 [RFC5226]. A
designated area expert will review the proposed feature cap, and designated area expert will review the proposed feature cap, and
consult with members of related mailing lists. consult with members of related mailing lists.
4.2.3. Feature Cap Registration Tree 4.2.3. SIP Tree
The feature cap sip tree is similar to the media feature tag sip tree The sip feature cap tree is similar to the media feature tag sip tree
defined in RFC 3840 [RFC3840]. defined in RFC 3840 [RFC3840].
A feature cap in the sip tree will be distinguished by the leading A feature cap in the sip tree will be distinguished by the leading
facet "sip.". facet "sip.".
When a feature cap is registered in the sip tree, it needs to meet When a feature cap is registered in the sip tree, it needs to meet
the "IETF Consensus" policies defined in RFC 5226 [RFC5226]. An RFC, the "IETF Consensus" policies defined in RFC 5226 [RFC5226]. An RFC,
which contains the registration of the feature cap, MUST be which contains the registration of the feature cap, MUST be
published. published.
skipping to change at page 15, line 5 skipping to change at page 15, line 5
This specification registers a new SIP header field, Feature-Caps, This specification registers a new SIP header field, Feature-Caps,
according to the process of RFC 3261 [RFC3261]. according to the process of RFC 3261 [RFC3261].
The following is the registration for the Feature-Caps header field: The following is the registration for the Feature-Caps header field:
RFC Number: RFC XXX RFC Number: RFC XXX
Header Field Name: Feature-Caps Header Field Name: Feature-Caps
7.2. Global Feature Cap Registration Tree 7.2. Proxy-Feature Feature Caps Trees
This specification creates a new feature cap tree. The name of the 7.2.1. Introduction
tree is "Global Feature Cap Registration Tree", and its leading facet
is "g.". It is used for the registration of feature caps.
The addition of entries into this registry occurs through the Expert This specification creates a new sub registry to the IANA "Session
Review policies, as defined in RFC 5226 [RFC5226]. A designated area Initiation Protocol (SIP) Parameters" Protocol Registry, per the
expert will review the proposed SIP feature cap, and consult with guidelines in RFC 5226 [RFC5226]. The name of the sub registry is
members of related mailing lists. The information required in the "Proxy-Feature Feature Caps Trees".
registration is defined in Section 4.3 of RFC XXX.
Note that all feature caps registered in the SIP tree will have names 7.2.2. Global Feature Cap Registration Tree
with a leading facet "g.". No leading "+" is used in the
registrations in any of the media feature tag trees.
7.3. Feature Cap Registration Tree This specification creates a new feature cap tree in the IANA "Proxy-
Feature Feature Caps Trees" registry. The name of the tree is
"Global Feature Cap Registration Tree", and its leading facet is
"g.". It is used for the registration of feature caps.
This specification creates a new feature cap tree, per the guidelines The addition of entries into this tree occurs through the Expert
in RFC 5226 [RFC5226]. The name of the tree is "Feature Cap Review policies, as defined in RFC 5226. A designated area expert
Registration Tree", and its leading facet is "sip.". It is used for will review the proposed feature cap, and consult with members of
the registration of feature caps. related mailing lists. The information required in the registration
is defined in Section 4.3 of RFC XXX.
The addition of entries into this registry occurs through the IETF Note that all feature caps registered in the global tree will have
names with a leading facet "g.". No leading "+" is used in the
registrations in any of the feature cap registration trees.
7.2.3. SIP Feature Cap Registration Tree
This specification creates a new feature cap tree in the IANA "Proxy-
Feature Feature Caps Trees" registry. The name of the tree is "SIP
Feature Cap Registration Tree", and its leading facet is "sip.". It
is used for the registration of feature caps.
The addition of entries into this tree occurs through the IETF
Consensus, as defined in RFC 5226. This requires the publication of Consensus, as defined in RFC 5226. This requires the publication of
an RFC that contains the registration. The information required in an RFC that contains the registration. The information required in
the registration is defined in Section 4.3 of RFC XXX. the registration is defined in Section 4.3 of RFC XXX.
Note that all feature caps registered in the SIP tree will have names Note that all feature caps registered in the SIP tree will have names
with a leading facet "sip.". No leading "+" is used in the with a leading facet "sip.". No leading "+" is used in the
registrations in any of the media feature tag trees. registrations in any of the feature cap registration trees.
8. Security Considerations 8. Security Considerations
Feature caps can provide sensitive information about a SIP entity. The security issues for feature caps are similar to the ones defined
RFC 3840 cautions against providing sensitive information to another in RFC 3840 for media feature tags. However, as feature caps will
party. Once this information is given out, any use may be made of typically not be used to convey capability information of end-user
it. devices, those aspects of RFC 3840 do not apply to feature caps.
In addition, the RFC 3840 security issue regarding an attacker using
the SIP caller preferences extension [RFC3841] in order to affect
routing decisions does not apply, as the mechanism is not defined to
be used with feature caps.
Feature caps can provide capability and characteristics information
about the SIP entity, some of which might be sensitive. The Feature-
Caps header field does not convey address information about SIP
entities. However, individual feature caps might provide address
information as feature cap values. Therefore, mechanisms for
guaranteeing confidentiality and authenticity SHOULD be provided.
9. Acknowledgements 9. Acknowledgements
The authors wish to thank everyone in the SIP community that provided
input and feedback on the work of this specification.
10. Change Log 10. Change Log
[RFC EDITOR NOTE: Please remove this Section when publishing] [RFC EDITOR NOTE: Please remove this Section when publishing]
Changes from draft-ietf-sipcore-proxy-feature-03
o Additional Security Considerations text added.
o IANA Considerations modified.
o Editorial corrections.
Changes from draft-ietf-sipcore-proxy-feature-02 Changes from draft-ietf-sipcore-proxy-feature-02
o Changes based on WGLC comments from Shida Schubert. o Changes based on WGLC comments from Shida Schubert.
o - Document title changed o - Document title changed
o - Terminology alignment o - Terminology alignment
o - Note text clarifications o - Note text clarifications
o Changes based on WGLC comments from Lili Yang. o Changes based on WGLC comments from Lili Yang.
Changes from draft-ietf-sipcore-proxy-feature-01 Changes from draft-ietf-sipcore-proxy-feature-01
o Changes based on comments from Paul Kyzivat. o Changes based on comments from Paul Kyzivat.
o IANA Considerations text added. o IANA Considerations text added.
skipping to change at page 17, line 23 skipping to change at page 17, line 50
11.2. Informative References 11.2. Informative References
[RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag
Registration Procedure", BCP 31, RFC 2506, March 1999. Registration Procedure", BCP 31, RFC 2506, March 1999.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session "Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004. Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol Initiated Connections in the Session Initiation Protocol
(SIP)", RFC 5626, October 2009. (SIP)", RFC 5626, October 2009.
[3GPP.23.237] [3GPP.23.237]
3GPP, "IP Multimedia Subsystem (IMS) Service Continuity; 3GPP, "IP Multimedia Subsystem (IMS) Service Continuity;
 End of changes. 26 change blocks. 
49 lines changed or deleted 87 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/