draft-ietf-sipcore-proxy-feature-12.txt   rfc6809.txt 
SIPCORE Working Group C. Holmberg Internet Engineering Task Force (IETF) C. Holmberg
Internet-Draft I. Sedlacek Request for Comments: 6809 I. Sedlacek
Intended status: Standards Track Ericsson Category: Standards Track Ericsson
Expires: April 22, 2013 H. Kaplan ISSN: 2070-1721 H. Kaplan
Acme Packet Acme Packet
October 19, 2012 November 2012
Mechanism to indicate support of features and capabilities in the Mechanism to Indicate Support of Features and Capabilities in
Session Initiation Protocol (SIP) the Session Initiation Protocol (SIP)
draft-ietf-sipcore-proxy-feature-12.txt
Abstract Abstract
This specification defines a new SIP header field, Feature-Caps. The This specification defines a new SIP header field, Feature-Caps. The
Feature-Caps header field conveys feature capability indicators that Feature-Caps header field conveys feature-capability indicators that
are used to indicate support of features and capabilities for SIP are used to indicate support of features and capabilities for SIP
entities that are not represented by the Uniform Resource Identifier entities that are not represented by the Uniform Resource Identifier
(URI) of the Contact header field. (URI) of the Contact header field.
SIP entities that are represented by the URI of the SIP Contact SIP entities that are represented by the URI of the SIP Contact
header field can convey media feature tags in the Contact header header field can convey media feature tags in the Contact header
field to indicate support of features and capabilities. 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
This Internet-Draft is submitted to IETF in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on April 22, 2013. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6809.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 ....................................................3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions .....................................................4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions .....................................................4
4. Feature-Caps Header Field . . . . . . . . . . . . . . . . . . 5 4. Feature-Caps Header Field .......................................4
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Introduction ...............................................4
4.2. User Agent and Proxy Behavior . . . . . . . . . . . . . . 5 4.2. User Agent and Proxy Behavior ..............................4
4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5 4.2.1. General .............................................4
4.2.2. B2BUA Behavior . . . . . . . . . . . . . . . . . . . . 6 4.2.2. B2BUA Behavior ......................................5
4.2.3. Registrar Behavior . . . . . . . . . . . . . . . . . . 6 4.2.3. Registrar Behavior ..................................6
4.2.4. Proxy behavior . . . . . . . . . . . . . . . . . . . . 7 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) .........................7
4.3.4. SIP Stand-Alone Transactions . . . . . . . . . . . . . 8 4.3.4. SIP Standalone Transactions .........................8
5. Feature Capability Indicators . . . . . . . . . . . . . . . . 9 5. Feature-Capability Indicators ...................................8
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Introduction ...............................................8
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 ............................................9
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 . . . . . . . . . . . . . . . . . 10 5.3.2. Overall Description ................................10
5.3.3. Feature Capability Indicator Values . . . . . . . . . 11 5.3.3. Feature-Capability Indicator Values ................10
5.3.4. Usage Restrictions . . . . . . . . . . . . . . . . . . 11 5.3.4. Usage Restrictions .................................11
5.3.5. Interoperability Considerations . . . . . . . . . . . 11 5.3.5. Interoperability Considerations ....................11
5.3.6. Security Considerations . . . . . . . . . . . . . . . 12 5.3.6. Security Considerations ............................11
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.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Syntax .........................................................12
6.2. Syntax: Feature-Caps header field . . . . . . . . . . . . 12 6.1. General ...................................................12
6.2.1. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Syntax: Feature-Caps Header Field .........................12
6.3. Syntax: feature capability indicator . . . . . . . . . . . 13 6.2.1. ABNF ...............................................12
6.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 13 6.3. Syntax: Feature-Capability Indicator ......................12
6.3.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.3.1. General ............................................12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6.3.2. ABNF ...............................................13
7.1. Registration of the Feature-Caps header field . . . . . . 13 7. IANA Considerations ............................................13
7.2. Registration of the Feature-Caps header field parameter . 13 7.1. Registration of the Feature-Caps Header Field .............13
7.3. Proxy-Feature Feature Capability Indicator Trees . . . . . 14 7.2. Registration of the Feature-Caps Header Field Parameter ...13
7.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 14 7.3. Proxy-Feature Feature-Capability Indicator Trees ..........14
7.3.2. Global Feature Capability Indicator Registration 7.3.1. Introduction .......................................14
Tree . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.3.2. Global Feature-Capability Indicator
7.3.3. SIP Feature Capability Indicator Registration Tree . . 15 Registration Tree ..................................14
8. Feature Capability Indicator Registration Template . . . . . . 16 7.3.3. SIP Feature-Capability Indicator
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 Registration Tree ..................................15
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 8. Feature-Capability Indicator Registration Template .............16
11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations ........................................17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. Acknowledgements ..............................................17
12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 11. References ....................................................18
12.2. Informative References . . . . . . . . . . . . . . . . . . 21 11.1. Normative References .....................................18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 11.2. Informative References ...................................18
1. Introduction 1. Introduction
The Session Initiation Protocol (SIP) [RFC3261] "Caller Preferences" The Session Initiation Protocol (SIP) [RFC3261] extension for
extension, defined in RFC 3840 [RFC3840], provides a mechanism that indicating User Agent (UA) capabilities, defined in RFC 3840
allows a SIP message to convey information relating to the [RFC3840], provides a mechanism that allows a SIP message to convey
originator's features and capabilities, using the Contact header information relating to the originator's features and capabilities,
field. using the Contact header field.
This specification defines a new SIP header field, Feature-Caps. The This specification defines a new SIP header field, Feature-Caps. The
Feature-Caps header field conveys feature capability indicators that Feature-Caps header field conveys feature-capability indicators that
are used to indicate support of features and capabilities for SIP are used to indicate support of features and capabilities for SIP
entities that are not represented by the Uniform Resource Identifier entities that are not represented by the Uniform Resource Identifier
(URI) of the Contact header field. 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 Back-to-Back User Agent (B2BUA) o The SIP entity acts as a SIP registrar.
o The SIP entity acts as a Back-to-Back User Agent (B2BUA)
[RFC3261], where the Contact header field URI represents another [RFC3261], where the Contact header field URI represents another
SIP entity. SIP entity.
SIP entities that are represented by the URI of the SIP Contact SIP entities that are represented by the URI of the SIP Contact
header field can convey media feature tags in the Contact header header field can convey media feature tags in the Contact header
field to indicate support of features and capabilities. field to indicate support of features and capabilities.
Unlike media feature tags, feature capability indicators are intended Unlike media feature tags, feature-capability indicators are intended
to only be used with the SIP protocol. to only be used with SIP.
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
[RFC2119]. [RFC2119].
3. Definitions 3. Definitions
skipping to change at page 5, line 10 skipping to change at page 4, line 32
SIP request is sent. SIP request is sent.
Upstream SIP entity: SIP entity in the direction from which a SIP Upstream SIP entity: SIP entity in the direction from which a SIP
request is received. request is received.
4. Feature-Caps Header Field 4. Feature-Caps Header Field
4.1. Introduction 4.1. Introduction
The Feature-Caps header field is used by SIP entities to convey The Feature-Caps header field is used by SIP entities to convey
support of features and capabilities, by setting feature capability support of features and capabilities, by setting feature-capability
indicators. A feature capability indicator conveyed in a Feature- indicators. A feature-capability indicator conveyed in a
Caps header field indicates that a SIP entity in the SIP message Feature-Caps header field indicates that a SIP entity in the SIP
signalling path supports the associated feature and capability. message signaling path supports the associated feature and
capability.
4.2. User Agent and Proxy Behavior 4.2. User Agent and Proxy Behavior
4.2.1. General 4.2.1. General
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 signaling
path. The procedure by which features and capabilities are invoked path. The procedure by which features and capabilities are invoked
are 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.
A Feature-Caps header field value cannot convey the address of the A Feature-Caps header field value cannot convey the address of the
SIP entity that inserted the Feature-Caps header field. If SIP entity that inserted the Feature-Caps header field. If
additional data about a supported feature needs to be conveyed, such additional data about a supported feature needs to be conveyed, such
as the address of the SIP entity that indicated support of the as the address of the SIP entity that indicated support of the
feature, then the feature definition needs to define a way to convey feature, then the feature definition needs to define a way to convey
that information as a value of the associated feature capability that information as a value of the associated feature-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", from a SIP the supported features and capabilities "closest", from a SIP
signaling point of view, to the entity. signaling point of view, to the entity.
Based on features and policies, a SIP entity MAY remove a Feature- Based on features and policies, a SIP entity MAY remove a
Caps header field from a SIP message. Also, a SIP entity MAY remove Feature-Caps header field from a SIP message. Also, a SIP entity MAY
a feature capability indicator from a Feature-Caps header field remove a feature-capability indicator from a Feature-Caps header
within a SIP message. A SIP entity SHOULD NOT re-order the Feature- field within a SIP message. A SIP entity SHOULD NOT re-order the
Caps header fields within a SIP message. Feature-Caps header fields within a SIP message.
For a given fc-value, as defined in section 6.2.1, the order in which For a given fc-value, as defined in Section 6.2.1, the order in which
feature capability indicators are listed has no significance. For feature-capability indicators are listed has no significance. 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
SIP entity that inserted the feature capability indicator supports the SIP entity that inserted the feature-capability indicator
the features and capabilities associated with the "foo" and "bar" supports the features and capabilities associated with the "foo" and
feature capability indicators. "bar" feature-capability indicators).
4.2.2. B2BUA Behavior 4.2.2. B2BUA Behavior
The procedures in this Section apply to User Agents (UAs) [RFC3261] The procedures in this section apply to User Agents (UAs) [RFC3261]
that are part of B2BUAs that are referenced in the message by a that are part of B2BUAs that are referenced in the message by a
Record-Route header field rather than by the URI of the Contact Record-Route header field rather than by the URI of the Contact
header field. 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 in 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
by copying them to the outgoing SIP request, similar to a SIP proxy, by copying them to the outgoing SIP request, similar to a SIP proxy,
before it inserts its own Feature-Caps header field to the SIP before it inserts its own Feature-Caps header field in the SIP
request. request.
When such a UA receives a SIP response, if the UA wants to indicate When such a UA receives a SIP response, if the UA wants to indicate
support of features and capabilities towards its upstream SIP support of features and capabilities towards its upstream SIP
entities, it inserts a Feature-Caps header field to the response, entities, it inserts a Feature-Caps header field in the response,
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
response. response.
If the SIP response is triggered by another SIP response that the If the SIP response is triggered by another SIP response that the
B2BUA has received, the UA MAY forward received Feature-Caps header B2BUA has received, the UA MAY forward received Feature-Caps header
field by copying them to the outgoing SIP response, similar to a SIP fields by copying them to the outgoing SIP response, similar to a SIP
proxy, before it inserts its own Feature-Caps header field to the SIP proxy, before it inserts its own Feature-Caps header field in the SIP
response. response.
4.2.3. Registrar Behavior 4.2.3. Registrar Behavior
If a SIP registrar wants to indicate support of features and If a SIP registrar wants to indicate support of features and
capabilities towards its upstream SIP entities, it inserts a Feature- capabilities towards its upstream SIP entities, it inserts a
Caps header field, containing one or more feature capability Feature-Caps header field, containing one or more feature-capability
indicators associated with the supported features and capabilities, indicators associated with the supported features and capabilities,
to a REGISTER response. in a REGISTER response.
4.2.4. Proxy behavior 4.2.4. Proxy Behavior
When a SIP proxy receives a SIP request, if the proxy wants to When a SIP proxy receives a SIP request, if the proxy wants to
indicate support of features and capabilities towards its downstream indicate support of features and capabilities towards its downstream
SIP entities, it inserts a Feature-Caps header field to the request, SIP entities, it inserts a Feature-Caps header field in the request,
containing one or more SIP feature capability indicators associated containing one or more SIP feature-capability indicators associated
with the supported features and capabilities, before it forwards the with the supported features and capabilities, before it forwards the
request. request.
When a proxy receives a SIP response, if the proxy wants to indicate When a proxy receives a SIP response, if the proxy wants to indicate
support of features and capabilities towards its upstream SIP support of features and capabilities towards its upstream SIP
entities, it inserts a Feature-Caps header field to the response, entities, it inserts a Feature-Caps header field in the response,
containing one or more SIP feature capability indicators associated containing one or more SIP feature-capability indicators associated
with the supported features and capabilities, before it forwards the with the supported features and capabilities, before it forwards the
response. response.
4.3. SIP Message Type and Response Code Semantics 4.3. SIP Message Type and Response Code Semantics
4.3.1. General 4.3.1. General
This Section describes the general usage and semantics of the This section describes the general usage and semantics of the
Feature-Caps header field for different SIP message types and Feature-Caps header field for different SIP message types and
response codes. response codes.
Section 6.2.1 defines the Feature-Caps header field ABNF. Section 6.2.1 defines the Feature-Caps header field ABNF.
4.3.2. SIP Dialog 4.3.2. SIP Dialog
The Feature-Caps header field can be used within an initial SIP The Feature-Caps header field can be used within an initial SIP
request for a dialog, within a target refresh SIP request, and within request for a dialog, within a target refresh SIP request, and within
any 18x or 2xx response associated with such requests. any 18x or 2xx response associated with such requests.
If a feature capability indicator is inserted in a Feature-Caps If a feature-capability indicator is inserted in a Feature-Caps
header field of an initial request for a dialog, or within a response header field of an initial request for a dialog, or within a response
of such request, it indicates to the receivers of the request (or of such a request, it indicates to the receivers of the request (or
response) that the feature associated with the feature capability response) that the feature associated with the feature-capability
indicator is supported for the duration of the dialog, until a target indicator is supported for the duration of the dialog, until a target
refresh request is sent for the dialog, or the dialog is terminated. refresh request is sent for the dialog, or until the dialog is
terminated.
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 a 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.
As it cannot be guaranteed that 2xx responses associated with SIP As it cannot be guaranteed that 2xx responses associated with SIP
SUBSCRIBE requests will reach the User Agent Client (UAC) [RFC3261], SUBSCRIBE requests will reach the User Agent Client (UAC) [RFC3261],
due to forking of the request, entities need to indicate supported due to forking of the request, entities need to indicate supported
features and capabilities in the SIP NOTIFY request that will be sent features and capabilities in the SIP NOTIFY request that will be sent
for each of 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 a
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.
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 are
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,
and SIP entities MUST NOT insert a Feature-Caps header field to such and SIP entities MUST NOT insert a Feature-Caps header field in such
messages. messages.
If SIP Outbound [RFC5626] is used, the rules above apply. However, If SIP outbound [RFC5626] is used, the rules above apply. However,
supported features and capabilities only apply for the registration supported features and capabilities only apply for the registration
flow on which support has been explicitly indicated. flow on which support has been explicitly indicated.
4.3.4. SIP Stand-Alone Transactions 4.3.4. SIP Standalone Transactions
The Feature-Caps header field can be used within a standalone SIP The Feature-Caps header field can be used within a standalone SIP
request, and within any 2xx response associated with such request. request and within any 2xx response associated with such a request.
If a feature capability indicator is inserted in a Feature-Caps If a feature-capability indicator is inserted in a Feature-Caps
header field of a standalone request, or within a response of such header field of a standalone request, or within a response of such a
request, it indicates to the receivers of the request (or response) request, it indicates to the receivers of the request (or response)
that the feature associated with the feature capability indicator is that the feature associated with the feature-capability indicator is
supported for the duration of the standalone transaction. supported for the duration of the standalone transaction.
5. Feature Capability Indicators 5. Feature-Capability Indicators
5.1. Introduction 5.1. Introduction
Feature capability indicators are used by SIP entities not Feature-capability indicators are used by SIP entities not
represented by the URI of the Contact header field to indicate represented by the URI of the Contact header field to indicate
support of features and capabilities, where media feature tags cannot support of features and capabilities, where media feature tags cannot
be used to indicate the support. be used to indicate such support.
A value, or a list of values, that provides additional information A value, or a list of values, that provides additional information
about the supported feature or capability, can be associated with a about the supported feature or capability can be associated with a
feature capability indicator. feature-capability indicator.
5.2. Registration Trees 5.2. Registration Trees
5.2.1. General 5.2.1. General
The following subsections define registration trees, distinguished by The following subsections define registration trees, distinguished
the use of faceted names (e.g., names of the form "tree.feature- by the use of faceted names (e.g., names of the form
name"). The registration trees are defined in the IANA "Proxy- "tree.feature-name"). The registration trees are defined in the IANA
Feature Feature Capability Indicator Trees" registry. "Proxy-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 RFCs 2506 [RFC2506] and 3840
Other registration trees are outside the scope of this specification. [RFC3840]. Other registration trees are outside the scope of this
specification.
In contrast to RFC 2506 and RFC 3840, this specification only defines In contrast to RFCs 2506 and 3840, this specification only defines a
a global tree and a sip tree, as they are the only trees defined in global tree and a SIP tree, as they are the only trees defined in
those RFCs that have been used for defining SIP-specific media those RFCs that have been used for defining SIP-specific 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 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").
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.".
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).
It is bad practice for feature capability indicator specifications to It is bad practice for feature-capability indicator specifications to
repeat procedures (e.g. general procedures on the usage of the repeat procedures (e.g., general procedures on the usage of the
Feature-Caps header field and feature capability indicators) defined Feature-Caps header field and feature-capability indicators) defined
in this specification, unless needed for clarification or emphasis in this specification, unless needed for clarification or emphasis
purpose. A feature capability indicator specification MUST NOT purposes. A feature-capability indicator specification MUST NOT
modify the Feature-Caps header field rules and semantics defined in modify the Feature-Caps header field rules and semantics defined in
Section 4. Section 4.
A feature capability indicator specification MUST NOT weaken any A feature-capability indicator specification MUST NOT weaken any
behavior designated with "SHOULD" or "MUST" in this specification. behavior designated with "SHOULD" or "MUST" in this specification.
However, a specification MAY strengthen "SHOULD", "MAY", or However, a specification MAY strengthen "SHOULD", "MAY", or
"RECOMMENDED" requirements to "MUST" strength if features and "RECOMMENDED" requirements to "MUST" strength if features and
capabilities associated with the feature capability indicator require capabilities associated with the feature-capability indicator
it. require it.
5.3.2. Overall Description 5.3.2. Overall Description
The feature capability indicator specification MUST contain an The feature-capability indicator specification MUST contain an
overall description of the feature capability indicator: how it is overall description of the feature-capability indicator: how it is
used to indicate support of a feature, a description of the feature used to indicate support of a feature, a description of the feature
associated with the feature capability indicator, a description of associated with the feature-capability indicator, a description of
any additional information (conveyed using one or more feature any additional information (conveyed using one or more feature-
capability indicator values) that can be conveyed together with the capability indicator values) that can be conveyed together with the
feature capability indicator, and a description of how the associated feature-capability indicator, and a description of how the associated
feature MAY be exercised/invoked. feature MAY be exercised/invoked.
5.3.3. Feature Capability Indicator Values 5.3.3. Feature-Capability Indicator Values
A feature capability indicator can have an associated value, or a A feature-capability indicator can have an associated value, or a
list of values. The feature capability indicator specification MUST list of values. The feature-capability indicator specification MUST
define the syntax and semantics of any value defined for the feature define the syntax and semantics of any value defined for the feature-
capability indicator, including possible restrictions related to the capability indicator, including possible restrictions related to the
usage of a specific value. The feature capability indicator usage of a specific value. The feature-capability indicator
specification MUST define the value(s) in accordance with the ABNF specification MUST define the value(s) in accordance with the ABNF
defined in Section 6.3.2. The feature capability indicator defined in Section 6.3.2. The feature-capability indicator
specification MUST define whether the feature capability indicator specification MUST define whether the feature-capability indicator
has a default value. has a default value.
If no values are defined for the feature capability indicator, it If no values are defined for the feature-capability indicator, it
MUST be indicated in the feature capability indicator specification. MUST be indicated in the feature-capability indicator specification.
A feature capability indicator value is only applicable for the A feature-capability indicator value is only applicable for the
feature capability indicator for which it has been defined. For feature-capability indicator for which it has been defined. For
other feature capability indicators, the value has to be defined other feature-capability indicators, the value has to be defined
explicitly, even if the semantics are identical. explicitly, even if the semantics are identical.
It is strongly RECOMMENDED to not re-use a value that already has It is strongly RECOMMENDED to not re-use a value that already has
been defined for another feature capability indicator, unless the been defined for another feature-capability indicator, unless the
semantics of the values are the same. semantics of the values are the same.
5.3.4. Usage Restrictions 5.3.4. Usage Restrictions
If there are restrictions on how SIP entities can insert a feature If there are restrictions on how SIP entities can insert a feature-
capability indicator, the feature capability indicator specification capability indicator, the feature-capability indicator specification
MUST document such restrictions. MUST document such restrictions.
There might be restrictions related to whether entities are allowed There might be restrictions related to whether or not entities
to insert a feature capability indicator in registration related
messages, standalone transaction messages, dialog related messages, o are allowed to insert a feature-capability indicator in
whether entities are allowed to insert a feature capability indicator registration-related messages, standalone transaction messages, or
in requests or responses, whether entities also need to support other dialog-related messages,
features and capabilities in order to insert a feature capability
indicator, and whether entities are allowed to indicate support of a o are allowed to insert a feature-capability indicator in requests
feature in conjunction with another feature. or responses,
o also need to support other features and capabilities in order to
insert a feature-capability indicator, and
o are allowed to indicate support of a feature in conjunction with
another feature.
5.3.5. Interoperability Considerations 5.3.5. Interoperability Considerations
The feature capability indicator specification MUST document any The feature-capability indicator specification MUST document any
specific interoperability considerations that apply to the feature specific interoperability considerations that apply to the feature-
capability indicator. capability indicator.
Interoperability considerations can e.g. include procedures related Interoperability considerations can, e.g., include procedures related
to cases where an expected feature capability indicator is not to cases where an expected feature-capability indicator is not
present, or where it contains an unexpected value. present or where it contains an unexpected value.
5.3.6. Security Considerations 5.3.6. Security Considerations
The feature capability indicator specification MUST document any The feature-capability indicator specification MUST document any
specific security considerations that apply to the feature capability specific security considerations that apply to the feature-capability
indicator. indicator.
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
messages and message descriptions. messages and message descriptions.
Note that example message flows are by definition informative, and do Note that example message flows are by definition informative and do
not replace normative text. not replace normative text.
5.3.8. Other Information 5.3.8. Other Information
If there is additional information about the feature capability If there is additional information about the feature-capability
indicator, it is recommended to describe such information. It can indicator, it is recommended to describe such information. It can
include e.g. names of related feature capability indicators. include, for example, names of related feature-capability indicators.
6. Syntax 6. Syntax
6.1. General 6.1. General
This Section defines the ABNF for the Feature-Caps header field, and This section defines the ABNF for the Feature-Caps header field and
for the feature capability indicators. The ABNF defined in this for the feature-capability indicators. The ABNF defined in this
specification is conformant to RFC 5234 [RFC5234]." specification is conformant to RFC 5234 [RFC5234].
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)
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]. RFCs 3840 [RFC3840] and 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
used to implement a feature capability indicator tree hierarchy (e.g. used to implement a feature-capability indicator tree hierarchy
tree.feature.subfeature). The description of usage of such tree (e.g., tree.feature.subfeature). The description of usage of such a
hierarchy must be described when registered. tree hierarchy must be described when registered.
6.3.2. ABNF 6.3.2. ABNF
The ABNF for the feature capability indicator: The ABNF for the feature-capability indicator is:
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
of the feature capability indicator name is mandatory. the feature-capability indicator name is mandatory.
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 defined in RFC 3261 [RFC3261].
The following is the registration for the Feature-Caps header field: The following is the registration for Feature-Caps in the "Header
Fields" registry:
RFC Number: RFC XXXX RFC Number: RFC 6809
Header Field Name: Feature-Caps Header Field Name: Feature-Caps
7.2. Registration of the Feature-Caps header field parameter 7.2. Registration of the Feature-Caps Header Field Parameter
This specification adds the Feature-Caps header field to the IANA This specification adds the Feature-Caps header field to the IANA
"Header Field Parameters and Parameter Values" registry, according to "Header Field Parameters and Parameter Values" registry, according to
the process of RFC 3968 [RFC3968]. the process described in RFC 3968 [RFC3968].
Predefined Predefined
Header Field Parameter Name Values Reference Header Field Parameter Name Values Reference
------------------------------------------------------------------ --------------------------------------------------------------------
Feature-Caps +<fcap-name> * No [RFC XXXX] Feature-Caps +<fcap-name> * No [RFC6809]
* <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 6809. Valid
feature capability indicators are registered in [IANA: feature-capability indicators are registered in the
insert reference to the new Proxy-Feature Feature Proxy-Feature Feature-Capability Indicator Trees registry.
Capability Indicator Trees registry].
(IANA: please sort the "Feature-Caps" line into the table and place
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" registry, according to the
the process of RFC 5226. The name of the sub registry is "Proxy- process defined in RFC 5226. The name of the sub-registry is
Feature Feature Capability Indicator Trees". "Proxy-Feature Feature-Capability Indicator Trees".
Feature capability indicators are categorized by the "leading facet" Feature-capability indicators are categorized by the "leading facet"
of their name. The leading facet is a prefix of the name consisting of their name. The leading facet is a prefix of the name consisting
of all characters up to and including the first ".". Feature of all characters up to and including the first ".". Feature-
capability indicator names that contain no "." characters are capability indicator names that contain no "." characters are
considered to have an empty ("") leading facet. considered to have an empty ("") leading facet.
The "Proxy-Feature Feature Capability Indicator Trees" registry The "Proxy-Feature Feature-Capability Indicator Trees" registry
contains sub registries for subsets (called 'trees') of feature contains sub-registries for subsets (called 'trees') of feature-
capability indicators sharing the same leading facet. Each feature capability indicators sharing the same leading facet. Each feature-
capability indicator is registered within the tree that matches its capability indicator is registered within the tree that matches its
leading facet. If no tree matches its leading facet then the feature leading facet. If no tree matches its leading facet, then the
capability indicator can not be registered. feature-capability indicator cannot be registered.
New feature capability indicator sub registries (trees) can be New feature-capability indicator sub-registries (trees) can be
registered. The registration must meet the "Standards Action" registered. The registration must meet the "Standards Action"
policies defined in RFC 5226 [RFC5226]. A new name, unique leading policies defined in RFC 5226 [RFC5226]. A new name, unique leading
facet, and registration policies (as defined in RFC 5226) for feature facet, and registration policies (as defined in RFC 5226) for
capability indicators within this tree need to be provided. feature-capability indicators within this tree need to be provided.
This document defines the first two feature capability indicator This document defines the first two feature-capability indicator
trees ("g." and "sip."). It does not define a tree for the empty trees ("g." and "sip."). It does not define a tree for the empty
leading facet. leading facet.
7.3.2. Global Feature Capability Indicator Registration Tree 7.3.2. Global 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 "Global Feature Capability Indicator The name of the tree is "Global Feature-Capability Indicator
Registration Tree", and its leading facet is "g.". It is used for Registration Tree", and its leading facet is "g.". 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 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
5226. A designated area expert will review the proposed feature RFC 5226. A designated area expert will review the proposed feature-
capability indicator, and consult with members of related mailing capability indicator and consult with members of related mailing
lists. The information required in the registration is defined in lists. The information required in the registration is defined in
Section 5.3 of RFC XXXX. Section 5.3 of this document.
Note that all feature capability indicators registered in the global Note that all feature-capability indicators registered in the global
tree will have names with a leading facet "g.". No leading "+" is tree will have names with a leading facet "g.". 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 global tree is as described below: The format of the global tree is as described below:
Name Description Reference Name Description Reference
------------------------------ ------------------------------
Name contains the Feature Capability Indicator Name, provided Name - contains the Feature-Capability Indicator Name, provided in
in the registration feature capability indication registration 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
indication registration template. registration template.
No initial values are registered in the global tree. No initial values are registered in the global tree.
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 Review" policies defined in RFC 5226. The needs to meet the "IETF Review" policies defined in RFC 5226. The
information required in the registration is defined in Section 5.3 of information required in the registration is defined in Section 5.3 of
RFC XXXX. this document.
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
------------------------------ ------------------------------
Name contains the Feature Capability Indicator Name, provided Name - contains the Feature-Capability Indicator Name, provided in
in the registration feature capability indication registration 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
indication registration template. registration template.
No initial values are registered in the SIP tree. No initial values are registered in the SIP tree.
8. Feature Capability Indicator Registration Template 8. Feature-Capability Indicator Registration Template
Registration requests for the global tree are submitted
by e-mail to iana@iana.org.
Registration requests for the sip tree requires submitting Registration requests for the global tree are submitted by email to
an Internet-Draft to the IESG. iana@iana.org.
Registration requests for the SIP tree requires submitting an
Internet-Draft to the IESG.
| Instructions are preceded by '|'. All fields are mandatory. | Instructions are preceded by '|'. All fields are mandatory.
Feature capability indicator name: Feature-capability indicator name:
Description: Description:
| The description should be no longer than 4 lines. More | The description should be no longer than 4 lines. More
| detailed information can be provided in the feature | detailed information can be provided in the feature
| capability indicator specification. | capability indicator specification.
Feature capability indicator name: Feature-capability indicator specification reference:
| The referenced specification must contain the information
| listed in Section 5.3 of RFC XXXX.
Feature capability indicator specification reference:
| 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 6809.
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)
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
indicators. indicators.
In addition, the RFC 3840 security issue regarding an attacker using In addition, the security issue discussed in RFC 3840 regarding an
the SIP caller preferences extension [RFC3841] in order to affect attacker using the SIP caller preferences extension [RFC3841] in
routing decisions does not apply, as the mechanism is not defined to order to affect routing decisions does not apply, as the mechanism is
be used with feature capability indicators. not defined to 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, if the feature capability indicators provide information Therefore, if the feature-capability indicators provide information
that requires data integrity or origin authentication, mechanisms for that requires data integrity or origin authentication, mechanisms for
providing those MUST be provided. If confidentiality is required providing those MUST be provided. If confidentiality is required,
then the specification MUST call for use of Transport Layer Security then the specification MUST call for the use of Transport Layer
(TLS) [RFC5246] at all hops. Since there are no satisfactory middle- Security (TLS) [RFC5246] at all hops. Since there are no
to-end or middle-to-middle SIP confidentiality mechanisms, TLS is as satisfactory middle-to-end or middle-to-middle SIP confidentiality
good as it gets and specifications SHOULD NOT define feature mechanisms, TLS is as good as it gets, and specifications SHOULD NOT
capability indicators that need confidentiality that is better than define feature-capability indicators that need confidentiality that
the hop-by-hop confidentiality provided by TLS. is better than the hop-by-hop confidentiality provided by TLS.
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. References
[RFC EDITOR NOTE: Please remove this Section when publishing]
Changes from draft-holmberg-sipcore-proxy-feature-11
o IANA: Indicating that no initial values are registered in the
trees.
o IESG: Editorial changes based on comments from Barry Leiba.
o IESG: Reference to RFC 5234 added based on comments from Adrian
Farrel.
o IESG: Editorial changes and Security Consideration modification
based on comments from Stephen Farrell.
o IESG: Editorial changes based on comments from Pete Resnick.
Changes from draft-holmberg-sipcore-proxy-feature-10
o Editorial changes.
o 'IETF Consensus' changed to 'IETF Review' (section 7.3.3)
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
o Comments from Atle Mondrad.
Changes from draft-holmberg-sipcore-proxy-feature-06
o Editorial changes.
Changes from draft-holmberg-sipcore-proxy-feature-05
o AD comments from Robert Sparks
o Additional text added to the Security Considerations section.
o IANA registration template modified.
o IANA registration procedures clarified.
o Feature Capability Indicator specification requirements modified.
o Note regarding SUBSCRIBE 200 responses added.
o Editorial modifications.
Changes from draft-holmberg-sipcore-proxy-feature-04
o WGLC comments from Keith Drage
o 'feature cap' name changed to 'feature capability indicator'.
o Feature-Caps header field added to IANA Header Field Parameters
and Parameter Values registry.
o Editorial modifications.
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
o Changes based on WGLC comments from Shida Schubert.
o - Document title changed
o - Terminology alignment
o - Note text clarifications
o Changes based on WGLC comments from Lili Yang.
Changes from draft-ietf-sipcore-proxy-feature-01
o Changes based on comments from Paul Kyzivat.
o IANA Considerations text added.
Changes from draft-holmberg-sipcore-proxy-feature-04/
draft-ietf-sipcore-proxy-feature-00
o Media feature tags replaced with feature caps, based on SIPCORE
consensus at IETF#83 (Paris).
o Editorial corrections and modifications.
Changes from draft-holmberg-sipcore-proxy-feature-03
o Hadriel Kaplan added as co-author.
o Terminology change: instead of talking of proxies, talk about
entities which are not represented by the URI in a Contact header
field (http://www.ietf.org/mail-archive/web/sipcore/current/
msg04449.html).
o Clarification regarding the usage of the header field in 18x/2xx
responses (http://www.ietf.org/mail-archive/web/sipcore/current/
msg04449.html).
o Specifying that feature support can also be indicated in target
refresh requests (http://www.ietf.org/mail-archive/web/sipcore/
current/msg04454.html).
o Feature Cap specification registration information added.
Changes from draft-holmberg-sipcore-proxy-feature-02
o Definition, and usage of, a new header field, instead of Path,
Record-Route, Route and Service-Route.
Changes from draft-holmberg-sipcore-proxy-feature-01
o Requirement section added
o Use-cases and examples updated based on work in 3GPP
Changes from draft-holmberg-sipcore-proxy-feature-00
o Additional use-cases added
o Direction section added
12. References
12.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
12.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 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)", Preferences for the Session Initiation Protocol (SIP)",
skipping to change at page 21, line 41 skipping to change at page 19, line 5
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 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, "IP Multimedia Subsystem (IMS) Service Continuity;
Stage 2", 3GPP TS 23.237 10.9.0, March 2012.
[3GPP.24.837]
3GPP, "IP Multimedia (IM) Core Network (CN) subsystem
inter-UE transfer enhancements; Stage 3", 3GPP TR 24.837
10.0.0, April 2011.
Authors' Addresses Authors' Addresses
Christer Holmberg Christer Holmberg
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: christer.holmberg@ericsson.com EMail: christer.holmberg@ericsson.com
Ivo Sedlacek Ivo Sedlacek
Ericsson Ericsson
Scheelevaegen 19C Scheelevaegen 19C
Lund 22363 Lund 22363
Sweden Sweden
Email: ivo.sedlacek@ericsson.com EMail: ivo.sedlacek@ericsson.com
Hadriel Kaplan Hadriel Kaplan
Acme Packet Acme Packet
71 Third Ave. 71 Third Ave.
Burlington, MA 01803 Burlington, MA 01803
USA USA
Email: hkaplan@acmepacket.com EMail: hkaplan@acmepacket.com
 End of changes. 156 change blocks. 
449 lines changed or deleted 338 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/