draft-ietf-sipcore-proxy-feature-09.txt   draft-ietf-sipcore-proxy-feature-10.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: March 8, 2013 H. Kaplan Expires: March 25, 2013 H. Kaplan
Acme Packet Acme Packet
September 4, 2012 September 21, 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-09.txt draft-ietf-sipcore-proxy-feature-10.txt
Abstract Abstract
This specification defines a new SIP header field, Feature-Caps, to This specification defines a new SIP header field, Feature-Caps. The
convey feature capability indicators, which are used by SIP entities Feature-Caps header field conveys feature capability indicators that
not represented by the URI of the Contact header field to indicate are used to indicate support of features and capabilities for SIP
support of features and capabilities, where media feature tags cannot entities that are not represented by the Uniform Resource Identifier
be used to indicate the support. (URI) of the Contact header field.
SIP entities that are represented by the URI of the SIP Contact
header field can convey media feature tags in the header field to
indicate support of features and capabilities.
This specification also defines feature capability indicators, and This specification also defines feature capability indicators, and
creates a new IANA registry, "Proxy-Feature Feature Capability creates a new IANA registry, "Proxy-Feature Feature Capability
Indicator Trees", for registering feature capability indicators. Indicator Trees", for registering feature capability indicators.
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 March 8, 2013. This Internet-Draft will expire on March 25, 2013.
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 17 skipping to change at page 2, line 21
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
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 Header Field . . . . . . . . . . . . . . . . . . 4 4. Feature-Caps Header Field . . . . . . . . . . . . . . . . . . 5
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. User Agent and Proxy Behavior . . . . . . . . . . . . . . 5 4.2. User Agent and Proxy Behavior . . . . . . . . . . . . . . 5
4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5
4.2.2. B2BUA Behavior . . . . . . . . . . . . . . . . . . . . 6 4.2.2. B2BUA Behavior . . . . . . . . . . . . . . . . . . . . 6
4.2.3. Registrar Behavior . . . . . . . . . . . . . . . . . . 6 4.2.3. Registrar Behavior . . . . . . . . . . . . . . . . . . 6
4.2.4. Proxy behavior . . . . . . . . . . . . . . . . . . . . 6 4.2.4. Proxy behavior . . . . . . . . . . . . . . . . . . . . 6
4.3. SIP Message Type and Response Code Semantics . . . . . . . 7 4.3. SIP Message Type and Response Code Semantics . . . . . . . 7
4.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 7 4.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 7
4.3.2. SIP Dialog . . . . . . . . . . . . . . . . . . . . . . 7 4.3.2. SIP Dialog . . . . . . . . . . . . . . . . . . . . . . 7
4.3.3. SIP Registration (REGISTER) . . . . . . . . . . . . . 8 4.3.3. SIP Registration (REGISTER) . . . . . . . . . . . . . 8
4.3.4. SIP Stand-Alone Transactions . . . . . . . . . . . . . 8 4.3.4. SIP Stand-Alone Transactions . . . . . . . . . . . . . 8
5. Feature Capability Indicators . . . . . . . . . . . . . . . . 9 5. Feature Capability Indicators . . . . . . . . . . . . . . . . 9
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Registration Trees . . . . . . . . . . . . . . . . . . . . 9 5.2. Registration Trees . . . . . . . . . . . . . . . . . . . . 9
5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 9 5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 9
5.2.2. Global Tree . . . . . . . . . . . . . . . . . . . . . 9 5.2.2. Global Tree . . . . . . . . . . . . . . . . . . . . . 9
5.2.3. SIP Tree . . . . . . . . . . . . . . . . . . . . . . . 10 5.2.3. SIP Tree . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Feature Capability Indicator Specification Requirements . 10 5.3. Feature Capability Indicator Specification Requirements . 10
5.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 10 5.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 10
5.3.2. Overall Description . . . . . . . . . . . . . . . . . 11 5.3.2. Overall Description . . . . . . . . . . . . . . . . . 10
5.3.3. Feature Capability Indicator Values . . . . . . . . . 11 5.3.3. Feature Capability Indicator Values . . . . . . . . . 11
5.3.4. Usage Restrictions . . . . . . . . . . . . . . . . . . 11 5.3.4. Usage Restrictions . . . . . . . . . . . . . . . . . . 11
5.3.5. Interoperability Considerations . . . . . . . . . . . 12 5.3.5. Interoperability Considerations . . . . . . . . . . . 11
5.3.6. Security Considerations . . . . . . . . . . . . . . . 12 5.3.6. Security Considerations . . . . . . . . . . . . . . . 12
5.3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . 12 5.3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . 12
5.3.8. Other Information . . . . . . . . . . . . . . . . . . 12 5.3.8. Other Information . . . . . . . . . . . . . . . . . . 12
6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Syntax: Feature-Caps header field . . . . . . . . . . . . 12 6.2. Syntax: Feature-Caps header field . . . . . . . . . . . . 12
6.2.1. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2.1. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.3. Syntax: feature capability indicator . . . . . . . . . . . 13 6.3. Syntax: feature capability indicator . . . . . . . . . . . 13
6.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 13 6.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 13
6.3.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.3.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 13
skipping to change at page 3, line 4 skipping to change at page 3, line 8
5.3.6. Security Considerations . . . . . . . . . . . . . . . 12 5.3.6. Security Considerations . . . . . . . . . . . . . . . 12
5.3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . 12 5.3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . 12
5.3.8. Other Information . . . . . . . . . . . . . . . . . . 12 5.3.8. Other Information . . . . . . . . . . . . . . . . . . 12
6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Syntax: Feature-Caps header field . . . . . . . . . . . . 12 6.2. Syntax: Feature-Caps header field . . . . . . . . . . . . 12
6.2.1. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2.1. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.3. Syntax: feature capability indicator . . . . . . . . . . . 13 6.3. Syntax: feature capability indicator . . . . . . . . . . . 13
6.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 13 6.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 13
6.3.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.3.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7.1. Registration of the Feature-Caps header field . . . . . . 13 7.1. Registration of the Feature-Caps header field . . . . . . 13
7.2. Registration of the Feature-Caps header field parameter . 14 7.2. Registration of the Feature-Caps header field parameter . 13
7.3. Proxy-Feature Feature Capability Indicator Trees . . . . . 14 7.3. Proxy-Feature Feature Capability Indicator Trees . . . . . 14
7.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 14 7.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 14
7.3.2. Global Feature Capability Indicator Registration 7.3.2. Global Feature Capability Indicator Registration
Tree . . . . . . . . . . . . . . . . . . . . . . . . . 14 Tree . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.3.3. SIP Feature Capability Indicator Registration Tree . . 15 7.3.3. SIP Feature Capability Indicator Registration Tree . . 15
8. Feature Capability Indicator Registration Template . . . . . . 17 8. Feature Capability Indicator Registration Template . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 12.1. Normative References . . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . . 20 12.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
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 defines a new SIP header field, Feature-Caps, to This specification defines a new SIP header field, Feature-Caps. The
convey feature capability indicators, which are used by SIP entities Feature-Caps header field conveys feature capability indicators that
not represented by the URI of the Contact header field to indicate are used to indicate support of features and capabilities for SIP
support of features and capabilities, where media feature tags cannot entities that are not represented by the Uniform Resource Identifier
be used to indicate the support. Such cases are: (URI) of the Contact header field. 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 Back-to-Back User Agent (B2BUA)
URI represents another SIP entity. [RFC3261], where the Contact header field URI represents another
SIP entity.
NOTE: Unlike media feature tags, feature capability indicators are SIP entities that are represented by the URI of the SIP Contact
intended to only be used with the SIP protocol. header field can convey media feature tags in the header field to
indicate support of features and capabilities.
Unlike media feature tags, feature capability indicators are intended
to only be used with the SIP protocol.
This specification also defines feature capability indicators, and This specification also defines feature capability indicators, and
creates a new IANA registry, "Proxy-Feature Feature Capability creates a new IANA registry, "Proxy-Feature Feature Capability
Indicator Trees", for registering feature capability indicators. Indicator Trees", for registering feature capability indicators.
2. Conventions 2. Conventions
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 BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
skipping to change at page 5, line 25 skipping to change at page 5, line 28
If the URI in a Contact header field of a request or response If the URI in a Contact header field of a request or response
represents a SIP entity, the entity MUST NOT indicate supported represents a SIP entity, the entity MUST NOT indicate supported
features and capabilities using a Feature-Caps header field within features and capabilities using a Feature-Caps header field within
that request or response. that request or response.
When a SIP entity receives a SIP request, or response, that contains When a SIP entity receives a SIP request, or response, that contains
one or more Feature-Caps header fields, the feature capability one or more Feature-Caps header fields, the feature capability
indicators in the header field inform the entity about the features indicators in the header field inform the entity about the features
and capabilities supported by entities in the SIP message signalling and capabilities supported by entities in the SIP message signalling
path. Procedures how features and capabilities are invoked are path. The procedure by which features and capabilities are invoked
outside the scope of this specification, and MUST be described by are outside the scope of this specification, and MUST be described by
individual feature capability indicator specifications. individual feature capability indicator specifications.
NOTE: It is not possible to, as a Feature-Caps header field value, A Feature-Caps header field value cannot convey the address of the
convey the address of the SIP entity that inserted the Feature-Caps SIP entity that inserted the Feature-Caps header field. If
header field. If additional data about a supported feature needs to additional data about a supported feature needs to be conveyed, such
be conveyed, such as the address of the SIP entity that indicated as the address of the SIP entity that indicated support of the
support of the feature, then the feature definition needs to define a feature, then the feature definition needs to define a way to convey
way to convey that information as a value of the associated feature that information as a value of the associated feature capability
capability indicator. indicator.
When a SIP entity adds a Feature-Caps header field to a SIP message, When a SIP entity adds a Feature-Caps header field to a SIP message,
it MUST place the header field before any existing Feature-Caps it MUST place the header field before any existing Feature-Caps
header field in the message to be forwarded, so that the added header header field in the message to be forwarded, so that the added header
field becomes the top-most one. Then, when another SIP entity field becomes the top-most one. Then, when another SIP entity
receives a SIP request or the response, the SIP feature capability receives a SIP request or the response, the SIP feature capability
indicators in the top-most Feature-Caps header field will represent indicators in the top-most Feature-Caps header field will represent
the supported features and capabilities "closest" to the entity. the supported features and capabilities "closest" to the entity.
For a given fc-value, as defined in section 5.3.1, feature capability For a given fc-value, as defined in section 6.2.1, the order in which
indicators are listed in a non-priority order, and any order of the feature capability indicators are listed has no significance. For
listed SIP feature capability indicators have the same meaning. For
example, "foo;bar" and "bar;foo" have the same meaning (i.e. that the example, "foo;bar" and "bar;foo" have the same meaning (i.e. that the
SIP entity that inserted the feature capability indicator supports SIP entity that inserted the feature capability indicator supports
the features and capabilities associated with the "foo" and "bar" the features and capabilities associated with the "foo" and "bar"
feature capability indicators. feature capability indicators.
4.2.2. B2BUA Behavior 4.2.2. B2BUA Behavior
The procedures in this Section applies to UAs that are part of B2BUAs The procedures in this Section apply to User Agents (UAs) [RFC3261]
that are referenced in the message by a Record-Route header field that are part of B2BUAs that are referenced in the message by a
rather than by the URI of the Contact header field. Record-Route header field rather than by the URI of the Contact
header field.
When such a UA sends a SIP request, if the UA wants to indicate When such a UA sends a SIP request, if the UA wants to indicate
support of features and capabilities towards its downstream SIP support of features and capabilities towards its downstream SIP
entities, it inserts a Feature-Caps header field to the request, entities, it inserts a Feature-Caps header field to the request,
containing one or more feature capability indicators associated with containing one or more feature capability indicators associated with
the supported features and capabilities, before it forwards the the supported features and capabilities, before it forwards the
request. request.
If the SIP request is triggered by another SIP request that the B2BUA If the SIP request is triggered by another SIP request that the B2BUA
has received, the UA MAY forward received Feature-Caps header fields has received, the UA MAY forward received Feature-Caps header fields
skipping to change at page 7, line 44 skipping to change at page 7, line 47
Unless a feature capability indicator is inserted in a Feature-Caps Unless a feature capability indicator is inserted in a Feature-Caps
header field of a target refresh request, or within a response of header field of a target refresh request, or within a response of
such request, it indicates to the receivers of the request (or such request, it indicates to the receivers of the request (or
response) that the feature is no longer supported for the dialog. response) that the feature is no longer supported for the dialog.
For a given dialog a SIP entity MUST insert the same feature For a given dialog a SIP entity MUST insert the same feature
capability indicators in all 18x and 2xx responses associated with a capability indicators in all 18x and 2xx responses associated with a
given transaction. given transaction.
NOTE: As it cannot be guaranteed that 2xx responses associated with As it cannot be guaranteed that 2xx responses associated with SIP
SIP SUBSCRIBE requests will reach the UAC, due to forking of the SUBSCRIBE requests will reach the User Agent Client (UAC) [RFC3261],
request, entities need to indicate supported features and due to forking of the request, entities need to indicate supported
capabilities in the SIP NOTIFY request that will be sent for each of features and capabilities in the SIP NOTIFY request that will be sent
the created subscription dialogs. for each of the created subscription dialogs.
4.3.3. SIP Registration (REGISTER) 4.3.3. SIP Registration (REGISTER)
The Feature-Caps header field can be used within a SIP REGISTER The Feature-Caps header field can be used within a SIP REGISTER
request, and within the 200 (OK) response associated with such request, and within the 200 (OK) response associated with such
request. request.
If a feature capability indicator is conveyed in a Feature-Caps If a feature capability indicator is conveyed in a Feature-Caps
header field of a REGISTER request, or within an associated response, header field of a REGISTER request, or within an associated response,
it indicates to the receivers of the message that the feature it indicates to the receivers of the message that the feature
associated with the feature capability indicator is supported for the associated with the feature capability indicator is supported for the
registration, until the registration of the contact that was registration, until the registration of the contact that was
explicitly conveyed in the REGISTER request expires, or until the explicitly conveyed in the REGISTER request expires, or until the
registered contact is explicitly refreshed and the refresh REGISTER registered contact is explicitly refreshed and the refresh REGISTER
request does not contain the feature capability indicator associated request does not contain the feature capability indicator associated
with the feature. with the feature.
NOTE: While a REGISTER response can contain contacts that have been While a REGISTER response can contain contacts that have been
registered as part of other registration transactions, support of any registered as part of other registration transactions, support of any
indicated feature only applies to requests sent to the contact(s) indicated feature only applies to requests sent to the contact(s)
that were explicitly conveyed in the associated REGISTER request. that were explicitly conveyed in the associated REGISTER request.
This specification does not define any semantics for usage of the This specification does not define any semantics for usage of the
Feature-Caps header field in pure registration binding fetching Feature-Caps header field in pure registration binding fetching
messages (see Section 10.2.3 of RFC 3261), where the REGISTER request messages (see Section 10.2.3 of RFC 3261), where the REGISTER request
does not contain a Contact header field. Unless such semantics is does not contain a Contact header field. Unless such semantics is
defined in a future extension, fetching messages will not have any defined in a future extension, fetching messages will not have any
impact on previously indicated support of features and capabilities, impact on previously indicated support of features and capabilities,
skipping to change at page 9, line 31 skipping to change at page 9, line 31
The following subsections define registration trees, distinguished by The following subsections define registration trees, distinguished 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"). The registration trees are defined in the IANA "Proxy- name"). The registration trees are defined in the IANA "Proxy-
Feature Feature Capability Indicator Trees" registry. Feature Feature Capability Indicator 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.
Other registration trees are outside the scope of this specification. Other registration trees are outside the scope of this specification.
NOTE: In contrast to RFC 2506 and RFC 3840, this specification only In contrast to RFC 2506 and RFC 3840, this specification only defines
defines a global tree and a sip tree, as they are the only trees a global tree and a sip tree, as they are the only trees defined in
defined in those RFCs that have been used for defining SIP-specific those RFCs that have been used for defining SIP-specific media
media feature tags. feature tags.
When a feature capability indicator is registered in any registration When a feature capability indicator is registered in any registration
tree, no leading "+" is used in the registration. tree, no leading "+" is used in the registration.
5.2.2. Global Tree 5.2.2. Global Tree
The global feature capability indicator tree is similar to the media The global feature capability indicator tree is similar to the media
feature tag global tree defined in RFC 2506 [RFC2506]. feature tag global tree defined in RFC 2506 [RFC2506].
A feature capability indicator for the global tree will be registered
by the IANA after review by a designated expert. That review will
serve to ensure that the definition of the feature capability
indicator meets the technical requirements of this specification.
A feature capability indicator in the global tree will be A feature capability indicator in the global tree will be
distinguished by the leading facet "g.". An organization can propose distinguished by the leading facet "g.". An organization can propose
either a designation indicative of the feature, (e.g., "g.blinktags") either a designation indicative of the feature, (e.g., "g.blinktags")
or a faceted designation including the organization name (e.g., or a faceted designation including the organization name (e.g.,
"g.organization.blinktags"). "g.organization.blinktags").
When a feature capability indicator is registered in the global tree, When a feature capability indicator is registered in the global tree,
it needs to meet the "Specification Required" policies defined in RFC it needs to meet the "Specification Required" policies defined in RFC
5226 [RFC5226]. A designated area expert will review the proposed 5226 [RFC5226]. A designated area expert will review the proposed
feature capability indicator, and consult with members of related feature capability indicator, and consult with members of related
mailing lists. mailing lists.
5.2.3. SIP Tree 5.2.3. SIP Tree
The sip feature capability indicator tree is similar to the media The sip feature capability indicator tree is similar to the media
feature tag sip tree defined in RFC 3840. feature tag sip tree defined in RFC 3840.
A feature capability indicator in the sip tree will be distinguished A feature capability indicator in the sip tree will be distinguished
by the leading facet "sip.". by the leading facet "sip.".
When a feature capability indicator is registered in the sip tree, it
needs to meet the "IETF Consensus" policies defined in RFC 5226. An
RFC, which contains the registration of the feature capability
indicator, MUST be published.
5.3. Feature Capability Indicator Specification Requirements 5.3. Feature Capability Indicator Specification Requirements
5.3.1. General 5.3.1. General
A feature capability indicator specification MUST address the issues A feature capability indicator specification MUST address the issues
defined in the following subsections, or document why an issue is not defined in the following subsections, or document why an issue is not
applicable for the specific feature capability indicator. A applicable for the specific feature capability indicator. A
reference to the specification MUST be provided when the feature reference to the specification MUST be provided when the feature
capability indicator is registered with IANA (see Section 8). capability indicator is registered with IANA (see Section 8).
skipping to change at page 12, line 12 skipping to change at page 11, line 50
features and capabilities in order to insert a feature capability features and capabilities in order to insert a feature capability
indicator, and whether entities are allowed to indicate support of a indicator, and whether entities are allowed to indicate support of a
feature in conjunction with another feature. feature in conjunction with another feature.
5.3.5. Interoperability Considerations 5.3.5. Interoperability Considerations
If there are specific interoperability considerations that apply to If there are specific interoperability considerations that apply to
the feature capability indicator, the feature capability indicator the feature capability indicator, the feature capability indicator
specification MUST document such considerations. specification MUST document such considerations.
Interoperability considerations can e.g. include procedures related
to cases where an expected feature capability indicator is not
present, or where it contains an unexpected value.
5.3.6. Security Considerations 5.3.6. Security Considerations
If there are specific security considerations that apply to the If there are specific security considerations that apply to the
feature capability indicator, the feature capability indicator feature capability indicator, the feature capability indicator
specification MUST document such considerations. specification MUST document such considerations.
5.3.7. Examples 5.3.7. Examples
It is RECOMMENDED that the feature capability indicator specification It is RECOMMENDED that the feature capability indicator specification
provide demonstrative message flow diagrams, paired with complete provide demonstrative message flow diagrams, paired with complete
skipping to change at page 13, line 4 skipping to change at page 12, line 42
6.2. Syntax: Feature-Caps header field 6.2. Syntax: Feature-Caps header field
6.2.1. ABNF 6.2.1. ABNF
The ABNF for the Feature-Caps header fields is: The ABNF for the Feature-Caps header fields is:
Feature-Caps = "Feature-Caps" HCOLON fc-value Feature-Caps = "Feature-Caps" HCOLON fc-value
*(COMMA fc-value) *(COMMA fc-value)
fc-value = "*" *(SEMI feature-cap) fc-value = "*" *(SEMI feature-cap)
Figure 1: ABNF
NOTE: The "*" value is present in order to follow the guidelines for NOTE: The "*" value is present in order to follow the guidelines for
syntax in RFC 4485 [RFC4485] and to maintain a consistent format with syntax in RFC 4485 [RFC4485] and to maintain a consistent format with
RFC 3840 and RFC 3841 [RFC3841]. RFC 3840 and RFC 3841 [RFC3841].
6.3. Syntax: feature capability indicator 6.3. Syntax: feature capability indicator
6.3.1. General 6.3.1. General
In a feature capability indicator name (ABNF: fcap-name), dots can be In a feature capability indicator name (ABNF: fcap-name), dots can be
skipping to change at page 13, line 33 skipping to change at page 13, line 28
feature-cap = "+" fcap-name [EQUAL LDQUOT (fcap-value-list feature-cap = "+" fcap-name [EQUAL LDQUOT (fcap-value-list
/ fcap-string-value ) RDQUOT] / fcap-string-value ) RDQUOT]
fcap-name = ftag-name fcap-name = ftag-name
fcap-value-list = tag-value-list fcap-value-list = tag-value-list
fcap-string-value = string-value fcap-string-value = string-value
;; ftag-name, tag-value-list, string-value defined in RFC 3840 ;; ftag-name, tag-value-list, string-value defined in RFC 3840
NOTE: In comparison with media feature tags, the "+" sign in front NOTE: In comparison with media feature tags, the "+" sign in front
of the feature capability indicator name is mandatory. of the feature capability indicator name is mandatory.
Figure 2: ABNF
7. IANA Considerations 7. IANA Considerations
7.1. Registration of the Feature-Caps header field 7.1. Registration of the Feature-Caps header field
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 XXXX RFC Number: RFC XXXX
skipping to change at page 14, line 23 skipping to change at page 14, line 17
------------------------------------------------------------------ ------------------------------------------------------------------
Feature-Caps +<fcap-name> * No [RFC XXXX] Feature-Caps +<fcap-name> * No [RFC XXXX]
* <fcap-name> denotes parameter names conforming to the * <fcap-name> denotes parameter names conforming to the
syntax <fcap-name> defined in RFC XXXX. Valid syntax <fcap-name> defined in RFC XXXX. Valid
feature capability indicators are registered in [IANA: feature capability indicators are registered in [IANA:
insert reference to the new Proxy-Feature Feature insert reference to the new Proxy-Feature Feature
Capability Indicator Trees registry]. Capability Indicator Trees registry].
Figure 3: SIP Parameter Header Field
(IANA: please sort the "Feature-Caps" line into the table and place (IANA: please sort the "Feature-Caps" line into the table and place
the remainder of the above as a footnote to the table.) the remainder of the above as a footnote to the table.)
7.3. Proxy-Feature Feature Capability Indicator Trees 7.3. Proxy-Feature Feature Capability Indicator Trees
7.3.1. Introduction 7.3.1. Introduction
This specification creates a new sub registry to the IANA "Session This specification creates a new sub registry to the IANA "Session
Initiation Protocol (SIP) Parameters" Protocol Registry, according to Initiation Protocol (SIP) Parameters" Protocol Registry, according to
the process of RFC 5226. The name of the sub registry is "Proxy- the process of RFC 5226. The name of the sub registry is "Proxy-
skipping to change at page 15, line 26 skipping to change at page 15, line 19
in the registration feature capability indication registration in the registration feature capability indication registration
template. template.
Description, provided in the registration feature capability Description, provided in the registration feature capability
indication registration template. indication registration template.
Reference contains the Feature Capability Indicator Specification Reference contains the Feature Capability Indicator Specification
Reference, provided in the registration feature capability Reference, provided in the registration feature capability
indication registration template. indication registration template.
Figure 4
7.3.3. SIP Feature Capability Indicator Registration Tree 7.3.3. SIP Feature Capability Indicator Registration Tree
This specification creates a new feature capability indicator tree in This specification creates a new feature capability indicator tree in
the IANA "Proxy-Feature Feature Capability Indicator Trees" registry. the IANA "Proxy-Feature Feature Capability Indicator Trees" registry.
The name of the tree is "SIP Feature Capability Indicator The name of the tree is "SIP Feature Capability Indicator
Registration Tree", and its leading facet is "sip.". It is used for Registration Tree", and its leading facet is "sip.". It is used for
the registration of feature capability indicators. the registration of feature capability indicators.
When a feature capability indicator is registered in the sip tree, it When a feature capability indicator is registered in the sip tree, it
needs to meet the "IETF Consensus" policies defined in RFC 5226. An needs to meet the "IETF Consensus" policies defined in RFC 5226. The
RFC, which contains the registration of the feature capability information required in the registration is defined in Section 5.3 of
indicator, MUST be published. The information required in the RFC XXXX.
registration is defined in Section 5.3 of RFC XXXX.
Note that all feature capability indicators registered in the SIP Note that all feature capability indicators registered in the SIP
tree will have names with a leading facet "sip.". No leading "+" is tree will have names with a leading facet "sip.". No leading "+" is
used in the registrations in any of the feature capability indicator used in the registrations in any of the feature capability indicator
registration trees. registration trees.
The format of the SIP tree is as described below: The format of the SIP tree is as described below:
Name Description Reference Name Description Reference
------------------------------ ------------------------------
skipping to change at page 16, line 19 skipping to change at page 16, line 6
in the registration feature capability indication registration in the registration feature capability indication registration
template. template.
Description, provided in the registration feature capability Description, provided in the registration feature capability
indication registration template. indication registration template.
Reference contains the Feature Capability Indicator Specification Reference contains the Feature Capability Indicator Specification
Reference, provided in the registration feature capability Reference, provided in the registration feature capability
indication registration template. indication registration template.
Figure 5
8. Feature Capability Indicator Registration Template 8. Feature Capability Indicator Registration Template
Registration requests for the global tree are submitted Registration requests for the global tree are submitted
by e-mail to iana@iana.org. by e-mail to iana@iana.org.
Registration requests for the sip tree requires submitting Registration requests for the sip tree requires submitting
an Internet-Draft to the IESG. an Internet-Draft to the IESG.
| Instructions are preceded by '|'. All fields are mandatory. | Instructions are preceded by '|'. All fields are mandatory.
skipping to change at page 17, line 40 skipping to change at page 16, line 41
| The referenced specification MUST contain the information | The referenced specification MUST contain the information
| listed in Section 5.3 of RFC XXXX. | listed in Section 5.3 of RFC XXXX.
Contact: Contact:
| Name(s) & email address(es) of person(s) to | Name(s) & email address(es) of person(s) to
| contact for further information." | contact for further information."
(IANA: Please replace XXXX with the assigned RFC number) (IANA: Please replace XXXX with the assigned RFC number)
Figure 6: Registration Template
9. Security Considerations 9. Security Considerations
The security issues for feature capability indicators are similar to The security issues for feature capability indicators are similar to
the ones defined in RFC 3840 for media feature tags. Media feature the ones defined in RFC 3840 for media feature tags. Media feature
tags can reveal information about end-users and end-user equipment, tags can reveal information about end-users and end-user equipment,
which can be used for industrial espionage. The knowledge about end- which can be used for industrial espionage. The knowledge about end-
user equipment capabilities can also be used to influence application user equipment capabilities can also be used to influence application
behavior. As feature capability indicators are not intended to behavior. As feature capability indicators are not intended to
convey capability information of end-user devices, such end-user convey capability information of end-user devices, such end-user
security aspects of RFC 3840 do not apply to feature capability security aspects of RFC 3840 do not apply to feature capability
skipping to change at page 18, line 22 skipping to change at page 17, line 24
be used with feature capability indicators. be used with feature capability indicators.
Feature capability indicators can, however, provide capability and Feature capability indicators can, however, provide capability and
characteristics information about the SIP entity, some of which might characteristics information about the SIP entity, some of which might
be sensitive. Malicious elements viewing the indicators may be able be sensitive. Malicious elements viewing the indicators may be able
to discern application deployment details or identify elements with to discern application deployment details or identify elements with
exploitable feature implementation weaknesses. The Feature-Caps exploitable feature implementation weaknesses. The Feature-Caps
header field does not convey address information about SIP entities. header field does not convey address information about SIP entities.
However, individual feature capability indicators might provide However, individual feature capability indicators might provide
address information as feature capability indicator values. address information as feature capability indicator values.
Therefore, mechanisms for guaranteeing confidentiality and Therefore, if the feature capability indicators provide sensitive
authenticity SHOULD be provided. information, mechanisms for guaranteeing confidentiality and
authenticity MUST be provided.
10. Acknowledgements 10. Acknowledgements
The authors wish to thank everyone in the SIP community that provided The authors wish to thank everyone in the SIP community that provided
input and feedback on the work of this specification. input and feedback on the work of this specification.
11. Change Log 11. Change Log
[RFC EDITOR NOTE: Please remove this Section when publishing] [RFC EDITOR NOTE: Please remove this Section when publishing]
Changes from draft-holmberg-sipcore-proxy-feature-09
o Editorial changes based on SECDIR comments from Radia Perlman.
o Editorial changes based on Gen-Art comments from Brian E
Carpenter.
o Editorial changes based on OPSDIR comments from Jouni Korhonen.
o Change in security considerations indicating that, if sensitive
information is conveyed, mechanisms for guaranteeing
confidentiality and authenticity must be provided.
Changes from draft-holmberg-sipcore-proxy-feature-08 Changes from draft-holmberg-sipcore-proxy-feature-08
o Comments from Atle Mondrad. o Comments from Atle Mondrad.
Changes from draft-holmberg-sipcore-proxy-feature-06 Changes from draft-holmberg-sipcore-proxy-feature-06
o Editorial changes. o Editorial changes.
Changes from draft-holmberg-sipcore-proxy-feature-05 Changes from draft-holmberg-sipcore-proxy-feature-05
o AD comments from Robert Sparks o AD comments from Robert Sparks
o Additional text added to the Security Considerations section. o Additional text added to the Security Considerations section.
o IANA registration template modified. o IANA registration template modified.
 End of changes. 33 change blocks. 
83 lines changed or deleted 83 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/