SIPCORE Working Group
Internet Engineering Task Force (IETF)                       C. Holmberg
Internet-Draft
Request for Comments: 6809                                   I. Sedlacek
Intended status:
Category: Standards Track                                       Ericsson
Expires: April 22, 2013
ISSN: 2070-1721                                                H. Kaplan
                                                             Acme Packet
                                                        October 19,
                                                           November 2012

   Mechanism to indicate support Indicate Support of features Features and capabilities Capabilities in the
                   Session Initiation Protocol (SIP)
                draft-ietf-sipcore-proxy-feature-12.txt

Abstract

   This specification defines a new SIP header field, Feature-Caps.  The
   Feature-Caps header field conveys feature capability 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, feature-capability indicators and
   creates a new IANA registry, "Proxy-Feature Feature Capability Feature-Capability
   Indicator Trees", for registering feature capability feature-capability indicators.

Status of this 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 an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum 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 six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 22, 2013.
   http://www.rfc-editor.org/info/rfc6809.

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 . . . . . . . . . . . . . . . . . . . . . . . . .  4 ....................................................3
   2. Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  4 .....................................................4
   3. Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  4 .....................................................4
   4. Feature-Caps Header Field  . . . . . . . . . . . . . . . . . .  5 .......................................4
      4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . .  5 ...............................................4
      4.2. User Agent and Proxy Behavior  . . . . . . . . . . . . . .  5 ..............................4
           4.2.1. General  . . . . . . . . . . . . . . . . . . . . . . .  5 .............................................4
           4.2.2. B2BUA Behavior . . . . . . . . . . . . . . . . . . . .  6 ......................................5
           4.2.3. Registrar Behavior . . . . . . . . . . . . . . . . . .  6 ..................................6
           4.2.4. Proxy behavior . . . . . . . . . . . . . . . . . . . .  7 Behavior ......................................6
      4.3. SIP Message Type and Response Code Semantics . . . . . . .  7 ...............7
           4.3.1. General  . . . . . . . . . . . . . . . . . . . . . . .  7 .............................................7
           4.3.2. SIP Dialog . . . . . . . . . . . . . . . . . . . . . .  7 ..........................................7
           4.3.3. SIP Registration (REGISTER)  . . . . . . . . . . . . .  8 .........................7
           4.3.4. SIP Stand-Alone Standalone Transactions . . . . . . . . . . . . .  8 .........................8
   5.  Feature Capability Feature-Capability Indicators  . . . . . . . . . . . . . . . .  9 ...................................8
      5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . .  9 ...............................................8
      5.2. Registration Trees . . . . . . . . . . . . . . . . . . . .  9 .........................................9
           5.2.1. General  . . . . . . . . . . . . . . . . . . . . . . .  9 .............................................9
           5.2.2. Global Tree  . . . . . . . . . . . . . . . . . . . . .  9 .........................................9
           5.2.3. SIP Tree . . . . . . . . . . . . . . . . . . . . . . . 10 ............................................9
      5.3.  Feature Capability Feature-Capability Indicator Specification Requirements  . 10 ...10
           5.3.1. General  . . . . . . . . . . . . . . . . . . . . . . . 10 ............................................10
           5.3.2. Overall Description  . . . . . . . . . . . . . . . . . 10 ................................10
           5.3.3.  Feature Capability Feature-Capability Indicator Values  . . . . . . . . . 11 ................10
           5.3.4. Usage Restrictions . . . . . . . . . . . . . . . . . . 11 .................................11
           5.3.5. Interoperability Considerations  . . . . . . . . . . . 11 ....................11
           5.3.6. Security Considerations  . . . . . . . . . . . . . . . 12 ............................11
           5.3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . 12 ...........................................12
           5.3.8. Other Information  . . . . . . . . . . . . . . . . . . 12 ..................................12
   6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 .........................................................12
      6.1. General  . . . . . . . . . . . . . . . . . . . . . . . . . 12 ...................................................12
      6.2. Syntax: Feature-Caps header field  . . . . . . . . . . . . 12 Header Field .........................12
           6.2.1. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 12 ...............................................12
      6.3. Syntax: feature capability indicator . . . . . . . . . . . 13 Feature-Capability Indicator ......................12
           6.3.1. General  . . . . . . . . . . . . . . . . . . . . . . . 13 ............................................12
           6.3.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 13 ...............................................13
   7. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13 ............................................13
      7.1. Registration of the Feature-Caps header field  . . . . . . 13 Header Field .............13
      7.2. Registration of the Feature-Caps header field parameter  . 13 Header Field Parameter ...13
      7.3. Proxy-Feature Feature Capability Feature-Capability Indicator Trees . . . . . 14 ..........14
           7.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 14 .......................................14
           7.3.2. Global Feature Capability Feature-Capability Indicator
                  Registration Tree . . . . . . . . . . . . . . . . . . . . . . . . . 15 ..................................14
           7.3.3. SIP Feature Capability Feature-Capability Indicator
                  Registration Tree . . 15 ..................................15
   8.  Feature Capability Feature-Capability Indicator Registration Template . . . . . . 16 .............16
   9. Security Considerations  . . . . . . . . . . . . . . . . . . . 17 ........................................17
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 ..............................................17
   11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 18
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     12.1. ....................................................18
      11.1. Normative References . . . . . . . . . . . . . . . . . . . 20
     12.2. .....................................18
      11.2. Informative References . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 ...................................18

