SIPCORE Working Group                                        C. Holmberg
Internet-Draft                                               I. Sedlacek
Intended status: Standards Track                                Ericsson
Expires: September 2, October 19, 2012                                      H. Kaplan
                                                             Acme Packet
                                                           March 1,
                                                          April 17, 2012

               Indication of features supported by proxy
                draft-ietf-sipcore-proxy-feature-00.txt
                draft-ietf-sipcore-proxy-feature-01.txt

Abstract

   This document defines specification creates a new SIP header field, Feature-Caps, that can
   be IANA registry, "SIP Feature Cap
   Registry", which is used to register indicators, "SIP feature caps",
   used by SIP entities to indicate support of features and
   capabilities, in cases where the Contact header field contains a URI
   that does not represent the SIP entity that wants to indicate support
   of its features and capabilities.

   This specification also defines a new SIP header field, Feature-Caps,
   that can be used by SIP entities to convey information about
   supported features and capabilities, using SIP feature caps.

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 September 2, October 19, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3  4
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  3  4
   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3  4
   4.  User Agent (UA) Behavior . . .  SIP Feature Caps . . . . . . . . . . . . . . . .  3
     4.1.  General . . . . . . .  5
     4.1.  Introduction . . . . . . . . . . . . . . . . . .  3
     4.2.  B2BUA Behavior . . . . .  5
     4.2.  Syntax . . . . . . . . . . . . . . . . .  4
     4.3.  Registrar Behavior . . . . . . . . .  5
       4.2.1.  General  . . . . . . . . . . .  4
   5.  Proxy behavior . . . . . . . . . . . .  5
       4.2.2.  ABNF . . . . . . . . . . . .  5
   6.  Feature-Caps Header Field Definition . . . . . . . . . . . . .  5
     6.1.  General
     4.3.  Registration Trees . . . . . . . . . . . . . . . . . . . .  6
       4.3.1.  General  . . . . .  5
     6.2.  SIP Dialog . . . . . . . . . . . . . . . . . .  6
       4.3.2.  Global Tree  . . . . . .  5
     6.3.  SIP Registration (REGISTER) . . . . . . . . . . . . . . .  6
     6.4.
       4.3.3.  SIP Stand-Alone Transactions Feature Cap Registration Tree  . . . . . . . . . .  7
     4.4.  Registration Template  . . . . .  6
     6.5.  SIP Capability Query (OPTIONS) . . . . . . . . . . . . .  7
     4.5.  SIP Feature Cap Specification Requirements .  6
   7.  Syntax . . . . . . .  9
       4.5.1.  General  . . . . . . . . . . . . . . . . . . . . .  6
     7.1.  General . .  9
       4.5.2.  Overall Description  . . . . . . . . . . . . . . . . .  9
       4.5.3.  Feature Cap Values . . . . . .  6
     7.2.  ABNF . . . . . . . . . . . .  9
       4.5.4.  Usage Restrictions . . . . . . . . . . . . . . .  6
   8.  Feature Tag Usage With Feature-Caps . . . 10
       4.5.5.  Implementation Details . . . . . . . . . .  7
   9.  Feature Tag Requirements . . . . . . 10
       4.5.6.  Examples . . . . . . . . . . . . .  7
     9.1.  General . . . . . . . . . . 10
   5.  Feature-Caps Header Field  . . . . . . . . . . . . . . .  7
     9.2.  Overall Description . . . 10
     5.1.  Introduction . . . . . . . . . . . . . . . .  8
     9.3.  Applicability . . . . . . . 11
     5.2.  User Agent and Proxy Behavior  . . . . . . . . . . . . . . 11
       5.2.1.  General  .  8
     9.4.  Feature Tag Name . . . . . . . . . . . . . . . . . . . . .  8
     9.5.  Feature Tag Values . 11
       5.2.2.  B2BUA Behavior . . . . . . . . . . . . . . . . . . .  8
     9.6.  SIP Option Tags . 12
       5.2.3.  Registrar Behavior . . . . . . . . . . . . . . . . . . 12
       5.2.4.  Proxy behavior . .  8
     9.7.  Feature Tag Usage Restrictions . . . . . . . . . . . . . .  9
     9.8.  Feature Tag Security Considerations . . . . 12
     5.3.  SIP Message Type and Response Code Semantics . . . . . . .  9
     9.9.  Implementation Details 13
       5.3.1.  General  . . . . . . . . . . . . . . . . . .  9
     9.10. Examples . . . . . 13
       5.3.2.  SIP Dialog . . . . . . . . . . . . . . . . . . . .  9
   10. IANA Considerations . . 13
       5.3.3.  SIP Registration (REGISTER)  . . . . . . . . . . . . . 14
       5.3.4.  SIP Stand-Alone Transactions . . . . . . 10
     10.1. Registration of the Feature-Caps header field . . . . . . 10
   11. Security Considerations . 14
     5.4.  Syntax . . . . . . . . . . . . . . . . . . 10
   12. Acknowledgements . . . . . . . . 14
       5.4.1.  ABNF . . . . . . . . . . . . . . . 10
   13. Change Log . . . . . . . . . . 14
   6.  IANA Considerations  . . . . . . . . . . . . . . . . 10
   14. References . . . . . 15
     6.1.  Registration of the Feature-Caps header field  . . . . . . 15
   7.  Security Considerations  . . . . . . . . . . . . . . . 11
     14.1. Normative References . . . . 15
   8.  Acknowledgements . . . . . . . . . . . . . . . 11
     14.2. Informative References . . . . . . . . 15
   9.  Change Log . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . 15
   10. References . . . . . . . . 11 . . . . . . . . . . . . . . . . . . 16
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
     10.2. Informative References . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17

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 document defines specification creates a new SIP header field, Feature-Caps, IANA registry, "SIP Feature Cap
   Registry", which is used to register indicators, "SIP feature caps",
   that can be used by SIP entities to indicate support of features and
   capabilities, in cases where the Contact header field contains a URI
   that does not represent the SIP entity that wants to indicate support
   of its features and capabilities. capabilities, and 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,
   that can be used by SIP entities to convey information about
   supported features and capabilities, using SIP feature caps.

   Unlike media feature tags, SIP feature caps are intended to only be
   used with the SIP protocol.

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.  User Agent (UA) Behavior  SIP Feature Caps

