SIPCORE Working Group                                        C. Holmberg
Internet-Draft                                               I. Sedlacek
Intended status: Standards Track                                Ericsson
Expires: December 16, 2012 February 9, 2013                                      H. Kaplan
                                                             Acme Packet
                                                           June 14,
                                                          August 8, 2012

   Mechanism to indicate support of features and capabilities in the
                   Session Initiation Protocol (SIP)
                draft-ietf-sipcore-proxy-feature-04.txt
                draft-ietf-sipcore-proxy-feature-05.txt

Abstract

   This specification creates defines a new IANA registry, "Proxy-Feature
   Feature Caps Trees", for registering "feature caps", SIP header field, Feature-Caps, to
   convey feature capability indicators, which 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.

   This specification also defines feature capability indicators, and
   creates a new SIP header field, Feature-Caps,
   to convey IANA registry, "Proxy-Feature Feature Capability
   Indicator Trees", for registering feature caps in SIP messages. 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 December 16, 2012. February 9, 2013.

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

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 creates defines a new IANA registry, "Proxy-Feature
   Feature Caps Trees", for registering "feature caps", SIP header field, Feature-Caps, to
   convey feature capability indicators, which 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.  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 B2BUA, where the Contact header field
      URI represents another SIP entity.

   This specification also defines a new SIP header field, Feature-Caps,
   to convey feature caps in SIP messages.

   NOTE: Unlike media feature tags, feature caps 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.

4.  Feature Caps  Feature-Caps Header Field
4.1.  Introduction

   Feature caps are

   The Feature-Caps header field is used by SIP entities not represented by the URI of
   the Contact header field to indicate convey
   support of features and capabilities, where media by setting feature tags cannot be used to indicate the
   support. capability
   indicators.  A value, or a list of values, that provides additional information
   about the supported feature or capability, can be associated with a
   feature cap.

   Section 5 defines how feature caps are capability indicator conveyed using the in a Feature-
   Caps header field.

   The feature cap ABNF is defined in Section 6.2.2.

4.2.  Registration Trees

4.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 field indicates that a SIP entity in the IANA "Proxy-
   Feature Feature Caps Trees" registry.

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

   NOTE: In contrast to RFC 2506 and RFC 3840, this specification only
   defines a global tree and capability.

   For a sip tree, given fc-value, as they are the only trees defined in those RFCs that have been used for defining SIP-specific
   media feature tags.

   When a section 5.3.1, feature cap is registered capability
   indicators are listed in a non-priority order, and any registration tree, no leading
   "+" is used in order of the registration.

