draft-ietf-sipcore-proxy-feature-00.txt   draft-ietf-sipcore-proxy-feature-01.txt 
SIPCORE Working Group C. Holmberg SIPCORE Working Group C. Holmberg
Internet-Draft I. Sedlacek Internet-Draft I. Sedlacek
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: September 2, 2012 H. Kaplan Expires: October 19, 2012 H. Kaplan
Acme Packet Acme Packet
March 1, 2012 April 17, 2012
Indication of features supported by proxy Indication of features supported by proxy
draft-ietf-sipcore-proxy-feature-00.txt draft-ietf-sipcore-proxy-feature-01.txt
Abstract Abstract
This document defines a new SIP header field, Feature-Caps, that can This specification creates a new IANA registry, "SIP Feature Cap
be used by SIP entities to indicate support of features and 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 capabilities, in cases where the Contact header field contains a URI
that does not represent the SIP entity that wants to indicate support that does not represent the SIP entity that wants to indicate support
of its features and capabilities. 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 Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 2, 2012. This Internet-Draft will expire on October 19, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. User Agent (UA) Behavior . . . . . . . . . . . . . . . . . . . 3 4. SIP Feature Caps . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. B2BUA Behavior . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. Registrar Behavior . . . . . . . . . . . . . . . . . . . . 4 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5
5. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Feature-Caps Header Field Definition . . . . . . . . . . . . . 5 4.3. Registration Trees . . . . . . . . . . . . . . . . . . . . 6
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 6
6.2. SIP Dialog . . . . . . . . . . . . . . . . . . . . . . . . 5 4.3.2. Global Tree . . . . . . . . . . . . . . . . . . . . . 6
6.3. SIP Registration (REGISTER) . . . . . . . . . . . . . . . 6 4.3.3. SIP Feature Cap Registration Tree . . . . . . . . . . 7
6.4. SIP Stand-Alone Transactions . . . . . . . . . . . . . . . 6 4.4. Registration Template . . . . . . . . . . . . . . . . . . 7
6.5. SIP Capability Query (OPTIONS) . . . . . . . . . . . . . . 6 4.5. SIP Feature Cap Specification Requirements . . . . . . . . 9
7. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.5.1. General . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.5.2. Overall Description . . . . . . . . . . . . . . . . . 9
7.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.5.3. Feature Cap Values . . . . . . . . . . . . . . . . . . 9
8. Feature Tag Usage With Feature-Caps . . . . . . . . . . . . . 7 4.5.4. Usage Restrictions . . . . . . . . . . . . . . . . . . 10
9. Feature Tag Requirements . . . . . . . . . . . . . . . . . . . 7 4.5.5. Implementation Details . . . . . . . . . . . . . . . . 10
9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.5.6. Examples . . . . . . . . . . . . . . . . . . . . . . . 10
9.2. Overall Description . . . . . . . . . . . . . . . . . . . 8 5. Feature-Caps Header Field . . . . . . . . . . . . . . . . . . 10
9.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 11
9.4. Feature Tag Name . . . . . . . . . . . . . . . . . . . . . 8 5.2. User Agent and Proxy Behavior . . . . . . . . . . . . . . 11
9.5. Feature Tag Values . . . . . . . . . . . . . . . . . . . . 8 5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 11
9.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . . 8 5.2.2. B2BUA Behavior . . . . . . . . . . . . . . . . . . . . 12
9.7. Feature Tag Usage Restrictions . . . . . . . . . . . . . . 9 5.2.3. Registrar Behavior . . . . . . . . . . . . . . . . . . 12
9.8. Feature Tag Security Considerations . . . . . . . . . . . 9 5.2.4. Proxy behavior . . . . . . . . . . . . . . . . . . . . 12
9.9. Implementation Details . . . . . . . . . . . . . . . . . . 9 5.3. SIP Message Type and Response Code Semantics . . . . . . . 13
9.10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5.3.2. SIP Dialog . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Registration of the Feature-Caps header field . . . . . . 10 5.3.3. SIP Registration (REGISTER) . . . . . . . . . . . . . 14
11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5.3.4. SIP Stand-Alone Transactions . . . . . . . . . . . . . 14
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 5.4. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 14
13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.4.1. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 14
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
14.1. Normative References . . . . . . . . . . . . . . . . . . . 11 6.1. Registration of the Feature-Caps header field . . . . . . 15
14.2. Informative References . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
The Session Initiation Protocol (SIP) "Caller Preferences" extension, The Session Initiation Protocol (SIP) [RFC3261] "Caller Preferences"
defined in RFC 3840 [RFC3840], provides a mechanism that allows a SIP extension, defined in RFC 3840 [RFC3840], provides a mechanism that
message to convey information relating to the originator's features allows a SIP message to convey information relating to the
and capabilities, using the Contact header field. originator's features and capabilities, using the Contact header
field.
This document defines a new SIP header field, Feature-Caps, that can This specification creates a new IANA registry, "SIP Feature Cap
be used by SIP entities to indicate support of features and 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 capabilities, in cases where the Contact header field contains a URI
that does not represent the SIP entity that wants to indicate support that does not represent the SIP entity that wants to indicate support
of its features and capabilities. Such cases are: 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 proxy.
o - The SIP entity acts as a SIP registrar. o - The SIP entity acts as a SIP registrar.
o - The SIP entity acts as a B2BUA, where the Contact header field o - The SIP entity acts as a B2BUA, where the Contact header field
URI represents another SIP entity. 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 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
3. Definitions 3. Definitions
Downstream SIP entity: SIP entity in the direction towards which a Downstream SIP entity: SIP entity in the direction towards which a
SIP request is sent. SIP request is sent.
Upstream SIP entity: SIP entity in the direction from which a SIP Upstream SIP entity: SIP entity in the direction from which a SIP
request is received. request is received.
4. User Agent (UA) Behavior 4. SIP Feature Caps
4.1. General 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.
[ref-to-section] defines how SIP feature caps are conveyed using the
SIP Feature-Caps header 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 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 use of faceted names (e.g., names of the form "tree.feature-
name").
The tree definitions are based on the global tree and sip tree
defined for media feature tags, in RFC 2506 [RFC2506] and RFC 3841
[RFC3841].
Additional feature caps trees can be created by IANA, following the
same rules and procedures as defined for media feature tags in
section 3.1.4 of RFC 2506 [RFC2506].
The acceptance of the 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
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 cap global tree is based on 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.
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.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 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 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 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
order to insert a SIP feature cap, and whether entities are allowed
to indicate support of a feature in conjunction with another feature.
4.5.5. Implementation Details
The SIP feature cap specification SHOULD define the procedure
regarding how implementers shall implement and use the Feature Cap,
or refer to other locations where implementers can find that
information.
NOTE: Sometimes a SIP feature cap designer might choose to not reveal
the implementation details of a SIP feature cap. However, in order
to allow multiple implementations to support the SIP feature cap,
designers are strongly encouraged to provide the implementation
details.
4.5.6. 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 inserted 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 [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, 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 If the URI in a Contact header field of a request or response
represents a UA, the UA MUST NOT indicate supported features and represents a UA, the UA MUST NOT indicate supported features and
capabilities using a Feature-Caps header field within that request or capabilities using a Feature-Caps header field within that request or
response. response.
When a UA receives a SIP request, or response, that contains one or When a UA receives a SIP request, or response, that contains one or
more Feature-Caps header fields, the Feature Tags in the header field more Feature-Caps header fields, the Feature Caps in the header field
inform the UA is about the features supported by the entities that inform the UA is about the features supported by the entities that
inserted the header fields. Procedures how features are invoked are inserted the header fields. Procedures how features are invoked are
outside the scope of this specification, and MUST be described by outside the scope of this specification, and MUST be described by
individual Feature Tag specifications. individual Feature Cap specifications.
When the UA receives the SIP request or the response, the feature When the UA receives the SIP request or the response, the SIP feature
tags in the topmost Feature-Caps header field will represent the caps in the topmost Feature-Caps header field will represent the
supported features "closest" to the UA. supported features "closest" to the UA.
4.2. B2BUA Behavior 5.2.2. B2BUA Behavior
The procedures in this section applies to UAs that are part of The procedures in this section applies to UAs that are part of
B2BUAs, but where the URI in the Contact header field does not B2BUAs, but where the URI in the Contact header field does not
represent the UA, because the B2BUA is also acting as a proxy and represent the UA, because the B2BUA is also acting as a proxy and
inserts its URI e.g. in a Record-Route header field. inserts its URI e.g. in a Record-Route header field.
When a UA sends a SIP request, if the UA wants to indicate support of When a UA sends a SIP request, if the UA wants to indicate support of
features towards its downstream SIP entities, it adds a Feature-Caps features towards its downstream SIP entities, it adds a Feature-Caps
header field to the request, together with one or more Feature Tags header field to the request, together with one or more Feature Caps
associated with the supported features, before it forwards the associated with the supported features, before it forwards the
request. request.
If the SIP request is triggered by another SIP request that the B2BUA If the SIP request is triggered by another SIP request that the B2BUA
has received, the UA MAY forward those Feature-Caps header field by has received, the UA MAY forward those Feature-Caps header field by
copying them to the outgoing SIP request, similar to a SIP proxy, copying them to the outgoing SIP request, similar to a SIP proxy,
before it adds its own Feature-Caps header field to the SIP request. before it adds its own Feature-Caps header field to the SIP request.
When a UA receives a SIP response, if the UA wants to indicate When a UA receives a SIP response, if the UA wants to indicate
support of features towards its upstream SIP entities, it adds a support of features towards its upstream SIP entities, it adds a
Feature-Caps header field to the response, together with one or more Feature-Caps header field to the response, together with one or more
Feature Tags associated with the supported features, before it Feature Caps associated with the supported features, before it
forwards the response. forwards the response.
If the SIP response is triggered by another SIP response that the If the SIP response is triggered by another SIP response that the
B2BUA has received, the UA MAY forward those Feature-Caps header B2BUA has received, the UA MAY forward those Feature-Caps header
field by copying them to the outgoing SIP response, similar to a SIP field by copying them to the outgoing SIP response, similar to a SIP
proxy, before it adds its own Feature-Caps header field to the SIP proxy, before it adds its own Feature-Caps header field to the SIP
response. response.
4.3. Registrar Behavior 5.2.3. Registrar Behavior
If a SIP registrar wants to indicate support of features towards its If a SIP registrar wants to indicate support of features towards its
upstream SIP entities, it can insert a Feature-Caps header field, upstream SIP entities, it can insert a Feature-Caps header field,
together with Feature Tags associated with the supported features, in together with Feature Caps associated with the supported features, in
a REGISTER response. a REGISTER response.
5. Proxy behavior 5.2.4. Proxy behavior
When a proxy receives a SIP request, if the proxy wants to indicate When a SIP proxy receives a SIP request, if the proxy wants to
support of features towards its downstream SIP entities, it adds a indicate support of features towards its downstream SIP entities, it
Feature-Caps header field to the request, together with one or more adds a Feature-Caps header field to the request, together with one or
Feature Tags associated with the supported features, before it more SIP feature caps associated with the supported features, before
forwards the request. it forwards the request.
When a proxy adds a Feature-Caps header field to a SIP request, it When a proxy adds a Feature-Caps header field to a SIP message, it
MUST place the header field before any existing Feature-Caps header MUST place the header field before any existing Feature-Caps header
field in the request. fields in the request.
When a proxy receives a SIP response, if the proxy wants to indicate When a proxy receives a SIP response, if the proxy wants to indicate
support of features towards its upstream SIP entities, it adds a support of features towards its upstream SIP entities, it adds a
Feature-Caps header field to the response, together with one or more Feature-Caps header field to the response, together with one or more
Feature Tags associated with the supported features, before it SIP feature caps associated with the supported features, before it
forwards the response. forwards the response.
When a proxy adds a Feature-Caps header field to a SIP response, it When a proxy adds a Feature-Caps header field to a SIP response, it
MUST place the header field before any existing Feature-Caps header MUST place the header field before any existing Feature-Caps header
field in the response. field in the response.
6. Feature-Caps Header Field Definition 5.3. SIP Message Type and Response Code Semantics
6.1. General 5.3.1. General
This section describes how the Feature-Caps header field is used, and This section describes the general usage and semantics of the
the associated semantics, with different SIP methods and response Feature-Caps header field for different SIP message types and
codes. response codes. The usage and semantics of a specific SIP feature
cap MUST be described in the associated SIP feature cap
specification.
NOTE: Future specification can define usage semantics of the Feature- NOTE: Future specifications can define usage and semantics of the
Caps header fields for SIP methods, response codes and request types Feature-Caps header field for SIP methods, response codes and request
not specified in this specification. types not specified in this specification.
6.2. SIP Dialog 5.3.2. SIP Dialog
The Feature-Caps header field can be used within an initial SIP The Feature-Caps header field can be used within an initial SIP
request for a dialog, within a target refresh SIP request, and within request for a dialog, within a target refresh SIP request, and within
any 18x or 2xx response associated with such requests. any 18x or 2xx response associated with such requests.
If a Feature Tag is inserted in a Feature-Caps header field of such If a SIP feature cap is inserted in a Feature-Caps header field of an
request or such response, the feature associated with the Feature Tag initial request for a dialog, or within a response of such request,
MUST be supported for the dialog, until the next time the dialog it indicates to the receivers of the request (or response) that the
target is refreshed, or the dialog is terminated. feature associated with the SIP feature cap is supported for the
duration of the dialog, until a target refresh request is sent for
For a given dialog the entity MUST use the same Feature-Caps header the dialog, or the dialog is terminated.
field value (if included) in all 18x and 2xx responses for the same
transaction.
6.3. SIP Registration (REGISTER)
The Feature-Caps header field can be used within a SIP REGISTER
request, and within the 200 (OK) response of such request.
If a Feature Tag is inserted in a Feature-Caps header field of a SIP Unless a SIP feature cap is inserted in a Feature-Caps header field
REGISTER request or response, the feature associated with the Feature or a target refresh request, or within a response of such request, it
Tag MUST be supported for the registration, and all SIP transactions indicates to the receivers of the request (or response) that the
associated with the registration, until the registration is re- feature is no long supported for the dialog.
freshed or terminated.
6.4. SIP Stand-Alone Transactions 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.
The Feature-Caps header field can be used within an request for 5.3.3. SIP Registration (REGISTER)
standalone SIP transaction, and within any 18x or 2xx response
associated with such request.
If a Feature Tag is inserted in a Feature-Caps header field of an The Feature-Caps header field can be used within a SIP REGISTER
request or response for a standalone transaction, the feature request, and within the 200 (OK) response associated with such
associated with the Feature Tag MUST be supported for the duration of request.
the standalone transaction.
6.5. SIP Capability Query (OPTIONS) If a SIP feature cap is inserted in a Feature-Caps header 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 SIP feature cap is supported for the
duration of the registration, and for all SIP transactions associated
with the registration, until the registration is re-freshed or
terminated.
7. Syntax 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 receivers of the request (or response) that the
feature is no long supported for the registration.
7.1. General 5.3.4. SIP Stand-Alone Transactions
Each value of a Feature-Caps header field MUST contain a "*" value, The Feature-Caps header field can be used within a standalone SIP
followed by one or more Feature Tags, associated with the supported request, and within any 18x or 2xx response associated with such
features, separated by semicolon (";"). request.
NOTE: A "*" value means that no information regarding which proxy, or If a SIP feature cap is inserted in a Feature-Caps header field of a
domain, that support the features associated with the Feature Tags, standalone request, or within a response of such request, it
is provided. 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.
NOTE: When used in a Contact header field, a "*" value has an "any 5.4. Syntax
URI" meaning. When used in a Feature-Caps header field, it simply
means that no URI information is provided.
7.2. ABNF 5.4.1. ABNF
The ABNF for the Feature-Caps header fields is: The ABNF for the Feature-Caps header fields is:
Feature-Caps = ("Feature-Caps" / "fc") HCOLON fc-value Feature-Caps = ("Feature-Caps" / "fc") HCOLON fc-value
*(COMMA fc-value) *(COMMA fc-value)
fc-value = "*" *(SEMI feature-param) fc-value = "*" *(SEMI feature-cap)
;;feature-param from RFC 3840
Figure 1: ABNF
8. Feature Tag Usage With Feature-Caps
Feature tags inserted in a Feature-Caps header field indicate that
the SIP entity that inserted the header field supports the associated
features.
In order to use a Feature Tag in a Feature-Caps header field, the
Feature Tag specification MUST specify the semantics of the feature
tag when inserted in the Feature-Caps header field. Unless the
feature specification defines such semantics, a the Feature Tag MUST
NOT be used in a Feature-Caps header field.
Within a given Feature-Caps header field, Feature Tags are listed in
a non-priority order, and for a given header field 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 the
"foo" and "bar" Feature Tags.
9. Feature Tag Requirements
9.1. General
This section provides guidance on how to define an Feature Tag, and
what information needs to exist in an Feature Tag specification.
It is bad practice for Feature Tag specifications to repeat
procedures defined in this document, unless needed for clarification
or emphasis purpose.
Feature Tag specifications MUST NOT weaken any behavior designated
with "SHOULD" or "MUST" in this specification. However, Feature Tags
specifications MAY strengthen "SHOULD", "MAY", or "RECOMMENDED"
requirements to "MUST" strength if features associated with the
Feature Tag require it.
Feature Tag specifications MUST address the issues defined in the
following subsections, or document why an issue is not applicable for
the specific Feature Tag.
9.2. Overall Description
The Feature Tag specification MUST contain an overall description of
the Feature Tag: a description of the feature associated with the
Feature Tag, and a description what information is carried in
associated Feature Tag values (if any).
9.3. Applicability
The Feature Tag specification MUST describe why the support of the
feature can not be indicated in a SIP Contact header field [RFC3261],
using the mechanism defined in RFC 3840. The reason is either that
the entity inserting the Feature Tag is acting as a SIP proxy, or SIP
registrar, or a B2BUA but is not represented by the URI in the
Contact header field.
9.4. Feature Tag Name
The Feature Tag specification MUST define an Feature Tag name, which
entities use as a header field value to identify the Feature Tag in
the 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,
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 the syntax and semantics of
the values associated with the Feature Tag. In addition, the
specification MUST define whether there are restrictions regarding
the usage of specific values.
Feature Tags can share value defined for other Feature Tags, but the
value is Feature Tag specific, and the value semantics MUST be
defined for each Feature Tag tag uses the value.
9.6. SIP Option Tags
The Feature Tag specification MAY define SIP option tags, which 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 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, and whether entities are allowed to insert Feature Tags
togheter with other Feature Tags.
9.8. Feature Tag Security Considerations
If the information carried in a Feature Tag requires a certain level
of security, the Feature Tag specification MUST describe the
mechanisms 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 the underlying SIP protocol provides, this
MUST be stated in the Feature Tag specification.
9.9. Implementation Details
It is strongly RECOMMENDED that the Feature Tag specification defines
the procedure regarding how implementors shall implement and use the
Feature Tag, or refer to other locations where implementors can find
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 support the Feature Tag, Feature Tag designers are
strongly encouraged to provide the implementation details.
9.10. Examples
It is RECOMMENDED that the Feature Tag specification provide Figure 3: ABNF
demonstrative message flow diagrams, paired with complete messages
and message descriptions.
Note that example flows are by definition informative, and do not NOTE: A "*" value means that no information regarding which SIP
replace normative text. entity, or domain, that indicate support of features is provided.
10. IANA Considerations 6. IANA Considerations
10.1. Registration of the Feature-Caps header field 6.1. Registration of the Feature-Caps header field
This specification registers a new SIP header field, Feature-Caps, This specification registers a new SIP header field, Feature-Caps,
according to the process of RFC 3261 [RFC3261]. according to the process of RFC 3261 [RFC3261].
The following is the registration for the Feature-Caps header field: The following is the registration for the Feature-Caps header field:
RFC Number: RFC XXX RFC Number: RFC XXX
Header Field Name: Feature-Caps Header Field Name: Feature-Caps Header Field Name: Feature-Caps
Compact Form: fc Compact Form: fc
11. Security Considerations 7. Security Considerations
Feature tags can provide sensitive information about a SIP entity. SIP feature caps can provide sensitive information about a SIP
RFC 3840 cautions against providing sensitive information to another entity. RFC 3840 cautions against providing sensitive information to
party. Once this information is given out, any use may be made of another party. Once this information is given out, any use may be
it. made of it.
12. Acknowledgements 8. Acknowledgements
13. Change Log 9. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing] [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 Changes from draft-holmberg-sipcore-proxy-feature-03
o Hadriel Kaplan added as co-author. o Hadriel Kaplan added as co-author.
o Terminology change: instead of talking of proxies, talk about o Terminology change: instead of talking of proxies, talk about
entities which are not represented by the URI in a Contact header entities which are not represented by the URI in a Contact header
field (http://www.ietf.org/mail-archive/web/sipcore/current/ field (http://www.ietf.org/mail-archive/web/sipcore/current/
msg04449.html). msg04449.html).
o Clarification regarding the usage of the header field in 18x/2xx o Clarification regarding the usage of the header field in 18x/2xx
responses (http://www.ietf.org/mail-archive/web/sipcore/current/ responses (http://www.ietf.org/mail-archive/web/sipcore/current/
msg04449.html). msg04449.html).
o Specifying that feature support can also be indicated in target o Specifying that feature support can also be indicated in target
refresh requests (http://www.ietf.org/mail-archive/web/sipcore/ refresh requests (http://www.ietf.org/mail-archive/web/sipcore/
current/msg04454.html). current/msg04454.html).
o Feature Tag specification registration information added. o Feature Cap specification registration information added.
Changes from draft-holmberg-sipcore-proxy-feature-02 Changes from draft-holmberg-sipcore-proxy-feature-02
o Definition, and usage of, a new header field, instead of Path, o Definition, and usage of, a new header field, instead of Path,
Record-Route, Route and Service-Route. Record-Route, Route and Service-Route.
Changes from draft-holmberg-sipcore-proxy-feature-01 Changes from draft-holmberg-sipcore-proxy-feature-01
o Requirement section added o Requirement section added
o Use-cases and examples updated based on work in 3GPP o Use-cases and examples updated based on work in 3GPP
Changes from draft-holmberg-sipcore-proxy-feature-00 Changes from draft-holmberg-sipcore-proxy-feature-00
o Additional use-cases added o Additional use-cases added
o Direction section added o Direction section added
14. References 10. References
14.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. 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, [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session "Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004. Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
for the Session Initiation Protocol (SIP) and the Real- Preferences for the Session Initiation Protocol (SIP)",
time Applications and Infrastructure Area", BCP 67, RFC 3841, August 2004.
RFC 5727, March 2010.
14.2. Informative References [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[3GPP.23.237] [3GPP.23.237]
3GPP, "IP Multimedia Subsystem (IMS) Service Continuity; 3GPP, "IP Multimedia Subsystem (IMS) Service Continuity;
Stage 2", 3GPP TS 23.237 10.8.0, December 2011. Stage 2", 3GPP TS 23.237 10.9.0, March 2012.
[3GPP.24.837] [3GPP.24.837]
3GPP, "IP Multimedia (IM) Core Network (CN) subsystem 3GPP, "IP Multimedia (IM) Core Network (CN) subsystem
inter-UE transfer enhancements; Stage 3", 3GPP TR 24.837 inter-UE transfer enhancements; Stage 3", 3GPP TR 24.837
10.0.0, April 2011. 10.0.0, April 2011.
Authors' Addresses Authors' Addresses
Christer Holmberg Christer Holmberg
Ericsson Ericsson
 End of changes. 62 change blocks. 
273 lines changed or deleted 483 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/