1.  Introduction

   The Session Initiation Protocol (SIP) [RFC3261] "Caller Preferences"
   extension, 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 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 feature-capability indicators are intended
   to only be used with the SIP protocol. SIP.

   This specification also defines feature capability indicators, feature-capability indicators and
   creates a new IANA registry, "Proxy-Feature Feature Capability Feature-Capability
   Indicator Trees", for registering feature capability 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 feature-capability
   indicators.  A feature capability feature-capability indicator conveyed in a Feature-
   Caps
   Feature-Caps header field indicates that a SIP entity in the SIP
   message
   signalling 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 feature-capability
   indicators in the header field inform the entity about the features
   and capabilities supported by entities in the SIP message signalling signaling
   path.  The procedure by which features and capabilities are invoked
   are outside the scope of this specification, specification and MUST be described by
   individual feature capability 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 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 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
   Feature-Caps header field from a SIP message.  Also, a SIP entity MAY
   remove a feature capability feature-capability indicator from a Feature-Caps header
   field within a SIP message.  A SIP entity SHOULD NOT re-order the Feature-
   Caps
   Feature-Caps header fields within a SIP message.

   For a given fc-value, as defined in section Section 6.2.1, the order in which
   feature capability
   feature-capability indicators are listed has no significance.  For
   example, "foo;bar" and "bar;foo" have the same meaning (i.e. (i.e., that
   the SIP entity that inserted the feature capability feature-capability indicator
   supports the features and capabilities associated with the "foo" and
   "bar"
   feature capability indicators. feature-capability indicators).

4.2.2.  B2BUA Behavior

   The procedures in this Section 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 in the request,
   containing one or more feature capability 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 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 to in the response,
   containing one or more feature capability 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
   fields by copying them to the outgoing SIP response, similar to a SIP
   proxy, before it inserts its own Feature-Caps header field to 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
   Feature-Caps header field, containing one or more feature capability feature-capability
   indicators associated with the supported features and capabilities,
   to
   in a REGISTER response.

4.2.4.  Proxy behavior 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 in the request,
   containing one or more SIP feature capability 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 in the response,
   containing one or more SIP feature capability 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 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 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 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 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 dialog, a SIP entity MUST insert the same feature 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,
   request and within the 200 (OK) response associated with such a
   request.

   If a feature capability 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 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 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 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 to in such
   messages.

   If SIP Outbound 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 Standalone Transactions

   The Feature-Caps header field can be used within a standalone SIP
   request,
   request and within any 2xx response associated with such a request.

   If a feature capability 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 feature-capability indicator is
   supported for the duration of the standalone transaction.

5.  Feature Capability  Feature-Capability Indicators

5.1.  Introduction

   Feature capability

   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 such support.

   A value, or a list of values, that provides additional information
   about the supported feature or capability, capability can be associated with a
   feature capability
   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").
   "tree.feature-name").  The registration trees are defined in the IANA "Proxy-
   Feature Feature Capability
   "Proxy-Feature Feature-Capability Indicator Trees" registry.

   The trees defined herein are similar to the global tree and sip SIP tree
   defined for media feature tags, in RFC RFCs 2506 [RFC2506] and RFC 3840. 3840
   [RFC3840].  Other registration trees are outside the scope of this
   specification.

   In contrast to RFC RFCs 2506 and RFC 3840, this specification only defines a
   global tree and a sip 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 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 feature-capability indicator tree is similar to the media
   feature tag global tree defined in RFC 2506 [RFC2506].

   A feature capability 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, 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 SIP feature-capability indicator tree is similar to the media
   feature tag sip SIP tree defined in RFC 3840.

   A feature capability feature-capability indicator in the sip SIP tree will be distinguished
   by the leading facet "sip.".