4.2.2.  Global Tree

   The global
   listed SIP feature cap tree is similar to capability indicators have the media feature tag
   global tree defined in RFC 2506 [RFC2506].

   A feature cap for same meaning.  For
   example, "foo;bar" and "bar;foo" have the global tree will be registered by same meaning (i.e. that the IANA
   after review by a designated expert.  That review will serve to
   ensure
   SIP entity that inserted the feature cap meets capability indicator supports
   the technical requirements of this
   specification.

   A feature cap in features and capabilities associated with the global tree will be distinguished by "foo" and "bar"
   feature capability indicators.

4.2.  User Agent and Proxy Behavior

4.2.1.  General

   If the leading
   facet "g.".  An organization can propose either URI in a designation
   indicative Contact header field of the feature, (e.g., "g.blinktags") a request or response
   represents a faceted
   designation including SIP entity, the organization name (e.g.,
   "g.organization.blinktags"). 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 cap is registered capability
   indicators in the global tree, it needs to meet header field inform the "Expert Review" policies defined entity about the features
   and capabilities supported by entities in RFC 5226 [RFC5226].  A
   designated area expert will review the proposed feature cap, SIP message signalling
   path.  Procedures how features and
   consult with members capabilities are invoked are
   outside the scope of related mailing lists.

4.2.3.  SIP Tree

   The sip this specification, and MUST be described by
   individual feature cap tree capability indicator specifications.

   NOTE: It is similar to not possible to, as a Feature-Caps header field value,
   convey the media feature tag sip tree
   defined in RFC 3840 [RFC3840].

   A feature cap in address of the sip tree will be distinguished by SIP entity that inserted the leading
   facet "sip.".

   When Feature-Caps
   header field.  If additional data about a supported feature cap is registered in the sip tree, it needs to meet
   be conveyed, such as the "IETF Consensus" policies defined in RFC 5226 [RFC5226].  An RFC,
   which contains address of the registration SIP entity that indicated
   support of the feature, then the feature cap, MUST be
   published.

4.3.  Registration Template

   To: sip-feature-caps@apps.ietf.org (feature caps mailing list)
   Subject: Registration definition needs to define a
   way to convey that information as a value of the associated feature cap XXXX

   | Instructions are preceded by '|'.  Some fields are optional.

   Feature cap name:

   Summary of feature indicated by this feature cap:

   | The summary should be no longer than 4 lines. More
   | detailed information can be provided in the SIP feature
   | cap specification.

   Feature cap specification reference:

   | The referenced specification MUST contain the information
   | listed in section XX of XXXX (IANA: Replace XXXX with
   | assigned RFC number of this specification.

   Values appropriate for use with this feature cap:

   | If no values are defined for the feature cap,
   | indicate "N/A". Details about feature cap values
   | MUST be defined in the feature cap specification.

   The feature cap is intended primarily for
   use in the following applications, protocols,
   services, or negotiation mechanisms:                    [optional]

   | For applications, also specify the number of the
   | first version which will use the feature cap,
   | if applicable.

   Examples of typical use:                                [optional]

   Considerations particular to use in individual
   applications, protocols, services, or negotiation
   mechanisms:                                             [optional]

   Interoperability considerations:                        [optional]

   Security considerations:

   Privacy concerns, related to exposure of personal
   information:

   Denial of service concerns related to consequences
   of specifying incorrect values:

   Other:

       Additional information:                         [optional]

       Keywords:                                       [optional]

       Related feature caps:                       [optional]

       Name(s) & email address(es) of person(s) to
       contact for further information:

       Intended usage:

       | one of COMMON, LIMITED USE or OBSOLETE

       Author/Change controller:

       Other information:                               [optional]

       | Any other information that the author deems
       | interesting may be added here.

                      Figure 1: Registration Template

4.4.  Feature Cap Specification Requirements

4.4.1.  General

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

   It is bad practice for feature cap specifications to repeat
   procedures (e.g. general procedures on the usage of the Feature-Caps
   header field and feature caps) defined in this specification, unless
   needed for clarification or emphasis purpose.

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

4.4.2.  Overall Description

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

4.4.3.  Feature Cap Values

   A feature cap can have an associated value, or a list of values.

   The feature cap specification MUST define the syntax and semantics of
   any value defined for the feature cap, including possible
   restrictions related to the usage of a specific value.  The feature
   cap specification MUST define the value(s) in accordance with the
   syntax defined in section 6.2.2.

   A feature cap value is only applicable for the feature cap for which
   it has been defined.  For other feature caps, 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 cap, unless the semantics of the
   values are the same.

4.4.4.  Usage Restrictions

   If there are restrictions on how SIP entities can insert a SIP
   feature cap, the feature cap specification MUST document such
   restrictions.

   There might be restrictions related to whether entities are allowed
   to insert a feature cap in registration related messages, standalone
   transaction messages, or dialog related messages, whether entities
   are allowed to insert a feature cap in requests or responses, whether
   entities also need to support other features and capabilities in
   order to insert
   capability indicator.

   When a feature cap, and whether entities are allowed to
   indicate support of SIP entity adds a feature in conjunction with another feature.

4.4.5.  Examples

   It is RECOMMENDED that the feature cap 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.  Feature-Caps Header Field

5.1.  Introduction

   The Feature-Caps header field is used by SIP entities to convey
   support of features and capabilities, by setting feature caps.
   Feature caps conveyed in a SIP message,
   it MUST place the header field before any existing Feature-Caps
   header field indicate that in the SIP entity message to be forwarded, so that inserted the added header
   field supports becomes the associated
   features and capabilities.

   NOTE: It is not possible to, as top-most one.  Then, when another SIP entity
   receives a Feature-Caps header field value,
   convey SIP request or the address of response, the SIP entity that inserted feature capability
   indicators in the top-most Feature-Caps header field.  If additional data about a field will represent
   the supported feature needs features and capabilities "closest" to
   be conveyed, such as the address of the SIP entity entity.

4.2.2.  B2BUA Behavior

   The procedures in this Section applies to UAs that indicated
   support are part of the feature, then the feature definition needs to define a
   way to convey B2BUAs
   that information as are referenced in the message by a value Record-Route header field
   rather than by the URI of the associated feature
   cap.

   The feature cap specification MUST specify for which Contact header field.

   When a UA sends a SIP methods and
   message types, 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 semantics, with the feature cap is
   applicable.  See Section 4 for more information.  No semantics supported
   features and capabilities, before it forwards the request.

   If the SIP request is
   defined for feature caps present in triggered by another SIP methods and message types not
   covered request that the B2BUA
   has received, the UA MAY forward received Feature-Caps header fields
   by copying them to the associated feature cap specification.

   Within outgoing SIP request, similar to a given SIP proxy,
   before it inserts its own Feature-Caps header field, feature caps are listed in field to the SIP
   request.

   When a non-priority order, UA receives a SIP response, if the UA wants to indicate
   support of features and for capabilities towards its upstream SIP
   entities, it inserts a given Feature-Caps header field any order of
   listed SIP to the response,
   containing one or more feature caps have capability indicators associated with
   the same meaning.  For example,
   "foo;bar" supported features and "bar;foo" have capabilities, before it forwards the same meaning (i.e. that
   response.

   If the SIP
   entity response is triggered by another SIP response that inserted the feature caps supports the features and
   capabilities associated with
   B2BUA has received, the "foo" and "bar" feature caps.

5.2.  User Agent and Proxy Behavior

5.2.1.  General

   If UA MAY forward received Feature-Caps header
   field by copying them to the URI in outgoing SIP response, similar to a Contact 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 request Feature-
   Caps header field, containing one or response
   represents a SIP entity, more feature capability
   indicators associated with the entity MUST NOT indicate supported features and capabilities using capabilities,
   to a Feature-Caps header field within
   that request or REGISTER response.

4.2.4.  Proxy behavior

   When a SIP entity proxy receives a SIP request, or response, that contains
   one or more Feature-Caps header fields, the feature caps in if the proxy wants to
   indicate support of features and capabilities towards its downstream
   SIP entities, it inserts a Feature-Caps header field inform to the entity about request,
   containing one or more SIP feature capability indicators associated
   with the supported features and capabilities
   supported by capabilities, before it forwards the entities that inserted
   request.

   When a proxy receives a SIP response, if the header fields.
   Procedures how proxy wants to indicate
   support of features and capabilities are invoked are outside the
   scope of this specification, and MUST be described by individual
   feature cap specifications.

   When a towards its upstream SIP entity adds
   entities, it inserts a Feature-Caps header field to a the response,
   containing one or more SIP message,
   it MUST place feature capability indicators associated
   with the header field supported features and capabilities, before any existing Feature-Caps
   header field in the message to be forwarded, so that the added header
   field becomes it forwards the top-most one.  Then, when another SIP entity
   receives a
   response.

4.3.  SIP request or Message Type and Response Code Semantics

4.3.1.  General

   This Section describes the response, general usage and semantics of the
   Feature-Caps header field for different SIP feature caps in message types and
   response codes.

   NOTE: Future specifications can define usage and semantics of the
   top-most
   Feature-Caps header field will represent the supported
   features for SIP methods, response codes and capabilities "closest" to the entity.

5.2.2.  B2BUA Behavior

   The procedures request
   types not specified in this specification.

   Section applies to UAs that are part of B2BUAs
   that are referenced in 6.2.1 defines the message by a Record-Route Feature-Caps header field
   rather than by the URI of the Contact ABNF.

4.3.2.  SIP Dialog

   The Feature-Caps header field.

   When field can be used within an initial SIP
   request for a UA sends dialog, within a target refresh SIP request, if the UA wants to indicate support of
   features and capabilities towards its downstream SIP entities, it
   inserts 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 request, containing one or
   more receivers of the request (or
   response) that the feature caps associated with the feature capability
   indicator is supported features and
   capabilities, before it forwards for the request.

   If duration of the SIP dialog, until a target
   refresh request is triggered by another SIP request that sent for the B2BUA
   has received, dialog, or the UA MAY forward received dialog is terminated.

   Unless a feature capability indicator is inserted in a Feature-Caps
   header fields
   by copying them to the outgoing SIP field or a target refresh request, similar to or within a SIP proxy,
   before response of
   such request, it inserts its own Feature-Caps header field indicates to the SIP
   request.

   When receivers of the request (or
   response) that the feature is no long supported for the dialog.

   For a UA receives given dialog a SIP response, if entity MUST insert the UA wants to indicate
   support of features same feature
   capability indicators in all 18x and capabilities towards its upstream 2xx responses associated with a
   given transaction.

4.3.3.  SIP
   entities, it inserts 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 response,
   containing one or more receivers of the message that the feature caps
   associated with the feature capability indicator is supported
   features and capabilities, before it forwards for the response.

   If
   registration, until the SIP response registration of the contact that was
   explicitly conveyed in the REGISTER request expires, or until the
   registered contact is triggered by another SIP explicitly refreshed and the refresh REGISTER
   request does not contain the feature capability indicator associated
   with the feature.

   NOTE: 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 the
   B2BUA has received, contact(s) that were explicitly
   conveyed in the associated REGISTER request.

   This specification does not define any semantics for usage of the UA MAY forward received
   Feature-Caps header field by copying them to in pure registration binding fetching
   messages (see Section 10.2.3 of RFC 3261), where the outgoing SIP response, similar to 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
   proxy, before it inserts its own entities MUST NOT insert a Feature-Caps header field to the SIP
   response.

5.2.3.  Registrar Behavior such
   messages.

   If a SIP registrar wants to indicate support of Outbound [RFC5626] is used, the rules above apply.  However,
   supported features and capabilities towards its upstream only apply for the registration
   flow on which support has been explicitly indicated.

4.3.4.  SIP entities, it inserts Stand-Alone Transactions

   The Feature-Caps header field can be used within a Feature-
   Caps header field, containing one standalone SIP
   request, and within any 18x or more feature caps 2xx response associated with the supported features and capabilities, to such
   request.

   If a REGISTER response.

5.2.4.  Proxy behavior

   When feature capability indicator is inserted in a SIP proxy receives Feature-Caps
   header field of a SIP standalone request, if the proxy wants to
   indicate support or within a response of features and capabilities towards its downstream
   SIP entities, such
   request, it inserts a Feature-Caps header field indicates to the request,
   containing one or more SIP receivers of the request (or response)
   that the feature caps associated with the feature capability indicator is
   supported
   features and capabilities, before it forwards for the request.

   When a proxy receives a duration of the standalone transaction.

5.  Feature Capability Indicators

5.1.  Introduction

   Feature capability indicators are used by SIP response, if entities not
   represented by the proxy wants URI of the Contact header field to indicate
   support of features and capabilities towards its upstream SIP
   entities, it inserts a Feature-Caps header field capabilities, where media feature tags cannot
   be used to indicate the response,
   containing one support.

   A value, or more SIP a list of values, that provides additional information
   about the supported feature caps or capability, can be associated with a
   feature capability indicator.

   Section 4 defines how feature capability indicators are conveyed
   using the supported
   features and capabilities, before it forwards Feature-Caps header field.

   Section 6.3.2 defines the response.

5.3.  SIP Message Type and Response Code Semantics

5.3.1.  General

   This feature capability indicator ABNF.

   Section describes 8 provides a template for registering feature capability
   indicators.

5.2.  Registration Trees

5.2.1.  General

   The following subsections define registration trees, distinguished by
   the general usage and semantics use of faceted names (e.g., names of the
   Feature-Caps header field for different SIP message types and
   response codes. form "tree.feature-
   name").  The registration trees are defined in the IANA "Proxy-
   Feature Feature Capability Indicator Trees" registry.

   The usage trees defined herein are similar to the global tree and semantics of a specific sip tree
   defined for media feature cap
   MUST be described tags, in RFC 2506 [RFC2506] and RFC 3840
   [RFC3840].  Other registration trees are outside the associated feature cap scope of this
   specification.

   NOTE: Future specifications can define usage In contrast to RFC 2506 and semantics of RFC 3840, this specification only
   defines a global tree and a sip tree, as they are the
   Feature-Caps header field only trees
   defined in those RFCs that have been used for SIP methods, response codes and request
   types not specified defining SIP-specific
   media feature tags.

   When a feature capability indicator is registered in this specification. any registration
   tree, no leading "+" is used in the registration.

5.2.2.  Global Tree

   The Feature-Caps header field ABNF global feature capability indicator tree is similar to the media
   feature tag global tree defined in Section 6.3.1.

5.3.2.  SIP Dialog

   The Feature-Caps header field can be used within an initial SIP
   request RFC 2506 [RFC2506].

   A feature capability indicator for the global tree will be registered
   by the IANA after review by a dialog, within designated expert.  That review will
   serve to ensure that the feature capability indicator meets the
   technical requirements of this specification.

   A feature capability indicator in the global tree will be
   distinguished by the leading facet "g.".  An organization can propose
   either a target refresh SIP request, and within
   any 18x designation indicative of the feature, (e.g., "g.blinktags")
   or 2xx response associated with such requests.

   If a faceted designation including the organization name (e.g.,
   "g.organization.blinktags").

   When a feature cap capability indicator is inserted registered in a Feature-Caps header field of an
   initial request for a dialog, or within a response of such request, the global tree,
   it indicates needs to meet the receivers of the request (or response) that "Expert Review" policies defined in RFC 5226
   [RFC5226].  A designated area expert will review the proposed feature associated
   capability indicator, and consult with members of related mailing
   lists.  This policy overrides the policy defined for registering new
   header field parameters.

5.2.3.  SIP Tree

   The sip feature cap capability indicator tree is supported for the duration
   of similar to the dialog, until a target refresh request is sent for media
   feature tag sip tree defined in RFC 3840 [RFC3840].

   A feature capability indicator in the dialog,
   or sip tree will be distinguished
   by the dialog is terminated.

   Unless leading facet "sip.".

   When a feature cap capability indicator is inserted registered in a Feature-Caps header field or a
   target refresh request, or within a response of such request, the sip tree, it
   indicates
   needs to meet the receivers "IETF Consensus" policies defined in RFC 5226
   [RFC5226].  An RFC, which contains the registration of the request (or response) that feature
   capability indicator, MUST be published.  This policy overrides the
   policy defined for registering new header field parameters.

5.3.  Feature Capability Indicator Specification Requirements

5.3.1.  General

   A feature capability indicator specification MUST address the issues
   defined in the following subsections, or document why an issue is no long supported not
   applicable for the dialog.

   For a given dialog a SIP entity specific feature capability indicator.  A
   reference to the specification MUST insert 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 same feature caps in
   all 18x and 2xx responses associated with a given transaction.

5.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 cap is conveyed capability indicators) defined
   in a this specification, unless needed for clarification or emphasis
   purpose.  A feature capability indicator specification MUST NOT
   modify the Feature-Caps header field of 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
   REGISTER request, specification MAY strengthen "SHOULD", "MAY", or within an associated response, it indicates
   "RECOMMENDED" requirements to
   the receivers of the message that the feature "MUST" strength if features and
   capabilities associated with the SIP feature cap is supported for the registration, until the registration capability indicator
   require it.

5.3.2.  Overall Description

   The feature capability indicator specification MUST contain an
   overall description of the contact that was explicitly conveyed in the REGISTER request
   expires, or until the registered contact feature capability indicator: how it is explicitly refreshed and
   the refresh REGISTER request does not contain
   used to indicate support of a feature, a description of the feature cap
   associated with the feature.

   NOTE: While SIP feature cap, a REGISTER response can contain contacts that have been
   registered as part of other registration transactions, support description of any
   indicated additional
   information (conveyed using one or more feature only applies to the contact(s) capability indicator
   values) that were explicitly can be conveyed in together with the feature capability
   indicator, and a description of how the associated REGISTER request.

   This 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 does not MUST define any 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 cap specification MUST define the
   Feature-Caps header field
   value(s) in pure registration binding fetching
   messages (see Section 10.2.3 of RFC 3261), where accordance with the REGISTER request
   does not contain a Contact header field.  Unless such semantics is ABNF 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] Section 6.3.2.

   A feature capability indicator value is used, the rules above apply.  However,
   supported features and capabilities only apply applicable for the registration
   flow on
   feature capability indicator for which support it has been explicitly indicated. 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 Stand-Alone Transactions

   The Feature-Caps header field entities can be used within insert a standalone SIP
   request, and within any 18x or 2xx response associated with
   feature cap, the feature capability indicator specification MUST
   document such
   request.

   If restrictions.

   There might be restrictions related to whether entities are allowed
   to insert a feature cap is inserted capability indicator in a Feature-Caps header field of a registration related
   messages, standalone request, transaction messages, or dialog related
   messages, whether entities are allowed to insert a feature capability
   indicator in requests or within responses, whether entities also need to
   support other features and capabilities in order to insert a response of such request, it
   indicates feature
   capability indicator, and whether entities are allowed to the receivers indicate
   support of the request (or response) that the a feature associated in conjunction with the feature cap another feature.

5.3.5.  Examples

   It is supported for the duration
   of RECOMMENDED that the standalone transaction. 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.

6.  Syntax

6.1.  General

   This Section defines the ABNF for Feature-Caps, the Feature-Caps header field, and
   for the Feature-
   Cap header field. feature capability indicators.

6.2.  Syntax: feature cap 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)

                              Figure 1: ABNF

   NOTE: A "*" value means that no information regarding which SIP
   entity, or domain, that indicate support of features and capabilities
   is provided.

6.3.  Syntax: feature capability indicator

6.3.1.  General

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

6.2.2.

6.3.2.  ABNF

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

                              Figure 2: ABNF

6.3.  Syntax: Feature-Caps header field

6.3.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)

                              Figure 3: ABNF

   NOTE: A "*" value means that no information regarding which SIP
   entity, or domain, that indicate support of features and capabilities
   is provided.

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 3261 [RFC3261].

   The following is the registration for the Feature-Caps header field:

   RFC Number: RFC XXX

   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]

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

  Feature-Caps      <feature-cap>*    No                 [xxx]

         *<feature-cap> denotes parameter names conforming to the registration for
         syntax <feature-cap> defined in [xxx]. Valid feature capability
             indicators are registered in [reference to the Feature-Caps header field:

   RFC Number: RFC XXX new
             Proxy-Feature Feature Capability Indicator Trees registry].

                   Figure 3: SIP Parameter Header Field Name: Feature-Caps

