SIPPING G. Camarillo Internet-Draft Ericsson Expires: August 29, 2006 February 25, 2006 The Session Initiation Protocol (SIP) List State Event Package draft-camarillo-sipping-list-state-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any 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 August 29, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines the SIP List State event package. This event package is used by Resource List Servers to inform user agents about the consent-related status of the entries in one or several resource lists. Camarillo Expires August 29, 2006 [Page 1] Internet-Draft List State Event Package February 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3 4. List State Event Package Definition . . . . . . . . . . . . . 3 4.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 4 4.1.1. Event Package Parameters . . . . . . . . . . . . . . . 4 4.1.2. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . 4 4.1.3. Subscription Duration . . . . . . . . . . . . . . . . 4 4.1.4. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . 4 4.1.5. Notifier Processing of SUBSCRIBE Requests . . . . . . 5 4.1.6. Notifier Generation of NOTIFY Requests . . . . . . . . 5 4.1.7. Subscriber Processing of NOTIFY Requests . . . . . . . 5 4.1.8. Handling of Forked Requests . . . . . . . . . . . . . 5 4.1.9. Rate of Notifications . . . . . . . . . . . . . . . . 5 4.1.10. State Agents . . . . . . . . . . . . . . . . . . . . . 5 4.1.11. Example . . . . . . . . . . . . . . . . . . . . . . . 6 5. Usage of the 'list-state' Event Package with the XCAP Diff Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. List State RLS Service . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Camarillo Expires August 29, 2006 [Page 2] Internet-Draft List State Event Package February 2006 1. Introduction The framework for consent-based communications in SIP [4] identifies the need for users manipulating the translation logic at a relay (e.g., adding a new recipient) to be informed about the consent- related status of the recipients of a given translation. That is, the user manipulating the translation logic needs to know which recipients have given the relay permission to send them SIP requests. This document defines a SIP event package whereby user agents can subscribe to the state of a resource list that defines a translation. This state includes the consent related-status of the resources of the resource list. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations. 3. Overview of Operation A user agent subscribes to a resource list server using the 'list- state' event package. NOTIFY requests within this event package can carry an XML document in the "application/resource-lists+xml" format [5] or in the "application/xcap-diff+xml" format [6]. A document in the "application/resource-lists+xml" format provides the user agent with the whole resource list, including consent- related state information. A document in the "application/xcap-diff+xml" format informs the user agent that the document that described the resource list has changed. The user agent then downloads the document in the "application/ resource-lists+xml" format from the permission server using XCAP. 4. List State Event Package Definition This section provides the details for defining a SIP [2] event notification package, as specified by RFC 3265 [3]. Camarillo Expires August 29, 2006 [Page 3] Internet-Draft List State Event Package February 2006 4.1. Event Package Name The name of this event package is "list-state". This package name is carried in the Event and Allow-Events header, as defined in RFC 3265 [3]. 4.1.1. Event Package Parameters This package does not define any event package parameters. 4.1.2. SUBSCRIBE Bodies A SUBSCRIBE for 'list-state' events MAY contain a body. This body would serve the purpose of filtering the subscription. The definition of such a body is outside the scope of this specification. A SUBSCRIBE for the 'list-state' package MAY be sent without a body. This implies that the default session policy filtering policy has been requested. The default policy is that notifications are generated every time there is any change in the state of a resource in the list. 4.1.3. Subscription Duration The default expiration time for a subscription is one hour (3600 seconds). 4.1.4. NOTIFY Bodies In this event package, the body of the notifications contains a resource list document. This document describes a resource list and the consent-related state of its resources. All subscribers and notifiers MUST support the "application/resource-lists+xml" data format [5] and its extension to carry consent-related state information [7]. The subscribe request MAY contain an Accept header field. If no such header field is present, it has a default value of "application/resource-lists+xml". If the header field is present, it MUST include "application/resource-lists+xml", and MAY include any other types capable of representing translation state. OPEN ISSUE: do we need to discuss how to use content indirection here? Additionally, all subscribers and notifiers SHOULD support the "application/xcap-diff+xml" format [6]. Section 5 discusses the usage of the 'list-state' event package with this format. Camarillo Expires August 29, 2006 [Page 4] Internet-Draft List State Event Package February 2006 4.1.5. Notifier Processing of SUBSCRIBE Requests The state of a resource list defining a translation can reveal sensitive information. Therefore, all subscriptions SHOULD be authenticated and then authorized before approval. Authorization policy is at the discretion of the administrator. 4.1.6. Notifier Generation of NOTIFY Requests A notifier for the List State event package SHOULD include the element [7] when the framework for consent-based communications in SIP is used. When present, the element MUST be positioned as an instance of the element within the element. Notifications SHOULD be generated for the List State package whenever there is a change in the resource-list state. 4.1.7. Subscriber Processing of NOTIFY Requests NOTIFY requests contain the full resource-list state. The subscriber does not need to perform any type of information aggregation. 4.1.8. Handling of Forked Requests The state of a given resource list is normally handled by a server and stored in a repository. Therefore, there is usually a single place where the resource-list state is resident. This implies that a subscription for this information is readily handled by a single element with access to this repository. There is, therefore, no compelling need for a subscription to session policy information to fork. As a result, a subscriber MUST NOT create multiple dialogs as a result of a single subscription request. The required processing to guarantee that only a single dialog is established is described in Section 4.4.9 of RFC 3265 [3]. 4.1.9. Rate of Notifications For reasons of congestion control, it is important that the rate of notifications not become excessive. As a result, it is RECOMMENDED that the server doesn't generate notifications for a single subscriber at a rate faster than once every 5 seconds. 4.1.10. State Agents State agents have no role in the handling of this package. Camarillo Expires August 29, 2006 [Page 5] Internet-Draft List State Event Package February 2006 4.1.11. Example The following is an example of an "application/xcap-diff+xml" document that carries consent-related state information using elements: Bill Doe pending Joe Smith pending Nancy Gross granted 5. Usage of the 'list-state' Event Package with the XCAP Diff Format As discussed in Section 4.1.4, if a client subscribing to the 'list- state' event package an Accept header field including the MIME type "application/xcap-diff+xml", the permission server has the option of returning documents in this format (instead of in the 'application/ list-state+xml' format). Upon initial subscription, the permission server does not know which instance of the resource list document for the user (where each instance is identified by an etag) the client currently posessses, if any. Indeed, upon startup, the client will not have any documents. The initial NOTIFY request in this case MUST include a 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. Camarillo Expires August 29, 2006 [Page 6] Internet-Draft List State Event Package February 2006 Upon receipt of this document, the client can determine whether its local instance document, if any, matches the etag in the XCAP diff document. If they do not match, the client SHOULD perform a conditional GET for each document. The document URI is constructed by appending the XCAP root in the "xcap-root" attribute of the element to the escape coded "doc-selector" from the element. The request is made conditional by including an If-Match header field, with the value of the etag from the element. So long as the documents haven't 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 SUBSCRIBE refresh request to trigger a new NOTIFY. The server will always generate a "reference" XML diff document on receipt of a SUBSCRIBE refresh. This establishes a new baseline etag, and the client can then attempt to do another fetch. Once the client has obtained the version of the document identified in the reference XML diff, it can process NOTIFY requests on that subscription. To process the NOTIFY requests, it makes sure that its current version matches the version in the "previous-etag" attribute of the element. If not, the client can then fetch the updated document from the server. If they do match, the client has the most current version. 6. List State RLS Service TBD: Define the 'List State' RLS service [5]. Example: presence list state 7. IANA Considerations TBD. 8. Security Considerations TBD. Camarillo Expires August 29, 2006 [Page 7] Internet-Draft List State Event Package February 2006 9. Acknowledgements TBD. 10. References 10.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [4] Rosenberg, J., "A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)", draft-ietf-sipping-consent-framework-03 (work in progress), October 2005. [5] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", draft-ietf-simple-xcap-list-usage-05 (work in progress), February 2005. [6] Rosenberg, J., "An Extensible Markup Language (XML) Document Format for Indicating A Change in XML Configuration Access Protocol (XCAP) Resources", draft-ietf-simple-xcap-diff-02 (work in progress), October 2005. [7] Camarillo, G., "Session Initiation Protocol (SIP) Registration Event Package Extension for Consent-Based Communications", draft-camarillo-sipping-consent-reg-event-00 (work in progress), February 2006. 10.2. Informative References Camarillo Expires August 29, 2006 [Page 8] Internet-Draft List State Event Package February 2006 Author's Address Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Gonzalo.Camarillo@ericsson.com Camarillo Expires August 29, 2006 [Page 9] Internet-Draft List State Event Package February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Camarillo Expires August 29, 2006 [Page 10]