SIMPLE WG M. Lonnfors Internet-Draft Nokia Research Center Expires: April 12, 2005 E. Leppanen Nokia A. Niemi Nokia Research Center October 12, 2004 Partial Publication of Presence Information draft-ietf-simple-partial-publish-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 April 12, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract The size of the published presence information document may be large. As specified in "Event State Publication Extension to the Session Initiation Protocol (SIP)" a presence user agent publishes a full event state of presence information in every publication operation Lonnfors, et al. Expires April 12, 2005 [Page 1] Internet-Draft Partial Publication October 2004 which modifies the current event state. This is done regardless of which presence information has been changed compared to the earlier publications. It may not be reasonable to send the full presence information over low bandwidth and high latency links when only a part of presence information changes. This memo presents a solution that aids in reducing the impact of those constrains and increasing transport efficiency, by introducing a mechanism called partial publication. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions and Document Conventions . . . . . . . . . . . . . 3 3. Overall Operation . . . . . . . . . . . . . . . . . . . . . . 3 3.1 Overall Operation of Event State Publication . . . . . . . 4 3.2 Overview of Partial Publication . . . . . . . . . . . . . 4 4. Client and server operations . . . . . . . . . . . . . . . . . 5 4.1 Content-type for Partial Publications . . . . . . . . . . 5 4.2 Presence User Agent Generation of PUBLISH Requests . . . . 5 4.3 Presence Agent Processing PUBLISH Requests . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . 9 5.2 Access Control . . . . . . . . . . . . . . . . . . . . . . 9 5.3 Replay Prevention . . . . . . . . . . . . . . . . . . . . 9 5.4 Denial of Service Attacks . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1 Normative references . . . . . . . . . . . . . . . . . . . . 10 7.2 Informative references . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . 12 Lonnfors, et al. Expires April 12, 2005 [Page 2] Internet-Draft Partial Publication October 2004 1. Introduction Event State Publication Extension to the Session Initiation Protocol (SIP) [3] allows Presence User Agents ('PUA') to publish presence information of a user ('presentity'). The Presence Agent ('PA') collects publications for a presentity from one or several presence user agents, and generates the composite event state of the presentity. The base format of the presence information is defined in PIDF [4] and used by the Event State Publication Extension to SIP [3]. The presence information is grouped into elements called "tuples". There may also be some presence information outside the tuple elements. More information about the presence information model can be found from RFC 2778 [5]. The size of the published presence information document may be large. As specified in the Event State Publication Extension to SIP [3] a PUA publishes its full event state of presence information in every modify operation of a publication. This is done regardless of what presence information have been changed compared to the earlier publications. It may not be reasonable to send the full presence information over low bandwidth and high latency links when only a part of presence information changes. This memo specifies a mechanism called 'partial publication' for the PUA to be able to publish only changed parts of presence information compared to the information delivered in the previous publications. 2. Definitions and Document Conventions In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant implementations. This document makes use of the vocabulary defined in RFC 2778 [5], the State Publication Extension to SIP [3], and PIDF Extension to Partial Presence [2]. This document introduces the following terms: Publication Context: A sequence of PUBLISH requests starting from an initial publication of an event state and ending at a removal or expiration of the event state. 3. Overall Operation This chapter introduces the basic functionality of the event state publication, and gives an overview of the partial publication Lonnfors, et al. Expires April 12, 2005 [Page 3] Internet-Draft Partial Publication October 2004 mechanism. This section is informational in nature. It does not contain any normative statements. 3.1 Overall Operation of Event State Publication The publication of presence information operates so that a presence user agent sends a PUBLISH request targeted to the Request URI of the presentity. The body of the PUBLISH request carries a full event state of presence information when the event state is either published first time or modified. The PA receives and processes the PUBLISH request according to the Event State Publication Extension to SIP [3]. In case of a successful PUBLISH request the PA assigns an identifier ('entity-tag') to the published event state. The PUA uses the entity-tag in the next PUBLISH request for identifying the event state that the request is refreshing, modifying or removing. The "id" attribute of each tuple is kept unchanged to have unique tuple values. 3.2 Overview of Partial Publication The partial publication mechanism enables the PUA to publish only presence information that have actually changed. The partial publication mechanism can be applied to the initial and modify operations of the event state publication [3]. Normally the partial publication applies to the initial publication where the full event state is published, and in consecutive "modify" operations the partial event state is published. The "modify" operation can also publish the full event state. The full event state initializes the internal version counter for the future partial event states. When the PUA decides to start partial publications the PUA first publishes the full event state using the 'application/pidf-partial+xml' content type. After that the partial event states are published. The partial event state may contain new tuple elements, tuple elements which content have changed and/or a list of removed tuple elements compared to previously published tuples. Additionally, the state may contain presence information outside the tuple elements. The PUA constructs a PUBLISH request using the partial publication mechanism according to the Event State Publication Extension to SIP [3], PIDF Extension to Partial Presence [2] and this specification. When a presence agent receives a partial publication the PA looks Lonnfors, et al. Expires April 12, 2005 [Page 4] Internet-Draft Partial Publication October 2004 into the "state" attribute (defined in the PIDF Extension to Partial Presence [2]) for resolving if the publication contains a full or partial event state. In case of the full event state the PA replaces a possibly existing event state with the new one and stores the version number received in the PUBLISH request to be used as basis for partial event states. In case of the partial event state the PA uses the "id" attribute of each tuple as defined in the PIDF [4] and existing event state stored in the PA for constructing a new local copy of the full event state. 4. Client and server operations Unless otherwise specified in this document, the reqular presence user agent and presence agent behavior are applied as defined in the Event State Publication Extension to SIP [3]. 4.1 Content-type for Partial Publications The entities supporting the partial publication extension described in this document MUST support the 'application/pidf-partial+xml' content type defined in the PIDF Extension for Partial Presence [2]. 4.2 Presence User Agent Generation of PUBLISH Requests When a presence user agent decides to use the partial publication mechanism the PUA sets the Content Type header field of each PUBLISH request to the value 'application/pidf-partial+xml'. The PUA constructs the body of the PUBLISH request in accordance with the PIDF Extension for Partial Presence [2] and this specification. The PUA MUST publish a full event state and initiallize the version information to form a basis before publishing one or more partial event states. The PUA can start a publication context by using the PUBLISH request as specified in State Publication Extension to SIP [3] and subsequently change to partial publication. The PUA SHOULD NOT publish by 'application/pidf+xml', while using 'application/pidf-partial+xml', as this will terminate the partial publication. The logic which the PUA uses to construct an event state carried in the body of the PUBLISH request depends on if a full or partial event state is being published. The PUA MUST construct the presence document containing the full event state according to the following logic: o The "state" attribute is set to the value "full". Lonnfors, et al. Expires April 12, 2005 [Page 5] Internet-Draft Partial Publication October 2004 o The value of the "version" attribute is initialized. o The full presence information related to the publication context is included. o No elements are included. The presence document containing the partial event state MUST be constructed according to the following logic: o The "state" attribute is set to the value "partial". o The value of the "version" attribute is incremented by one compared to the previous publication. o Only the changed or new tuples compared to the previously published event states are included. Removed tuples are not considered as changed tuples in this case. Presence information, which is located outside the tuple elements, is processed as specified in the PIDF Extension for Partial Presence [2] and the Event State Publication Extension to SIP [3], i.e. the PUA includes all this information in every publication. o When tuples are removed since the previously published event states, the value of the "id" attribute of each removed tuple element is listed in the element as defined in the PIDF Extension for Partial Presence [2]. When the PA has discovered an error in the processing of a PUBLISH request containing a partial publication the PUA receives an abnormal response. The PUA reacts to the exceptional cases according to the following logic: o In case the source of the error was the PUA, the PUA SHOULD either send a full event state by using either partial publication or the publication mechanism defined in the Event State Publication Extension to SIP [3] or terminate the publication context. o In case the PA did not support the partial publication mechanism the PUA SHOULD use the publication mechanism as defined in the Event State Publication Extension to SIP [3]. 4.3 Presence Agent Processing PUBLISH Requests If the PA supports the partial publication mechanism the Lonnfors, et al. Expires April 12, 2005 [Page 6] Internet-Draft Partial Publication October 2004 functionality described as follows apply. The PA looks into the "state" attribute of the presence document for resolving if the publication contains a full or partial event state. The PA MUST ensure that it has received a full event state before receiving any partial event states. In case of the full event state the PA MUST perform the following actions: o The PA first discards any existing information related to the publication context. o The PA initializes an internal version counter related to the particular publication context to the value of "version" attribute received in the PUBLISH request. o The PA stores the value of the "id" attribute of each tuple element together with the content of the tuples received in the publication. Presence information, which is located outside the tuple elements, is processed as specified in the Event State Publication Extension to SIP [3], i.e. the PA stores the information as received in the publication. The stored presence information is the PA's local copy of the full presence information of the publication context. When the PA receives subsequent publications within the same publication context and the "state" attribute has the value "partial" the PA MUST construct the presence information according to the following logic: o The PA compares the "version" attribute of the presence element with the version information stored with the previous publication. If the version number is incremented by one the PA continues processing the event state present in the publication. o The PA stores the new version number as received in the PUBLISH request. o The PA compares the "id" attribute of each published tuple element to the tuple id values within the local copy of the publication context. If an "id" attribute in the publication matches a stored tuple id the content of the stored tuple is replaced with the newly received one. If an "id" attribute in the publication does not match those stored in the local copy of the publication context, the content of the tuple and its "id" are stored as new information in the local copy of the publication context. Lonnfors, et al. Expires April 12, 2005 [Page 7] Internet-Draft Partial Publication October 2004 o If the published presence document includes the "removed" element, the PA removes the tuples which "id" attributes are listed in the publication from the local copy of the publication context. o Tuples, which "id" attributes are not included in the published document, remain unchanged in the local copy of the publication context. o All presence information which is located outside the tuple elements are processed as specified in the PIDF Extension to Partial Presence [2] and the Event State Publication Extension to SIP [3], i.e., the PA replaces the existing information with the information received in the publication. Processing of exceptional cases: o In case the PA receives a publication containing a partial event state with an unexpected "version" attribute's value, the PA assumes a PUA error has happened. The PA MUST respond with an error. o In case the PA receives a partial event state before receiving the corresponding full event state the PA considers it as a PUA error and MUST respond with an error. o In case the PA receives a presence document containing the element in a full event state the PA considers it as a PUA error and SHOULD respond with an error. o In case the PA receives a presence document containing the same value of the "id" attribute of a tuple as a value in both a tuple specific information and the element the PA considers it as a PUA error and MUST respond with an error. o In case the PUA changes the content type used in publications within an existing publication context the PA MUST discard the local copy of presence information and version information, and process the new content as specified for that content type. Note that in case the PUA decides to start publishing partial event states again the PUA MUST send a full event state as specified in this specification first. o In case the PA does not support the 'application/pidf-partial+xml' content type the PA SHOULD return an error response '415 Unsupported Media Type'. OPEN: It is still open which error code should be used for PUA Lonnfors, et al. Expires April 12, 2005 [Page 8] Internet-Draft Partial Publication October 2004 errors. 5. Security Considerations This specification relies on the Event State Publication Extension to SIP [3] and it does not introduce any new protocol functionality. Partial publications can reveal information what has been changed compared to last time when publication was done. This can make it easier for eavesdroppers to know what kind of changes are happening in presentity's presence information. However, the same information can be found if publication is done with the baseline PIDF [4]. Thus, this specification does not introduce any new security considerations compared to the Event State Publication Extension to SIP [3]. Event state publication related security considerations are extensively discussed in the Event State Publication Extension to SIP [3] and all those identified security considerations apply to this document as well. Issues described in the Event State Publication Extension to SIP [3] are briefly reviewed below. 5.1 Confidentiality Confidentiality considerations identified in the Event State Publication Extension to SIP [3] apply here without any changes. 5.2 Access Control Access control considerations identified in the Event State Publication Extension to SIP [3] apply here without any changes. 5.3 Replay Prevention Replay prevention considerations identified in the Event State Publication Extension to SIP [3] apply here without any changes. 5.4 Denial of Service Attacks Denial of service attacks considerations identified in the Event State Publication Extension to SIP [3] apply here without any changes. 6. Acknowledgements The authors would like to thank Atle Monrad, Christian Schmidt and George Foti for review comments. Lonnfors, et al. Expires April 12, 2005 [Page 9] Internet-Draft Partial Publication October 2004 7. References 7.1 Normative references [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Lonnfors, M., Khartabil, H. and E. Leppanen, "Presence Information Data Format (PIDF) Extension for Partial Presence", draft-ietf-simple-partial-pidf-format-01 (work in progress), April 2004. [3] Niemi, A., "An Event State Publication Extension to the Session Initiation Protocol (SIP)", draft-ietf-sip-publish-04, May 2004. [4] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and J. Peterson, "CPIM presence information data format", RFC 3863, August 2004. 7.2 Informative references [5] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. Authors' Addresses Mikko Lonnfors Nokia Research Center Itamerenkatu 11-13 Helsinki Finland Phone: +358 71 8008000 EMail: mikko.lonnfors@nokia.com Eva Leppanen Nokia P.O BOX 785 Tampere Finland EMail: eva-maria.leppanen@nokia.com Lonnfors, et al. Expires April 12, 2005 [Page 10] Internet-Draft Partial Publication October 2004 Aki Niemi Nokia Research Center P.O. Box 407 NOKIA GROUP, FIN 00045 Finland Phone: +358 50 389 1644 EMail: aki.niemi@nokia.com Lonnfors, et al. Expires April 12, 2005 [Page 11] Internet-Draft Partial Publication October 2004 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 (2004). 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. Lonnfors, et al. Expires April 12, 2005 [Page 12]