5.3.  Feature Capability  Feature-Capability Indicator Specification Requirements

5.3.1.  General

   A feature capability feature-capability indicator specification MUST address the issues
   defined in the following subsections, subsections or document why an issue is not
   applicable for the specific feature capability feature-capability indicator.  A
   reference to the specification MUST be provided when the feature feature-
   capability indicator is registered with IANA (see Section 8).

   It is bad practice for feature capability feature-capability indicator specifications to
   repeat procedures (e.g. (e.g., general procedures on the usage of the
   Feature-Caps header field and feature capability feature-capability indicators) defined
   in this specification, unless needed for clarification or emphasis
   purpose.
   purposes.  A feature capability feature-capability indicator specification MUST NOT
   modify the Feature-Caps header field rules and semantics defined in
   Section 4.

   A feature capability 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 feature-capability indicator
   require it.

5.3.2.  Overall Description

   The feature capability feature-capability indicator specification MUST contain an
   overall description of the feature capability feature-capability indicator: how it is
   used to indicate support of a feature, a description of the feature
   associated with the feature capability feature-capability indicator, a description of
   any additional information (conveyed using one or more feature feature-
   capability indicator values) that can be conveyed together with the
   feature capability
   feature-capability indicator, and a description of how the associated
   feature MAY be exercised/invoked.

5.3.3.  Feature Capability  Feature-Capability Indicator Values

   A feature capability feature-capability indicator can have an associated value, or a
   list of values.  The feature capability feature-capability indicator specification MUST
   define the syntax and semantics of any value defined for the feature feature-
   capability indicator, including possible restrictions related to the
   usage of a specific value.  The feature capability feature-capability indicator
   specification MUST define the value(s) in accordance with the ABNF
   defined in Section 6.3.2.  The feature capability feature-capability indicator
   specification MUST define whether the feature capability feature-capability indicator
   has a default value.

   If no values are defined for the feature capability feature-capability indicator, it
   MUST be indicated in the feature capability feature-capability indicator specification.

   A feature capability feature-capability indicator value is only applicable for the
   feature capability
   feature-capability indicator for which it has been defined.  For
   other feature capability 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 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 feature-
   capability indicator, the feature capability 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 feature-capability indicator in registration related
      registration-related messages, standalone transaction messages, dialog related or
      dialog-related messages,
   whether entities

   o  are allowed to insert a feature capability feature-capability indicator in requests
      or responses, whether entities

   o  also need to support other features and capabilities in order to
      insert a feature capability feature-capability indicator, and whether entities

   o  are allowed to indicate support of a feature in conjunction with
      another feature.

5.3.5.  Interoperability Considerations

   The feature capability feature-capability indicator specification MUST document any
   specific interoperability considerations that apply to the feature feature-
   capability indicator.

   Interoperability considerations can e.g. can, e.g., include procedures related
   to cases where an expected feature capability feature-capability indicator is not
   present,
   present or where it contains an unexpected value.

5.3.6.  Security Considerations

   The feature capability feature-capability indicator specification MUST document any
   specific security considerations that apply to the feature capability feature-capability
   indicator.

5.3.7.  Examples

   It is recommended that the feature capability 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, informative and do
   not replace normative text.

5.3.8.  Other Information

   If there is additional information about the feature capability feature-capability
   indicator, it is recommended to describe such information.  It can
   include e.g.
   include, for example, names of related feature capability feature-capability indicators.

6.  Syntax

6.1.  General

   This Section section defines the ABNF for the Feature-Caps header field, field and
   for the feature capability feature-capability indicators.  The ABNF defined in this
   specification is conformant to RFC 5234 [RFC5234]." [RFC5234].

6.2.  Syntax: Feature-Caps header field 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
   RFCs 3840 [RFC3840] and RFC 3841 [RFC3841].

6.3.  Syntax: feature capability indicator Feature-Capability Indicator

6.3.1.  General

   In a feature capability feature-capability indicator name (ABNF: fcap-name), dots can be
   used to implement a feature capability feature-capability indicator tree hierarchy (e.g.
   (e.g., tree.feature.subfeature).  The description of usage of such a
   tree hierarchy must be described when registered.

6.3.2.  ABNF

   The ABNF for the feature capability indicator: 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 feature-capability indicator name is mandatory.

7.  IANA Considerations

7.1.  Registration of the Feature-Caps header field Header Field

   This specification registers a new SIP header field, Feature-Caps,
   according to the process of defined in RFC 3261 [RFC3261].

   The following is the registration for the Feature-Caps header field: in the "Header
   Fields" registry:

   RFC Number: RFC XXXX 6809

   Header Field Name: Feature-Caps

7.2.  Registration of the Feature-Caps header field parameter 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 described in RFC 3968 [RFC3968].

                                       Predefined
   Header Field      Parameter Name    Values        Reference
   ------------------------------------------------------------------
   --------------------------------------------------------------------

   Feature-Caps      +<fcap-name> *    No          [RFC XXXX]            [RFC6809]

          * <fcap-name> denotes parameter names conforming to the
            syntax <fcap-name> defined in RFC XXXX. 6809.  Valid
            feature capability
            feature-capability indicators are registered in [IANA:
            insert reference to the new
            Proxy-Feature Feature
            Capability 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.) registry.

7.3.  Proxy-Feature Feature Capability Feature-Capability Indicator Trees

7.3.1.  Introduction

   This specification creates a new sub registry sub-registry to the IANA "Session
   Initiation Protocol (SIP) Parameters" Protocol Registry, registry, according to the
   process of defined in RFC 5226.  The name of the sub registry sub-registry is "Proxy-
   Feature Feature Capability
   "Proxy-Feature Feature-Capability Indicator Trees".

   Feature capability

   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  Feature-
   capability indicator names that contain no "." characters are
   considered to have an empty ("") leading facet.

   The "Proxy-Feature Feature Capability Feature-Capability Indicator Trees" registry
   contains sub registries sub-registries for subsets (called 'trees') of feature feature-
   capability indicators sharing the same leading facet.  Each feature feature-
   capability indicator is registered within the tree that matches its
   leading facet.  If no tree matches its leading facet facet, then the feature
   capability
   feature-capability indicator can not cannot be registered.

   New feature capability feature-capability indicator sub registries 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
   feature-capability indicators within this tree need to be provided.

   This document defines the first two feature capability feature-capability indicator
   trees ("g." and "sip.").  It does not define a tree for the empty
   leading facet.

7.3.2.  Global Feature Capability Feature-Capability Indicator Registration Tree

   This specification creates a new feature capability feature-capability indicator tree in
   the IANA "Proxy-Feature Feature Capability Feature-Capability Indicator Trees" registry.
   The name of the tree is "Global Feature Capability Feature-Capability Indicator
   Registration Tree", and its leading facet is "g.".  It is used for
   the registration of feature capability feature-capability indicators.

   When a feature capability 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 feature-
   capability indicator, indicator and consult with members of related mailing
   lists.  The information required in the registration is defined in
   Section 5.3 of RFC XXXX. this document.

   Note that all feature capability 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 feature-capability indicator
   registration trees.

   The format of the global tree is as described below:

   Name   Description   Reference
   ------------------------------

   Name - contains the Feature Capability Feature-Capability Indicator Name, provided in
   the registration feature capability feature-capability indication registration template.

   Description,

   Description - provided in the registration feature capability feature-capability
   indication registration template.

   Reference - contains the Feature Capability Feature-Capability Indicator Specification
   Reference, specification
   reference provided in the registration feature capability feature-capability indication
   registration template.

   No initial values are registered in the global tree.

7.3.3.  SIP Feature Capability Feature-Capability Indicator Registration Tree

   This specification creates a new feature capability feature-capability indicator tree in
   the IANA "Proxy-Feature Feature Capability Feature-Capability Indicator Trees" registry.
   The name of the tree is "SIP Feature Capability Feature-Capability Indicator
   Registration Tree", and its leading facet is "sip.".  It is used for
   the registration of feature capability feature-capability indicators.

   When a feature capability feature-capability indicator is registered in the sip 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
   RFC XXXX.
   this document.

   Note that all feature capability 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 feature-capability indicator
   registration trees.

   The format of the SIP tree is as described below:

   Name   Description   Reference
   ------------------------------

   Name - contains the Feature Capability Feature-Capability Indicator Name, provided in
   the registration feature capability feature-capability indication registration template.

   Description,

   Description - provided in the registration feature capability feature-capability
   indication registration template.

   Reference - contains the Feature Capability Feature-Capability Indicator Specification
   Reference, specification
   reference provided in the registration feature capability feature-capability indication
   registration template.

   No initial values are registered in the SIP tree.

8.  Feature Capability  Feature-Capability Indicator Registration Template

   Registration requests for the global tree are submitted by e-mail email to
   iana@iana.org.

   Registration requests for the sip SIP tree requires submitting an
   Internet-Draft to the IESG.

   | Instructions are preceded by '|'.  All fields are mandatory.

   Feature capability

   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

   Feature-capability indicator specification reference:

   | The referenced specification must contain the information
   | listed in Section 5.3 of RFC XXXX. 6809.

   Contact:

   | Name(s) & email address(es) of person(s) to
   | contact for further information."

   (IANA: Please replace XXXX with the assigned RFC number) information.

9.  Security Considerations

   The security issues for feature capability 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 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 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 feature-capability
   indicators.

   In addition, the RFC 3840 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 feature-capability indicators.

   Feature capability

   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 feature-capability indicators might provide
   address information as feature capability feature-capability indicator values.
   Therefore, if the feature capability feature-capability indicators provide information
   that requires data integrity or origin authentication, mechanisms for
   providing those MUST be provided.  If confidentiality is required 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 middle-to-end or middle-to-middle SIP confidentiality
   mechanisms, TLS is as good as it gets gets, and specifications SHOULD NOT
   define feature
   capability 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.

11.  Change Log

   [RFC EDITOR NOTE: Please remove this Section when publishing]

   Changes from draft-holmberg-sipcore-proxy-feature-11
   o  IANA: Indicating that no initial values are registered in the
      trees.
   o  IESG: Editorial changes based on comments from Barry Leiba.
   o  IESG: Reference to RFC 5234 added based on comments from Adrian
      Farrel.
   o  IESG: Editorial changes and Security Consideration modification
      based on comments from Stephen Farrell.
   o  IESG: Editorial changes based on comments from Pete Resnick.

   Changes from draft-holmberg-sipcore-proxy-feature-10
   o  Editorial changes.

   o  'IETF Consensus' changed to 'IETF Review' (section 7.3.3)

   Changes from draft-holmberg-sipcore-proxy-feature-09
   o  Editorial changes based on SECDIR comments from Radia Perlman.
   o  Editorial changes based on Gen-Art comments from Brian E
      Carpenter.
   o  Editorial changes based on OPSDIR comments from Jouni Korhonen.
   o  Change in security considerations indicating that, if sensitive
      information is conveyed, mechanisms for guaranteeing
      confidentiality and authenticity must be provided.

   Changes from draft-holmberg-sipcore-proxy-feature-08
   o  Comments from Atle Mondrad.

   Changes from draft-holmberg-sipcore-proxy-feature-06
   o  Editorial changes.

   Changes from draft-holmberg-sipcore-proxy-feature-05
   o  AD comments from Robert Sparks
   o  Additional text added to the Security Considerations section.
   o  IANA registration template modified.
   o  IANA registration procedures clarified.
   o  Feature Capability Indicator specification requirements modified.
   o  Note regarding SUBSCRIBE 200 responses added.
   o  Editorial modifications.

   Changes from draft-holmberg-sipcore-proxy-feature-04
   o  WGLC comments from Keith Drage
   o  'feature cap' name changed to 'feature capability indicator'.
   o  Feature-Caps header field added to IANA Header Field Parameters
      and Parameter Values registry.
   o  Editorial modifications.

   Changes from draft-ietf-sipcore-proxy-feature-03
   o  Additional Security Considerations text added.
   o  IANA Considerations modified.
   o  Editorial corrections.

   Changes from draft-ietf-sipcore-proxy-feature-02
   o  Changes based on WGLC comments from Shida Schubert.
   o  - Document title changed
   o  - Terminology alignment
   o  - Note text clarifications
   o  Changes based on WGLC comments from Lili Yang.

   Changes from draft-ietf-sipcore-proxy-feature-01
   o  Changes based on comments from Paul Kyzivat.
   o  IANA Considerations text added.

   Changes from draft-holmberg-sipcore-proxy-feature-04/
   draft-ietf-sipcore-proxy-feature-00
   o  Media feature tags replaced with feature caps, based on SIPCORE
      consensus at IETF#83 (Paris).
   o  Editorial corrections and modifications.

   Changes from draft-holmberg-sipcore-proxy-feature-03
   o  Hadriel Kaplan added as co-author.
   o  Terminology change: instead of talking of proxies, talk about
      entities which are not represented by the URI in a Contact header
      field (http://www.ietf.org/mail-archive/web/sipcore/current/
      msg04449.html).
   o  Clarification regarding the usage of the header field in 18x/2xx
      responses (http://www.ietf.org/mail-archive/web/sipcore/current/
      msg04449.html).
   o  Specifying that feature support can also be indicated in target
      refresh requests (http://www.ietf.org/mail-archive/web/sipcore/
      current/msg04454.html).
   o  Feature Cap specification registration information added.

   Changes from draft-holmberg-sipcore-proxy-feature-02
   o  Definition, and usage of, a new header field, instead of Path,
      Record-Route, Route and Service-Route.

   Changes from draft-holmberg-sipcore-proxy-feature-01
   o  Requirement section added
   o  Use-cases and examples updated based on work in 3GPP

   Changes from draft-holmberg-sipcore-proxy-feature-00
   o  Additional use-cases added
   o  Direction section added

12.  References

12.1.

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.

12.2.

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.

   [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:

   EMail: christer.holmberg@ericsson.com

   Ivo Sedlacek
   Ericsson
   Scheelevaegen 19C
   Lund  22363
   Sweden

   Email:

   EMail: ivo.sedlacek@ericsson.com

   Hadriel Kaplan
   Acme Packet
   71 Third Ave.
   Burlington, MA  01803
   USA

   Email:

   EMail: hkaplan@acmepacket.com