Skip to main content

Indication of features supported by proxy
draft-ietf-sipcore-proxy-feature-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 6809.
Authors Christer Holmberg , Ivo Sedlacek , Hadriel Kaplan
Last updated 2012-05-09
Replaces draft-holmberg-sipcore-proxy-feature
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 6809 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-sipcore-proxy-feature-02
SIPCORE Working Group                                        C. Holmberg
Internet-Draft                                               I. Sedlacek
Intended status: Standards Track                                Ericsson
Expires: November 10, 2012                                     H. Kaplan
                                                             Acme Packet
                                                             May 9, 2012

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

Abstract

   This specification creates a new 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 November 10, 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

Holmberg, et al.        Expires November 10, 2012               [Page 1]
Internet-Draft                proxy feature                     May 2012

   (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.  SIP Feature Caps . . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  Introduction . . . . . . . . . . . . . . . . . . . . . . .  5
     4.2.  Registration Trees . . . . . . . . . . . . . . . . . . . .  5
       4.2.1.  General  . . . . . . . . . . . . . . . . . . . . . . .  5
       4.2.2.  Global Tree  . . . . . . . . . . . . . . . . . . . . .  5
       4.2.3.  SIP Feature Cap Registration Tree  . . . . . . . . . .  6
     4.3.  Registration Template  . . . . . . . . . . . . . . . . . .  6
     4.4.  SIP Feature Cap Specification Requirements . . . . . . . .  8
       4.4.1.  General  . . . . . . . . . . . . . . . . . . . . . . .  8
       4.4.2.  Overall Description  . . . . . . . . . . . . . . . . .  8
       4.4.3.  Feature Cap Values . . . . . . . . . . . . . . . . . .  8
       4.4.4.  Usage Restrictions . . . . . . . . . . . . . . . . . .  9
       4.4.5.  Examples . . . . . . . . . . . . . . . . . . . . . . .  9
   5.  Feature-Caps Header Field  . . . . . . . . . . . . . . . . . .  9
     5.1.  Introduction . . . . . . . . . . . . . . . . . . . . . . .  9
     5.2.  User Agent and Proxy Behavior  . . . . . . . . . . . . . . 10
       5.2.1.  General  . . . . . . . . . . . . . . . . . . . . . . . 10
       5.2.2.  B2BUA Behavior . . . . . . . . . . . . . . . . . . . . 10
       5.2.3.  Registrar Behavior . . . . . . . . . . . . . . . . . . 11
       5.2.4.  Proxy behavior . . . . . . . . . . . . . . . . . . . . 11
     5.3.  SIP Message Type and Response Code Semantics . . . . . . . 11
       5.3.1.  General  . . . . . . . . . . . . . . . . . . . . . . . 11
       5.3.2.  SIP Dialog . . . . . . . . . . . . . . . . . . . . . . 12
       5.3.3.  SIP Registration (REGISTER)  . . . . . . . . . . . . . 12
       5.3.4.  SIP Stand-Alone Transactions . . . . . . . . . . . . . 13
   6.  Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     6.1.  General  . . . . . . . . . . . . . . . . . . . . . . . . . 13
     6.2.  Syntax: SIP feature cap  . . . . . . . . . . . . . . . . . 13
       6.2.1.  General  . . . . . . . . . . . . . . . . . . . . . . . 13
       6.2.2.  ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 13
     6.3.  Syntax: Feature-Caps header field  . . . . . . . . . . . . 14
       6.3.1.  ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 14
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
     7.1.  Registration of the Feature-Caps header field  . . . . . . 14

Holmberg, et al.        Expires November 10, 2012               [Page 2]
Internet-Draft                proxy feature                     May 2012

     7.2.  Global Feature Cap Registration Tree . . . . . . . . . . . 14
     7.3.  SIP Feature Cap Registration Tree  . . . . . . . . . . . . 15
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
     11.2. Informative References . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17

Holmberg, et al.        Expires November 10, 2012               [Page 3]
Internet-Draft                proxy feature                     May 2012

1.  Introduction

   The Session Initiation Protocol (SIP) [RFC3261] "Caller Preferences"
   extension, defined in RFC 3840 [RFC3840], provides a mechanism that
   allows a SIP message to convey information relating to the
   originator's features and capabilities, using the Contact header
   field.

   This specification creates a new 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, 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.

Holmberg, et al.        Expires November 10, 2012               [Page 4]
Internet-Draft                proxy feature                     May 2012

4.  SIP Feature Caps

4.1.  Introduction

   A SIP feature cap can be used by SIP entities to indicate support of
   features and capabilities, in cases where media feature tags cannot
   be used, ie if the Contact header field contains a URI that does not
   represent the SIP entity that wants to indicate support of its
   features and capabilities.

   A value, or a list of values, can be associated with a SIP feature
   cap.

   Section 5 defines how SIP feature caps are conveyed using the SIP
   Feature-Caps header field.

   The SIP 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 trees defined herein are similar to the global tree and sip tree
   defined for media feature tags, in RFC 2506 [RFC2506] and RFC 3841
   [RFC3841].  Other registration trees are outside the scope of this
   specification.

   NOTE: Compared to RFC 2506, this specification only defines a global
   tree and a sip tree, as they are the only tree defined in RFC 2506
   that have been used for defining media feature tags for SIP.

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

4.2.2.  Global Tree

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

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

Holmberg, et al.        Expires November 10, 2012               [Page 5]
Internet-Draft                proxy feature                     May 2012

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

   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.2.3.  SIP Feature Cap Registration Tree

   The SIP feature cap sip tree is similar to 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.3.  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 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 SIP feature cap:

Holmberg, et al.        Expires November 10, 2012               [Page 6]
Internet-Draft                proxy feature                     May 2012

   | 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 specify the number of the
   | first version which will use the SIP 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 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:

       Other information:                               [optional]

       | Any other information that the author deems

Holmberg, et al.        Expires November 10, 2012               [Page 7]
Internet-Draft                proxy feature                     May 2012

       | interesting may be added here.

                      Figure 1: Registration Template

4.4.  SIP Feature Cap Specification Requirements

4.4.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 Section 4.3).

   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.4.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, 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, and a description of how the associated feature
   may be exercised/invoked.

