draft-ietf-sipping-pending-additions-05.txt   rfc5362.txt 
SIPPING G. Camarillo Network Working Group G. Camarillo
Internet-Draft Ericsson Request for Comments: 5362 Ericsson
Intended status: Standards Track May 26, 2008 Category: Standards Track October 2008
Expires: November 27, 2008
The Session Initiation Protocol (SIP) Pending Additions Event Package The Session Initiation Protocol (SIP) Pending Additions Event Package
draft-ietf-sipping-pending-additions-05.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any Status of This Memo
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 27, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008). This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
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 . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . 7 5.1.8. Handling of Forked Requests .........................7
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. Partial Notifications . . . . . . . . . . . . . . . . . . . . 8 6. Partial Notifications ...........................................8
6.1. Generation of Partial Notifications . . . . . . . . . . . 8 6.1. Generation of Partial Notifications ........................8
6.2. Processing of Partial Notifications . . . . . . . . . . . 9 6.2. Processing of Partial Notifications ........................9
6.3. XML Schema for Partial Notifications . . . . . . . . . . . 10 6.3. XML Schema for Partial Notifications .......................9
6.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.4. Examples ..................................................11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations ............................................11
7.1. SIP Event Package Registration . . . . . . . . . . . . . . 13 7.1. SIP Event Package Registration ............................11
7.2. URN Sub-Namespace Registration: consent-status . . . . . . 13 7.2. URN Sub-Namespace Registration: consent-status ............12
7.3. XML Schema Registration: consent-status . . . . . . . . . 14 7.3. XML Schema Registration: consent-status ...................12
7.4. XML Schema Registration: resource-lists . . . . . . . . . 14 7.4. XML Schema Registration: resource-lists ...................13
7.5. MIME type Registration: 7.5. MIME Type Registration:
application/resource-lists-diff+xml . . . . . . . . . . . 14 application/resource-lists-diff+xml .......................13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations ........................................14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgments ................................................14
10. Normative References . . . . . . . . . . . . . . . . . . . . . 16 10. Normative References ..........................................14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 18
1. Introduction 1. Introduction
The framework for consent-based communications in SIP The framework for consent-based communications in SIP [RFC5360]
[I-D.ietf-sip-consent-framework] identifies the need for users identifies the need for users manipulating the translation logic at a
manipulating the translation logic at a relay (e.g., adding a new relay (e.g., adding a new recipient) to be informed about the
recipient) to be informed about the consent-related status of the consent-related status of the recipients of a given translation.
recipients of a given translation. That is, the user manipulating That is, the user manipulating the translation logic needs to know
the translation logic needs to know which recipients have given the which recipients have given the relay permission to send them SIP
relay permission to send them SIP requests. requests.
This document defines a SIP event package whereby user agents can This document defines a SIP event package whereby user agents can
subscribe to the consent-related state of the resources that are subscribe to the consent-related state of the resources that are
being added to a resource list that defines a translation. being added to a resource list that defines a translation.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 3, line 36 skipping to change at page 3, line 36
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/resource-lists-diff+xml" format, which is based in the "application/resource-lists-diff+xml" format, which is based
on XML patch operations [I-D.ietf-simple-xml-patch-ops]. on XML patch operations [RFC5261].
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. A document in the "application/resource-lists-diff+xml" resources. A document in the "application/resource-lists-diff+xml"
format provides the user agent with the changes the list of resources format provides the user agent with the changes the list of resources
being added has experimented since the last notification sent to the being added has experimented with since the last notification sent to
user agent. the user agent.
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 4, line 45 skipping to change at page 4, line 44
Pending: the relay has received a request to add a resource to its Pending: the relay has received a request to add a resource to its
translation logic and will ask for permission to do so. translation logic and will ask for permission to do so.
Waiting: the relay has requested permission to add the resource to Waiting: the relay has requested permission to add the resource to
its translation logic but has not gotten any answer from the its translation logic but has not gotten any answer from the
resource yet. resource yet.
Error: the relay has requested permission to add the resource to its Error: the relay has requested permission to add the resource to its
translation logic and has received an error response (e.g., a SIP translation logic and has received an error response (e.g., a SIP
error response to the MESSAGE request send to request permission). error response to the MESSAGE request sent 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/ Section 5.1.11 contains an example of an "application/resource-
resource-lists+xml" document that carries consent-related state lists+xml" document that carries consent-related state information
information using <consent-status> elements. 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]. Support for this notification package, as specified by [RFC3265]. Support for this
section (i.e., Section 5) is REQUIRED for implementations of this section (i.e., Section 5) is REQUIRED for implementations of this
specification. Support for partial notifications is optional, but if specification. Support for partial notifications is optional, but if
a subscriber signals support for partial notifications, Section 6 a subscriber signals support for partial notifications, Section 6
MUST be implemented. MUST be implemented.
skipping to change at page 6, line 15 skipping to change at page 6, line 8
5.1.4. NOTIFY Bodies 5.1.4. NOTIFY Bodies
In this event package, the body of the notifications contains a In this event package, the body of the notifications contains a
resource list document. This document describes the resources being resource list document. This document describes the resources being
added as recipients to a translation operation. All subscribers and added as recipients to a translation operation. All subscribers and
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
resource-lists+xml", and MAY include any other types capable of "application/resource-lists+xml", and MAY include any other types
representing consent-related state. capable of representing consent-related state.
Additionally, all subscribers and notifiers SHOULD support the Additionally, all subscribers and notifiers SHOULD support the
"application/resource-lists-diff+xml" format. Section 6 discusses "application/resource-lists-diff+xml" format. Section 6 discusses
the usage of the Pending Additions event package with this format. the usage of the Pending Additions event package 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.
skipping to change at page 6, line 45 skipping to change at page 6, line 38
<any> element within the <entry> element. <any> element within the <entry> element.
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
As stated in Section 3, a document in the "application/ As stated in Section 3, a document in the "application/resource-
resource-lists+xml" format provides the subscriber with the whole lists+xml" format provides the subscriber with the whole list of
list of resources being added to a resource list along with the resources being added to a resource list along with the consent-
consent-related status of those resources. On receiving a NOTIFY related status of those resources. On receiving a NOTIFY request
request with such a document, the subscriber SHOULD update its local with such a document, the subscriber SHOULD update its local
information about the resources being added to the resource list with information about the resources being added to the resource list with
the information in the document. NOTIFY requests contain full state. the information in the document. NOTIFY requests contain full state.
The subscriber does not need to perform any type of information The subscriber does not need to perform any type of information
aggregation. Section 6 discusses the use of the Pending Additions aggregation. Section 6 discusses the use of the Pending Additions
event package with partial notifications. 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
skipping to change at page 8, line 40 skipping to change at page 8, line 21
Generating large notifications to report small changes does not meet Generating large notifications to report small changes does not meet
the efficiency requirements of some bandwidth-constrained the efficiency requirements of some bandwidth-constrained
environments. The partial notifications mechanism specified in this environments. The partial notifications mechanism specified in this
section is a more efficient way to report changes in the status of section is a more efficient way to report changes in the status of
resources. resources.
Subscribers signal support for partial notifications by including the Subscribers signal support for partial notifications by including the
"application/resource-lists-diff+xml" format in the Accept header "application/resource-lists-diff+xml" format in the Accept header
field of the SUBSCRIBE requests they generate. If a client field of the SUBSCRIBE requests they generate. If a client
subscribing to the Pending Additions event package generates an subscribing to the Pending Additions event package generates an
Accept header field that includes the MIME type "application/ Accept header field that includes the MIME type
resource-lists-diff+xml", the server has the option of returning "application/resource-lists-diff+xml", the server has the option of
documents in this format (instead of in the "application/ returning documents in this format (instead of in the
resource-list+xml" format). "application/resource-list+xml" format).
6.1. Generation of Partial Notifications 6.1. Generation of Partial Notifications
Once a subscription is accepted and installed, the server MUST Once a subscription is accepted and installed, the server MUST
deliver full state in its first notification. To report full state, deliver full state in its first notification. To report full state,
the server uses the regular format for resource lists. Consequently, the server uses the regular format for resource lists. Consequently,
the server MUST set the Content-Type header field to the value the server MUST set the Content-Type header field to the value
'application/resource-lists+xml'. 'application/resource-lists+xml'.
In order to deliver a partial notification, the server MUST set the In order to deliver a partial notification, the server MUST set the
Content-Type header field to the value 'application/ Content-Type header field to the value 'application/resource-lists-
resource-lists-diff+xml'. When the server generates a partial diff+xml'. When the server generates a partial notification, the
notification, the server SHOULD only include the information that has server SHOULD only include the information that has changed since the
changed compared to the previous notification. It is up to the previous notification. It is up to the server's local policy to
server's local policy to determine what is considered as a change to determine what is considered as a change to the previous state.
the previous state.
The server MUST construct partial notifications according to the The server MUST construct partial notifications according to the
following logic: all the information that has been added to the following logic: all information that has been added to the document
document is listed inside <add> elements. All information that has is listed inside <add> elements, all information that has been
been removed from the document is listed inside <remove> elements and removed from the document is listed inside <remove> elements, and all
all information that has been changed is listed under <replace> information that has been changed is listed under <replace> elements.
elements.
The server MUST NOT send a new NOTIFY request with a partial The server MUST NOT send a new NOTIFY request with a partial
notification until it has received a final response from the notification until it has received a final response from the
subscriber for the previous one or the previous NOTIFY request has subscriber for the previous one or the previous NOTIFY request has
timed out. timed out.
When the server receives a SUBSCRIBE request (refresh or termination) When the server receives a SUBSCRIBE request (refresh or termination)
within the associated subscription, it SHOULD send a NOTIFY request within the associated subscription, it SHOULD send a NOTIFY request
containing the full document using the 'application/ containing the full document using the 'application/resource-
resource-lists+xml' content type. lists+xml' content type.
If the server has used a content type other than 'application/ If the server has used a content type other than
resource-lists+xml' in notifications within the existing subscription 'application/resource-lists+xml' in notifications within the existing
and changes to deliver partial notifications, the server MUST deliver subscription and changes to deliver partial notifications, the server
full state using the 'application/resource-lists+xml' content type MUST deliver full state using the 'application/resource-lists+xml'
before generating its first partial notification. content type before generating its first partial notification.
6.2. Processing of Partial Notifications 6.2. Processing of Partial Notifications
When a subscriber receives the first notification containing full When a subscriber receives the first notification containing full
state in a 'application/resource-lists+xml' MIME body, the subscriber state in a 'application/resource-lists+xml' MIME body, the subscriber
MUST store the received full document as its local copy. MUST store the received full document as its local copy.
When the subscriber receives a subsequent notification, the When the subscriber receives a subsequent notification, the
subscriber MUST modify its locally-stored information according to subscriber MUST modify its locally stored information according to
the following logic: the following logic:
o If the notification carries a 'application/resource-lists+xml' o If the notification carries an %'application/resource-lists+xml'
document, the subscriber MUST replace its local copy of the document, the subscriber MUST replace its local copy of the
document with the document received in notification. document with the document received in notification.
o If the notification carries a 'application/ o If the notification carries an 'application/resource-lists-
resource-lists-diff+xml' document, the subscriber MUST apply the diff+xml' document, the subscriber MUST apply the changes
changes indicated in the received 'application/ indicated in the received 'application/resource-lists-diff+xml'
resource-lists-diff+xml' document to its local copy of the full document to its local copy of the full document.
document.
If subscriber encounters a processing error while processing a If a subscriber encounters a processing error while processing an
'application/resource-lists-diff+xml' encoded document, the 'application/resource-lists-diff+xml' encoded document, the
subscriber SHOULD renew its subscription. A subscriber can fall back subscriber SHOULD renew its subscription. A subscriber can fall back
to normal operations by not including the "application/ to normal operations by not including the 'application/resource-
resource-list-diff+xml' format in a new SUBSCRIBE request. list-diff+xml' format in a new SUBSCRIBE request.
If the server changes the content type used in notifications within If the server changes the content type used in notifications within
the existing subscription, the subscriber MUST discard all the the existing subscription, the subscriber MUST discard all the
previously received information and process the new content as previously received information and process the new content as
specified for that content type. specified for that content type.
6.3. XML Schema for Partial Notifications 6.3. XML Schema for Partial Notifications
This is the XML schema for the "application/resource-lists-diff+xml" This is the XML schema for the "application/resource-lists-diff+xml"
data format. The "urn:ietf:params:xml:schema:xml-patch-ops" schema data format. The "urn:ietf:params:xml:schema:xml-patch-ops" schema
is defined in [I-D.ietf-simple-xml-patch-ops]. is defined in [RFC5261].
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema <xs:schema
targetNamespace="urn:ietf:params:xml:ns:resource-lists" targetNamespace="urn:ietf:params:xml:ns:resource-lists"
xmlns="urn:ietf:params:xml:ns:resource-lists" xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"> elementFormDefault="qualified">
<!-- include patch-ops type definitions --> <!-- include patch-ops type definitions -->
<xs:include <xs:include
skipping to change at page 12, line 7 skipping to change at page 11, line 7
</xs:element> </xs:element>
<xs:any namespace="##other" processContents="lax"/> <xs:any namespace="##other" processContents="lax"/>
</xs:choice> </xs:choice>
</xs:sequence> </xs:sequence>
<xs:anyAttribute processContents="lax"/> <xs:anyAttribute processContents="lax"/>
</xs:element> </xs:element>
</xs:schema> </xs:schema>
6.4. Examples 6.4. Examples
Section 5.1.11 contains and example of an 'application/ Section 5.1.11 contains an example of an 'application/resource-
resource-lists+xml' document, which carries full state. The lists+xml' document, which carries full state. The following is an
following is an 'application/resource-lists-diff+xml' partial update 'application/resource-lists-diff+xml' partial update document:
document:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<resource-lists-diff xmlns="urn:ietf:params:xml:ns:resource-lists" <resource-lists-diff xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:cs="urn:ietf:params:xml:ns:consent-status"> xmlns:cs="urn:ietf:params:xml:ns:consent-status">
<replace <replace
sel="*/list/entry[@uri='sip:bill@example.com']/cs:consent-status/text()" sel="*/list/entry[@uri='sip:bill@example.com']/cs:consent-status/text()"
>granted</replace> >granted</replace>
</resource-lists-diff> </resource-lists-diff>
skipping to change at page 13, line 16 skipping to change at page 12, line 11
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 5362.
replace XXXX with the RFC Number of this specification.)
7.2. URN Sub-Namespace Registration: consent-status 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>
</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="http://www.rfc-editor.org/rfc/rfc5362.txt">RFC 5362
RFC-EDITOR/IANA: Please replace XXXX with the RFC Number of </a>.</p>
this specification]]</a>.</p>
</body> </body>
</html> </html>
7.3. XML Schema Registration: consent-status 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 7.4. XML Schema Registration: resource-lists
This section registers an XML schema per the procedures in [RFC3688]. This section registers an XML schema per the procedures in [RFC3688].
This XML schema is an extension to the XML schema (whose ID is 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 resource-list) defined in [RFC4826]. The IANA has added a row in the
row in the XML schema registry with the following values: XML schema registry with the following values:
ID: resource-list-diff ID: resource-list-diff
URI: urn:ietf:params:xml:schema:resource-lists-diff URI: urn:ietf:params:xml:schema:resource-lists-diff
Filename: resource-lists-diff Filename: resource-lists-diff
Reference [RFCxxxx] Reference [RFC5362]
(Note to the RFC Editor: Please replace XXXX with the RFC Number of
this specification.)
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 6.3. The XML for this schema can be found in Section 6.3.
7.5. MIME type Registration: application/resource-lists-diff+xml 7.5. MIME Type Registration: application/resource-lists-diff+xml
This section registers the 'application/resource-lists-diff+xml' MIME This section registers the 'application/resource-lists-diff+xml' MIME
type. type.
MIME media type name: application MIME media type name: application
MIME subtype name: resource-lists-diff+xml MIME subtype name: resource-lists-diff+xml
Mandatory parameters: none Mandatory parameters: none
Optional Parameters: Same as charset parameter application/xml as Optional parameters: Same as charset parameter application/xml as
specified in [RFC3023]. specified in [RFC3023].
Encoding considerations: Same as encoding considerations of Encoding considerations: Same as encoding considerations of
application/xml as specified in [RFC3023]. application/xml as specified in [RFC3023].
Security considerations: Security considerations: See Section 10 of Security considerations: See Section 10 of [RFC3023] and Section 7 of
[RFC3023] and Section 7 of [RFC4826]. [RFC4826].
Interoperability considerations: none Interoperability considerations: none
Published specification: RFC xxxx (Note to the RFC Editor: Please Published specification: RFC 5362
replace XXXX with the RFC Number of this specification.)
Applications that use this media type: This document type has been Applications that use this media type: This document type has been
defined to support partial notifications in subscriptions to defined to support partial notifications in subscriptions to
resource lists. resource lists.
Additional Information: Additional Information:
Magic Number: none Magic number: none
File extension: .rld File extension: .rld
Macintosh file type code: "TEXT" Macintosh file type code: "TEXT"
Personal and email address for further information: Gonzalo Personal and email address for further information: Gonzalo
Camarillo <Gonzalo.Camarillo@ericsson.com> Camarillo <Gonzalo.Camarillo@ericsson.com>
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: The IETF. Author/Change controller: The IETF
8. Security Considerations 8. Security Considerations
The Framework for Consent-based Communications in the Session "A Framework for Consent-Based Communications in the Session
Initiation Protocol (SIP) [I-D.ietf-sip-consent-framework] discusses Initiation Protocol (SIP)" [RFC5360] discusses security-related
security-related issues that are related to this specification. issues that are related to this specification.
Subscriptions to the Pending Additions even package can reveal Subscriptions to the Pending Additions event 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 subscribers. 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 subscribers SHOULD The mechanism used for conveying information to subscribers SHOULD
ensure the integrity and confidentially of the information. In order ensure the integrity and confidentially of the information. In order
to 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. Acknowledgments
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. Jari Urpalainen helped improve the partial notifications document. Jari Urpalainen helped improve the partial notifications
mechanism. 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.
skipping to change at page 16, line 34 skipping to change at page 15, line 14
[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.
[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-xml-patch-ops] [RFC5261] Urpalainen, J., "An Extensible Markup Language (XML) Patch
Urpalainen, J., "An Extensible Markup Language (XML) Patch
Operations Framework Utilizing XML Path Language (XPath) Operations Framework Utilizing XML Path Language (XPath)
Selectors", draft-ietf-simple-xml-patch-ops-04 (work in Selectors", RFC 5261, September 2008.
progress), November 2007.
[I-D.ietf-sip-consent-framework] [RFC5360] Rosenberg, J., Camarillo, G., and D. Willis, "A Framework
Rosenberg, J., Camarillo, G., and D. Willis, "A Framework for Consent-Based Communications in the Session Initiation
for Consent-based Communications in the Session Initiation Protocol (SIP)", RFC 5360, October 2008.
Protocol (SIP)", draft-ietf-sip-consent-framework-04 (work
in progress), January 2008.
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 (2008). 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
skipping to change at page 18, line 44 skipping to change at line 696
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 46 change blocks. 
163 lines changed or deleted 124 lines changed or added

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