draft-ietf-sipping-pending-additions-03.txt   draft-ietf-sipping-pending-additions-04.txt 
SIPPING G. Camarillo SIPPING G. Camarillo
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track November 13, 2007 Intended status: Standards Track February 15, 2008
Expires: May 16, 2008 Expires: August 18, 2008
The Session Initiation Protocol (SIP) Pending Additions Event Package The Session Initiation Protocol (SIP) Pending Additions Event Package
draft-ietf-sipping-pending-additions-03.txt draft-ietf-sipping-pending-additions-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 May 16, 2008. This Internet-Draft will expire on August 18, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document defines the SIP Pending Additions event package. This This document defines the SIP Pending Additions event package. This
event package is used by SIP relays to inform user agents about the event package is used by SIP relays to inform user agents about the
consent-related status of the entries to be added to a resource list. consent-related status of the entries to be added to a resource list.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3
4. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 4 4. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 3
5. Pending Additions Event Package Definition . . . . . . . . . . 5 5. Pending Additions Event Package Definition . . . . . . . . . . 5
5.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 5 5.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 5
5.1.1. Event Package Parameters . . . . . . . . . . . . . . . 5 5.1.1. Event Package Parameters . . . . . . . . . . . . . . . 5
5.1.2. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . 5 5.1.2. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . 5
5.1.3. Subscription Duration . . . . . . . . . . . . . . . . 5 5.1.3. Subscription Duration . . . . . . . . . . . . . . . . 5
5.1.4. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . 6 5.1.4. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . 5
5.1.5. Notifier Processing of SUBSCRIBE Requests . . . . . . 6 5.1.5. Notifier Processing of SUBSCRIBE Requests . . . . . . 6
5.1.6. Notifier Generation of NOTIFY Requests . . . . . . . . 6 5.1.6. Notifier Generation of NOTIFY Requests . . . . . . . . 6
5.1.7. Subscriber Processing of NOTIFY Requests . . . . . . . 6 5.1.7. Subscriber Processing of NOTIFY Requests . . . . . . . 6
5.1.8. Handling of Forked Requests . . . . . . . . . . . . . 6 5.1.8. Handling of Forked Requests . . . . . . . . . . . . . 6
5.1.9. Rate of Notifications . . . . . . . . . . . . . . . . 7 5.1.9. Rate of Notifications . . . . . . . . . . . . . . . . 7
5.1.10. State Agents . . . . . . . . . . . . . . . . . . . . . 7 5.1.10. State Agents . . . . . . . . . . . . . . . . . . . . . 7
5.1.11. Example . . . . . . . . . . . . . . . . . . . . . . . 7 5.1.11. Example . . . . . . . . . . . . . . . . . . . . . . . 7
6. Usage of the Pending Additions Event Package with the XCAP 6. Partial Notifications . . . . . . . . . . . . . . . . . . . . 7
Diff Format . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Generation of Partial Notifications . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6.2. Processing of Partial Notifications . . . . . . . . . . . 9
7.1. SIP Event Package Registration . . . . . . . . . . . . . . 9 6.3. XML Schema for Partial Notifications . . . . . . . . . . . 9
7.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 9 6.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.3. XML Schema Registration . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7.1. SIP Event Package Registration . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 7.2. URN Sub-Namespace Registration: consent-status . . . . . . 12
10. Normative References . . . . . . . . . . . . . . . . . . . . . 11 7.3. XML Schema Registration: consent-status . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.4. XML Schema Registration: resource-lists . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 13 7.5. MIME type Registration:
application/resource-lists-diff+xml . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. Normative References . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 17
1. Introduction 1. Introduction
The framework for consent-based communications in SIP The framework for consent-based communications in SIP
[I-D.ietf-sip-consent-framework] identifies the need for users [I-D.ietf-sip-consent-framework] identifies the need for users
manipulating the translation logic at a relay (e.g., adding a new manipulating the translation logic at a relay (e.g., adding a new
recipient) to be informed about the consent-related status of the recipient) to be informed about the consent-related status of the
recipients of a given translation. That is, the user manipulating recipients of a given translation. That is, the user manipulating
the translation logic needs to know which recipients have given the the translation logic needs to know which recipients have given the
relay permission to send them SIP requests. relay permission to send them SIP requests.
skipping to change at page 3, line 35 skipping to change at page 3, line 35
Relay: Any SIP server, be it a proxy, B2BUA (Back-to-Back User Relay: Any SIP server, be it a proxy, B2BUA (Back-to-Back User
Agent), or some hybrid, that receives a request, translates its Agent), or some hybrid, that receives a request, translates its
Request-URI into one or more next-hop URIs (i.e., recipient URIs), Request-URI into one or more next-hop URIs (i.e., recipient URIs),
and delivers the request to those URIs. and delivers the request to those URIs.
3. Overview of Operation 3. Overview of Operation
A user agent subscribes to a relay using the Pending Additions event A user agent subscribes to a relay using the Pending Additions event
package. NOTIFY requests within this event package can carry an XML package. NOTIFY requests within this event package can carry an XML
document in the "application/resource-lists+xml" format [RFC4826] or document in the "application/resource-lists+xml" format [RFC4826] or
in the "application/xcap-diff+xml" format in the "application/resource-lists-diff+xml" format, which is based
[I-D.ietf-simple-xcap-diff]. on XML patch operations [I-D.ietf-simple-xml-patch-ops].
A document in the "application/resource-lists+xml" format provides A document in the "application/resource-lists+xml" format provides
the user agent with the whole list of resources being added to a the user agent with the whole list of resources being added to a
resource list along with the consent-related status of those resource list along with the consent-related status of those
resources. resources. A document in the "application/resource-lists-diff+xml"
format provides the user agent with the changes the list of resources
A document in the "application/xcap-diff+xml" format informs the user being added has experimented since the last notification sent to the
agent that the document that describes the resources being added to user agent.
the resource list has changed. The user agent can then download the
document in the "application/resource-lists+xml" format from the
relay using XCAP [RFC4825].
4. XML Schema Definition 4. XML Schema Definition
This section defines the <consent-status> element, which provides This section defines the <consent-status> element, which provides
consent-related information about a resource to be added to a relay's consent-related information about a resource to be added to a relay's
translation logic. translation logic.
A consent-status document is an XML document that MUST be well-formed A consent-status document is an XML document that MUST be well-formed
and SHOULD be valid. Consent-status documents MUST be based on XML and SHOULD be valid. Consent-status documents MUST be based on XML
1.0 and MUST be encoded using UTF-8. This specification makes use of 1.0 and MUST be encoded using UTF-8. This specification makes use of
skipping to change at page 5, line 17 skipping to change at page 5, line 11
error response to the MESSAGE request send to request permission). error response to the MESSAGE request send to request permission).
That is, the permission document requesting permission could not That is, the permission document requesting permission could not
be delivered to the resource. be delivered to the resource.
Denied: the resource has denied the relay permission to add the Denied: the resource has denied the relay permission to add the
resource to the relay's translation logic. resource to the relay's translation logic.
Granted: the resource has granted the relay permission to add the Granted: the resource has granted the relay permission to add the
resource to the relay's translation logic. resource to the relay's translation logic.
Section 5.1.11 contains an example of an "application/
resource-lists+xml" document that carries consent-related state
information using <consent-status> elements.
5. Pending Additions Event Package Definition 5. Pending Additions Event Package Definition
This section provides the details for defining a SIP [RFC3261] event This section provides the details for defining a SIP [RFC3261] event
notification package, as specified by [RFC3265]. notification package, as specified by [RFC3265].
5.1. Event Package Name 5.1. Event Package Name
The name of this event package is "consent-pending-additions". This The name of this event package is "consent-pending-additions". This
package name is carried in the Event and Allow-Events header, as package name is carried in the Event and Allow-Events header, as
defined in [RFC3265]. defined in [RFC3265].
skipping to change at page 6, line 20 skipping to change at page 6, line 14
notifiers MUST support the "application/resource-lists+xml" data notifiers MUST support the "application/resource-lists+xml" data
format [RFC4826] and its extension to carry consent-related state format [RFC4826] and its extension to carry consent-related state
information, which is specified in Section 4. The SUBSCRIBE request information, which is specified in Section 4. The SUBSCRIBE request
MAY contain an Accept header field. If no such header field is MAY contain an Accept header field. If no such header field is
present, it has a default value of "application/resource-lists+xml". present, it has a default value of "application/resource-lists+xml".
If the header field is present, it MUST include "application/ If the header field is present, it MUST include "application/
resource-lists+xml", and MAY include any other types capable of resource-lists+xml", and MAY include any other types capable of
representing consent-related state. representing consent-related state.
Additionally, all subscribers and notifiers SHOULD support the Additionally, all subscribers and notifiers SHOULD support the
"application/xcap-diff+xml" format [I-D.ietf-simple-xcap-diff]. "application/resource-lists-diff+xml" format. Section 6 discusses
Section 6 discusses the usage of the Pending Additions event package the usage of the Pending Additions event package with this format.
with this format.
5.1.5. Notifier Processing of SUBSCRIBE Requests 5.1.5. Notifier Processing of SUBSCRIBE Requests
The state of the resources to be added to a relay's translation logic The state of the resources to be added to a relay's translation logic
can reveal sensitive information. Therefore, all subscriptions can reveal sensitive information. Therefore, all subscriptions
SHOULD be authenticated and then authorized before approval. SHOULD be authenticated and then authorized before approval.
Authorization policy is at the discretion of the administrator. Authorization policy is at the discretion of the administrator.
5.1.6. Notifier Generation of NOTIFY Requests 5.1.6. Notifier Generation of NOTIFY Requests
skipping to change at page 6, line 47 skipping to change at page 6, line 40
Notifications SHOULD be generated for the Pending Additions package Notifications SHOULD be generated for the Pending Additions package
whenever there is a change in the consent-related state of a whenever there is a change in the consent-related state of a
resource. When a resource moves to the error, denied, or granted resource. When a resource moves to the error, denied, or granted
states, and once a NOTIFY request is sent, the resource is removed states, and once a NOTIFY request is sent, the resource is removed
from further notifications. from further notifications.
5.1.7. Subscriber Processing of NOTIFY Requests 5.1.7. Subscriber Processing of NOTIFY Requests
NOTIFY requests contain full state. The subscriber does not need to NOTIFY requests contain full state. The subscriber does not need to
perform any type of information aggregation. perform any type of information aggregation. Section 6 discusses the
use of the Pending Additions event package with partial
notifications.
5.1.8. Handling of Forked Requests 5.1.8. Handling of Forked Requests
The state of a given resource list is normally handled by a server The state of a given resource list is normally handled by a server
and stored in a repository. Therefore, there is usually a single and stored in a repository. Therefore, there is usually a single
place where the resource-list state is resident. This implies that a place where the resource-list state is resident. This implies that a
subscription for this information is readily handled by a single subscription for this information is readily handled by a single
element with access to this repository. There is, therefore, no element with access to this repository. There is, therefore, no
compelling need for a subscription to pending additions information compelling need for a subscription to pending additions information
to fork. As a result, a subscriber MUST NOT create multiple dialogs to fork. As a result, a subscriber MUST NOT create multiple dialogs
skipping to change at page 7, line 32 skipping to change at page 7, line 28
State agents have no role in the handling of this package. State agents have no role in the handling of this package.
5.1.11. Example 5.1.11. Example
The following is an example of an "application/resource-lists+xml" The following is an example of an "application/resource-lists+xml"
document that carries consent-related state information using document that carries consent-related state information using
<consent-status> elements: <consent-status> elements:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists" <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:cs="urn:ietf:params:xml:ns:consent-status"> xmlns:cs="urn:ietf:params:xml:ns:consent-status">
<list> <list>
<entry uri="sip:bill@example.com"> <entry uri="sip:bill@example.com">
<display-name>Bill Doe</display-name> <display-name>Bill Doe</display-name>
<cs:consent-status>pending</cs:consent-status> <cs:consent-status>pending</cs:consent-status>
</entry> </entry>
<entry uri="sip:joe@example.com"> <entry uri="sip:joe@example.com">
<display-name>Joe Smith</display-name> <display-name>Joe Smith</display-name>
<cs:consent-status>pending</cs:consent-status> <cs:consent-status>pending</cs:consent-status>
</entry> </entry>
<entry uri="sip:nancy@example.com"> <entry uri="sip:nancy@example.com">
<display-name>Nancy Gross</display-name> <display-name>Nancy Gross</display-name>
<cs:consent-status>granted</cs:consent-status> <cs:consent-status>granted</cs:consent-status>
</entry> </entry>
</list> </list>
</resource-lists> </resource-lists>
6. Usage of the Pending Additions Event Package with the XCAP Diff 6. Partial Notifications
Format
As discussed in Section 5.1.4, if a client subscribing to the Pending The lists of resources reported by this event package may contain
Additions event package generates an Accept header field that many resources. When the "application/resource-lists+xml" format is
includes the MIME type "application/xcap-diff+xml", the relay has the used and there is a change in the consent-related status of a
option of returning documents in this format (instead of in the resource, the server generates a notification with the whole list.
'application/resource-list+xml' format). Generating large notifications to report small changes does not meet
the efficiency requirements of some bandwidth-constrained
environments. The partial notifications mechanism specified in this
section is a more efficient way to report changes in the status of
resources.
Upon initial subscription, the relay does not know which instance of Subscribers signal support for partial notifications by including the
the resource list document for the user (where each instance is "application/resource-lists-diff+xml" format in the Accept header
identified by an etag) the client currently possesses, if any. field of the SUBSCRIBE requests they generate. If a client
Indeed, upon startup, the client will not have any documents. subscribing to the Pending Additions event package generates an
Accept header field that includes the MIME type "application/
resource-lists-diff+xml", the server has the option of returning
documents in this format (instead of in the "application/
resource-list+xml" format).
The initial NOTIFY request in this case MUST include a <document> 6.1. Generation of Partial Notifications
element for the resource list. The "previous-etag" attribute MUST be
absent, and the "new-etag" attribute MUST be present and contain the
entity tag for the current version of the document. An XCAP diff
document structured this way is called a "reference" XCAP diff
document. It establishes the baseline etag and document URI for the
document covered by the subscription.
Upon receipt of this document, the client can determine whether its Once a subscription is accepted and installed, the server MUST
local instance document, if any, matches the etag in the XCAP diff deliver full state in its first notification. To report full state,
document. If they do not match, the client SHOULD perform a the server uses the regular format for resource lists. Consequently,
conditional GET for each document. The document URI is constructed the server MUST set the Content-Type header field to the value
by appending the XCAP root in the "xcap-root" attribute of the <xcap- 'application/resource-lists+xml'.
diff> element to the escape coded "doc-selector" from the <document>
element. The request is made conditional by including an If-Match
header field, with the value of the etag from the <document> element.
So long as the documents have not changed between the NOTIFY and the
GET, the client will obtain the reference version that the server
will use for subsequent notifications.
If the conditional GET should fail, the client SHOULD generate a In order to deliver a partial notification, the server MUST set the
SUBSCRIBE refresh request to trigger a new NOTIFY. The server will Content-Type header field to the value 'application/
always generate a "reference" XML diff document on receipt of a resource-lists-diff+xml'. When the server generates a partial
SUBSCRIBE refresh. This establishes a new baseline etag, and the notification, the server SHOULD only include the information that has
client can then attempt to do another fetch. changed compared to the previous notification. It is up to the
server's local policy to determine what is considered as a change to
the previous state.
Once the client has obtained the version of the document identified The server MUST construct partial notifications according to the
in the reference XML diff, it can process NOTIFY requests on that following logic: all the information that has been added to the
subscription. To process the NOTIFY requests, it makes sure that its document is listed inside <add> elements. All information that has
current version matches the version in the "previous-etag" attribute been removed from the document is listed inside <remove> elements and
of the <document> element. If not, the client can then fetch the all information that has been changed is listed under <replace>
updated document from the server. If they do match, the client has elements.
the most current version.
The server MUST NOT send a new NOTIFY request with a partial
notification until it has received a final response from the
subscriber for the previous one or the previous NOTIFY request has
timed out.
When the server receives a SUBSCRIBE request (refresh or termination)
within the associated subscription, it SHOULD send a NOTIFY request
containing the full document using the 'application/
resource-lists+xml' content type.
If the server has used a content type other than 'application/
resource-lists+xml' in notifications within the existing subscription
and changes to deliver partial notifications, the server MUST deliver
full state using the 'application/resource-lists+xml' content type
before generating its first partial notification.
6.2. Processing of Partial Notifications
When a subscriber receives the first notification containing full
state in a 'application/resource-lists+xml' MIME body, the subscriber
MUST store the received full document as its local copy.
When the subscriber receives a subsequent notification, the
subscriber MUST modify its locally-stored information according to
the following logic:
o If the notification carries a 'application/resource-lists+xml'
document, the subscriber MUST replace its local copy of the
document with the document received in notification.
o If the notification carries a 'application/
resource-lists-diff+xml' document, the subscriber MUST apply the
changes indicated in the received 'application/
resource-lists-diff+xml' document to its local copy of the full
document.
If subscriber encounters a processing error while processing a
'application/resource-lists-diff+xml' encoded document, the
subscriber SHOULD renew its subscription. A subscriber can fall back
to normal operations by not including the "application/
resource-list-diff+xml' format in a new SUBSCRIBE request.
If the server changes the content type used in notifications within
the existing subscription, the subscriber MUST discard all the
previously received information and process the new content as
specified for that content type.
6.3. XML Schema for Partial Notifications
This is the XML schema for the "application/resource-lists-diff+xml"
data format. The "urn:ietf:params:xml:schema:xml-patch-ops" schema
is defined in [I-D.ietf-simple-xml-patch-ops].
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:resource-lists"
xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<!-- include patch-ops type definitions -->
<xs:include
schemaLocation="urn:ietf:params:xml:schema:patch-ops"/>
<!-- partial updates -->
<xs:element name="resource-lists-diff">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:choice>
<xs:element name="add">
<xs:complexType mixed="true">
<xs:complexContent>
<xs:extension base="add">
<xs:anyAttribute processContents="lax"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="remove">
<xs:complexType>
<xs:complexContent>
<xs:extension base="remove">
<xs:anyAttribute processContents="lax"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="replace">
<xs:complexType mixed="true">
<xs:complexContent>
<xs:extension base="replace">
<xs:anyAttribute processContents="lax"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:any namespace="##other" processContents="lax"/>
</xs:choice>
</xs:sequence>
<xs:anyAttribute processContents="lax"/>
</xs:element>
</xs:schema>
6.4. Examples
Section 5.1.11 contains and example of an 'application/
resource-lists+xml' document, which carries full state. The
following is an 'application/resource-lists-diff+xml' partial update
document:
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists-diff xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:cs="urn:ietf:params:xml:ns:consent-status">
<replace
sel="*/list/entry[@uri='sip:bill@example.com']/cs:consent-status/text()"
>granted</replace>
</resource-lists-diff>
The following is the resulting 'application/resource-lists+xml'
document after applying the partial update:
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:cs="urn:ietf:params:xml:ns:consent-status">
<list>
<entry uri="sip:bill@example.com">
<display-name>Bill Doe</display-name>
<cs:consent-status>granted</cs:consent-status>
</entry>
<entry uri="sip:joe@example.com">
<display-name>Joe Smith</display-name>
<cs:consent-status>pending</cs:consent-status>
</entry>
<entry uri="sip:nancy@example.com">
<display-name>Nancy Gross</display-name>
<cs:consent-status>granted</cs:consent-status>
</entry>
</list>
</resource-lists>
7. IANA Considerations 7. IANA Considerations
There are three IANA considerations associated with this There are five IANA considerations associated with this
specification. specification.
7.1. SIP Event Package Registration 7.1. SIP Event Package Registration
This specification registers a SIP event package per the procedures This specification registers a SIP event package per the procedures
in [RFC3265]. in [RFC3265].
Package name: consent-pending-additions Package name: consent-pending-additions
Type: package Type: package
Contact: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Contact: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Published Specification: RFC XXXX. (Note to the RFC Editor: Please Published Specification: RFC XXXX. (Note to the RFC Editor: Please
replace XXXX with the RFC Number of this specification.) replace XXXX with the RFC Number of this specification.)
7.2. URN Sub-Namespace Registration 7.2. URN Sub-Namespace Registration: consent-status
This section registers a new XML namespace per the procedures in This section registers a new XML namespace per the procedures in
[RFC3688]. [RFC3688].
URI: The URI for this namespace is URI: The URI for this namespace is
urn:ietf:params:xml:ns:consent-status urn:ietf:params:xml:ns:consent-status
Registrant Contact: IETF SIPPING working group, <sipping@ietf.org>, Registrant Contact: IETF SIPPING working group, <sipping@ietf.org>,
Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
XML: XML:
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"> <html xmlns="http://www.w3.org/1999/xhtml">
<head> <head>
<meta http-equiv="content-type" <meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/> content="text/html;charset=iso-8859-1"/>
<title>Pending Additions Extension Namespace</title> <title>Pending Additions Extension Namespace</title>
skipping to change at page 10, line 24 skipping to change at page 13, line 5
</head> </head>
<body> <body>
<h1>Namespace for Consent-related Status Information Extension</h1> <h1>Namespace for Consent-related Status Information Extension</h1>
<h2>urn:ietf:params:xml:ns:consent-status</h2> <h2>urn:ietf:params:xml:ns:consent-status</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX [[NOTE TO <p>See <a href="[URL of published RFC]">RFCXXXX [[NOTE TO
RFC-EDITOR/IANA: Please replace XXXX with the RFC Number of RFC-EDITOR/IANA: Please replace XXXX with the RFC Number of
this specification]]</a>.</p> this specification]]</a>.</p>
</body> </body>
</html> </html>
7.3. XML Schema Registration 7.3. XML Schema Registration: consent-status
This section registers an XML schema per the procedures in [RFC3688]. This section registers an XML schema per the procedures in [RFC3688].
URI: urn:ietf:params:xml:schema:consent-status. URI: urn:ietf:params:xml:schema:consent-status.
Registrant Contact: IETF SIPPING working group, <sipping@ietf.org>, Registrant Contact: IETF SIPPING working group, <sipping@ietf.org>,
Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
The XML for this schema can be found in Section 4. The XML for this schema can be found in Section 4.
7.4. XML Schema Registration: resource-lists
This section registers an XML schema per the procedures in [RFC3688].
This XML schema is an extension to the XML schema (whose ID is
resource-list) defined in [RFC4826]. The IANA is requested to add a
row in the XML schema registry with the following values:
ID: resource-list-diff
URI: urn:ietf:params:xml:schema:resource-lists-diff
Filename: resource-lists-diff
Reference [RFCxxxx]
(Note to the RFC Editor: Please replace XXXX with the RFC Number of
this specification.)
Registrant Contact: IETF SIPPING working group, <sipping@ietf.org>,
Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
The XML for this schema can be found in Section 6.3.
7.5. MIME type Registration: application/resource-lists-diff+xml
This section registers the 'application/resource-lists-diff+xml' MIME
type.
MIME media type name: application
MIME subtype name: resource-lists-diff+xml
Mandatory parameters: none
Optional Parameters: Same as charset parameter application/xml as
specified in [RFC3023].
Encoding considerations: Same as encoding considerations of
application/xml as specified in [RFC3023].
Security considerations: Security considerations: See Section 10 of
[RFC3023] and Section 7 of [RFC4826].
Interoperability considerations: none
Published specification: RFC xxxx (Note to the RFC Editor: Please
replace XXXX with the RFC Number of this specification.)
Applications that use this media type: This document type has been
defined to support partial notifications in subscriptions to
resource lists.
Additional Information:
Magic Number: none
File extension: .rld
Macintosh file type code: "TEXT"
Personal and email address for further information: Gonzalo
Camarillo <Gonzalo.Camarillo@ericsson.com>
Intended usage: COMMON
Author/Change controller: The IETF.
8. Security Considerations 8. Security Considerations
The Framework for Consent-based Communications in the Session The Framework for Consent-based Communications in the Session
Initiation Protocol (SIP) [I-D.ietf-sip-consent-framework] discusses Initiation Protocol (SIP) [I-D.ietf-sip-consent-framework] discusses
security-related issues that are related to this specification. security-related issues that are related to this specification.
Subscriptions to the Pending Additions even package can reveal Subscriptions to the Pending Additions even package can reveal
sensitive information. For this reason, it is RECOMMENDED that sensitive information. For this reason, it is RECOMMENDED that
relays use strong means for authentication and information relays use strong means for authentication and information
confidentiality. Additionally, attackers may attempt to modify the confidentiality. Additionally, attackers may attempt to modify the
contents of the notifications sent by a relay to its clients. contents of the notifications sent by a relay to its subscribers.
Consequently, it is RECOMMENDED that relays use a strong means for Consequently, it is RECOMMENDED that relays use a strong means for
information integrity protection. information integrity protection.
It is RECOMMENDED that relays authenticate subscribers using the It is RECOMMENDED that relays authenticate subscribers using the
normal SIP authentication mechanisms, such as Digest, as defined in normal SIP authentication mechanisms, such as Digest, as defined in
[RFC3261]. [RFC3261].
The mechanism used for conveying information to clients SHOULD ensure The mechanism used for conveying information to subscribers SHOULD
the integrity and confidentially of the information. In order to ensure the integrity and confidentially of the information. In order
achieve these, an end-to-end SIP encryption mechanism, such as to achieve these, an end-to-end SIP encryption mechanism, such as
S/MIME, as described in [RFC3261], SHOULD be used. S/MIME, as described in [RFC3261], SHOULD be used.
If strong end-to-end security means (such as above) is not available, If strong end-to-end security means (such as above) is not available,
it is RECOMMENDED that hop-by-hop security based on TLS and SIPS it is RECOMMENDED that hop-by-hop security based on TLS and SIPS
URIs, as described in [RFC3261], is used. URIs, as described in [RFC3261], is used.
9. Acknowledgements 9. Acknowledgements
Jonathan Rosenberg provided useful ideas on this document. Ben Jonathan Rosenberg provided useful ideas on this document. Ben
Campbell and Mary Barnes performed a thorough review of this Campbell and Mary Barnes performed a thorough review of this
document. document. Jari Urpalainen helped improve the partial notifications
mechanism.
10. Normative References 10. 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.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[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.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002. Event Notification", RFC 3265, June 2002.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats [RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats
for Representing Resource Lists", RFC 4826, May 2007. for Representing Resource Lists", RFC 4826, May 2007.
[I-D.ietf-simple-xcap-diff] [I-D.ietf-simple-xml-patch-ops]
Rosenberg, J., "An Extensible Markup Language (XML) Urpalainen, J., "An Extensible Markup Language (XML) Patch
Document Format for Indicating A Change in XML Operations Framework Utilizing XML Path Language (XPath)
Configuration Access Protocol (XCAP) Resources", Selectors", draft-ietf-simple-xml-patch-ops-02 (work in
draft-ietf-simple-xcap-diff-05 (work in progress), progress), March 2006.
March 2007.
[I-D.ietf-sip-consent-framework] [I-D.ietf-sip-consent-framework]
Rosenberg, J., "A Framework for Consent-Based Rosenberg, J., "A Framework for Consent-Based
Communications in the Session Initiation Protocol (SIP)", Communications in the Session Initiation Protocol (SIP)",
draft-ietf-sip-consent-framework-01 (work in progress), draft-ietf-sip-consent-framework-01 (work in progress),
November 2006. November 2006.
Author's Address Author's Address
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Gonzalo.Camarillo@ericsson.com Email: Gonzalo.Camarillo@ericsson.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 32 change blocks. 
91 lines changed or deleted 288 lines changed or added

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