4.4.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
   6.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 is only applicable for the SIP feature cap
   for which it has been defined.  For other SIP feature caps, the value
   has to be defined explicitly, even if the name or the semantics are

Holmberg, et al.        Expires November 10, 2012               [Page 8]
Internet-Draft                proxy feature                     May 2012

   identical.

   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.4.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
   order to insert a SIP feature cap, and whether entities are allowed
   to indicate support of a feature in conjunction with another feature.

4.4.5.  Examples

   It is RECOMMENDED that the SIP 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 is used by SIP entities to convey
   support of features and capabilities, using SIP feature caps.  SIP
   feature caps conveyed in a Feature-Caps header field indicate that
   the SIP entity that inserted the header field supports the associated
   features.

   NOTE: It is not possible to convey the address of the SIP 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 associated SIP feature cap value.

   The SIP feature cap specification MUST specify for which SIP methods
   and message types, and the associated semantics, the SIP feature cap
   is applicable.  See Section 4 for more information.  No semantics is

Holmberg, et al.        Expires November 10, 2012               [Page 9]
Internet-Draft                proxy feature                     May 2012

   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, SIP feature caps are listed
   in a non-priority order, and for a given header field any 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 of a request or response
   represents a SIP entity, the entity MUST NOT indicate supported
   features and capabilities using a Feature-Caps header field within
   that request or response.

   When a SIP entity receives a SIP request, or response, that contains
   one or more Feature-Caps header fields, the SIP feature caps in the
   header field inform the entity about the features supported by the
   entities that inserted the header fields.  Procedures how features
   are invoked are outside the scope of this specification, and MUST be
   described by individual SIP feature cap specifications.

   When a SIP entity adds a Feature-Caps header field to a SIP message,
   it MUST place the header field before any existing Feature-Caps
   header field in the message to be forwarded, so that the added header
   field becomes the top-most one.  Then, when another SIP entity
   receives a SIP request or the response, the SIP feature caps in the
   top-most Feature-Caps header field will represent the supported
   features "closest" to the entity.