4.1.  General

   If the URI  Introduction

   A SIP feature cap can be used by SIP entities to indicate support of
   features and capabilities, in a cases where media feature tags cannot
   be used, ie if the Contact header field of a request or response
   represents contains a UA, URI that does not
   represent the UA MUST NOT SIP entity that wants to indicate supported support of its
   features and
   capabilities using a Feature-Caps header field within that request capabilities.

   A value, or
   response.

   When a UA receives list of values, can be associated with a SIP request, or response, that contains one or
   more feature
   cap.

   [ref-to-section] defines how SIP feature caps are conveyed using the
   SIP Feature-Caps header fields, the Feature Tags in field.

4.2.  Syntax

4.2.1.  General

   In a SIP feature cap 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.

4.2.2.  ABNF

   The ABNF for the Feature-Caps header field
   inform the UA is about the features supported is:

   feature-cap       =  ["+"] fcap-name [EQUAL LDQUOT (fcap-value-list
                        / string-value ) RDQUOT]
   fcap-name         =  ALPHA *( ALPHA / DIGIT / "!" / "'"
                        / "." / "-" / "%" )
   fcap-value-list   =  fcap-value *("," fcap-value)
   fcap-value        =  ["!"] (token-nobang / boolean / numeric)
   token-nobang      =  1*(alphanum / "-" / "." / "%" / "*"
                        / "_" / "+" / "`" / "'" / "~" )
   boolean           =  "TRUE" / "FALSE"
   numeric           =  "#" numeric-relation number
   numeric-relation  =  ">=" / "<=" / "=" / (number ":")
   number            =  [ "+" / "-" ] 1*DIGIT ["." 0*DIGIT]
   string-value      =  "<" *(qdtext-no-abkt / quoted-pair ) ">"
   qdtext-no-abkt    =  LWS / %x21 / %x23-3B / %x3D
                        / %x3F-5B / %x5D-7E / UTF8-NONASCII
                        ;;gdtext as defined in RFC 3261
                              Figure 1: ABNF

4.3.  Registration Trees

