draft-ietf-sipping-config-framework-15.txt   draft-ietf-sipping-config-framework-16.txt 
SIPPING D. Petrie SIPPING D. Petrie
Internet-Draft SIPez LLC. Internet-Draft SIPez LLC.
Intended status: Standards Track S. Channabasappa, Ed. Intended status: Standards Track S. Channabasappa, Ed.
Expires: August 16, 2008 CableLabs Expires: April 1, 2010 CableLabs
February 13, 2008 September 28, 2009
A Framework for Session Initiation Protocol User Agent Profile Delivery A Framework for Session Initiation Protocol User Agent Profile Delivery
draft-ietf-sipping-config-framework-15 draft-ietf-sipping-config-framework-16
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 16, 2008. This Internet-Draft will expire on April 1, 2010.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
This document specifies a framework to enable configuration of This document specifies a framework to enable configuration of
Session Initiation Protocol (SIP) User Agents in SIP deployments. Session Initiation Protocol (SIP) User Agents in SIP deployments.
The framework provides a means to deliver profile data that User The framework provides a means to deliver profile data that User
Agents need to be functional, automatically and with minimal or no Agents need to be functional, automatically and with minimal or no
User and Administrative intervention. The framework describes how User and Administrative intervention. The framework describes how
SIP User Agents can discover sources, request profiles and receive SIP User Agents can discover sources, request profiles and receive
notifications related to profile modifications. As part of this notifications related to profile modifications. As part of this
framework, a new SIP event package is defined for notification of framework, a new SIP event package is defined for notification of
profile changes. The framework provides minimal data retrieval profile changes. The framework provides minimal data retrieval
options to ensure interoperability. The framework does not include options to ensure interoperability. The framework does not include
specification of the profile data within its scope. specification of the profile data within its scope.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Reference Model . . . . . . . . . . . . . . . . . . . . . 6 3.1. Reference Model . . . . . . . . . . . . . . . . . . . . . 7
3.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Profile Types . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Profile Types . . . . . . . . . . . . . . . . . . . . . . 10
3.4. Profile delivery stages . . . . . . . . . . . . . . . . . 10 3.4. Profile delivery stages . . . . . . . . . . . . . . . . . 11
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Simple Deployment Scenario . . . . . . . . . . . . . . . . 11 4.1. Simple Deployment Scenario . . . . . . . . . . . . . . . . 12
4.2. Devices supporting multiple users from different 4.2. Devices supporting multiple users from different
Service Providers . . . . . . . . . . . . . . . . . . . . 12 Service Providers . . . . . . . . . . . . . . . . . . . . 13
5. Profile Delivery Framework . . . . . . . . . . . . . . . . . . 14 5. Profile Delivery Framework . . . . . . . . . . . . . . . . . . 15
5.1. Profile delivery stages . . . . . . . . . . . . . . . . . 14 5.1. Profile delivery stages . . . . . . . . . . . . . . . . . 15
5.1.1. Profile Enrollment . . . . . . . . . . . . . . . . . . 15 5.1.1. Profile Enrollment . . . . . . . . . . . . . . . . . . 16
5.1.2. Content Retrieval . . . . . . . . . . . . . . . . . . 17 5.1.2. Content Retrieval . . . . . . . . . . . . . . . . . . 18
5.1.3. Change Notification . . . . . . . . . . . . . . . . . 17 5.1.3. Change Notification . . . . . . . . . . . . . . . . . 18
5.1.4. Enrollment Data and Caching . . . . . . . . . . . . . 18 5.1.4. Enrollment Data and Caching . . . . . . . . . . . . . 19
5.2. Securing Profile Delivery . . . . . . . . . . . . . . . . 21 5.2. Securing Profile Delivery . . . . . . . . . . . . . . . . 22
5.2.1. Securing Profile Enrollment . . . . . . . . . . . . . 22 5.2.1. Securing Profile Enrollment . . . . . . . . . . . . . 23
5.2.2. Securing Content Retrieval . . . . . . . . . . . . . . 23 5.2.2. Securing Content Retrieval . . . . . . . . . . . . . . 24
5.2.3. Securing Change Notification . . . . . . . . . . . . . 24 5.2.3. Securing Change Notification . . . . . . . . . . . . . 25
5.3. Additional Considerations . . . . . . . . . . . . . . . . 24 5.3. Additional Considerations . . . . . . . . . . . . . . . . 25
5.3.1. Bootstrapping Identities and Credentials . . . . . . . 24 5.3.1. Bootstrapping Identities and Credentials . . . . . . . 25
5.3.2. Profile Enrollment Request Attempt . . . . . . . . . . 26 5.3.2. Profile Enrollment Request Attempt . . . . . . . . . . 27
5.3.3. Device Types . . . . . . . . . . . . . . . . . . . . . 30 5.3.3. Device Types . . . . . . . . . . . . . . . . . . . . . 31
5.3.4. Profile Data . . . . . . . . . . . . . . . . . . . . . 30 5.3.4. Profile Data . . . . . . . . . . . . . . . . . . . . . 31
5.3.5. Profile Data Frameworks . . . . . . . . . . . . . . . 31 5.3.5. Profile Data Frameworks . . . . . . . . . . . . . . . 32
5.3.6. Additional Profile Types . . . . . . . . . . . . . . . 32 5.3.6. Additional Profile Types . . . . . . . . . . . . . . . 33
5.3.7. Deployment considerations . . . . . . . . . . . . . . 32 5.3.7. Deployment considerations . . . . . . . . . . . . . . 33
5.4. Support for NATs . . . . . . . . . . . . . . . . . . . . . 33 5.4. Support for NATs . . . . . . . . . . . . . . . . . . . . . 34
6. Event Package Definition . . . . . . . . . . . . . . . . . . . 33 6. Event Package Definition . . . . . . . . . . . . . . . . . . . 34
6.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 33 6.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 34
6.2. Event Package Parameters . . . . . . . . . . . . . . . . . 33 6.2. Event Package Parameters . . . . . . . . . . . . . . . . . 34
6.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 36 6.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 37
6.4. Subscription Duration . . . . . . . . . . . . . . . . . . 37 6.4. Subscription Duration . . . . . . . . . . . . . . . . . . 38
6.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 37 6.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 38
6.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 37 6.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 38
6.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 38 6.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 39
6.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 38 6.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 39
6.9. Handling of Forked Requests . . . . . . . . . . . . . . . 39 6.9. Handling of Forked Requests . . . . . . . . . . . . . . . 40
6.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 39 6.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 40
6.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 39 6.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 40
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.1. Example 1: Device requesting profile . . . . . . . . . . . 39 7.1. Example 1: Device requesting profile . . . . . . . . . . . 40
7.2. Example 2: Device obtaining change notification . . . . . 42 7.2. Example 2: Device obtaining change notification . . . . . 43
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
8.1. SIP Event Package . . . . . . . . . . . . . . . . . . . . 46 8.1. SIP Event Package . . . . . . . . . . . . . . . . . . . . 47
8.2. Registry of SIP configuration profile types . . . . . . . 46 8.2. Registry of SIP configuration profile types . . . . . . . 47
9. Security Considerations . . . . . . . . . . . . . . . . . . . 47 9. Security Considerations . . . . . . . . . . . . . . . . . . . 48
9.1. Local-network profile . . . . . . . . . . . . . . . . . . 48 9.1. Local-network profile . . . . . . . . . . . . . . . . . . 49
9.2. Device profile . . . . . . . . . . . . . . . . . . . . . . 49 9.2. Device profile . . . . . . . . . . . . . . . . . . . . . . 50
9.3. User profile . . . . . . . . . . . . . . . . . . . . . . . 51 9.3. User profile . . . . . . . . . . . . . . . . . . . . . . . 52
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53
11.1. Normative References . . . . . . . . . . . . . . . . . . . 52 11.1. Normative References . . . . . . . . . . . . . . . . . . . 53
11.2. Informative References . . . . . . . . . . . . . . . . . . 53 11.2. Informative References . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55
Intellectual Property and Copyright Statements . . . . . . . . . . 55
1. Introduction 1. Introduction
SIP User Agents require configuration data to function properly. SIP User Agents require configuration data to function properly.
Examples include local network, device and user specific information. Examples include local network, device and user specific information.
A configuration data set specific to an entity is termed a profile. A configuration data set specific to an entity is termed a profile.
For example, device profile contains the configuration data related For example, device profile contains the configuration data related
to a device. The process of providing devices with one or more to a device. The process of providing devices with one or more
profiles is termed profile delivery. Ideally, this profile delivery profiles is termed profile delivery. Ideally, this profile delivery
process should be automatic and require minimal or no user process should be automatic and require minimal or no user
skipping to change at page 12, line 31 skipping to change at page 13, line 31
The following assumptions apply: The following assumptions apply:
o Provider A is the Device and Local Network Provider for the o Provider A is the Device and Local Network Provider for the
device, and the SIP Service Provider for user A; Provider B is device, and the SIP Service Provider for user A; Provider B is
the SIP Service Provider for user B. the SIP Service Provider for user B.
o Profile enrollment always results in content indirection o Profile enrollment always results in content indirection
information requiring profile content retrieval. information requiring profile content retrieval.
o Communication between the device and the PDSs is facilitated via o Communication between the device and the PDSs is facilitated via
one or more SIP proxies (only one is shown in the illustration). one or more SIP proxies (only one is shown in the illustration).
Figure 4 illustrates the use case and highlights the communications Figure 5 illustrates the use case and highlights the communications
relevant to the framework specified in this document. relevant to the framework specified in this document.
User User User User
A B +----------------------+ +----------------------+ A B +----------------------+ +----------------------+
+--------+ | Provider | | Provider | +--------+ | Provider | | Provider |
| Device | | A | | B | | Device | | A | | B |
| | | | | | | | | | | |
+--------+ | DHCP PROXY PDS | | PROXY PDS | +--------+ | DHCP PROXY PDS | | PROXY PDS |
+----------------------+ +----------------------+ +----------------------+ +----------------------+
| | | | | | | | | | | |
skipping to change at page 16, line 5 skipping to change at page 17, line 5
'example.net', it cannot present a user AoR associated with the 'example.net', it cannot present a user AoR associated with the
local domain 'example.com'. local domain 'example.com'.
* The device SHOULD adhere to the following order of data usage: * The device SHOULD adhere to the following order of data usage:
configured, cached and discovered. An exception is when the configured, cached and discovered. An exception is when the
device is explicitly configured to use a different order. device is explicitly configured to use a different order.
Upon failure to obtain the profile using any methods specified in Upon failure to obtain the profile using any methods specified in
this framework, the device MAY provide a user interface to allow this framework, the device MAY provide a user interface to allow
for user intervention. This can result in temporary, one-time for user intervention. This can result in temporary, one-time
data to bootstrap the device. Such temporary data is not data to bootstrap the device. Such temporary data is not
considered to be "configured" and is not expected to be cached considered to be "configured" and SHOULD NOT not be cached across
across resets. The configuration obtained using such data MAY resets. The configuration obtained using such data MAY provide
provide the configuration data required for the device to continue the configuration data required for the device to continue
functioning normally. functioning normally.
Devices attempting enrollment MUST comply with the SIP-specific Devices attempting enrollment MUST comply with the SIP-specific
event notification specified in [RFC3265], the event package event notification specified in [RFC3265], the event package
requirements specified in Section 6.2, and the security requirements specified in Section 6.2, and the security
requirements specified in Section 5.2. requirements specified in Section 5.2.
Enrollment request admittance Enrollment request admittance
A PDS or a SIP proxy will receive a transmitted enrollment A PDS or a SIP proxy will receive a transmitted enrollment
request. If a SIP infrastructure element receives the request, it request. If a SIP infrastructure element receives the request, it
will relay it to the authoritative proxy for the domain indicated will relay it to the authoritative proxy for the domain indicated
in the Request-URI (the same way it would handle any other in the Request-URI (the same way it would handle any other
SUBSCRIBE message). The authoritative proxy is required to SUBSCRIBE message). The authoritative proxy is required to
examine the request (e.g., event package) and transmit it to a PDS examine the request (e.g., event package) and transmit it to a PDS
capable of addressing the profile enrollment request. capable of addressing the profile enrollment request.
A PDS receiving the enrollment request SHOULD respond to the A PDS receiving the enrollment request SHOULD respond to the
request, or proxy it to a PDS that can respond. An exception is request, or proxy it to a PDS that can respond. An exception to
when a policy prevents a response (e.g., recognition of a DoS responding or proxying the request is when a policy prevents
attack, an invalid device, etc.). The PDS then verifies the response (e.g., recognition of a DoS attack, an invalid device,
identity presented in the request and performs any necessary etc.). The PDS then verifies the identity presented in the
authentication. Once authentication is successful, the PDS MUST request and performs any necessary authentication. Once
either admit or reject the enrollment request, based on applicable authentication is successful, the PDS MUST either admit or reject
authorization policies. A PDS admitting the enrollment request the enrollment request, based on applicable authorization
indicates it via a 2xx-class response, as specified in [RFC3265]. policies. A PDS admitting the enrollment request indicates it via
a 2xx-class response, as specified in [RFC3265].
Refer to Section 6.6 and Section 5.2 for more information on Refer to Section 6.6 and Section 5.2 for more information on
subscription request handling and security requirements, subscription request handling and security requirements,
respectively. respectively.
Enrollment request acceptance Enrollment request acceptance
A PDS that admits the enrollment request verifies applicable A PDS that admits the enrollment request verifies applicable
policies, identifies the requested profile data and prepares a SIP policies, identifies the requested profile data and prepares a SIP
NOTIFY message to the device. Such a notification can either NOTIFY message to the device. Such a notification can either
skipping to change at page 22, line 36 skipping to change at page 23, line 39
containing sensitive profile data (refer to Section 5.3.4), devices containing sensitive profile data (refer to Section 5.3.4), devices
and PDSs MUST support Digest Authentication as specified in and PDSs MUST support Digest Authentication as specified in
[RFC3261]. Future enhancements may provide other authentication [RFC3261]. Future enhancements may provide other authentication
methods such as authentication using X.509 certificates. For the methods such as authentication using X.509 certificates. For the
device to authenticate the PDS, the device MUST mutually authenticate device to authenticate the PDS, the device MUST mutually authenticate
with the PDS during digest authentication (device challenges the PDS, with the PDS during digest authentication (device challenges the PDS,
which responds with the Authorization header). Transmission of which responds with the Authorization header). Transmission of
sensitive profile data also requires message integrity. This can be sensitive profile data also requires message integrity. This can be
accomplished by configuring the device with, or by ensuring that the accomplished by configuring the device with, or by ensuring that the
discovery process during profile enrollment provides, a SIPS URI discovery process during profile enrollment provides, a SIPS URI
resulting in TLS establishment ([RFC4346]). TLS also prevents resulting in TLS establishment ([RFC5246]). TLS also prevents
offline dictionary attacks when digest authentication is used. Thus, offline dictionary attacks when digest authentication is used. Thus,
in the absence of TLS, the device MUST NOT respond to any in the absence of TLS, the device MUST NOT respond to any
authentication challenges. It is to be noted that the digest authentication challenges. It is to be noted that the digest
credentials used for obtaining profile data via this framework may, credentials used for obtaining profile data via this framework may,
or may not, be the same as that used for SIP registration (see or may not, be the same as that used for SIP registration (see
Section 5.3.1). Section 5.3.1).
When the PDS challenges a profile enrollment request, and it fails, When the PDS challenges a profile enrollment request, and it fails,
the PDS MAY refuse enrollment or provide profile data without the the PDS MAY refuse enrollment or provide profile data without the
user-specific information (e.g., to bootstrap a device as indicated user-specific information (e.g., to bootstrap a device as indicated
skipping to change at page 41, line 18 skipping to change at page 42, line 18
SIP SUBSCRIBE utilizing the Event Package specified in this SIP SUBSCRIBE utilizing the Event Package specified in this
framework. framework.
* Note: Some of the header fields (e.g., SUBSCRIBE, Event, via) * Note: Some of the header fields (e.g., SUBSCRIBE, Event, via)
are continued on a separate line due to format constraints of are continued on a separate line due to format constraints of
this document. this document.
SUBSCRIBE sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB SUBSCRIBE sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB
@example.com SIP/2.0 @example.com SIP/2.0
Event: ua-profile;profile-type=device;vendor="vendor.example.net"; Event: ua-profile;profile-type=device;vendor="vendor.example.net";
model="Z100";version="1.2.3"; model="Z100";version="1.2.3"
From: anonymous@example.com;tag=1234 From: anonymous@example.com;tag=1234
To: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB@example.com To: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB@example.com
Call-ID: 3573853342923422@192.0.2.44 Call-ID: 3573853342923422@192.0.2.44
CSeq: 2131 SUBSCRIBE CSeq: 2131 SUBSCRIBE
Contact: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB Contact: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB
@192.168.1.44 @192.168.1.44
;+sip.instance="<urn:uuid:00000000-0000-0000-0000-123456789AB0>" ;+sip.instance="<urn:uuid:00000000-0000-0000-0000-123456789AB0>"
;schemes="http,https" ;schemes="http,https"
Via: SIP/2.0/TCP 192.0.2.41; Via: SIP/2.0/TCP 192.0.2.41;
branch=z9hG4bK6d6d35b6e2a203104d97211a3d18f57a branch=z9hG4bK6d6d35b6e2a203104d97211a3d18f57a
skipping to change at page 46, line 50 skipping to change at page 47, line 50
Event effective-by No [RFCXXXX] Event effective-by No [RFCXXXX]
8.2. Registry of SIP configuration profile types 8.2. Registry of SIP configuration profile types
This document requests IANA to register new SIP configuration profile This document requests IANA to register new SIP configuration profile
types at http://www.iana.org/assignments/sip-parameters under "SIP types at http://www.iana.org/assignments/sip-parameters under "SIP
Configuration Profile Types". Configuration Profile Types".
SIP configuration profile types allocations fall under the category SIP configuration profile types allocations fall under the category
"Specification Required", as explained in "Guidelines for Writing an "Specification Required", as explained in "Guidelines for Writing an
IANA Considerations Section in RFCs" ([RFC2434]). IANA Considerations Section in RFCs" ([RFC5226]).
Registrations with the IANA MUST include a the profile type, and a Registrations with the IANA MUST include a the profile type, and a
published document which describes its purpose and usage. published document which describes its purpose and usage.
As this document specifies three SIP configuration profile types, the As this document specifies three SIP configuration profile types, the
initial IANA registration will contain the information shown in the initial IANA registration will contain the information shown in the
table below. It also demonstrates the type of information maintained table below. It also demonstrates the type of information maintained
by the IANA. by the IANA.
Profile Type Reference Profile Type Reference
skipping to change at page 52, line 24 skipping to change at page 53, line 24
Directors (Cullen Jennings from Cisco and Jon Peterson from Neustar) Directors (Cullen Jennings from Cisco and Jon Peterson from Neustar)
for facilitating discussions, reviews and contributions. for facilitating discussions, reviews and contributions.
11. References 11. References
11.1. Normative References 11.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.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication", Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999. RFC 2617, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
skipping to change at page 53, line 17 skipping to change at page 54, line 13
(SIP) Servers", RFC 3319, July 2003. (SIP) Servers", RFC 3319, July 2003.
[RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol [RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCP-for-IPv4) Option for Session Initiation Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol
(SIP) Servers", RFC 3361, August 2002. (SIP) Servers", RFC 3361, August 2002.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
July 2005. July 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006. Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4483] Burger, E., "A Mechanism for Content Indirection in [RFC4483] Burger, E., "A Mechanism for Content Indirection in
Session Initiation Protocol (SIP) Messages", RFC 4483, Session Initiation Protocol (SIP) Messages", RFC 4483,
May 2006. May 2006.
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for
IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
Option", RFC 4704, October 2006. Option", RFC 4704, October 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
11.2. Informative References 11.2. Informative References
[I-D.ietf-ecrit-phonebcp] [I-D.ietf-ecrit-phonebcp]
Rosen, B. and J. Polk, "Best Current Practice for Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling", Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-02 (work in progress), draft-ietf-ecrit-phonebcp-13 (work in progress),
September 2007. July 2009.
[I-D.ietf-sip-outbound] [I-D.ietf-sip-outbound]
Jennings, C. and R. Mahy, "Managing Client Initiated Jennings, C., "Managing Client Initiated Connections in
Connections in the Session Initiation Protocol (SIP)", the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-11 (work in progress), draft-ietf-sip-outbound-20 (work in progress), June 2009.
November 2007.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, October 1985. STD 9, RFC 959, October 1985.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map", RFC 4510, (LDAP): Technical Specification Road Map", RFC 4510,
June 2006. June 2006.
skipping to change at page 55, line 4 skipping to change at line 2339
URI: http://www.SIPez.com/ URI: http://www.SIPez.com/
Sumanth Channabasappa (Editor) Sumanth Channabasappa (Editor)
CableLabs CableLabs
858 Coal Creek Circle 858 Coal Creek Circle
Louisville, Co 80027 Louisville, Co 80027
USA USA
Email: sumanth@cablelabs.com Email: sumanth@cablelabs.com
URI: http://www.cablelabs.com/ URI: http://www.cablelabs.com/
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 19 change blocks. 
94 lines changed or deleted 108 lines changed or added

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