5.2.2.  B2BUA Behavior

   The procedures in this Section applies to UAs that are part of B2BUAs
   that are referenced in the message by a Record-Route header field
   rather than by the URI of the Contact header field.

   When a UA sends a SIP request, if the UA wants to indicate support of
   features towards its downstream SIP entities, it inserts a Feature-
   Caps header field to the request, containing one or more SIP feature
   caps associated with the supported features, before it forwards the
   request.

   If the SIP request is triggered by another SIP request that the B2BUA
   has received, the UA MAY forward received Feature-Caps header fields

Holmberg, et al.        Expires November 10, 2012              [Page 10]
Internet-Draft                proxy feature                     May 2012

   by copying them to the outgoing SIP request, similar to a SIP proxy,
   before it inserts its own Feature-Caps header field to the SIP
   request.

   When a UA receives a SIP response, if the UA wants to indicate
   support of features towards its upstream SIP entities, it inserts a
   Feature-Caps header field to the response, containing one or more SIP
   feature caps associated with the supported features, before it
   forwards the response.

   If the SIP response is triggered by another SIP response that the
   B2BUA has received, the UA MAY forward received Feature-Caps header
   field by copying them to the outgoing SIP response, similar to a SIP
   proxy, before it inserts its own Feature-Caps header field to the SIP
   response.

5.2.3.  Registrar Behavior

   If a SIP registrar wants to indicate support of features towards its
   upstream SIP entities, it inserts a Feature-Caps header field,
   containing one or more SIP feature caps associated with the supported
   features, to a REGISTER response.

5.2.4.  Proxy behavior

   When a SIP proxy receives a SIP request, if the proxy wants to
   indicate support of features towards its downstream SIP entities, it
   inserts a Feature-Caps header field to the request, containing one or
   more SIP feature caps associated with the supported features, before
   it forwards the request.

   When a proxy receives a SIP response, if the proxy wants to indicate
   support of features towards its upstream SIP entities, it inserts a
   Feature-Caps header field to the response, containing one or more SIP
   feature caps associated with the supported features, before it
   forwards the response.

5.3.  SIP Message Type and Response Code Semantics

5.3.1.  General

   This Section describes the general usage and semantics of the
   Feature-Caps header field for different SIP message types and
   response codes.  The usage and semantics of a specific SIP feature
   cap MUST be described in the associated SIP feature cap
   specification.

   NOTE: Future specifications can define usage and semantics of the

Holmberg, et al.        Expires November 10, 2012              [Page 11]
Internet-Draft                proxy feature                     May 2012

   Feature-Caps header field for SIP methods, response codes and request
   types not specified in this specification.

   The Feature-Caps header field ABNF is defined in Section 6.3.1.

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 2xx response associated with such requests.

   If a SIP feature cap is inserted in a Feature-Caps header field of an
   initial request for a dialog, or within a response of such request,
   it indicates to the receivers of the request (or response) that the
   feature associated with the SIP feature cap is supported for the
   duration of the dialog, until a target refresh request is sent for
   the dialog, or the dialog is terminated.

   Unless a SIP feature cap is inserted in a Feature-Caps header field
   or a target refresh request, or within a response of such request, it
   indicates to the receivers of the request (or response) that the
   feature is no long supported for the dialog.

   For a given dialog a SIP entity MUST 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 can be used within a SIP REGISTER
   request, and within the 200 (OK) response associated with such
   request.

   If a SIP feature cap is conveyed in a Feature-Caps header field of a
   REGISTER request, or within an associated response, it indicates to
   the receivers of the message that the feature associated with the SIP
   feature cap is supported for the registration, until the registration
   of the contact that was explicitly conveyed in the REGISTER request
   expires, or until the registered contact is explicitly refreshed and
   the refresh REGISTER request does not contain the SIP feature cap
   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 contact(s) that were explicitly
   conveyed in the associated REGISTER request.

   This specification does not define any semantics for usage of the
   Feature-Caps header field in pure registration binding fetching