7.2.

   (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 Caps Capability Indicator Trees

7.2.1.

7.3.1.  Introduction

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

7.2.2.

7.3.2.  Global Feature Cap Capability Indicator Registration Tree

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

   The addition of entries into this tree occurs through the Expert
   Review policies, as defined in RFC 5226.  A designated area expert
   will review the proposed feature cap, capability indicator, and consult
   with members of related mailing lists.  The information required in
   the registration is defined in Section 4.3 5.3 of RFC XXX.

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

7.2.3.

7.3.3.  SIP Feature Cap Capability Indicator Registration Tree

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

   The addition of entries into this tree occurs through the IETF
   Consensus, as IETF
   Consensus, as defined in RFC 5226.  This requires the publication of
   an RFC that contains the registration.  The information required in
   the registration is defined in Section 5.3 of RFC XXX.

   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.

8.  Feature Capability Indicator Registration Template

   To: sip-feature-capability-indicators@apps.ietf.org
   (feature capability indicators mailing list)
   Subject: Registration of feature capability indicator XXXX

   | Instructions are preceded by '|'.  Some fields are optional.

   Feature cap name:

   Summary of feature indicated by this feature capability indicator:

   | The summary should be no longer than 4 lines. More
   | detailed information can be provided in the SIP feature
   | cap specification.

   Feature cap specification reference:

   | The referenced specification MUST contain the information
   | listed in Section 5.3 of XXXX (IANA: Replace XXXX with
   | assigned RFC number of this specification.

   Values appropriate for use with this feature capability indicator:

   | If no values are defined for the feature capability indicator,
   | indicate "N/A". Details about feature capability indicator values
   | MUST be defined in RFC 5226.  This requires the publication of
   an RFC that contains the registration. feature capability indicator specification.

   The information required in
   the registration feature capability indicator is defined intended primarily for
   use in Section 4.3 the following applications, protocols,
   services, or negotiation mechanisms:                    [optional]

   | For applications, also specify the number of RFC XXX.

   Note that all feature caps registered in the SIP tree
   | first version which will have names
   with a leading facet "sip.".  No leading "+" is used in use the
   registrations feature capability indicator,
   | if applicable.

   Examples of typical use:                                [optional]

   Considerations particular to use in any individual
   applications, protocols, services, or negotiation
   mechanisms:                                             [optional]

   Interoperability considerations:                        [optional]

   Security considerations:

   Privacy concerns, related to exposure of the personal
   information:

   Denial of service concerns related to consequences
   of specifying incorrect values:

   Other:

       Additional information:                         [optional]

       Keywords:                                       [optional]

       Related feature cap registration trees.

8. capability indicators:          [optional]

       Name(s) & email address(es) of person(s) to
       contact for further information:

       Intended usage:

       | one of COMMON, LIMITED USE or OBSOLETE

       Author/Change controller:

       Other information:                               [optional]

       | Any other information that the author deems
       | interesting may be added here.

                      Figure 4: Registration Template

9.  Security Considerations

   The security issues for feature caps capability indicators are similar to
   the ones defined in RFC 3840 for media feature tags.  However, as
   feature caps capability indicators will typically not be used to convey
   capability information of end-user devices, those aspects of RFC 3840
   do not apply to feature caps. capability indicators.

   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 caps. capability indicators.

   Feature caps can provide capability and characteristics information
   about the SIP entity, some of which might be sensitive.  The Feature-
   Caps header field does not convey address information about SIP
   entities.  However, individual feature caps capability indicators might
   provide address information as feature cap capability indicator values.
   Therefore, mechanisms for guaranteeing confidentiality and
   authenticity SHOULD be provided.

9.

10.  Acknowledgements

   The authors wish to thank everyone in the SIP community that provided
   input and feedback on the work of this specification.

10.

11.  Change Log

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

   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

11.

12.  References

11.1.

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.

11.2.

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.

   [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
   Hadriel Kaplan
   Acme Packet
   71 Third Ave.
   Burlington, MA  01803
   USA

   Email: hkaplan@acmepacket.com