draft-ietf-sipcore-proxy-feature-11.txt   draft-ietf-sipcore-proxy-feature-12.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: April 1, 2013 H. Kaplan Expires: April 22, 2013 H. Kaplan
Acme Packet Acme Packet
September 28, 2012 October 19, 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-11.txt draft-ietf-sipcore-proxy-feature-12.txt
Abstract Abstract
This specification defines a new SIP header field, Feature-Caps. The This specification defines a new SIP header field, Feature-Caps. The
Feature-Caps header field conveys feature capability indicators that Feature-Caps header field conveys feature capability indicators that
are used to indicate support of features and capabilities for SIP are used to indicate support of features and capabilities for SIP
entities that are not represented by the Uniform Resource Identifier entities that are not represented by the Uniform Resource Identifier
(URI) of the Contact header field. (URI) of the Contact header field.
SIP entities that are represented by the URI of the SIP Contact SIP entities that are represented by the URI of the SIP Contact
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 April 1, 2013. This Internet-Draft will expire on April 22, 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 27 skipping to change at page 2, line 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Feature-Caps Header Field . . . . . . . . . . . . . . . . . . 5 4. Feature-Caps Header Field . . . . . . . . . . . . . . . . . . 5
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. User Agent and Proxy Behavior . . . . . . . . . . . . . . 5 4.2. User Agent and Proxy Behavior . . . . . . . . . . . . . . 5
4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 5
4.2.2. B2BUA Behavior . . . . . . . . . . . . . . . . . . . . 6 4.2.2. B2BUA Behavior . . . . . . . . . . . . . . . . . . . . 6
4.2.3. Registrar Behavior . . . . . . . . . . . . . . . . . . 6 4.2.3. Registrar Behavior . . . . . . . . . . . . . . . . . . 6
4.2.4. Proxy behavior . . . . . . . . . . . . . . . . . . . . 6 4.2.4. Proxy behavior . . . . . . . . . . . . . . . . . . . . 7
4.3. SIP Message Type and Response Code Semantics . . . . . . . 7 4.3. SIP Message Type and Response Code Semantics . . . . . . . 7
4.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 7 4.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 7
4.3.2. SIP Dialog . . . . . . . . . . . . . . . . . . . . . . 7 4.3.2. SIP Dialog . . . . . . . . . . . . . . . . . . . . . . 7
4.3.3. SIP Registration (REGISTER) . . . . . . . . . . . . . 8 4.3.3. SIP Registration (REGISTER) . . . . . . . . . . . . . 8
4.3.4. SIP Stand-Alone Transactions . . . . . . . . . . . . . 8 4.3.4. SIP Stand-Alone Transactions . . . . . . . . . . . . . 8
5. Feature Capability Indicators . . . . . . . . . . . . . . . . 9 5. Feature Capability Indicators . . . . . . . . . . . . . . . . 9
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Registration Trees . . . . . . . . . . . . . . . . . . . . 9 5.2. Registration Trees . . . . . . . . . . . . . . . . . . . . 9
5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 9 5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 9
5.2.2. Global Tree . . . . . . . . . . . . . . . . . . . . . 9 5.2.2. Global Tree . . . . . . . . . . . . . . . . . . . . . 9
5.2.3. SIP Tree . . . . . . . . . . . . . . . . . . . . . . . 10 5.2.3. SIP Tree . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Feature Capability Indicator Specification Requirements . 10 5.3. Feature Capability Indicator Specification Requirements . 10
5.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 10 5.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 10
5.3.2. Overall Description . . . . . . . . . . . . . . . . . 10 5.3.2. Overall Description . . . . . . . . . . . . . . . . . 10
5.3.3. Feature Capability Indicator Values . . . . . . . . . 10 5.3.3. Feature Capability Indicator Values . . . . . . . . . 11
5.3.4. Usage Restrictions . . . . . . . . . . . . . . . . . . 11 5.3.4. Usage Restrictions . . . . . . . . . . . . . . . . . . 11
5.3.5. Interoperability Considerations . . . . . . . . . . . 11 5.3.5. Interoperability Considerations . . . . . . . . . . . 11
5.3.6. Security Considerations . . . . . . . . . . . . . . . 12 5.3.6. Security Considerations . . . . . . . . . . . . . . . 12
5.3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . 12 5.3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . 12
5.3.8. Other Information . . . . . . . . . . . . . . . . . . 12 5.3.8. Other Information . . . . . . . . . . . . . . . . . . 12
6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Syntax: Feature-Caps header field . . . . . . . . . . . . 12 6.2. Syntax: Feature-Caps header field . . . . . . . . . . . . 12
6.2.1. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2.1. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.3. Syntax: feature capability indicator . . . . . . . . . . . 13 6.3. Syntax: feature capability indicator . . . . . . . . . . . 13
skipping to change at page 3, line 22 skipping to change at page 3, line 22
7.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 14 7.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 14
7.3.2. Global Feature Capability Indicator Registration 7.3.2. Global Feature Capability Indicator Registration
Tree . . . . . . . . . . . . . . . . . . . . . . . . . 15 Tree . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.3.3. SIP Feature Capability Indicator Registration Tree . . 15 7.3.3. SIP Feature Capability Indicator Registration Tree . . 15
8. Feature Capability Indicator Registration Template . . . . . . 16 8. Feature Capability Indicator Registration Template . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 18
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . . 20 12.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
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.
skipping to change at page 5, line 46 skipping to change at page 5, line 46
feature, then the feature definition needs to define a way to convey feature, then the feature definition needs to define a way to convey
that information as a value of the associated feature capability that information as a value of the associated feature capability
indicator. indicator.
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 capability receives a SIP request or the response, the SIP feature capability
indicators in the top-most Feature-Caps header field will represent indicators in the top-most Feature-Caps header field will represent
the supported features and capabilities "closest" to the entity. the supported features and capabilities "closest", from a SIP
signaling point of view, to the entity.
Based on features and policies, a SIP entity MAY remove a Feature-
Caps header field from a SIP message. Also, a SIP entity MAY remove
a feature capability indicator from a Feature-Caps header field
within a SIP message. A SIP entity SHOULD NOT re-order the Feature-
Caps header fields within a SIP message.
For a given fc-value, as defined in section 6.2.1, the order in which For a given fc-value, as defined in section 6.2.1, the order in which
feature capability indicators are listed has no significance. For feature capability indicators are listed has no significance. For
example, "foo;bar" and "bar;foo" have the same meaning (i.e. that the example, "foo;bar" and "bar;foo" have the same meaning (i.e. that the
SIP entity that inserted the feature capability indicator supports SIP entity that inserted the feature capability indicator supports
the features and capabilities associated with the "foo" and "bar" the features and capabilities associated with the "foo" and "bar"
feature capability indicators. feature capability indicators.
4.2.2. B2BUA Behavior 4.2.2. B2BUA Behavior
skipping to change at page 10, line 35 skipping to change at page 10, line 37
Feature-Caps header field and feature capability indicators) defined Feature-Caps header field and feature capability indicators) defined
in this specification, unless needed for clarification or emphasis in this specification, unless needed for clarification or emphasis
purpose. A feature capability indicator specification MUST NOT purpose. A feature capability indicator specification MUST NOT
modify the Feature-Caps header field rules and semantics defined in modify the Feature-Caps header field rules and semantics defined in
Section 4. Section 4.
A feature capability indicator specification MUST NOT weaken any A feature capability indicator specification MUST NOT weaken any
behavior designated with "SHOULD" or "MUST" in this specification. behavior designated with "SHOULD" or "MUST" in this specification.
However, a specification MAY strengthen "SHOULD", "MAY", or However, a specification MAY strengthen "SHOULD", "MAY", or
"RECOMMENDED" requirements to "MUST" strength if features and "RECOMMENDED" requirements to "MUST" strength if features and
capabilities associated with the SIP feature capability indicator capabilities associated with the feature capability indicator require
require it. it.
5.3.2. Overall Description 5.3.2. Overall Description
The feature capability indicator specification MUST contain an The feature capability indicator specification MUST contain an
overall description of the feature capability indicator: how it is overall description of the feature capability indicator: how it is
used to indicate support of a feature, a description of the feature used to indicate support of a feature, a description of the feature
associated with the feature capability indicator, a description of associated with the feature capability indicator, a description of
any additional information (conveyed using one or more feature any additional information (conveyed using one or more feature
capability indicator values) that can be conveyed together with the capability indicator values) that can be conveyed together with the
feature capability indicator, and a description of how the associated feature capability indicator, and a description of how the associated
feature may be exercised/invoked. feature MAY be exercised/invoked.
5.3.3. Feature Capability Indicator Values 5.3.3. Feature Capability Indicator Values
A feature capability indicator can have an associated value, or a A feature capability indicator can have an associated value, or a
list of values. The feature capability indicator specification MUST list of values. The feature capability indicator specification MUST
define the syntax and semantics of any value defined for the feature define the syntax and semantics of any value defined for the feature
capability indicator, including possible restrictions related to the capability indicator, including possible restrictions related to the
usage of a specific value. The feature capability indicator usage of a specific value. The feature capability indicator
specification MUST define the value(s) in accordance with the ABNF specification MUST define the value(s) in accordance with the ABNF
defined in Section 6.3.2. The feature capability indicator defined in Section 6.3.2. The feature capability indicator
skipping to change at page 11, line 41 skipping to change at page 11, line 46
to insert a feature capability indicator in registration related to insert a feature capability indicator in registration related
messages, standalone transaction messages, dialog related messages, messages, standalone transaction messages, dialog related messages,
whether entities are allowed to insert a feature capability indicator whether entities are allowed to insert a feature capability indicator
in requests or responses, whether entities also need to support other in requests or responses, whether entities also need to support other
features and capabilities in order to insert a feature capability features and capabilities in order to insert a feature capability
indicator, and whether entities are allowed to indicate support of a indicator, and whether entities are allowed to indicate support of a
feature in conjunction with another feature. feature in conjunction with another feature.
5.3.5. Interoperability Considerations 5.3.5. Interoperability Considerations
If there are specific interoperability considerations that apply to The feature capability indicator specification MUST document any
the feature capability indicator, the feature capability indicator specific interoperability considerations that apply to the feature
specification MUST document such considerations. capability indicator.
Interoperability considerations can e.g. include procedures related Interoperability considerations can e.g. include procedures related
to cases where an expected feature capability indicator is not to cases where an expected feature capability indicator is not
present, or where it contains an unexpected value. present, or where it contains an unexpected value.
5.3.6. Security Considerations 5.3.6. Security Considerations
If there are specific security considerations that apply to the The feature capability indicator specification MUST document any
feature capability indicator, the feature capability indicator specific security considerations that apply to the feature capability
specification MUST document such considerations. indicator.
5.3.7. Examples 5.3.7. Examples
It is RECOMMENDED that the feature capability indicator specification It is recommended that the feature capability indicator specification
provide demonstrative message flow diagrams, paired with complete provide demonstrative message flow diagrams, paired with complete
messages and message descriptions. messages and message descriptions.
Note that example message flows are by definition informative, and do Note that example message flows are by definition informative, and do
not replace normative text. not replace normative text.
5.3.8. Other Information 5.3.8. Other Information
If there is additional information about the feature capability If there is additional information about the feature capability
indicator, it is RECOMMENDED to describe such information. It can indicator, it is recommended to describe such information. It can
include e.g. names of related feature capability indicators. include e.g. names of related feature capability indicators.
6. Syntax 6. Syntax
6.1. General 6.1. General
This Section defines the ABNF for the Feature-Caps header field, and This Section defines the ABNF for the Feature-Caps header field, and
for the feature capability indicators. for the feature capability indicators. The ABNF defined in this
specification is conformant to RFC 5234 [RFC5234]."
6.2. Syntax: Feature-Caps header field 6.2. Syntax: Feature-Caps header field
6.2.1. ABNF 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)
skipping to change at page 14, line 44 skipping to change at page 14, line 44
The "Proxy-Feature Feature Capability Indicator Trees" registry The "Proxy-Feature Feature Capability Indicator Trees" registry
contains sub registries for subsets (called 'trees') of feature contains sub registries for subsets (called 'trees') of feature
capability indicators sharing the same leading facet. Each feature capability indicators sharing the same leading facet. Each feature
capability indicator is registered within the tree that matches its capability indicator is registered within the tree that matches its
leading facet. If no tree matches its leading facet then the feature leading facet. If no tree matches its leading facet then the feature
capability indicator can not be registered. capability indicator can not be registered.
New feature capability indicator sub registries (trees) can be New feature capability indicator sub registries (trees) can be
registered. The registration must meet the "Standards Action" registered. The registration must meet the "Standards Action"
policies defined in RFC 5226. A new name, unique leading facet, and policies defined in RFC 5226 [RFC5226]. A new name, unique leading
registration policies (as defined in RFC 5226) for feature capability facet, and registration policies (as defined in RFC 5226) for feature
indicators within this tree need to be provided. capability indicators within this tree need to be provided.
This document defines the first two feature capability indicator This document defines the first two feature capability indicator
trees ("g." and "sip."). It does not define a tree for the empty trees ("g." and "sip."). It does not define a tree for the empty
leading facet. leading facet.
7.3.2. Global Feature Capability Indicator Registration Tree 7.3.2. Global Feature Capability Indicator Registration Tree
This specification creates a new feature capability indicator tree in This specification creates a new feature capability indicator tree in
the IANA "Proxy-Feature Feature Capability Indicator Trees" registry. the IANA "Proxy-Feature Feature Capability Indicator Trees" registry.
The name of the tree is "Global Feature Capability Indicator The name of the tree is "Global Feature Capability Indicator
skipping to change at page 15, line 41 skipping to change at page 15, line 41
in the registration feature capability indication registration in the registration feature capability indication registration
template. template.
Description, provided in the registration feature capability Description, provided in the registration feature capability
indication registration template. indication registration template.
Reference contains the Feature Capability Indicator Specification Reference contains the Feature Capability Indicator Specification
Reference, provided in the registration feature capability Reference, provided in the registration feature capability
indication registration template. indication registration template.
No initial values are registered in the global tree.
7.3.3. SIP Feature Capability Indicator Registration Tree 7.3.3. SIP Feature Capability Indicator Registration Tree
This specification creates a new feature capability indicator tree in This specification creates a new feature capability indicator tree in
the IANA "Proxy-Feature Feature Capability Indicator Trees" registry. the IANA "Proxy-Feature Feature Capability Indicator Trees" registry.
The name of the tree is "SIP Feature Capability Indicator The name of the tree is "SIP Feature Capability Indicator
Registration Tree", and its leading facet is "sip.". It is used for Registration Tree", and its leading facet is "sip.". It is used for
the registration of feature capability indicators. the registration of feature capability indicators.
When a feature capability indicator is registered in the sip tree, it When a feature capability indicator is registered in the sip tree, it
needs to meet the "IETF Review" policies defined in RFC 5226. The needs to meet the "IETF Review" policies defined in RFC 5226. The
skipping to change at page 16, line 28 skipping to change at page 16, line 31
in the registration feature capability indication registration in the registration feature capability indication registration
template. template.
Description, provided in the registration feature capability Description, provided in the registration feature capability
indication registration template. indication registration template.
Reference contains the Feature Capability Indicator Specification Reference contains the Feature Capability Indicator Specification
Reference, provided in the registration feature capability Reference, provided in the registration feature capability
indication registration template. indication registration template.
No initial values are registered in the SIP tree.
8. Feature Capability Indicator Registration Template 8. Feature Capability Indicator Registration Template
Registration requests for the global tree are submitted Registration requests for the global tree are submitted
by e-mail to iana@iana.org. by e-mail to iana@iana.org.
Registration requests for the sip tree requires submitting Registration requests for the sip tree requires submitting
an Internet-Draft to the IESG. an Internet-Draft to the IESG.
| Instructions are preceded by '|'. All fields are mandatory. | Instructions are preceded by '|'. All fields are mandatory.
Feature capability indicator name: Feature capability indicator name:
Description: Description:
| The description should be no longer than 4 lines. More | The description should be no longer than 4 lines. More
| detailed information can be provided in the feature | detailed information can be provided in the feature
| capability indicator specification. | capability indicator specification.
Feature capability indicator name: Feature capability indicator name:
| The referenced specification MUST contain the information | The referenced specification must contain the information
| listed in Section 5.3 of RFC XXXX. | listed in Section 5.3 of RFC XXXX.
Feature capability indicator specification reference: Feature capability indicator specification reference:
| The referenced specification MUST contain the information | The referenced specification must contain the information
| listed in Section 5.3 of RFC XXXX. | listed in Section 5.3 of RFC XXXX.
Contact: Contact:
| Name(s) & email address(es) of person(s) to | Name(s) & email address(es) of person(s) to
| contact for further information." | contact for further information."
(IANA: Please replace XXXX with the assigned RFC number) (IANA: Please replace XXXX with the assigned RFC number)
9. Security Considerations 9. Security Considerations
skipping to change at page 18, line 18 skipping to change at page 18, line 18
be used with feature capability indicators. be used with feature capability indicators.
Feature capability indicators can, however, provide capability and Feature capability indicators can, however, provide capability and
characteristics information about the SIP entity, some of which might characteristics information about the SIP entity, some of which might
be sensitive. Malicious elements viewing the indicators may be able be sensitive. Malicious elements viewing the indicators may be able
to discern application deployment details or identify elements with to discern application deployment details or identify elements with
exploitable feature implementation weaknesses. The Feature-Caps exploitable feature implementation weaknesses. The Feature-Caps
header field does not convey address information about SIP entities. header field does not convey address information about SIP entities.
However, individual feature capability indicators might provide However, individual feature capability indicators might provide
address information as feature capability indicator values. address information as feature capability indicator values.
Therefore, if the feature capability indicators provide sensitive Therefore, if the feature capability indicators provide information
information, mechanisms for guaranteeing confidentiality and that requires data integrity or origin authentication, mechanisms for
authenticity MUST be provided. providing those MUST be provided. If confidentiality is required
then the specification MUST call for use of Transport Layer Security
(TLS) [RFC5246] at all hops. Since there are no satisfactory middle-
to-end or middle-to-middle SIP confidentiality mechanisms, TLS is as
good as it gets and specifications SHOULD NOT define feature
capability indicators that need confidentiality that is better than
the hop-by-hop confidentiality provided by TLS.
10. 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.
11. 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-11
o IANA: Indicating that no initial values are registered in the
trees.
o IESG: Editorial changes based on comments from Barry Leiba.
o IESG: Reference to RFC 5234 added based on comments from Adrian
Farrel.
o IESG: Editorial changes and Security Consideration modification
based on comments from Stephen Farrell.
o IESG: Editorial changes based on comments from Pete Resnick.
Changes from draft-holmberg-sipcore-proxy-feature-10 Changes from draft-holmberg-sipcore-proxy-feature-10
o Editorial changes. o Editorial changes.
o 'IETF Consensus' changed to 'IETF Review' (section 7.3.3) o 'IETF Consensus' changed to 'IETF Review' (section 7.3.3)
Changes from draft-holmberg-sipcore-proxy-feature-09 Changes from draft-holmberg-sipcore-proxy-feature-09
o Editorial changes based on SECDIR comments from Radia Perlman. o Editorial changes based on SECDIR comments from Radia Perlman.
o Editorial changes based on Gen-Art comments from Brian E o Editorial changes based on Gen-Art comments from Brian E
Carpenter. Carpenter.
o Editorial changes based on OPSDIR comments from Jouni Korhonen. o Editorial changes based on OPSDIR comments from Jouni Korhonen.
o Change in security considerations indicating that, if sensitive o Change in security considerations indicating that, if sensitive
information is conveyed, mechanisms for guaranteeing information is conveyed, mechanisms for guaranteeing
confidentiality and authenticity must be provided. confidentiality and authenticity must be provided.
skipping to change at page 20, line 34 skipping to change at page 21, line 5
12.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.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
12.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
skipping to change at page 21, line 13 skipping to change at page 21, line 34
December 2004. December 2004.
[RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors [RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors
of Extensions to the Session Initiation Protocol (SIP)", of Extensions to the Session Initiation Protocol (SIP)",
RFC 4485, May 2006. RFC 4485, May 2006.
[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.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 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;
Stage 2", 3GPP TS 23.237 10.9.0, March 2012. 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
 End of changes. 25 change blocks. 
28 lines changed or deleted 63 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/