draft-ietf-sipping-pending-additions-04.txt   draft-ietf-sipping-pending-additions-05.txt 
SIPPING G. Camarillo SIPPING G. Camarillo
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track February 15, 2008 Intended status: Standards Track May 26, 2008
Expires: August 18, 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-04.txt draft-ietf-sipping-pending-additions-05.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 August 18, 2008. This Internet-Draft will expire on November 27, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). 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.
skipping to change at page 2, line 16 skipping to change at page 2, line 16
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 . . . . . . . . . . . . . . . . . . . . 5 5.1.4. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . 9 6.3. XML Schema for Partial Notifications . . . . . . . . . . . 10
6.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7.1. SIP Event Package Registration . . . . . . . . . . . . . . 12 7.1. SIP Event Package Registration . . . . . . . . . . . . . . 13
7.2. URN Sub-Namespace Registration: consent-status . . . . . . 12 7.2. URN Sub-Namespace Registration: consent-status . . . . . . 13
7.3. XML Schema Registration: consent-status . . . . . . . . . 13 7.3. XML Schema Registration: consent-status . . . . . . . . . 14
7.4. XML Schema Registration: resource-lists . . . . . . . . . 13 7.4. XML Schema Registration: resource-lists . . . . . . . . . 14
7.5. MIME type Registration: 7.5. MIME type Registration:
application/resource-lists-diff+xml . . . . . . . . . . . 13 application/resource-lists-diff+xml . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
10. Normative References . . . . . . . . . . . . . . . . . . . . . 15 10. Normative References . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17 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
[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 5, line 18 skipping to change at page 5, line 18
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-lists+xml" document that carries consent-related state resource-lists+xml" document that carries consent-related state
information using <consent-status> elements. 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]. Support for this
section (i.e., Section 5) is REQUIRED for implementations of this
specification. Support for partial notifications is optional, but if
a subscriber signals support for partial notifications, Section 6
MUST be implemented.
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].
5.1.1. Event Package Parameters 5.1.1. Event Package Parameters
This package does not define any event package parameters. This package does not define any event package parameters.
5.1.2. SUBSCRIBE Bodies 5.1.2. SUBSCRIBE Bodies
A SUBSCRIBE for Pending Additions events MAY contain a body. This A SUBSCRIBE for Pending Additions events MAY contain a body. This
body would serve the purpose of filtering the subscription. The body would serve the purpose of filtering the subscription. Filter
definition of such a body is outside the scope of this specification. documents are not specified in this document and, at the time of
writing, they are expected to be the subject of future
standardization activity.
A SUBSCRIBE for the Pending Additions event package MAY be sent A SUBSCRIBE for the Pending Additions event package MAY be sent
without a body. This implies that the default session policy without a body. This implies that the default session policy
filtering policy has been requested. The default policy is that filtering policy has been requested. The default policy is that
notifications are generated every time there is any change in the notifications are generated every time there is any change in the
state of a resource in the list. state of a resource in the list.
5.1.3. Subscription Duration 5.1.3. Subscription Duration
The default expiration time for a subscription is one hour (3600 The default expiration time for a subscription is one hour (3600
skipping to change at page 6, line 39 skipping to change at page 6, line 45
<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
NOTIFY requests contain full state. The subscriber does not need to As stated in Section 3, a document in the "application/
perform any type of information aggregation. Section 6 discusses the resource-lists+xml" format provides the subscriber with the whole
use of the Pending Additions event package with partial list of resources being added to a resource list along with the
notifications. consent-related status of those resources. On receiving a NOTIFY
request with such a document, the subscriber SHOULD update its local
information about the resources being added to the resource list with
the information in the document. NOTIFY requests contain full state.
The subscriber does not need to 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 15, line 37 skipping to change at page 16, line 37
[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] [I-D.ietf-simple-xml-patch-ops]
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-02 (work in Selectors", draft-ietf-simple-xml-patch-ops-04 (work in
progress), March 2006. progress), November 2007.
[I-D.ietf-sip-consent-framework] [I-D.ietf-sip-consent-framework]
Rosenberg, J., "A Framework for Consent-Based Rosenberg, J., Camarillo, G., and D. Willis, "A Framework
Communications in the Session Initiation Protocol (SIP)", for Consent-based Communications in the Session Initiation
draft-ietf-sip-consent-framework-01 (work in progress), Protocol (SIP)", draft-ietf-sip-consent-framework-04 (work
November 2006. 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
 End of changes. 13 change blocks. 
33 lines changed or deleted 45 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/