Holmberg, et al.        Expires November 10, 2012              [Page 12]
Internet-Draft                proxy feature                     May 2012

   messages (see Section 10.2.3 of RFC 3261), where the REGISTER request
   does not contain a Contact header field.  Unless such semantics is
   defined in a future extension, fetching messages will not have any
   impact on previously indicated support of features, and SIP entities
   MUST NOT insert a Feature-Caps header field to such messages.

   If SIP Outbound [RFC5626] is used, the rules above apply.  However,
   supported features only apply for the registration flow on which
   support has been explicitly indicated.

5.3.4.  SIP Stand-Alone Transactions

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

   If a SIP feature cap is inserted in a Feature-Caps header field of a
   standalone request, or within a response of such request, it
   indicates to the receivers of the request (or response) that the
   feature associated with the SIP feature cap is supported for the
   duration of the standalone transaction.

6.  Syntax

6.1.  General

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

6.2.  Syntax: SIP feature cap

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

6.2.2.  ABNF

   The ABNF for the SIP feature cap:

Holmberg, et al.        Expires November 10, 2012              [Page 13]
Internet-Draft                proxy feature                     May 2012

   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 RFC3840

   NOTE: In comparison with media feature tags, the "+" sign in front
   of the feature cap 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 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 the registration for the Feature-Caps header field:

   RFC Number: RFC XXX

   Header Field Name: Feature-Caps

7.2.  Global Feature Cap Registration Tree

   This specification creates a new SIP feature cap tree.  The name of
   the tree is "Global Feature Cap Registration Tree", and its leading

Holmberg, et al.        Expires November 10, 2012              [Page 14]
Internet-Draft                proxy feature                     May 2012

   facet is "g.".  It is used for the registration of SIP feature caps.

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

   Note that all SIP feature caps registered in the SIP tree will have
   names with a leading facet "g.".  No leading "+" is used in the
   registrations in any of the media feature tag trees.

7.3.  SIP Feature Cap Registration Tree

   This specification creates a new SIP feature cap tree, per the
   guidelines...  The name of the tree is "SIP Feature Cap Registration
   Tree", and its leading facet is "sip.".  It is used for the
   registration of SIP feature caps.

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

   Note that all SIP feature caps registered in the SIP tree will have
   names with a leading facet "sip.".  No leading "+" is used in the
   registrations in any of the media feature tag trees.

8.  Security Considerations

   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.

9.  Acknowledgements

10.  Change Log

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

   Changes from draft-ietf-sipcore-proxy-feature-01

Holmberg, et al.        Expires November 10, 2012              [Page 15]
Internet-Draft                proxy feature                     May 2012

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

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

Holmberg, et al.        Expires November 10, 2012              [Page 16]
Internet-Draft                proxy feature                     May 2012

11.2.  Informative References

   [RFC2506]  Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag
              Registration Procedure", BCP 31, RFC 2506, March 1999.

   [RFC3840]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
              "Indicating User Agent Capabilities in the Session
              Initiation Protocol (SIP)", RFC 3840, August 2004.

   [RFC3841]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
              Preferences for the Session Initiation Protocol (SIP)",
              RFC 3841, August 2004.

   [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

Holmberg, et al.        Expires November 10, 2012              [Page 17]
Internet-Draft                proxy feature                     May 2012

   Ivo Sedlacek
   Ericsson
   Scheelevaegen 19C
   Lund  22363
   Sweden

   Email: ivo.sedlacek@ericsson.com

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

   Email: hkaplan@acmepacket.com

Holmberg, et al.        Expires November 10, 2012              [Page 18]