SIPCORE Working Group C. Holmberg Internet-Draft I. Sedlacek Intended status: Standards Track Ericsson Expires: April 1, 2013 H. Kaplan Acme Packet September 28, 2012 Mechanism to indicate support of features and capabilities in the Session Initiation Protocol (SIP) draft-ietf-sipcore-proxy-feature-11.txt Abstract This specification defines a new SIP header field, Feature-Caps. The Feature-Caps header field conveys feature capability indicators that are used to indicate support of features and capabilities for SIP entities that are not represented by the Uniform Resource Identifier (URI) of the Contact header field. SIP entities that are represented by the URI of the SIP Contact header field can convey media feature tags in the Contact header field to indicate support of features and capabilities. This specification also defines feature capability indicators, and creates a new IANA registry, "Proxy-Feature Feature Capability Indicator Trees", for registering feature capability indicators. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 1, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the Holmberg, et al. Expires April 1, 2013 [Page 1] Internet-Draft proxy feature September 2012 document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Feature-Caps Header Field . . . . . . . . . . . . . . . . . . 5 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. User Agent and Proxy Behavior . . . . . . . . . . . . . . 5 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5 4.2.2. B2BUA Behavior . . . . . . . . . . . . . . . . . . . . 6 4.2.3. Registrar Behavior . . . . . . . . . . . . . . . . . . 6 4.2.4. Proxy behavior . . . . . . . . . . . . . . . . . . . . 6 4.3. SIP Message Type and Response Code Semantics . . . . . . . 7 4.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 7 4.3.2. SIP Dialog . . . . . . . . . . . . . . . . . . . . . . 7 4.3.3. SIP Registration (REGISTER) . . . . . . . . . . . . . 8 4.3.4. SIP Stand-Alone Transactions . . . . . . . . . . . . . 8 5. Feature Capability Indicators . . . . . . . . . . . . . . . . 9 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Registration Trees . . . . . . . . . . . . . . . . . . . . 9 5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 9 5.2.2. Global Tree . . . . . . . . . . . . . . . . . . . . . 9 5.2.3. SIP Tree . . . . . . . . . . . . . . . . . . . . . . . 10 5.3. Feature Capability Indicator Specification Requirements . 10 5.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 10 5.3.2. Overall Description . . . . . . . . . . . . . . . . . 10 5.3.3. Feature Capability Indicator Values . . . . . . . . . 10 5.3.4. Usage Restrictions . . . . . . . . . . . . . . . . . . 11 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.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Syntax: Feature-Caps header field . . . . . . . . . . . . 12 Holmberg, et al. Expires April 1, 2013 [Page 2] Internet-Draft proxy feature September 2012 6.2.1. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.3. Syntax: feature capability indicator . . . . . . . . . . . 13 6.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 13 6.3.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7.1. Registration of the Feature-Caps header field . . . . . . 13 7.2. Registration of the Feature-Caps header field parameter . 13 7.3. Proxy-Feature Feature Capability Indicator Trees . . . . . 14 7.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 14 7.3.2. Global Feature Capability Indicator Registration Tree . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.3.3. SIP Feature Capability Indicator Registration Tree . . 15 8. Feature Capability Indicator Registration Template . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 12.2. Informative References . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Holmberg, et al. Expires April 1, 2013 [Page 3] Internet-Draft proxy feature September 2012 1. Introduction The Session Initiation Protocol (SIP) [RFC3261] "Caller Preferences" extension, defined in RFC 3840 [RFC3840], provides a mechanism that allows a SIP message to convey information relating to the originator's features and capabilities, using the Contact header field. This specification defines a new SIP header field, Feature-Caps. The Feature-Caps header field conveys feature capability indicators that are used to indicate support of features and capabilities for SIP entities that are not represented by the Uniform Resource Identifier (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 registrar. o - The SIP entity acts as a Back-to-Back User Agent (B2BUA) [RFC3261], where the Contact header field URI represents another SIP entity. SIP entities that are represented by the URI of the SIP Contact header field can convey media feature tags in the Contact header field to indicate support of features and capabilities. Unlike media feature tags, feature capability indicators are intended to only be used with the SIP protocol. This specification also defines feature capability indicators, and creates a new IANA registry, "Proxy-Feature Feature Capability Indicator Trees", for registering feature capability indicators. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 3. Definitions Downstream SIP entity: SIP entity in the direction towards which a SIP request is sent. Upstream SIP entity: SIP entity in the direction from which a SIP request is received. Holmberg, et al. Expires April 1, 2013 [Page 4] Internet-Draft proxy feature September 2012 4. Feature-Caps Header Field 4.1. Introduction The Feature-Caps header field is used by SIP entities to convey support of features and capabilities, by setting feature capability indicators. A feature capability indicator conveyed in a Feature- Caps header field indicates that a SIP entity in the SIP message signalling path supports the associated feature and capability. 4.2. User Agent and Proxy Behavior 4.2.1. General If the URI in a Contact header field of a request or response represents a SIP entity, the entity MUST NOT indicate supported features and capabilities using a Feature-Caps header field within that request or response. When a SIP entity receives a SIP request, or response, that contains one or more Feature-Caps header fields, the feature capability indicators in the header field inform the entity about the features and capabilities supported by entities in the SIP message signalling path. The procedure by which features and capabilities are invoked are outside the scope of this specification, and MUST be described by individual feature capability indicator specifications. A Feature-Caps header field value cannot convey the address of the SIP entity that inserted the Feature-Caps header field. If additional data about a supported feature needs to be conveyed, such as the address of the SIP entity that indicated support of the feature, then the feature definition needs to define a way to convey that information as a value of the associated feature capability indicator. 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 header field in the message to be forwarded, so that the added header field becomes the top-most one. Then, when another SIP entity receives a SIP request or the response, the SIP feature capability indicators in the top-most Feature-Caps header field will represent the supported features and capabilities "closest" to the entity. 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 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" Holmberg, et al. Expires April 1, 2013 [Page 5] Internet-Draft proxy feature September 2012 feature capability indicators. 4.2.2. B2BUA Behavior The procedures in this Section apply to User Agents (UAs) [RFC3261] 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 header field. When such a UA sends a SIP request, if the UA wants to indicate support of features and capabilities towards its downstream SIP entities, it inserts a Feature-Caps header field to the request, containing one or more feature capability indicators associated with the supported features and capabilities, before it forwards the request. If the SIP request is triggered by another SIP request that the B2BUA has received, the UA MAY forward received Feature-Caps header fields 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 request. When such a UA receives a SIP response, if the UA wants to indicate support of features and capabilities towards its upstream SIP entities, it inserts a Feature-Caps header field to the response, containing one or more feature capability indicators associated with the supported features and capabilities, before it forwards the response. If the SIP response is triggered by another SIP response that the B2BUA has received, the UA MAY forward received Feature-Caps header 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 response. 4.2.3. Registrar Behavior If a SIP registrar wants to indicate support of features and capabilities towards its upstream SIP entities, it inserts a Feature- Caps header field, containing one or more feature capability indicators associated with the supported features and capabilities, to a REGISTER response. 4.2.4. Proxy behavior When a SIP proxy receives a SIP request, if the proxy wants to indicate support of features and capabilities towards its downstream SIP entities, it inserts a Feature-Caps header field to the request, Holmberg, et al. Expires April 1, 2013 [Page 6] Internet-Draft proxy feature September 2012 containing one or more SIP feature capability indicators associated with the supported features and capabilities, before it forwards the request. When a proxy receives a SIP response, if the proxy wants to indicate support of features and capabilities towards its upstream SIP entities, it inserts a Feature-Caps header field to the response, containing one or more SIP feature capability indicators associated with the supported features and capabilities, before it forwards the response. 4.3. SIP Message Type and Response Code Semantics 4.3.1. General This Section describes the general usage and semantics of the Feature-Caps header field for different SIP message types and response codes. Section 6.2.1 defines the Feature-Caps header field ABNF. 4.3.2. SIP Dialog The Feature-Caps header field can be used within an initial SIP request for a dialog, within a target refresh SIP request, and within any 18x or 2xx response associated with such requests. If a feature capability indicator is inserted in a Feature-Caps 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 response) that the feature associated with the feature capability indicator is supported for the duration of the dialog, until a target refresh request is sent for the dialog, or the dialog is terminated. Unless a feature capability indicator is inserted in a Feature-Caps header field of a target refresh request, or within a response of such request, it indicates to the receivers of the request (or response) that the feature is no longer supported for the dialog. For a given dialog a SIP entity MUST insert the same feature capability indicators in all 18x and 2xx responses associated with a given transaction. As it cannot be guaranteed that 2xx responses associated with SIP SUBSCRIBE requests will reach the User Agent Client (UAC) [RFC3261], 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. Holmberg, et al. Expires April 1, 2013 [Page 7] Internet-Draft proxy feature September 2012 4.3.3. SIP Registration (REGISTER) The Feature-Caps header field can be used within a SIP REGISTER request, and within the 200 (OK) response associated with such request. If a feature capability indicator is conveyed in a Feature-Caps header field of a REGISTER request, or within an associated response, it indicates to the receivers of the message that the feature associated with the feature capability indicator is supported for the registration, until the registration of the contact that was explicitly conveyed in the REGISTER request expires, or until the registered contact is explicitly refreshed and the refresh REGISTER request does not contain the feature capability indicator associated with the feature. While a REGISTER response can contain contacts that have been registered as part of other registration transactions, support of any indicated feature only applies to requests sent to the contact(s) that were explicitly conveyed in the associated REGISTER request. This specification does not define any semantics for usage of the Feature-Caps header field in pure registration binding fetching messages (see Section 10.2.3 of RFC 3261), where the REGISTER request does not contain a Contact header field. Unless such semantics is defined in a future extension, fetching messages will not have any impact on previously indicated support of features and capabilities, and SIP entities MUST NOT insert a Feature-Caps header field to such messages. If SIP Outbound [RFC5626] is used, the rules above apply. However, supported features and capabilities only apply for the registration flow on which support has been explicitly indicated. 4.3.4. SIP Stand-Alone Transactions The Feature-Caps header field can be used within a standalone SIP request, and within any 2xx response associated with such request. If a feature capability indicator is inserted in a Feature-Caps header field of a standalone request, or within a response of such request, it indicates to the receivers of the request (or response) that the feature associated with the feature capability indicator is supported for the duration of the standalone transaction. Holmberg, et al. Expires April 1, 2013 [Page 8] Internet-Draft proxy feature September 2012 5. Feature Capability Indicators 5.1. Introduction Feature capability indicators are used by SIP entities not represented by the URI of the Contact header field to indicate support of features and capabilities, where media feature tags cannot be used to indicate the support. A value, or a list of values, that provides additional information about the supported feature or capability, can be associated with a feature capability indicator. 5.2. Registration Trees 5.2.1. General The following subsections define registration trees, distinguished by the use of faceted names (e.g., names of the form "tree.feature- name"). The registration trees are defined in the IANA "Proxy- Feature Feature Capability Indicator Trees" registry. 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. Other registration trees are outside the scope of this specification. 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 defined in those RFCs that have been used for defining SIP-specific media feature tags. When a feature capability indicator is registered in any registration tree, no leading "+" is used in the registration. 5.2.2. Global Tree The global feature capability indicator tree is similar to the media feature tag global tree defined in RFC 2506 [RFC2506]. A feature capability indicator in the global tree will be distinguished by the leading facet "g.". An organization can propose either a designation indicative of the feature, (e.g., "g.blinktags") or a faceted designation including the organization name (e.g., "g.organization.blinktags"). Holmberg, et al. Expires April 1, 2013 [Page 9] Internet-Draft proxy feature September 2012 5.2.3. SIP Tree The sip feature capability indicator tree is similar to the media feature tag sip tree defined in RFC 3840. A feature capability indicator in the sip tree will be distinguished by the leading facet "sip.". 5.3. Feature Capability Indicator Specification Requirements 5.3.1. General A feature capability indicator specification MUST address the issues defined in the following subsections, or document why an issue is not applicable for the specific feature capability indicator. A reference to the specification MUST be provided when the feature capability indicator is registered with IANA (see Section 8). It is bad practice for feature capability indicator specifications to repeat procedures (e.g. general procedures on the usage of the Feature-Caps header field and feature capability indicators) defined in this specification, unless needed for clarification or emphasis purpose. A feature capability indicator specification MUST NOT modify the Feature-Caps header field rules and semantics defined in Section 4. A feature capability indicator specification MUST NOT weaken any behavior designated with "SHOULD" or "MUST" in this specification. However, a specification MAY strengthen "SHOULD", "MAY", or "RECOMMENDED" requirements to "MUST" strength if features and capabilities associated with the SIP feature capability indicator require it. 5.3.2. Overall Description The feature capability indicator specification MUST contain an overall description of the feature capability indicator: how it is used to indicate support of a feature, a description of the feature associated with the feature capability indicator, a description of any additional information (conveyed using one or more feature capability indicator values) that can be conveyed together with the feature capability indicator, and a description of how the associated feature may be exercised/invoked. 5.3.3. Feature Capability Indicator Values A feature capability indicator can have an associated value, or a list of values. The feature capability indicator specification MUST Holmberg, et al. Expires April 1, 2013 [Page 10] Internet-Draft proxy feature September 2012 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. If no values are defined for the feature capability indicator, it MUST be indicated in the feature capability indicator specification. A feature capability indicator value is only applicable for the feature capability indicator for which it has been defined. For other feature capability indicators, the value has to be defined explicitly, even if the semantics are identical. It is strongly RECOMMENDED to not re-use a value that already has been defined for another feature capability indicator, unless the semantics of the values are the same. 5.3.4. Usage Restrictions If there are restrictions on how SIP entities can insert a feature capability indicator, the feature capability indicator specification MUST document such restrictions. There might be restrictions related to whether entities are allowed to insert a feature capability indicator in registration related messages, standalone transaction messages, dialog related messages, whether entities are allowed to insert a feature capability indicator in requests or responses, whether entities also need to support other features and capabilities in order to insert a feature capability indicator, and whether entities are allowed to indicate support of a feature in conjunction with another feature. 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. Interoperability considerations can e.g. include procedures related to cases where an expected feature capability indicator is not present, or where it contains an unexpected value. Holmberg, et al. Expires April 1, 2013 [Page 11] Internet-Draft proxy feature September 2012 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 provide demonstrative message flow diagrams, paired with complete messages and message descriptions. Note that example message flows are by definition informative, and do 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.1. General This Section defines the ABNF for the Feature-Caps header field, and for the feature capability indicators. 6.2. Syntax: Feature-Caps header field 6.2.1. ABNF The ABNF for the Feature-Caps header fields is: Feature-Caps = "Feature-Caps" HCOLON fc-value *(COMMA fc-value) fc-value = "*" *(SEMI feature-cap) NOTE: The "*" value is present in order to follow the guidelines for syntax in RFC 4485 [RFC4485] and to maintain a consistent format with RFC 3840 and RFC 3841 [RFC3841]. Holmberg, et al. Expires April 1, 2013 [Page 12] Internet-Draft proxy feature September 2012 6.3. Syntax: feature capability indicator 6.3.1. General In a feature capability indicator name (ABNF: fcap-name), dots can be used to implement a feature capability indicator tree hierarchy (e.g. tree.feature.subfeature). The description of usage of such tree hierarchy must be described when registered. 6.3.2. ABNF The ABNF for the feature capability indicator: feature-cap = "+" fcap-name [EQUAL LDQUOT (fcap-value-list / fcap-string-value ) RDQUOT] fcap-name = ftag-name fcap-value-list = tag-value-list fcap-string-value = string-value ;; ftag-name, tag-value-list, string-value defined in RFC 3840 NOTE: In comparison with media feature tags, the "+" sign in front of the feature capability indicator name is mandatory. 7. IANA Considerations 7.1. Registration of the Feature-Caps header field This specification registers a new SIP header field, Feature-Caps, according to the process of RFC 3261 [RFC3261]. The following is the registration for the Feature-Caps header field: RFC Number: RFC XXXX Header Field Name: Feature-Caps 7.2. Registration of the Feature-Caps header field parameter This specification adds the Feature-Caps header field to the IANA "Header Field Parameters and Parameter Values" registry, according to the process of RFC 3968 [RFC3968]. Holmberg, et al. Expires April 1, 2013 [Page 13] Internet-Draft proxy feature September 2012 Predefined Header Field Parameter Name Values Reference ------------------------------------------------------------------ Feature-Caps + * No [RFC XXXX] * denotes parameter names conforming to the syntax defined in RFC XXXX. Valid feature capability indicators are registered in [IANA: insert reference to the new Proxy-Feature Feature 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.1. Introduction This specification creates a new sub registry to the IANA "Session Initiation Protocol (SIP) Parameters" Protocol Registry, according to the process of RFC 5226. The name of the sub registry is "Proxy- Feature Feature Capability Indicator Trees". Feature capability indicators are categorized by the "leading facet" of their name. The leading facet is a prefix of the name consisting of all characters up to and including the first ".". Feature capability indicator names that contain no "." characters are considered to have an empty ("") leading facet. The "Proxy-Feature Feature Capability Indicator Trees" registry contains sub registries for subsets (called 'trees') of feature capability indicators sharing the same leading facet. Each feature capability indicator is registered within the tree that matches its leading facet. If no tree matches its leading facet then the feature capability indicator can not be registered. New feature capability indicator sub registries (trees) can be registered. The registration must meet the "Standards Action" policies defined in RFC 5226. A new name, unique leading facet, and registration policies (as defined in RFC 5226) for feature capability indicators within this tree need to be provided. This document defines the first two feature capability indicator trees ("g." and "sip."). It does not define a tree for the empty leading facet. Holmberg, et al. Expires April 1, 2013 [Page 14] Internet-Draft proxy feature September 2012 7.3.2. Global Feature Capability Indicator Registration Tree This specification creates a new feature capability indicator tree in the IANA "Proxy-Feature Feature Capability Indicator Trees" registry. The name of the tree is "Global Feature Capability Indicator Registration Tree", and its leading facet is "g.". It is used for the registration of feature capability indicators. When a feature capability indicator is registered in the global tree, it needs to meet the "Specification Required" policies defined in RFC 5226. A designated area expert will review the proposed feature capability indicator, and consult with members of related mailing lists. The information required in the registration is defined in Section 5.3 of RFC XXXX. Note that all feature capability indicators registered in the global tree will have names with a leading facet "g.". No leading "+" is used in the registrations in any of the feature capability indicator registration trees. The format of the global tree is as described below: Name Description Reference ------------------------------ Name contains the Feature Capability Indicator Name, provided in the registration feature capability indication registration template. Description, 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. 7.3.3. SIP Feature Capability Indicator Registration Tree This specification creates a new feature capability indicator tree in the IANA "Proxy-Feature Feature Capability Indicator Trees" registry. The name of the tree is "SIP Feature Capability Indicator Registration Tree", and its leading facet is "sip.". It is used for the registration of feature capability indicators. When a feature capability indicator is registered in the sip tree, it needs to meet the "IETF Review" policies defined in RFC 5226. The Holmberg, et al. Expires April 1, 2013 [Page 15] Internet-Draft proxy feature September 2012 information required in the registration is defined in Section 5.3 of RFC XXXX. Note that all feature capability indicators registered in the SIP tree will have names with a leading facet "sip.". No leading "+" is used in the registrations in any of the feature capability indicator registration trees. The format of the SIP tree is as described below: Name Description Reference ------------------------------ Name contains the Feature Capability Indicator Name, provided in the registration feature capability indication registration template. Description, 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. 8. Feature Capability Indicator Registration Template Holmberg, et al. Expires April 1, 2013 [Page 16] Internet-Draft proxy feature September 2012 Registration requests for the global tree are submitted by e-mail to 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. Feature capability indicator name: Description: | The description should be no longer than 4 lines. More | detailed information can be provided in the feature | capability indicator specification. Feature capability indicator name: | 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 | listed in Section 5.3 of RFC XXXX. Contact: | Name(s) & email address(es) of person(s) to | contact for further information." (IANA: Please replace XXXX with the assigned RFC number) 9. Security Considerations The security issues for feature capability indicators are similar to the ones defined in RFC 3840 for media feature tags. Media feature tags can reveal information about end-users and end-user equipment, which can be used for industrial espionage. The knowledge about end- 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. Holmberg, et al. Expires April 1, 2013 [Page 17] Internet-Draft proxy feature September 2012 In addition, the RFC 3840 security issue regarding an attacker using the SIP caller preferences extension [RFC3841] in order to affect routing decisions does not apply, as the mechanism is not defined to be used with feature capability indicators. Feature capability indicators can, however, provide capability and characteristics information about the SIP entity, some of which might be sensitive. Malicious elements viewing the indicators may be able to discern application deployment details or identify elements with 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, if the feature capability indicators provide sensitive information, mechanisms for guaranteeing confidentiality and authenticity MUST be provided. 10. Acknowledgements The authors wish to thank everyone in the SIP community that provided input and feedback on the work of this specification. 11. Change Log [RFC EDITOR NOTE: Please remove this Section when publishing] 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 Holmberg, et al. Expires April 1, 2013 [Page 18] Internet-Draft proxy feature September 2012 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). Holmberg, et al. Expires April 1, 2013 [Page 19] Internet-Draft proxy feature September 2012 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. 12.2. Informative References [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag Registration Procedure", BCP 31, RFC 2506, March 1999. [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004. [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004. [RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004. Holmberg, et al. Expires April 1, 2013 [Page 20] Internet-Draft proxy feature September 2012 [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 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- Initiated Connections in the Session Initiation Protocol (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 Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Ivo Sedlacek Ericsson Scheelevaegen 19C Lund 22363 Sweden Email: ivo.sedlacek@ericsson.com Holmberg, et al. Expires April 1, 2013 [Page 21] Internet-Draft proxy feature September 2012 Hadriel Kaplan Acme Packet 71 Third Ave. Burlington, MA 01803 USA Email: hkaplan@acmepacket.com Holmberg, et al. Expires April 1, 2013 [Page 22]