draft-ietf-sipcore-proxy-feature-05.txt   draft-ietf-sipcore-proxy-feature-06.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: February 9, 2013 H. Kaplan Expires: February 25, 2013 H. Kaplan
Acme Packet Acme Packet
August 8, 2012 August 24, 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-05.txt draft-ietf-sipcore-proxy-feature-06.txt
Abstract Abstract
This specification defines a new SIP header field, Feature-Caps, to This specification defines a new SIP header field, Feature-Caps, to
convey feature capability indicators, which are used by SIP entities convey feature capability indicators, which are used by SIP entities
not represented by the URI of the Contact header field to indicate not 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 the support.
This specification also defines feature capability indicators, and This specification also defines feature capability indicators, and
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 February 9, 2013. This Internet-Draft will expire on February 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 27 skipping to change at page 2, line 27
4. Feature-Caps Header Field . . . . . . . . . . . . . . . . . . 4 4. Feature-Caps Header Field . . . . . . . . . . . . . . . . . . 4
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) . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . 8 5. Feature Capability Indicators . . . . . . . . . . . . . . . . 9
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 8 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. Examples . . . . . . . . . . . . . . . . . . . . . . . 12 5.3.5. Interoperability Considerations . . . . . . . . . . . 11
5.3.6. Security Considerations . . . . . . . . . . . . . . . 12
5.3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . 12 6.3. Syntax: feature capability indicator . . . . . . . . . . . 13
6.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 12 6.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 13
6.3.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 12 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 . 13 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 . . 14 7.3.3. SIP Feature Capability Indicator Registration Tree . . 15
8. Feature Capability Indicator Registration Template . . . . . . 15 8. Feature Capability Indicator Registration Template . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 17 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 18
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
12.1. Normative References . . . . . . . . . . . . . . . . . . . 18 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . . 18 12.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
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, to
skipping to change at page 5, line 12 skipping to change at page 5, line 12
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 Feature-
Caps header field indicates that a SIP entity in the SIP message Caps header field indicates that a SIP entity in the SIP message
signalling path supports the associated feature and capability. signalling path supports the associated feature and capability.
For a given fc-value, as defined in section 5.3.1, feature capability
indicators are listed in a non-priority order, and any order of the
listed SIP feature capability indicators have the same meaning. For
example, "foo;bar" and "bar;foo" have the same meaning (i.e. that the
SIP entity that inserted the feature capability indicator supports
the features and capabilities associated with the "foo" and "bar"
feature capability indicators.
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
skipping to change at page 6, line 5 skipping to change at page 5, line 45
capability indicator. capability 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
indicators are listed in a non-priority order, and any order of the
listed SIP feature capability indicators have the same meaning. For
example, "foo;bar" and "bar;foo" have the same meaning (i.e. that the
SIP entity that inserted the feature capability indicator supports
the features and capabilities associated with the "foo" and "bar"
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 applies to UAs that are part of B2BUAs
that are referenced in the message by a Record-Route header field that are referenced in the message by a Record-Route header field
rather than by the URI of the Contact header field. rather than by the URI of the Contact header field.
When a UA sends a SIP request, if the UA wants to indicate support of When such UA sends a SIP request, if the UA wants to indicate support
features and capabilities towards its downstream SIP entities, it of features and capabilities towards its downstream SIP entities, it
inserts a Feature-Caps header field to the request, containing one or inserts a Feature-Caps header field to the request, containing one or
more feature capability indicators associated with the supported more feature capability indicators associated with the supported
features and capabilities, before it forwards the request. features and capabilities, before it forwards the 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 to the SIP
request. request.
When a UA receives a SIP response, if the UA wants to indicate When such 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 to 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 field 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 to the SIP
skipping to change at page 7, line 20 skipping to change at page 7, line 20
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.
NOTE: Future specifications can define usage and semantics of the
Feature-Caps header field for SIP methods, response codes and request
types not specified in this specification.
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 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 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 or a target refresh request, or within a response of header field or 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 long 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
SIP SUBSCRIBE requests will reach the UAC, due to forking of the
request, entities need to indicate supported features and
capabilities in the SIP NOTIFY request that will be sent 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 NOTE: 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 the contact(s) that were explicitly indicated feature only applies to requests sent to the contact(s)
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,
and SIP entities MUST NOT insert a Feature-Caps header field to such and SIP entities MUST NOT insert a Feature-Caps header field to 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 Stand-Alone 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 18x or 2xx response associated with such request, and within any 2xx response associated with such request.
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
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 the 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.
Section 4 defines how feature capability indicators are conveyed
using the Feature-Caps header field.
Section 6.3.2 defines the feature capability indicator ABNF.
Section 8 provides a template for registering feature capability
indicators.
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 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.
[RFC3840]. Other registration trees are outside the scope of this Other registration trees are outside the scope of this specification.
specification.
NOTE: In contrast to RFC 2506 and RFC 3840, this specification only NOTE: In contrast to RFC 2506 and RFC 3840, this specification only
defines a global tree and a sip tree, as they are the only trees defines a global tree and a sip tree, as they are the only trees
defined in those RFCs that have been used for defining SIP-specific defined in those RFCs that have been used for defining SIP-specific
media feature tags. media feature tags.
When a feature 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 A feature capability indicator for the global tree will be registered
by the IANA after review by a designated expert. That review will by the IANA after review by a designated expert. That review will
serve to ensure that the feature capability indicator meets the serve to ensure that the definition of the feature capability
technical requirements of this specification. 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,
it needs to meet the "Expert Review" policies defined in RFC 5226
[RFC5226]. A designated area expert will review the proposed feature
capability indicator, and consult with members of related mailing
lists. This policy overrides the policy defined for registering new
header field parameters.
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 [RFC3840]. 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
[RFC5226]. An RFC, which contains the registration of the feature
capability indicator, MUST be published. This policy overrides the
policy defined for registering new header field parameters.
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 11, line 11 skipping to change at page 10, line 44
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 SIP feature capability indicator capabilities associated with the SIP feature capability indicator
require 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 SIP feature cap, a description of any additional associated with the feature capability indicator, a description of
information (conveyed using one or more feature capability indicator any additional information (conveyed using one or more feature
values) that can be conveyed together with the feature capability capability indicator values) that can be conveyed together with the
indicator, and a description of how the associated feature may be feature capability indicator, and a description of how the associated
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. list of values. The feature capability indicator specification MUST
define the syntax and semantics of any value defined for the feature
capability indicator, including possible restrictions related to the
usage of a specific value. The feature capability indicator
specification MUST define the value(s) in accordance with the ABNF
defined in Section 6.3.2. The feature capability indicator
specification MUST define whether the feature capability indicator
has a default value.
The feature capability indicator specification MUST define the syntax If no values are defined for the feature capability indicator, it
and semantics of any value defined for the feature capability MUST be indicated in the feature capability indicator specification.
indicator, including possible restrictions related to the usage of a
specific value. The feature cap specification MUST define the
value(s) in accordance with the ABNF defined in Section 6.3.2.
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 SIP If there are restrictions on how SIP entities can insert a feature
feature cap, the feature capability indicator specification MUST capability indicator, the feature capability indicator specification
document such restrictions. MUST document such restrictions.
There might be restrictions related to whether entities are allowed There might be restrictions related to whether entities are allowed
to insert a feature capability indicator in registration related to insert a feature capability indicator in registration related
messages, standalone transaction messages, or dialog related messages, standalone transaction messages, or dialog related
messages, whether entities are allowed to insert a feature capability messages, whether entities are allowed to insert a feature capability
indicator in requests or responses, whether entities also need to indicator in requests or responses, whether entities also need to
support other features and capabilities in order to insert a feature support other features and capabilities in order to insert a feature
capability indicator, and whether entities are allowed to indicate capability indicator, and whether entities are allowed to indicate
support of a feature in conjunction with another feature. support of a feature in conjunction with another feature.
5.3.5. Examples 5.3.5. Interoperability Considerations
If there are specific interoperability considerations that apply to
the feature capability indicator, the feature capability indicator
specification MUST document such considerations.
5.3.6. Security Considerations
If there are specific security considerations that apply to the
feature capability indicator, the feature capability indicator
specification MUST document such considerations.
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
If there is additional information about the feature capability
indicator, it is RECOMMENDED to describe such information. It can
include e.g. 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. for the feature capability indicators.
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 Figure 1: ABNF
NOTE: A "*" value means that no information regarding which SIP NOTE: The "*" value is present in order to follow the guidelines for
entity, or domain, that indicate support of features and capabilities syntax in RFC 4485 [RFC4485] and to maintain a consistent format with
is provided. 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
used to implement a SIP feature cap tree hierarchy (e.g. used to implement a feature capability indicator tree hierarchy (e.g.
tree.feature.subfeature). The description of usage of such tree tree.feature.subfeature). The description of usage of such tree
hierarchy must be described when registered. 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:
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
skipping to change at page 13, line 26 skipping to change at page 13, line 39
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 XXX RFC Number: RFC XXXX (IANA: Replace XXXX with the assigned RFC number
of this specification)
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 of RFC 3968 [RFC3968].
Header Field Parameter Name Predefined Values Reference Header Field Parameter Name Predefined Values Reference
---------------------------------------------------------------- ----------------------------------------------------------------
--------------------------------------------------------------- Feature-Caps +<fcap-name> * No [XXXX]
Feature-Caps <feature-cap>* No [xxx]
*<feature-cap> denotes parameter names conforming to the * <fcap-name> denotes parameter names conforming to the
syntax <feature-cap> defined in [xxx]. Valid feature capability syntax <fcap-name> defined in [xxx]. Valid feature capability
indicators are registered in [reference to the new indicators are registered in [IANA: insert reference to the new
Proxy-Feature Feature Capability Indicator Trees registry]. Proxy-Feature Feature Capability Indicator Trees registry].
(IANA: Replace XXXX with the assigned RFC number of this
specification)
Figure 3: SIP Parameter Header Field 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 [RFC5226]. The name of the sub registry is the process of RFC 5226. The name of the sub registry is "Proxy-
"Proxy-Feature Feature Capability Indicator Trees". Feature Feature Capability Indicator Trees".
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.
The addition of entries into this tree occurs through the Expert The addition of entries into this tree occurs through the Expert
Review policies, as defined in RFC 5226. A designated area expert Review policy, as defined in RFC 5226. A designated area expert will
will review the proposed feature capability indicator, and consult review the proposed feature capability indicator, and consult with
with members of related mailing lists. The information required in members of related mailing lists. The information required in the
the registration is defined in Section 5.3 of RFC XXX. registration is defined in Section 5.3 of RFC XXXX (IANA: Replace
XXXX with the assigned RFC number of this specification).
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:
Decimal Name Description Reference
---------------------------------------------------
Decimal contains an integer value, incremented by IANA every
time a new feature capability indicator is added to the table.
Name contains the Feature Capability Indicator Name, provided
in the registration feature capability indication registration
template.
Description contains the Abstract, provided in the registration
feature capability indication registration template.
Reference contains the Feature Capability Indicator Specification
Reference, provided in the registration feature capability
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.
The addition of entries into this tree occurs through the IETF The addition of entries into this tree occurs through the IETF
Consensus, as defined in RFC 5226. This requires the publication of Consensus, as defined in RFC 5226. This requires the publication of
an RFC that contains the registration. The information required in an RFC that contains the registration. The information required in
the registration is defined in Section 5.3 of RFC XXX. the registration is defined in Section 5.3 of RFC XXXX (IANA: Replace
XXXX with the assigned RFC number of this specification).
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.
8. Feature Capability Indicator Registration Template The format of the SIP tree is as described below:
To: sip-feature-capability-indicators@apps.ietf.org
(feature capability indicators mailing list)
Subject: Registration of feature capability indicator XXXX
| Instructions are preceded by '|'. Some fields are optional.
Feature cap name:
Summary of feature indicated by this feature capability indicator:
| The summary should be no longer than 4 lines. More
| detailed information can be provided in the SIP feature
| cap specification.
Feature cap specification reference:
| The referenced specification MUST contain the information
| listed in Section 5.3 of XXXX (IANA: Replace XXXX with
| assigned RFC number of this specification.
Values appropriate for use with this feature capability indicator:
| If no values are defined for the feature capability indicator, Decimal Name Description Reference
| indicate "N/A". Details about feature capability indicator values ---------------------------------------------------
| MUST be defined in the feature capability indicator specification.
The feature capability indicator is intended primarily for Decimal contains an integer value, incremented by IANA every
use in the following applications, protocols, time a new feature capability indicator is added to the table.
services, or negotiation mechanisms: [optional]
| For applications, also specify the number of the Name contains the Feature Capability Indicator Name, provided
| first version which will use the feature capability indicator, in the registration feature capability indication registration
| if applicable. template.
Examples of typical use: [optional] Description contains the Abstract, provided in the registration
feature capability indication registration template.
Considerations particular to use in individual Reference contains the Feature Capability Indicator Specification
applications, protocols, services, or negotiation Reference, provided in the registration feature capability
mechanisms: [optional] indication registration template."
Interoperability considerations: [optional] Figure 5
Security considerations: 8. Feature Capability Indicator Registration Template
Privacy concerns, related to exposure of personal Registration requests for the global tree are submitted
information: by e-mail to iana@iana.org.
Denial of service concerns related to consequences Registration requests for the sip tree requires submitting
of specifying incorrect values: an Internet-Draft to the IESG.
Other: | Instructions are preceded by '|'. All fields are mandatory.
Additional information: [optional] Feature capability indicator name:
Keywords: [optional] Description:
Related feature capability indicators: [optional] | The description should be no longer than 4 lines. More
| detailed information can be provided in the feature
| capability indicator specification.
Name(s) & email address(es) of person(s) to Feature capability indicator name:
contact for further information:
Intended usage: | The referenced specification MUST contain the information
| listed in Section 5.3 of XXXX (IANA: Replace XXXX with
| the assigned RFC number of this specification).
| one of COMMON, LIMITED USE or OBSOLETE Feature capability indicator specification reference:
Author/Change controller: | The referenced specification MUST contain the information
| listed in Section 5.3 of XXXX (IANA: Replace XXXX with
| the assigned RFC number of this specification).
Other information: [optional] Contact:
| Any other information that the author deems | Name(s) & email address(es) of person(s) to
| interesting may be added here. | contact for further information."
Figure 4: Registration Template 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. However, as the ones defined in RFC 3840 for media feature tags. Media feature
feature capability indicators will typically not be used to convey tags can reveal information about end-users and end-user equipment,
capability information of end-user devices, those aspects of RFC 3840 which can be used for industrial espionage. The knowledge about end-
do not apply to feature capability indicators. user equipment capabilities can also be used to influence application
behavior. As feature capability indicators are not intended to
convey capability information of end-user devices, such end-user
security aspects of RFC 3840 do not apply to feature capability
indicators.
In addition, the RFC 3840 security issue regarding an attacker using In addition, the RFC 3840 security issue regarding an attacker using
the SIP caller preferences extension [RFC3841] in order to affect the SIP caller preferences extension [RFC3841] in order to affect
routing decisions does not apply, as the mechanism is not defined to routing decisions does not apply, as the mechanism is not defined to
be used with feature capability indicators. be used with feature capability indicators.
Feature caps can provide capability and characteristics information Feature capability indicators can, however, provide capability and
about the SIP entity, some of which might be sensitive. The Feature- characteristics information about the SIP entity, some of which might
Caps header field does not convey address information about SIP be sensitive. Malicious elements viewing the indicators may be able
entities. However, individual feature capability indicators might to discern application deployment details or identify elements with
provide address information as feature capability indicator values. exploitable feature implementation weaknesses. The Feature-Caps
header field does not convey address information about SIP entities.
However, individual feature capability indicators might provide
address information as feature capability indicator values.
Therefore, mechanisms for guaranteeing confidentiality and Therefore, mechanisms for guaranteeing confidentiality and
authenticity SHOULD be provided. authenticity SHOULD 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-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 Changes from draft-holmberg-sipcore-proxy-feature-04
o WGLC comments from Keith Drage o WGLC comments from Keith Drage
o 'feature cap' name changed to 'feature capability indicator'. o 'feature cap' name changed to 'feature capability indicator'.
o Feature-Caps header field added to IANA Header Field Parameters o Feature-Caps header field added to IANA Header Field Parameters
and Parameter Values registry. and Parameter Values registry.
o Editorial modifications. o Editorial modifications.
Changes from draft-ietf-sipcore-proxy-feature-03 Changes from draft-ietf-sipcore-proxy-feature-03
o Additional Security Considerations text added. o Additional Security Considerations text added.
o IANA Considerations modified. o IANA Considerations modified.
skipping to change at page 19, line 11 skipping to change at page 20, line 35
[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)",
RFC 3841, August 2004. RFC 3841, August 2004.
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority [RFC3968] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Header Field Parameter Registry for the Session (IANA) Header Field Parameter Registry for the Session
Initiation Protocol (SIP)", BCP 98, RFC 3968, Initiation Protocol (SIP)", BCP 98, RFC 3968,
December 2004. December 2004.
[RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors
of Extensions to the Session Initiation Protocol (SIP)",
RFC 4485, May 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol Initiated Connections in the Session Initiation Protocol
(SIP)", RFC 5626, October 2009. (SIP)", RFC 5626, October 2009.
[3GPP.23.237] [3GPP.23.237]
3GPP, "IP Multimedia Subsystem (IMS) Service Continuity; 3GPP, "IP Multimedia Subsystem (IMS) Service Continuity;
 End of changes. 68 change blocks. 
169 lines changed or deleted 202 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/