draft-ietf-sipcore-proxy-feature-04.txt   draft-ietf-sipcore-proxy-feature-05.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: December 16, 2012 H. Kaplan Expires: February 9, 2013 H. Kaplan
Acme Packet Acme Packet
June 14, 2012 August 8, 2012
Mechanism to indicate support of features and capabilities in the Mechanism to indicate support of features and capabilities in the
Session Initiation Protocol (SIP) Session Initiation Protocol (SIP)
draft-ietf-sipcore-proxy-feature-04.txt draft-ietf-sipcore-proxy-feature-05.txt
Abstract Abstract
This specification creates a new IANA registry, "Proxy-Feature This specification defines a new SIP header field, Feature-Caps, to
Feature Caps Trees", for registering "feature caps", which are used convey feature capability indicators, which are used by SIP entities
by SIP entities not represented by the URI of the Contact header not represented by the URI of the Contact header field to indicate
field to indicate support of features and capabilities, where media support of features and capabilities, where media feature tags cannot
feature tags cannot be used to indicate the support. be used to indicate the support.
This specification also defines a new SIP header field, Feature-Caps, This specification also defines feature capability indicators, and
to convey feature caps in SIP messages. creates a new IANA registry, "Proxy-Feature Feature Capability
Indicator Trees", for registering feature capability indicators.
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 December 16, 2012. This Internet-Draft will expire on February 9, 2013.
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
skipping to change at page 2, line 16 skipping to change at page 2, line 17
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Feature Caps . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Feature-Caps Header Field . . . . . . . . . . . . . . . . . . 4
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Registration Trees . . . . . . . . . . . . . . . . . . . . 5 4.2. User Agent and Proxy Behavior . . . . . . . . . . . . . . 5
4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5
4.2.2. Global Tree . . . . . . . . . . . . . . . . . . . . . 5 4.2.2. B2BUA Behavior . . . . . . . . . . . . . . . . . . . . 6
4.2.3. SIP Tree . . . . . . . . . . . . . . . . . . . . . . . 6 4.2.3. Registrar Behavior . . . . . . . . . . . . . . . . . . 6
4.3. Registration Template . . . . . . . . . . . . . . . . . . 6 4.2.4. Proxy behavior . . . . . . . . . . . . . . . . . . . . 6
4.4. Feature Cap Specification Requirements . . . . . . . . . . 8 4.3. SIP Message Type and Response Code Semantics . . . . . . . 7
4.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 8 4.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 7
4.4.2. Overall Description . . . . . . . . . . . . . . . . . 8 4.3.2. SIP Dialog . . . . . . . . . . . . . . . . . . . . . . 7
4.4.3. Feature Cap Values . . . . . . . . . . . . . . . . . . 8 4.3.3. SIP Registration (REGISTER) . . . . . . . . . . . . . 7
4.4.4. Usage Restrictions . . . . . . . . . . . . . . . . . . 9 4.3.4. SIP Stand-Alone Transactions . . . . . . . . . . . . . 8
4.4.5. Examples . . . . . . . . . . . . . . . . . . . . . . . 9 5. Feature Capability Indicators . . . . . . . . . . . . . . . . 8
5. Feature-Caps Header Field . . . . . . . . . . . . . . . . . . 9 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Registration Trees . . . . . . . . . . . . . . . . . . . . 9
5.2. User Agent and Proxy Behavior . . . . . . . . . . . . . . 10 5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 9
5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 10 5.2.2. Global Tree . . . . . . . . . . . . . . . . . . . . . 9
5.2.2. B2BUA Behavior . . . . . . . . . . . . . . . . . . . . 10 5.2.3. SIP Tree . . . . . . . . . . . . . . . . . . . . . . . 10
5.2.3. Registrar Behavior . . . . . . . . . . . . . . . . . . 11 5.3. Feature Capability Indicator Specification Requirements . 10
5.2.4. Proxy behavior . . . . . . . . . . . . . . . . . . . . 11 5.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. SIP Message Type and Response Code Semantics . . . . . . . 11 5.3.2. Overall Description . . . . . . . . . . . . . . . . . 11
5.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 11 5.3.3. Feature Capability Indicator Values . . . . . . . . . 11
5.3.2. SIP Dialog . . . . . . . . . . . . . . . . . . . . . . 12 5.3.4. Usage Restrictions . . . . . . . . . . . . . . . . . . 11
5.3.3. SIP Registration (REGISTER) . . . . . . . . . . . . . 12 5.3.5. Examples . . . . . . . . . . . . . . . . . . . . . . . 12
5.3.4. SIP Stand-Alone Transactions . . . . . . . . . . . . . 13 6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Syntax: Feature-Caps header field . . . . . . . . . . . . 12
6.2. Syntax: feature cap . . . . . . . . . . . . . . . . . . . 13 6.2.1. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 13 6.3. Syntax: feature capability indicator . . . . . . . . . . . 12
6.2.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 12
6.3. Syntax: Feature-Caps header field . . . . . . . . . . . . 14 6.3.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.3.1. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7.1. Registration of the Feature-Caps header field . . . . . . 13
7.1. Registration of the Feature-Caps header field . . . . . . 14 7.2. Registration of the Feature-Caps header field parameter . 13
7.2. Proxy-Feature Feature Caps Trees . . . . . . . . . . . . . 15 7.3. Proxy-Feature Feature Capability Indicator Trees . . . . . 14
7.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 15 7.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 14
7.2.2. Global Feature Cap Registration Tree . . . . . . . . . 15 7.3.2. Global Feature Capability Indicator Registration
7.2.3. SIP Feature Cap Registration Tree . . . . . . . . . . 15 Tree . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7.3.3. SIP Feature Capability Indicator Registration Tree . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 8. Feature Capability Indicator Registration Template . . . . . . 15
10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 17 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18
12.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
The Session Initiation Protocol (SIP) [RFC3261] "Caller Preferences" The Session Initiation Protocol (SIP) [RFC3261] "Caller Preferences"
extension, defined in RFC 3840 [RFC3840], provides a mechanism that extension, defined in RFC 3840 [RFC3840], provides a mechanism that
allows a SIP message to convey information relating to the allows a SIP message to convey information relating to the
originator's features and capabilities, using the Contact header originator's features and capabilities, using the Contact header
field. field.
This specification creates a new IANA registry, "Proxy-Feature This specification defines a new SIP header field, Feature-Caps, to
Feature Caps Trees", for registering "feature caps", which are used convey feature capability indicators, which are used by SIP entities
by SIP entities not represented by the URI of the Contact header not represented by the URI of the Contact header field to indicate
field to indicate support of features and capabilities, where media support of features and capabilities, where media feature tags cannot
feature tags cannot be used to indicate the support. Such cases are: 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, NOTE: Unlike media feature tags, feature capability indicators are
to convey feature caps in SIP messages. intended to only be used with the SIP protocol.
NOTE: Unlike media feature tags, feature caps are intended to only be This specification also defines feature capability indicators, and
used with the SIP protocol. creates a new IANA registry, "Proxy-Feature Feature Capability
Indicator Trees", for registering feature capability indicators.
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. Feature Caps 4. Feature-Caps Header Field
4.1. Introduction 4.1. Introduction
Feature caps are used by SIP entities not represented by the URI of The Feature-Caps header field is used by SIP entities to convey
the Contact header field to indicate support of features and support of features and capabilities, by setting feature capability
capabilities, where media feature tags cannot be used to indicate the indicators. A feature capability indicator conveyed in a Feature-
support. Caps header field indicates that a SIP entity in the SIP message
signalling path supports the associated feature and capability.
A value, or a list of values, that provides additional information
about the supported feature or capability, can be associated with a
feature cap.
Section 5 defines how feature caps are conveyed using the Feature-
Caps header field.
The feature cap ABNF is defined in Section 6.2.2. For a given fc-value, as defined in section 5.3.1, feature capability
indicators are listed in a non-priority order, and any order of the
listed SIP feature capability indicators 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 capability indicator supports
the features and capabilities associated with the "foo" and "bar"
feature capability indicators.
4.2. Registration Trees 4.2. User Agent and Proxy Behavior
4.2.1. General 4.2.1. General
The following subsections define registration trees, distinguished by If the URI in a Contact header field of a request or response
the use of faceted names (e.g., names of the form "tree.feature- represents a SIP entity, the entity MUST NOT indicate supported
name"). The registration trees are defined in the IANA "Proxy- features and capabilities using a Feature-Caps header field within
Feature Feature Caps Trees" registry. that request or response.
The trees defined herein are similar to the global tree and sip tree
defined for media feature tags, in RFC 2506 [RFC2506] and RFC 3840
[RFC3840]. Other registration trees are outside the scope of this
specification.
NOTE: In contrast to RFC 2506 and RFC 3840, this specification only
defines a global tree and a sip tree, as they are the only trees
defined in those RFCs that have been used for defining SIP-specific
media feature tags.
When a feature cap is registered in any registration tree, no leading
"+" is used in the registration.
4.2.2. Global Tree
The global feature cap tree is similar to the media feature tag
global tree defined in RFC 2506 [RFC2506].
A 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 feature cap meets the technical requirements of this
specification.
A 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 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 feature cap, and
consult with members of related mailing lists.
4.2.3. SIP Tree
The sip feature cap tree is similar to the media feature tag sip tree
defined in RFC 3840 [RFC3840].
A feature cap in the sip tree will be distinguished by the leading
facet "sip.".
When a 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 feature cap, MUST be
published.
4.3. Registration Template
To: sip-feature-caps@apps.ietf.org (feature caps mailing list)
Subject: Registration of feature cap XXXX
| Instructions are preceded by '|'. Some fields are optional.
Feature cap name:
Summary of feature indicated by this feature cap:
| The summary should be no longer than 4 lines. More
| detailed information can be provided in the SIP feature
| cap specification.
Feature cap specification reference:
| The referenced specification MUST contain the information
| listed in section XX of XXXX (IANA: Replace XXXX with
| assigned RFC number of this specification.
Values appropriate for use with this feature cap:
| If no values are defined for the feature cap,
| indicate "N/A". Details about feature cap values
| MUST be defined in the feature cap specification.
The feature cap is intended primarily for
use in the following applications, protocols,
services, or negotiation mechanisms: [optional]
| For applications, also specify the number of the
| first version which will use the feature cap,
| if applicable.
Examples of typical use: [optional]
Considerations particular to use in individual
applications, protocols, services, or negotiation
mechanisms: [optional]
Interoperability considerations: [optional]
Security considerations:
Privacy concerns, related to exposure of personal
information:
Denial of service concerns related to consequences
of specifying incorrect values:
Other:
Additional information: [optional]
Keywords: [optional]
Related feature caps: [optional]
Name(s) & email address(es) of person(s) to
contact for further information:
Intended usage:
| one of COMMON, LIMITED USE or OBSOLETE
Author/Change controller:
Other information: [optional]
| Any other information that the author deems
| interesting may be added here.
Figure 1: Registration Template
4.4. Feature Cap Specification Requirements
4.4.1. General
A feature cap specification MUST address the issues defined in the
following subsections, or document why an issue is not applicable for
the specific feature cap. A reference to the specification MUST be
provided when the feature cap is registered with IANA (see
Section 4.3).
It is bad practice for feature cap specifications to repeat
procedures (e.g. general procedures on the usage of the Feature-Caps
header field and feature caps) defined in this specification, unless
needed for clarification or emphasis purpose.
A feature cap specification MUST NOT weaken any behavior designated
with "SHOULD" or "MUST" in this specification. However, a
specification MAY strengthen "SHOULD", "MAY", or "RECOMMENDED"
requirements to "MUST" strength if features and capabilities
associated with the SIP feature cap require it.
4.4.2. Overall Description
The feature cap specification MUST contain an overall description of
the feature cap: how it is used to indicate support of a feature, a
description of the feature associated with the SIP feature cap, a
description of any additional information (conveyed using one or more
feature cap values) that can be conveyed together with the feature
cap, and a description of how the associated feature may be
exercised/invoked.
4.4.3. Feature Cap Values
A feature cap can have an associated value, or a list of values.
The feature cap specification MUST define the syntax and semantics of
any value defined for the feature cap, including possible
restrictions related to the usage of a specific value. The feature
cap specification MUST define the value(s) in accordance with the
syntax defined in section 6.2.2.
A feature cap value is only applicable for the feature cap for which
it has been defined. For other feature caps, the value has to be
defined explicitly, even if the semantics are identical.
It is STRONGLY RECOMMENDED to not re-use a value that already has
been defined for another feature cap, unless the semantics of the
values are the same.
4.4.4. Usage Restrictions
If there are restrictions on how SIP entities can insert a SIP
feature cap, the feature cap specification MUST document such
restrictions.
There might be restrictions related to whether entities are allowed
to insert a feature cap in registration related messages, standalone
transaction messages, or dialog related messages, whether entities
are allowed to insert a feature cap in requests or responses, whether
entities also need to support other features and capabilities in
order to insert a 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 feature cap specification provide
demonstrative message flow diagrams, paired with complete messages
and message descriptions.
Note that example message flows are by definition informative, and do
not replace normative text.
5. Feature-Caps Header Field
5.1. Introduction
The Feature-Caps header field is used by SIP entities to convey When a SIP entity receives a SIP request, or response, that contains
support of features and capabilities, by setting feature caps. one or more Feature-Caps header fields, the feature capability
Feature caps conveyed in a Feature-Caps header field indicate that indicators in the header field inform the entity about the features
the SIP entity that inserted the header field supports the associated and capabilities supported by entities in the SIP message signalling
features and capabilities. path. Procedures how features and capabilities are invoked are
outside the scope of this specification, and MUST be described by
individual feature capability indicator specifications.
NOTE: It is not possible to, as a Feature-Caps header field value, NOTE: It is not possible to, as a Feature-Caps header field value,
convey the address of the SIP entity that inserted the Feature-Caps convey the address of the SIP entity that inserted the Feature-Caps
header field. If additional data about a supported feature needs to header field. If additional data about a supported feature needs to
be conveyed, such as the address of the SIP entity that indicated be conveyed, such as the address of the SIP entity that indicated
support of the feature, then the feature definition needs to define a support of the feature, then the feature definition needs to define a
way to convey that information as a value of the associated feature way to convey that information as a value of the associated feature
cap. capability indicator.
The feature cap specification MUST specify for which SIP methods and
message types, and the associated semantics, the feature cap is
applicable. See Section 4 for more information. No semantics is
defined for feature caps present in SIP methods and message types not
covered by the associated feature cap specification.
Within a given Feature-Caps header field, 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 and
capabilities associated with the "foo" and "bar" 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 feature caps in the
header field inform the entity about the features and capabilities
supported by the entities that inserted the header fields.
Procedures how features and capabilities are invoked are outside the
scope of this specification, and MUST be described by individual
feature cap specifications.
When a SIP entity adds a Feature-Caps header field to a SIP message, 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 it MUST place the header field before any existing Feature-Caps
header field in the message to be forwarded, so that the added header header field in the message to be forwarded, so that the added header
field becomes the top-most one. Then, when another SIP entity field becomes the top-most one. Then, when another SIP entity
receives a SIP request or the response, the SIP feature caps in the receives a SIP request or the response, the SIP feature capability
top-most Feature-Caps header field will represent the supported indicators in the top-most Feature-Caps header field will represent
features and capabilities "closest" to the entity. the supported features and capabilities "closest" to the entity.
5.2.2. B2BUA Behavior 4.2.2. B2BUA Behavior
The procedures in this Section applies to UAs that are part of B2BUAs 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 that are referenced in the message by a Record-Route header field
rather than by the URI of the Contact 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 When a UA sends a SIP request, if the UA wants to indicate support of
features and capabilities towards its downstream SIP entities, it features and capabilities towards its downstream SIP entities, it
inserts a Feature-Caps header field to the request, containing one or inserts a Feature-Caps header field to the request, containing one or
more feature caps associated with the supported features and more feature capability indicators associated with the supported
capabilities, before it forwards the request. features and capabilities, before it forwards the 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 received Feature-Caps header fields has received, the UA MAY forward received Feature-Caps header fields
by copying them to the outgoing SIP request, similar to a SIP proxy, 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 before it inserts its own Feature-Caps header field to the SIP
request. 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 and capabilities towards its upstream SIP support of features and capabilities towards its upstream SIP
entities, it inserts a Feature-Caps header field to the response, entities, it inserts a Feature-Caps header field to the response,
containing one or more feature caps associated with the supported containing one or more feature capability indicators associated with
features and capabilities, before it forwards the response. the supported features and capabilities, before it 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 received Feature-Caps header B2BUA has received, the UA MAY forward received 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 inserts its own Feature-Caps header field to the SIP proxy, before it inserts its own Feature-Caps header field to the SIP
response. response.
5.2.3. Registrar Behavior 4.2.3. Registrar Behavior
If a SIP registrar wants to indicate support of features and If a SIP registrar wants to indicate support of features and
capabilities towards its upstream SIP entities, it inserts a Feature- capabilities towards its upstream SIP entities, it inserts a Feature-
Caps header field, containing one or more feature caps associated Caps header field, containing one or more feature capability
with the supported features and capabilities, to a REGISTER response. indicators associated with the supported features and capabilities,
to a REGISTER response.
5.2.4. Proxy behavior 4.2.4. Proxy behavior
When a SIP proxy receives a SIP request, if the proxy wants to When a SIP proxy receives a SIP request, if the proxy wants to
indicate support of features and capabilities towards its downstream indicate support of features and capabilities towards its downstream
SIP entities, it inserts a Feature-Caps header field to the request, SIP entities, it inserts a Feature-Caps header field to the request,
containing one or more SIP feature caps associated with the supported containing one or more SIP feature capability indicators associated
features and capabilities, before it forwards the request. with the supported features and capabilities, before it forwards 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 and capabilities towards its upstream SIP support of features and capabilities towards its upstream SIP
entities, it inserts a Feature-Caps header field to the response, entities, it inserts a Feature-Caps header field to the response,
containing one or more SIP feature caps associated with the supported containing one or more SIP feature capability indicators associated
features and capabilities, before it forwards the response. with the supported features and capabilities, before it forwards the
response.
5.3. SIP Message Type and Response Code Semantics 4.3. SIP Message Type and Response Code Semantics
5.3.1. General 4.3.1. General
This Section describes the general usage and semantics of the This Section describes the general usage and semantics of the
Feature-Caps header field for different SIP message types and Feature-Caps header field for different SIP message types and
response codes. The usage and semantics of a specific feature cap response codes.
MUST be described in the associated feature cap specification.
NOTE: Future specifications can define usage and semantics of the NOTE: Future specifications can define usage and semantics of the
Feature-Caps header field for SIP methods, response codes and request Feature-Caps header field for SIP methods, response codes and request
types not specified in this specification. types not specified in this specification.
The Feature-Caps header field ABNF is defined in Section 6.3.1. Section 6.2.1 defines the Feature-Caps header field ABNF.
5.3.2. SIP Dialog 4.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 cap is inserted in a Feature-Caps header field of an If a feature capability indicator is inserted in a Feature-Caps
initial request for a dialog, or within a response of such request, header field of an initial request for a dialog, or within a response
it indicates to the receivers of the request (or response) that the of such request, it indicates to the receivers of the request (or
feature associated with the feature cap is supported for the duration response) that the feature associated with the feature capability
of the dialog, until a target refresh request is sent for the dialog, indicator is supported for the duration of the dialog, until a target
or the dialog is terminated. refresh request is sent for the dialog, or the dialog is terminated.
Unless a feature cap is inserted in a Feature-Caps header field or a Unless a feature capability indicator is inserted in a Feature-Caps
target refresh request, or within a response of such request, it header field or a target refresh request, or within a response of
indicates to the receivers of the request (or response) that the such request, it indicates to the receivers of the request (or
feature is no long supported for the dialog. response) that the feature is no long supported for the dialog.
For a given dialog a SIP entity MUST insert the same feature caps in For a given dialog a SIP entity MUST insert the same feature
all 18x and 2xx responses associated with a given transaction. capability indicators in all 18x and 2xx responses associated with a
given transaction.
5.3.3. SIP Registration (REGISTER) 4.3.3. SIP Registration (REGISTER)
The Feature-Caps header field can be used within a SIP REGISTER The Feature-Caps header field can be used within a SIP REGISTER
request, and within the 200 (OK) response associated with such request, and within the 200 (OK) response associated with such
request. request.
If a feature cap is conveyed in a Feature-Caps header field of a If a feature capability indicator is conveyed in a Feature-Caps
REGISTER request, or within an associated response, it indicates to header field of a REGISTER request, or within an associated response,
the receivers of the message that the feature associated with the it indicates to the receivers of the message that the feature
feature cap is supported for the registration, until the registration associated with the feature capability indicator is supported for the
of the contact that was explicitly conveyed in the REGISTER request registration, until the registration of the contact that was
expires, or until the registered contact is explicitly refreshed and explicitly conveyed in the REGISTER request expires, or until the
the refresh REGISTER request does not contain the feature cap registered contact is explicitly refreshed and the refresh REGISTER
associated with the feature. request does not contain the feature capability indicator associated
with the feature.
NOTE: While a REGISTER response can contain contacts that have been NOTE: While a REGISTER response can contain contacts that have been
registered as part of other registration transactions, support of any registered as part of other registration transactions, support of any
indicated feature only applies to the contact(s) that were explicitly indicated feature only applies to the contact(s) that were explicitly
conveyed in the associated REGISTER request. conveyed in the associated REGISTER request.
This specification does not define any semantics for usage of the This specification does not define any semantics for usage of the
Feature-Caps header field in pure registration binding fetching Feature-Caps header field in pure registration binding fetching
messages (see Section 10.2.3 of RFC 3261), where the REGISTER request messages (see Section 10.2.3 of RFC 3261), where the REGISTER request
does not contain a Contact header field. Unless such semantics is does not contain a Contact header field. Unless such semantics is
defined in a future extension, fetching messages will not have any defined in a future extension, fetching messages will not have any
impact on previously indicated support of features and capabilities, impact on previously indicated support of features and capabilities,
and SIP entities MUST NOT insert a Feature-Caps header field to such and SIP entities MUST NOT insert a Feature-Caps header field to such
messages. messages.
If SIP Outbound [RFC5626] is used, the rules above apply. However, If SIP Outbound [RFC5626] is used, the rules above apply. However,
supported features and capabilities only apply for the registration supported features and capabilities only apply for the registration
flow on which support has been explicitly indicated. flow on which support has been explicitly indicated.
5.3.4. SIP Stand-Alone Transactions 4.3.4. SIP Stand-Alone Transactions
The Feature-Caps header field can be used within a standalone SIP The Feature-Caps header field can be used within a standalone SIP
request, and within any 18x or 2xx response associated with such request, and within any 18x or 2xx response associated with such
request. request.
If a feature cap is inserted in a Feature-Caps header field of a If a feature capability indicator is inserted in a Feature-Caps
standalone request, or within a response of such request, it header field of a standalone request, or within a response of such
indicates to the receivers of the request (or response) that the request, it indicates to the receivers of the request (or response)
feature associated with the feature cap is supported for the duration that the feature associated with the feature capability indicator is
of the standalone transaction. supported for the duration of the standalone transaction.
6. Syntax 5. Feature Capability Indicators
6.1. General 5.1. Introduction
This Section defines the ABNF for Feature-Caps, and for the Feature- Feature capability indicators are used by SIP entities not
Cap header field. represented by the URI of the Contact header field to indicate
support of features and capabilities, where media feature tags cannot
be used to indicate the support.
6.2. Syntax: feature cap A value, or a list of values, that provides additional information
about the supported feature or capability, can be associated with a
feature capability indicator.
6.2.1. General Section 4 defines how feature capability indicators are conveyed
using the Feature-Caps header field.
In a feature cap name (ABNF: fcap-name), dots can be used to Section 6.3.2 defines the feature capability indicator ABNF.
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 Section 8 provides a template for registering feature capability
indicators.
The ABNF for the feature cap: 5.2. Registration Trees
feature-cap = "+" fcap-name [EQUAL LDQUOT (fcap-value-list 5.2.1. General
/ fcap-string-value ) RDQUOT]
fcap-name = ftag-name
fcap-value-list = tag-value-list
fcap-string-value = string-value
;; ftag-name, tag-value-list, string-value defined in RFC 3840
NOTE: In comparison with media feature tags, the "+" sign in front The following subsections define registration trees, distinguished by
of the feature cap name is mandatory. the use of faceted names (e.g., names of the form "tree.feature-
name"). The registration trees are defined in the IANA "Proxy-
Feature Feature Capability Indicator Trees" registry.
Figure 2: ABNF The trees defined herein are similar to the global tree and sip tree
defined for media feature tags, in RFC 2506 [RFC2506] and RFC 3840
[RFC3840]. Other registration trees are outside the scope of this
specification.
6.3. Syntax: Feature-Caps header field NOTE: In contrast to RFC 2506 and RFC 3840, this specification only
defines a global tree and a sip tree, as they are the only trees
defined in those RFCs that have been used for defining SIP-specific
media feature tags.
6.3.1. ABNF When a feature capability indicator is registered in any registration
tree, no leading "+" is used in the registration.
5.2.2. Global Tree
The global feature capability indicator tree is similar to the media
feature tag global tree defined in RFC 2506 [RFC2506].
A feature capability indicator for the global tree will be registered
by the IANA after review by a designated expert. That review will
serve to ensure that the feature capability indicator meets the
technical requirements of this specification.
A feature capability indicator in the global tree will be
distinguished by the leading facet "g.". An organization can propose
either a designation indicative of the feature, (e.g., "g.blinktags")
or a faceted designation including the organization name (e.g.,
"g.organization.blinktags").
When a feature capability indicator 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 feature
capability indicator, and consult with members of related mailing
lists. This policy overrides the policy defined for registering new
header field parameters.
5.2.3. SIP Tree
The sip feature capability indicator tree is similar to the media
feature tag sip tree defined in RFC 3840 [RFC3840].
A feature capability indicator in the sip tree will be distinguished
by the leading facet "sip.".
When a feature capability indicator 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 feature
capability indicator, MUST be published. This policy overrides the
policy defined for registering new header field parameters.
5.3. Feature Capability Indicator Specification Requirements
5.3.1. General
A feature capability indicator specification MUST address the issues
defined in the following subsections, or document why an issue is not
applicable for the specific feature capability indicator. A
reference to the specification MUST be provided when the feature
capability indicator is registered with IANA (see Section 8).
It is bad practice for feature capability indicator specifications to
repeat procedures (e.g. general procedures on the usage of the
Feature-Caps header field and feature capability indicators) defined
in this specification, unless needed for clarification or emphasis
purpose. A feature capability indicator specification MUST NOT
modify the Feature-Caps header field rules and semantics defined in
Section 4.
A feature capability indicator specification MUST NOT weaken any
behavior designated with "SHOULD" or "MUST" in this specification.
However, a specification MAY strengthen "SHOULD", "MAY", or
"RECOMMENDED" requirements to "MUST" strength if features and
capabilities associated with the SIP feature capability indicator
require it.
5.3.2. Overall Description
The feature capability indicator specification MUST contain an
overall description of the feature capability indicator: how it is
used to indicate support of a feature, a description of the feature
associated with the SIP feature cap, a description of any additional
information (conveyed using one or more feature capability indicator
values) that can be conveyed together with the feature capability
indicator, and a description of how the associated feature may be
exercised/invoked.
5.3.3. Feature Capability Indicator Values
A feature capability indicator can have an associated value, or a
list of values.
The feature capability indicator specification MUST define the syntax
and semantics of any value defined for the feature capability
indicator, including possible restrictions related to the usage of a
specific value. The feature cap specification MUST define the
value(s) in accordance with the ABNF defined in Section 6.3.2.
A feature capability indicator value is only applicable for the
feature capability indicator for which it has been defined. For
other feature capability indicators, the value has to be defined
explicitly, even if the semantics are identical.
It is STRONGLY RECOMMENDED to not re-use a value that already has
been defined for another feature capability indicator, unless the
semantics of the values are the same.
5.3.4. Usage Restrictions
If there are restrictions on how SIP entities can insert a SIP
feature cap, the feature capability indicator specification MUST
document such restrictions.
There might be restrictions related to whether entities are allowed
to insert a feature capability indicator in registration related
messages, standalone transaction messages, or dialog related
messages, whether entities are allowed to insert a feature capability
indicator in requests or responses, whether entities also need to
support other features and capabilities in order to insert a feature
capability indicator, and whether entities are allowed to indicate
support of a feature in conjunction with another feature.
5.3.5. Examples
It is RECOMMENDED that the feature capability indicator specification
provide demonstrative message flow diagrams, paired with complete
messages and message descriptions.
Note that example message flows are by definition informative, and do
not replace normative text.
6. Syntax
6.1. General
This Section defines the ABNF for the Feature-Caps header field, and
for the feature capability indicators.
6.2. Syntax: Feature-Caps header field
6.2.1. ABNF
The ABNF for the Feature-Caps header fields is: The ABNF for the Feature-Caps header fields is:
Feature-Caps = "Feature-Caps" HCOLON fc-value Feature-Caps = "Feature-Caps" HCOLON fc-value
*(COMMA fc-value) *(COMMA fc-value)
fc-value = "*" *(SEMI feature-cap) fc-value = "*" *(SEMI feature-cap)
Figure 3: ABNF Figure 1: ABNF
NOTE: A "*" value means that no information regarding which SIP NOTE: A "*" value means that no information regarding which SIP
entity, or domain, that indicate support of features and capabilities entity, or domain, that indicate support of features and capabilities
is provided. is provided.
6.3. Syntax: feature capability indicator
6.3.1. General
In a feature capability indicator name (ABNF: fcap-name), dots can be
used to implement a SIP feature cap tree hierarchy (e.g.
tree.feature.subfeature). The description of usage of such tree
hierarchy must be described when registered.
6.3.2. ABNF
The ABNF for the feature capability indicator:
feature-cap = "+" fcap-name [EQUAL LDQUOT (fcap-value-list
/ fcap-string-value ) RDQUOT]
fcap-name = ftag-name
fcap-value-list = tag-value-list
fcap-string-value = string-value
;; ftag-name, tag-value-list, string-value defined in RFC 3840
NOTE: In comparison with media feature tags, the "+" sign in front
of the feature capability indicator name is mandatory.
Figure 2: ABNF
7. IANA Considerations 7. IANA Considerations
7.1. Registration of the Feature-Caps header field 7.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
7.2. Proxy-Feature Feature Caps Trees 7.2. Registration of the Feature-Caps header field parameter
7.2.1. Introduction This specification adds the Feature-Caps header field to the IANA
"Header Field Parameters and Parameter Values" registry, according to
the process of RFC 3968 [RFC3968]
Header Field Parameter Name Predefined Values Reference
----------------------------------------------------------------
Feature-Caps <feature-cap>* No [xxx]
*<feature-cap> denotes parameter names conforming to the
syntax <feature-cap> defined in [xxx]. Valid feature capability
indicators are registered in [reference to the new
Proxy-Feature Feature Capability Indicator Trees registry].
Figure 3: SIP Parameter Header Field
(IANA: please sort the "Feature-Caps" line into the table and place
the remainder of the above as a footnote to the table.)
7.3. Proxy-Feature Feature Capability Indicator Trees
7.3.1. Introduction
This specification creates a new sub registry to the IANA "Session This specification creates a new sub registry to the IANA "Session
Initiation Protocol (SIP) Parameters" Protocol Registry, per the Initiation Protocol (SIP) Parameters" Protocol Registry, according to
guidelines in RFC 5226 [RFC5226]. The name of the sub registry is the process of RFC 5226 [RFC5226]. The name of the sub registry is
"Proxy-Feature Feature Caps Trees". "Proxy-Feature Feature Capability Indicator Trees".
7.2.2. Global Feature Cap Registration Tree 7.3.2. Global Feature Capability Indicator Registration Tree
This specification creates a new feature cap tree in the IANA "Proxy- This specification creates a new feature capability indicator tree in
Feature Feature Caps Trees" registry. The name of the tree is the IANA "Proxy-Feature Feature Capability Indicator Trees" registry.
"Global Feature Cap Registration Tree", and its leading facet is The name of the tree is "Global Feature Capability Indicator
"g.". It is used for the registration of feature caps. Registration Tree", and its leading facet is "g.". It is used for
the registration of feature capability indicators.
The addition of entries into this tree occurs through the Expert The addition of entries into this tree occurs through the Expert
Review policies, as defined in RFC 5226. A designated area expert Review policies, as defined in RFC 5226. A designated area expert
will review the proposed feature cap, and consult with members of will review the proposed feature capability indicator, and consult
related mailing lists. The information required in the registration with members of related mailing lists. The information required in
is defined in Section 4.3 of RFC XXX. the registration is defined in Section 5.3 of RFC XXX.
Note that all feature caps registered in the global tree will have Note that all feature capability indicators registered in the global
names with a leading facet "g.". No leading "+" is used in the tree will have names with a leading facet "g.". No leading "+" is
registrations in any of the feature cap registration trees. used in the registrations in any of the feature capability indicator
registration trees.
7.2.3. SIP Feature Cap Registration Tree 7.3.3. SIP Feature Capability Indicator Registration Tree
This specification creates a new feature cap tree in the IANA "Proxy- This specification creates a new feature capability indicator tree in
Feature Feature Caps Trees" registry. The name of the tree is "SIP the IANA "Proxy-Feature Feature Capability Indicator Trees" registry.
Feature Cap Registration Tree", and its leading facet is "sip.". It The name of the tree is "SIP Feature Capability Indicator
is used for the registration of feature caps. Registration Tree", and its leading facet is "sip.". It is used for
the registration of feature capability indicators.
The addition of entries into this tree occurs through the IETF The addition of entries into this tree occurs through the IETF
Consensus, as defined in RFC 5226. This requires the publication of Consensus, as defined in RFC 5226. This requires the publication of
an RFC that contains the registration. The information required in an RFC that contains the registration. The information required in
the registration is defined in Section 4.3 of RFC XXX. the registration is defined in Section 5.3 of RFC XXX.
Note that all feature caps registered in the SIP tree will have names Note that all feature capability indicators registered in the SIP
with a leading facet "sip.". No leading "+" is used in the tree will have names with a leading facet "sip.". No leading "+" is
registrations in any of the feature cap registration trees. used in the registrations in any of the feature capability indicator
registration trees.
8. Security Considerations 8. Feature Capability Indicator Registration Template
The security issues for feature caps are similar to the ones defined To: sip-feature-capability-indicators@apps.ietf.org
in RFC 3840 for media feature tags. However, as feature caps will (feature capability indicators mailing list)
typically not be used to convey capability information of end-user Subject: Registration of feature capability indicator XXXX
devices, those aspects of RFC 3840 do not apply to feature caps.
| Instructions are preceded by '|'. Some fields are optional.
Feature cap name:
Summary of feature indicated by this feature capability indicator:
| The summary should be no longer than 4 lines. More
| detailed information can be provided in the SIP feature
| cap specification.
Feature cap specification reference:
| The referenced specification MUST contain the information
| listed in Section 5.3 of XXXX (IANA: Replace XXXX with
| assigned RFC number of this specification.
Values appropriate for use with this feature capability indicator:
| If no values are defined for the feature capability indicator,
| indicate "N/A". Details about feature capability indicator values
| MUST be defined in the feature capability indicator specification.
The feature capability indicator is intended primarily for
use in the following applications, protocols,
services, or negotiation mechanisms: [optional]
| For applications, also specify the number of the
| first version which will use the feature capability indicator,
| if applicable.
Examples of typical use: [optional]
Considerations particular to use in individual
applications, protocols, services, or negotiation
mechanisms: [optional]
Interoperability considerations: [optional]
Security considerations:
Privacy concerns, related to exposure of personal
information:
Denial of service concerns related to consequences
of specifying incorrect values:
Other:
Additional information: [optional]
Keywords: [optional]
Related feature capability indicators: [optional]
Name(s) & email address(es) of person(s) to
contact for further information:
Intended usage:
| one of COMMON, LIMITED USE or OBSOLETE
Author/Change controller:
Other information: [optional]
| Any other information that the author deems
| interesting may be added here.
Figure 4: Registration Template
9. Security Considerations
The security issues for feature capability indicators are similar to
the ones defined in RFC 3840 for media feature tags. However, as
feature capability indicators will typically not be used to convey
capability information of end-user devices, those aspects of RFC 3840
do not apply to feature capability indicators.
In addition, the RFC 3840 security issue regarding an attacker using In addition, the RFC 3840 security issue regarding an attacker using
the SIP caller preferences extension [RFC3841] in order to affect the SIP caller preferences extension [RFC3841] in order to affect
routing decisions does not apply, as the mechanism is not defined to routing decisions does not apply, as the mechanism is not defined to
be used with feature caps. be used with feature capability indicators.
Feature caps can provide capability and characteristics information Feature caps can provide capability and characteristics information
about the SIP entity, some of which might be sensitive. The Feature- about the SIP entity, some of which might be sensitive. The Feature-
Caps header field does not convey address information about SIP Caps header field does not convey address information about SIP
entities. However, individual feature caps might provide address entities. However, individual feature capability indicators might
information as feature cap values. Therefore, mechanisms for provide address information as feature capability indicator values.
guaranteeing confidentiality and authenticity SHOULD be provided. Therefore, mechanisms for guaranteeing confidentiality and
authenticity SHOULD be provided.
9. Acknowledgements 10. Acknowledgements
The authors wish to thank everyone in the SIP community that provided The authors wish to thank everyone in the SIP community that provided
input and feedback on the work of this specification. input and feedback on the work of this specification.
10. Change Log 11. 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
o WGLC comments from Keith Drage
o 'feature cap' name changed to 'feature capability indicator'.
o Feature-Caps header field added to IANA Header Field Parameters
and Parameter Values registry.
o Editorial modifications.
Changes from draft-ietf-sipcore-proxy-feature-03 Changes from draft-ietf-sipcore-proxy-feature-03
o Additional Security Considerations text added. o Additional Security Considerations text added.
o IANA Considerations modified. o IANA Considerations modified.
o Editorial corrections. o Editorial corrections.
Changes from draft-ietf-sipcore-proxy-feature-02 Changes from draft-ietf-sipcore-proxy-feature-02
o Changes based on WGLC comments from Shida Schubert. o Changes based on WGLC comments from Shida Schubert.
o - Document title changed o - Document title changed
o - Terminology alignment o - Terminology alignment
o - Note text clarifications o - Note text clarifications
skipping to change at page 17, line 29 skipping to change at page 18, line 29
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
11. References 12. References
11.1. Normative References 12.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.
11.2. Informative References 12.2. Informative References
[RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag
Registration Procedure", BCP 31, RFC 2506, March 1999. 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.
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)", Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004. RFC 3841, August 2004.
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Header Field Parameter Registry for the Session
Initiation Protocol (SIP)", BCP 98, RFC 3968,
December 2004.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol Initiated Connections in the Session Initiation Protocol
(SIP)", RFC 5626, October 2009. (SIP)", RFC 5626, October 2009.
[3GPP.23.237] [3GPP.23.237]
3GPP, "IP Multimedia Subsystem (IMS) Service Continuity; 3GPP, "IP Multimedia Subsystem (IMS) Service Continuity;
 End of changes. 77 change blocks. 
427 lines changed or deleted 485 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/