4.3.1.  General

   The following subsections define registration "trees", distinguished
   by the entities that
   inserted use of faceted names (e.g., names of the header fields.  Procedures how features are invoked form "tree.feature-
   name").

   The tree definitions are
   outside based on the scope of this specification, global tree and MUST sip tree
   defined for media feature tags, in RFC 2506 [RFC2506] and RFC 3841
   [RFC3841].

   Additional feature caps trees can be described created by
   individual Feature Tag specifications.

   When IANA, following the UA receives
   same rules and procedures as defined for media feature tags in
   section 3.1.4 of RFC 2506 [RFC2506].

   The acceptance of the SIP request proposed designation is at the discretion of
   IANA.  If IANA believes that additional information, or
   clarification, is needed, it can request an updated proposal from the response,
   proposing organization.

   When a SIP feature cap is registered in any registration tree, no
   leading "+" is used in the registration.

4.3.2.  Global Tree

   The SIP feature
   tags cap global tree is based on the media feature tag
   global tree defined in RFC 2506 [RFC2506].

   A SIP feature cap for the topmost Feature-Caps header field global tree will represent the
   supported features "closest" to be registered by the UA.

4.2.  B2BUA Behavior

   The procedures in this section applies IANA
   after review by a designated expert.  That review will serve to UAs
   ensure that are part of
   B2BUAs, but where the URI in SIP feature cap meets the Contact header field does not
   represent technical requirements of
   this specification.

   A SIP feature cap in the UA, because global tree will be distinguished by the B2BUA
   leading facet "g.".  An organization can propose either a designation
   indicative of the feature, (e.g., "g.blinktags") or a faceted
   designation including the organization name (e.g.,
   "g.organization.blinktags").

   When a SIP feature cap is registered in the global tree, it needs to
   meet the "Expert Review" policies defined in RFC 5226 [RFC5226].  A
   designated area expert will review the proposed SIP feature cap, and
   consult with members of related mailing lists.

4.3.3.  SIP Feature Cap Registration Tree

   The SIP feature cap sip tree is based on the media feature tag sip
   tree defined in RFC 3840 [RFC3840].

   A SIP feature cap in the sip tree will be distinguished by the
   leading facet "sip.".

   When a SIP feature cap is registered in the sip tree, it needs to
   meet the "IETF Consensus" policies defined in RFC 5226 [RFC5226].  An
   RFC, which contains the registration of the SIP feature cap, must be
   published.

4.4.  Registration Template

   To: sip-feature-caps@apps.ietf.org (SIP feature caps mailing list)
   Subject: Registration of SIP feature cap XXXX

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

   SIP feature cap name:

   Summary of feature indicated by this SIP feature cap:

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

   SIP feature cap specification reference:

   | The reference 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 SIP feature cap:

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

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

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

   Examples of typical use:                                [optional]

   Related standards or documents:                         [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 SIP 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:

       Requested IANA publication delay:                [optional]

       | A delay may only be requested for final placement
       | in the global or IETF trees, with a proxy maximum of two
       | months. Organizations requesting a registration
       | with a publication delay should note that this
       | delays only the official publication of the SIP
       | feature cap and
   inserts its URI e.g. does not prevent information on
           | it from being disseminated by the members of the
           | relevant mailing list.

       Other information:                               [optional]

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

                      Figure 2: Registration Template

4.5.  SIP Feature Cap Specification Requirements

4.5.1.  General

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

   It is bad practice for SIP feature cap specifications to repeat
   procedures defined in this specification, unless needed for
   clarification or emphasis purpose.

   A SIP 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 associated with the SIP
   feature cap require it.

4.5.2.  Overall Description

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

4.5.3.  Feature Cap Values

   A SIP feature cap can have an associated value, or a list of values.
   A SIP feature cap value MUST conform to the ABNF defined in
   Section 4.2.2.

   The SIP feature cap specification MUST define the syntax and
   semantics of any value defined for the SIP feature cap, including
   possible restrictions related to the usage of a specific value.

   A SIP feature cap value can share the name with a value defined for
   another SIP feature cap.  However, a value defined for a SIP feature
   cap is feature cap specific, and can only be used with a SIP feature
   cap for which the value has explicitly been defined.

   It is STRONLY RECOMMENDED to not re-use a value name that already has
   been defined for another SIP feature cap, unless the semantics of the
   values are the same.

4.5.4.  Usage Restrictions

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

   There might be restrictions related to whether entities are allowed
   to insert a SIP feature cap in registration related messages,
   standalone transaction messages, or dialog related messages, whether
   entities are allowed to insert a SIP feature cap in requests or
   responses, whether entities also need to support other features in a Record-Route header field.

   When a UA sends
   order to insert a SIP request, if the UA wants feature cap, and whether entities are allowed
   to indicate support of
   features towards its downstream SIP entities, it adds a Feature-Caps
   header field to the request, together with one or more Feature Tags
   associated feature in conjunction with the supported features, before it forwards the
   request.

   If the SIP request is triggered by another feature.

4.5.5.  Implementation Details

   The SIP request that the B2BUA
   has received, feature cap specification SHOULD define the UA MAY forward those Feature-Caps header field by
   copying them to procedure
   regarding how implementers shall implement and use the outgoing SIP request, similar Feature Cap,
   or refer to other locations where implementers can find that
   information.

   NOTE: Sometimes a SIP proxy,
   before it adds its own Feature-Caps header field feature cap designer might choose to not reveal
   the SIP request.

   When a UA receives implementation details of a SIP response, if the UA wants feature cap.  However, in order
   to allow multiple implementations to indicate support of features towards its upstream the SIP entities, it adds a
   Feature-Caps header field feature cap,
   designers are strongly encouraged to provide the response, together with one or more
   Feature Tags associated with the supported features, before it
   forwards the response.

   If the SIP response implementation
   details.

4.5.6.  Examples

   It is triggered by another SIP response RECOMMENDED that the
   B2BUA has received, the UA MAY forward those Feature-Caps header
   field by copying them to the outgoing SIP response, similar to a SIP
   proxy, before it adds its own feature cap specification provide
   demonstrative message flow diagrams, paired with complete messages
   and message descriptions.

   Note that example flows are by definition informative, and do not
   replace normative text.

5.  Feature-Caps Header Field
5.1.  Introduction

   The Feature-Caps header field to the SIP
   response.

4.3.  Registrar Behavior

   If a is used by SIP registrar wants entities to indicate convey
   support of features towards its
   upstream and capabilities, using SIP entities, it can insert feature caps.  SIP
   feature caps inserted in a Feature-Caps header field,
   together with Feature Tags associated with field indicate that
   the supported features, in
   a REGISTER response.

5.  Proxy behavior

   When a proxy receives a SIP request, if entity that inserted the proxy wants header field supports the associated
   features.

   NOTE: It is not possible to indicate
   support convey the address of features towards its downstream the SIP entities, it adds entity as a
   Feature-Caps header field parameter.  Each feature that requires
   address information to be conveyed need to define a way to convey
   that information as part of the request, together with one or more
   Feature Tags associated with SIP feature cap value.

   The SIP feature cap specification MUST specify for which SIP methods
   and message types, and the supported features, before it
   forwards associated semantics, the request.

   When a proxy adds SIP feature cap
   is applicable.  See section [ref-to-reg-temp} for more information.
   No semantics is defined for SIP feature caps present in SIP methods
   and message types not covered by the associated SIP feature cap
   specification.

   Within a given Feature-Caps header field to a field, SIP request, it
   MUST place the feature caps are listed
   in a non-priority order, and for a given header field before any existing Feature-Caps order of
   listed SIP feature caps have the same meaning.  For example,
   "foo;bar" and "bar;foo" have the same meaning(i.e. that the SIP
   entity that inserted the feature caps supports the features
   associated with the "foo" and "bar" SIP feature caps.

5.2.  User Agent and Proxy Behavior

5.2.1.  General

   If the URI in a Contact header field in the request.

   When of a proxy receives request or response
   represents a SIP response, if UA, the proxy wants to UA MUST NOT indicate
   support of supported features towards its upstream SIP entities, it adds and
   capabilities using a Feature-Caps header field to the within that request or
   response.

   When a UA receives a SIP request, or response, together with that contains one or
   more Feature-Caps header fields, the Feature Tags associated with Caps in the header field
   inform the UA is about the features supported features, before it
   forwards by the entities that
   inserted the response.

   When a proxy adds a Feature-Caps header field to a fields.  Procedures how features are invoked are
   outside the scope of this specification, and MUST be described by
   individual Feature Cap specifications.

   When the UA receives the SIP request or the response, it
   MUST place the header field before any existing SIP feature
   caps in the topmost Feature-Caps header field in will represent the response.

6.  Feature-Caps Header Field Definition

6.1.  General

   This
   supported features "closest" to the UA.

5.2.2.  B2BUA Behavior

   The procedures in this section describes how applies to UAs that are part of
   B2BUAs, but where the Feature-Caps URI in the Contact header field is used, and does not
   represent the associated semantics, with different SIP methods and response
   codes.

   NOTE: Future specification can define usage semantics of UA, because the Feature-
   Caps header fields for SIP methods, response codes B2BUA is also acting as a proxy and request types
   not specified
   inserts its URI e.g. in this specification.

6.2.  SIP Dialog

   The Feature-Caps a Record-Route header field can be used within an initial SIP
   request for field.

   When a dialog, within UA sends a target refresh SIP request, and within
   any 18x or 2xx response associated with such requests.

   If a Feature Tag is inserted in if the UA wants to indicate support of
   features towards its downstream SIP entities, it adds a Feature-Caps
   header field of such
   request or such response, to the feature request, together with one or more Feature Caps
   associated with the Feature Tag
   MUST be supported for the dialog, until the next time features, before it forwards the dialog
   target is refreshed, or
   request.

   If the dialog SIP request is terminated.

   For a given dialog triggered by another SIP request that the entity MUST use B2BUA
   has received, the same UA MAY forward those Feature-Caps header field value (if included) in all 18x and 2xx responses for by
   copying them to the same
   transaction.

6.3. outgoing SIP Registration (REGISTER)

   The request, similar to a SIP proxy,
   before it adds its own Feature-Caps header field can be used within to the SIP request.

   When a UA receives a SIP REGISTER
   request, and within response, if the 200 (OK) response UA wants to indicate
   support of such request.

   If a Feature Tag is inserted in features towards its upstream SIP entities, it adds a
   Feature-Caps header field of a SIP
   REGISTER request or response, to the feature response, together with one or more
   Feature Caps associated with the Feature
   Tag MUST be supported for features, before it
   forwards the response.

   If the registration, and all SIP transactions
   associated with response is triggered by another SIP response that the registration, until
   B2BUA has received, the registration is re-
   freshed or terminated.

6.4. UA MAY forward those Feature-Caps header
   field by copying them to the outgoing SIP Stand-Alone Transactions

   The response, similar to a SIP
   proxy, before it adds its own Feature-Caps header field can be used within an request for
   standalone to the SIP transaction, and within any 18x or 2xx response
   associated with such request.
   response.

5.2.3.  Registrar Behavior

   If a Feature Tag is inserted in SIP registrar wants to indicate support of features towards its
   upstream SIP entities, it can insert a Feature-Caps header field of an
   request or response for a standalone transaction, the feature field,
   together with Feature Caps associated with the Feature Tag MUST be supported for features, in
   a REGISTER response.

5.2.4.  Proxy behavior

   When a SIP proxy receives a SIP request, if the duration proxy wants to
   indicate support of
   the standalone transaction.

6.5. features towards its downstream SIP Capability Query (OPTIONS)

7.  Syntax

7.1.  General

   Each value of entities, it
   adds a Feature-Caps header field MUST contain a "*" value,
   followed by to the request, together with one or
   more Feature Tags, SIP feature caps associated with the supported features, separated by semicolon (";").

   NOTE: A "*" value means that no information regarding which proxy, or
   domain, that support the features associated with before
   it forwards the Feature Tags,
   is provided.

   NOTE: When used in a Contact header field, a "*" value has an "any
   URI" meaning. request.

   When used in a Feature-Caps header field, it simply
   means that no URI information is provided.

7.2.  ABNF

   The ABNF for the Feature-Caps header fields is:

           Feature-Caps = ("Feature-Caps" / "fc") HCOLON fc-value
                          *(COMMA fc-value)
           fc-value     = "*" *(SEMI feature-param)
                          ;;feature-param from RFC 3840

                              Figure 1: ABNF

8.  Feature Tag Usage With Feature-Caps

   Feature tags inserted in proxy adds a Feature-Caps header field indicate that
   the to a SIP entity that inserted message, it
   MUST place the header field supports the associated
   features.

   In order to use a Feature Tag in a before any existing Feature-Caps header field, the
   Feature Tag specification MUST specify the semantics of the feature
   tag when inserted
   fields in the Feature-Caps header field.  Unless the
   feature specification defines such semantics, request.

   When a proxy receives a SIP response, if the Feature Tag MUST
   NOT be used in proxy wants to indicate
   support of features towards its upstream SIP entities, it adds a
   Feature-Caps header field.

   Within field to the response, together with one or more
   SIP feature caps associated with the supported features, before it
   forwards the response.

   When a proxy adds a given Feature-Caps header field, Feature Tags are listed in
   a non-priority order, and for field to a given SIP response, it
   MUST place the header field before any order of
   listed Feature Tags have the same meaning.  For example, "foo;bar"
   and "bar;foo" have the same meaning (i.e. that the entity that
   inserted the Feature Tags supports the features associated with existing Feature-Caps header
   field in the
   "foo" response.

5.3.  SIP Message Type and "bar" Feature Tags.

9.  Feature Tag Requirements

9.1. Response Code Semantics

5.3.1.  General

   This section provides guidance on how to define an Feature Tag, describes the general usage and
   what information needs to exist semantics of the
   Feature-Caps header field for different SIP message types and
   response codes.  The usage and semantics of a specific SIP feature
   cap MUST be described in an Feature Tag the associated SIP feature cap
   specification.

   It is bad practice for Feature Tag

   NOTE: Future specifications to repeat
   procedures defined in this document, unless needed can define usage and semantics of the
   Feature-Caps header field for clarification
   or emphasis purpose.

   Feature Tag specifications MUST NOT weaken any behavior designated
   with "SHOULD" or "MUST" SIP methods, response codes and request
   types not specified in this specification.  However, Feature Tags
   specifications MAY strengthen "SHOULD", "MAY",

5.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 "RECOMMENDED"
   requirements to "MUST" strength if features 2xx response associated with the
   Feature Tag require it.

   Feature Tag specifications MUST address the issues defined such requests.

   If a SIP feature cap is inserted in the
   following subsections, or document why a Feature-Caps header field of an issue is not applicable
   initial request for
   the specific Feature Tag.

9.2.  Overall Description

   The Feature Tag specification MUST contain an overall description a dialog, or within a response of such request,
   it indicates to the Feature Tag: a description receivers of the request (or response) that the
   feature associated with the
   Feature Tag, and a description what information SIP feature cap is carried in
   associated Feature Tag values (if any).

9.3.  Applicability

   The Feature Tag specification MUST describe why supported for the support
   duration of the
   feature can not be indicated in dialog, until a SIP Contact header field [RFC3261],
   using the mechanism defined in RFC 3840.  The reason target refresh request is either that sent for
   the entity inserting dialog, or the Feature Tag dialog is acting as terminated.

   Unless a SIP proxy, feature cap is inserted in a Feature-Caps header field
   or SIP
   registrar, a target refresh request, or within a B2BUA but is not represented by response of such request, it
   indicates to the URI in receivers of the
   Contact header field.

9.4.  Feature Tag Name

   The Feature Tag specification request (or response) that the
   feature is no long supported for the dialog.

   For a given dialog a SIP entity MUST define an Feature Tag name, which
   entities use as insert the same SIP feature caps
   in all 18x and 2xx responses associated with a given transaction.

5.3.3.  SIP Registration (REGISTER)

   The Feature-Caps header field value to identify can be used within a SIP REGISTER
   request, and within the Feature Tag 200 (OK) response associated with such
   request.

   If a SIP feature cap is inserted in
   the a Feature-Caps header field.  The Feature Tag name MUST conform to
   the ABNF defined in Section 7.2.

9.5.  Feature Tag Values

   The Feature Tag specification MAY define Feature Tag values, field of a
   SIP REGISTER request, or within a response of such request, it
   indicates to the receivers of the request (or response) that the
   feature associated with the Feature Tag. A Feature Tag value MUST conform to
   the ABNF defined in Section 7.2.

   The Feature Tag specification MUST define SIP feature cap is supported for the syntax and semantics
   duration of the values registration, and for all SIP transactions associated
   with the Feature Tag. In addition, registration, until the
   specification MUST define whether there are restrictions regarding registration is re-freshed or
   terminated.

   Unless a SIP feature cap is inserted in a Feature-Caps header field
   or a re-registration, or within a response of such request, it
   indicates to the usage receivers of specific values.

   Feature Tags can share value defined for other Feature Tags, but the
   value is Feature Tag specific, and request (or response) that the value semantics MUST be
   defined
   feature is no long supported for each Feature Tag tag uses the value.

9.6. registration.

5.3.4.  SIP Option Tags Stand-Alone Transactions

   The Feature Tag specification MAY define SIP option tags, which Feature-Caps header field can be used as describe in RFC 3261.

   The registration requirements for option tags are defined in RFC 5727
   [RFC5727].

9.7.  Feature Tag Usage Restrictions

   If there are restrictions on how entities can insert within a Feature Tag,
   the Feature Tag specification MUST document such restrictions.

   There can be restrictions related to whether entities are allowed to
   insert Feature Tags in registration related messages, standalone
   transaction messages, or dialog related messages, whether entities
   are allowed to insert Feature Tags in requests or responses, whether
   entities also need to support other features in order to insert a
   Feature Tag, SIP
   request, and whether entities are allowed to insert Feature Tags
   togheter within any 18x or 2xx response associated with other Feature Tags.

9.8.  Feature Tag Security Considerations such
   request.

   If the information carried a SIP feature cap is inserted in a Feature Tag requires Feature-Caps header field of a
   standalone request, or within a certain level response of security, such request, it
   indicates to the Feature Tag specification MUST describe receivers of the
   mechanisms request (or response) that entities need to use in order to provide the required
   security.

   If the Feature Tag specification does not require any additional
   security, other than what
   feature associated with the underlying SIP protocol provides, this
   MUST be stated in the Feature Tag specification.

9.9.  Implementation Details

   It feature cap is strongly RECOMMENDED that supported for the Feature Tag specification defines
   duration of the procedure regarding how implementors shall implement and use standalone transaction.

5.4.  Syntax

5.4.1.  ABNF

   The ABNF for the
   Feature Tag, Feature-Caps header fields is:

   Feature-Caps = ("Feature-Caps" / "fc") 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 refer to other locations where implementors can find domain, that information.

   NOTE: Sometimes an Feature Tag designer might choose to not reveal
   the details of an Feature Tag. However, in order to allow multiple
   implementations to indicate support the Feature Tag, Feature Tag designers are
   strongly encouraged to provide the implementation details.

9.10.  Examples

   It of features is RECOMMENDED that the Feature Tag specification provide
   demonstrative message flow diagrams, paired with complete messages
   and message descriptions.

   Note that example flows are by definition informative, and do not
   replace normative text.

10. provided.

6.  IANA Considerations

10.1.

6.1.  Registration of the Feature-Caps header field

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

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

   RFC Number: RFC XXX

   Header Field Name: Feature-Caps Header Field Name: Feature-Caps

   Compact Form: fc

11.

7.  Security Considerations

   Feature tags

   SIP feature caps can provide sensitive information about a SIP
   entity.  RFC 3840 cautions against providing sensitive information to
   another party.  Once this information is given out, any use may be
   made of it.

12.

8.  Acknowledgements

13.

9.  Change Log

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

   Changes from draft-holmberg-sipcore-proxy-feature-04/
   draft-ietf-sipcore-proxy-feature-00
   o  Media feature tags replaced with SIP 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 Tag 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

14.

10.  References

14.1.

10.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.

10.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.

   [RFC5727]  Peterson,

   [RFC3841]  Rosenberg, J., Jennings, C., Schulzrinne, H., and R. Sparks, "Change Process P. Kyzivat, "Caller
              Preferences for the Session Initiation Protocol (SIP) and the Real-
              time Applications (SIP)",
              RFC 3841, August 2004.

   [RFC5226]  Narten, T. and Infrastructure Area", H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 67, 26, RFC 5727, March 2010.

14.2.  Informative References 5226,
              May 2008.

   [3GPP.23.237]
              3GPP, "IP Multimedia Subsystem (IMS) Service Continuity;
              Stage 2", 3GPP TS 23.237 10.8.0, December 2011. 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