diff options
Diffstat (limited to 'doc/rfc/rfc6809.txt')
| -rw-r--r-- | doc/rfc/rfc6809.txt | 1067 |
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc6809.txt b/doc/rfc/rfc6809.txt new file mode 100644 index 0000000..ce62cfe --- /dev/null +++ b/doc/rfc/rfc6809.txt @@ -0,0 +1,1067 @@ + + + + + + +Internet Engineering Task Force (IETF) C. Holmberg +Request for Comments: 6809 I. Sedlacek +Category: Standards Track Ericsson +ISSN: 2070-1721 H. Kaplan + Acme Packet + November 2012 + + + Mechanism to Indicate Support of Features and Capabilities in + the Session Initiation Protocol (SIP) + +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 is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6809. + + + + + + + + + + + +Holmberg, et al. Standards Track [Page 1] + +RFC 6809 Proxy Feature November 2012 + + +Copyright Notice + + Copyright (c) 2012 IETF Trust and the persons identified as the + 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 ....................................................3 + 2. Conventions .....................................................4 + 3. Definitions .....................................................4 + 4. Feature-Caps Header Field .......................................4 + 4.1. Introduction ...............................................4 + 4.2. User Agent and Proxy Behavior ..............................4 + 4.2.1. General .............................................4 + 4.2.2. B2BUA Behavior ......................................5 + 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) .........................7 + 4.3.4. SIP Standalone Transactions .........................8 + 5. Feature-Capability Indicators ...................................8 + 5.1. Introduction ...............................................8 + 5.2. Registration Trees .........................................9 + 5.2.1. General .............................................9 + 5.2.2. Global Tree .........................................9 + 5.2.3. SIP Tree ............................................9 + 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 ............................11 + 5.3.7. Examples ...........................................12 + 5.3.8. Other Information ..................................12 + + + + +Holmberg, et al. Standards Track [Page 2] + +RFC 6809 Proxy Feature November 2012 + + + 6. Syntax .........................................................12 + 6.1. General ...................................................12 + 6.2. Syntax: Feature-Caps Header Field .........................12 + 6.2.1. ABNF ...............................................12 + 6.3. Syntax: Feature-Capability Indicator ......................12 + 6.3.1. General ............................................12 + 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 ..................................14 + 7.3.3. SIP Feature-Capability Indicator + Registration Tree ..................................15 + 8. Feature-Capability Indicator Registration Template .............16 + 9. Security Considerations ........................................17 + 10. Acknowledgements ..............................................17 + 11. References ....................................................18 + 11.1. Normative References .....................................18 + 11.2. Informative References ...................................18 + +1. Introduction + + The Session Initiation Protocol (SIP) [RFC3261] extension for + indicating User Agent (UA) capabilities, 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. + + + +Holmberg, et al. Standards Track [Page 3] + +RFC 6809 Proxy Feature November 2012 + + + Unlike media feature tags, feature-capability indicators are intended + to only be used with SIP. + + 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. + +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 signaling 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 signaling + + + + + +Holmberg, et al. Standards Track [Page 4] + +RFC 6809 Proxy Feature November 2012 + + + 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", from a SIP + signaling point of view, to the entity. + + Based on features and policies, a SIP entity MAY remove a + Feature-Caps header field from a SIP message. Also, a SIP entity MAY + remove a feature-capability indicator from a Feature-Caps header + field within a SIP message. A SIP entity SHOULD NOT re-order the + Feature-Caps header fields within a SIP message. + + 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" 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 in the request, + containing one or more feature-capability indicators associated with + the supported features and capabilities, before it forwards the + request. + + + + +Holmberg, et al. Standards Track [Page 5] + +RFC 6809 Proxy Feature November 2012 + + + 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 in 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 in 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 + fields by copying them to the outgoing SIP response, similar to a SIP + proxy, before it inserts its own Feature-Caps header field in 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, + in 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 in the request, + 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 in the response, + containing one or more SIP feature-capability indicators associated + with the supported features and capabilities, before it forwards the + response. + + + + + + + + + +Holmberg, et al. Standards Track [Page 6] + +RFC 6809 Proxy Feature November 2012 + + +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 a 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 until 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 a 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. + +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 a + 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 + + + +Holmberg, et al. Standards Track [Page 7] + +RFC 6809 Proxy Feature November 2012 + + + 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 are + 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 in 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 Standalone Transactions + + The Feature-Caps header field can be used within a standalone SIP + request and within any 2xx response associated with such a request. + + If a feature-capability indicator is inserted in a Feature-Caps + header field of a standalone request, or within a response of such a + 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. + +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 such 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. + + + +Holmberg, et al. Standards Track [Page 8] + +RFC 6809 Proxy Feature November 2012 + + +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 RFCs 2506 [RFC2506] and 3840 + [RFC3840]. Other registration trees are outside the scope of this + specification. + + In contrast to RFCs 2506 and 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"). + +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.". + + + + + + + + + + + +Holmberg, et al. Standards Track [Page 9] + +RFC 6809 Proxy Feature November 2012 + + +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 + purposes. 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 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 + 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. + + + + +Holmberg, et al. Standards Track [Page 10] + +RFC 6809 Proxy Feature November 2012 + + + 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 or not entities + + o are allowed to insert a feature-capability indicator in + registration-related messages, standalone transaction messages, or + dialog-related messages, + + o are allowed to insert a feature-capability indicator in requests + or responses, + + o also need to support other features and capabilities in order to + insert a feature-capability indicator, and + + o are allowed to indicate support of a feature in conjunction with + another feature. + +5.3.5. Interoperability Considerations + + The feature-capability indicator specification MUST document any + specific interoperability considerations that apply to the feature- + capability indicator. + + Interoperability considerations can, e.g., include procedures related + to cases where an expected feature-capability indicator is not + present or where it contains an unexpected value. + +5.3.6. Security Considerations + + The feature-capability indicator specification MUST document any + specific security considerations that apply to the feature-capability + indicator. + + + +Holmberg, et al. Standards Track [Page 11] + +RFC 6809 Proxy Feature November 2012 + + +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, for example, 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. The ABNF defined in this + specification is conformant to RFC 5234 [RFC5234]. + +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 + RFCs 3840 [RFC3840] and 3841 [RFC3841]. + +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 a + tree hierarchy must be described when registered. + + + + + + +Holmberg, et al. Standards Track [Page 12] + +RFC 6809 Proxy Feature November 2012 + + +6.3.2. ABNF + + The ABNF for the feature-capability indicator is: + + 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 defined in RFC 3261 [RFC3261]. + + The following is the registration for Feature-Caps in the "Header + Fields" registry: + + RFC Number: RFC 6809 + + 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 described in RFC 3968 [RFC3968]. + + Predefined + Header Field Parameter Name Values Reference + -------------------------------------------------------------------- + + Feature-Caps +<fcap-name> * No [RFC6809] + + * <fcap-name> denotes parameter names conforming to the + syntax <fcap-name> defined in RFC 6809. Valid + feature-capability indicators are registered in the + Proxy-Feature Feature-Capability Indicator Trees registry. + + + + + + + +Holmberg, et al. Standards Track [Page 13] + +RFC 6809 Proxy Feature November 2012 + + +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" registry, according to the + process defined in 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 cannot be registered. + + New feature-capability indicator sub-registries (trees) can be + registered. The registration must meet the "Standards Action" + policies defined in RFC 5226 [RFC5226]. 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. + +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 this document. + + + + + +Holmberg, et al. Standards Track [Page 14] + +RFC 6809 Proxy Feature November 2012 + + + 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. + + No initial values are registered in the global tree. + +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 + information required in the registration is defined in Section 5.3 of + this document. + + 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. + + + + + + + + + + + + +Holmberg, et al. Standards Track [Page 15] + +RFC 6809 Proxy Feature November 2012 + + + 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. + + No initial values are registered in the SIP tree. + +8. Feature-Capability Indicator Registration Template + + Registration requests for the global tree are submitted by email 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 specification reference: + + | The referenced specification must contain the information + | listed in Section 5.3 of RFC 6809. + + Contact: + + | Name(s) & email address(es) of person(s) to + | contact for further information. + + + + + + + +Holmberg, et al. Standards Track [Page 16] + +RFC 6809 Proxy Feature November 2012 + + +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. + + In addition, the security issue discussed in RFC 3840 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 information + that requires data integrity or origin authentication, mechanisms for + providing those MUST be provided. If confidentiality is required, + then the specification MUST call for the use of Transport Layer + Security (TLS) [RFC5246] at all hops. Since there are no + satisfactory middle-to-end or middle-to-middle SIP confidentiality + mechanisms, TLS is as good as it gets, and specifications SHOULD NOT + define feature-capability indicators that need confidentiality that + is better than the hop-by-hop confidentiality provided by TLS. + +10. Acknowledgements + + The authors wish to thank everyone in the SIP community that provided + input and feedback on the work of this specification. + + + + + + + + + + + + +Holmberg, et al. Standards Track [Page 17] + +RFC 6809 Proxy Feature November 2012 + + +11. References + +11.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. + + [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, January 2008. + +11.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. + + [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. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008. + + [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- + Initiated Connections in the Session Initiation Protocol + (SIP)", RFC 5626, October 2009. + + + + +Holmberg, et al. Standards Track [Page 18] + +RFC 6809 Proxy Feature November 2012 + + +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 + + + Hadriel Kaplan + Acme Packet + 71 Third Ave. + Burlington, MA 01803 + USA + + EMail: hkaplan@acmepacket.com + + + + + + + + + + + + + + + + + + + + + + + + +Holmberg, et al. Standards Track [Page 19] + |