SIMPLE WG M. Lonnfors Internet-Draft Nokia Research Center Expires: November 15, 2004 E. Leppanen A. Niemi Nokia May 17, 2004 Partial Publication of Presence Information draft-lonnfors-simple-partial-publish-01 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I 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 November 15, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. 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 which modifies the current event state. This is done regardless of which presence information has been changed compared to the earlier publications. Lonnfors, et al. Expires November 15, 2004 [Page 1] 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 . . . . . . . . . . . . . . . . . . . . . . 4 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. Changes since the version 00 . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1 Normative references . . . . . . . . . . . . . . . . . . . . 10 7.2 Informative references . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . 12 Lonnfors, et al. Expires November 15, 2004 [Page 2] Internet-Draft Partial Publication May 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 [6]. 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. Requirements for the partial publication are defined in the SIMPLE Presence Publication Requirements [5]. 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 [6], 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. Lonnfors, et al. Expires November 15, 2004 [Page 3] Internet-Draft Partial Publication May 2004 3. Overall Operation This chapter introduces the basic functionality of the event state publication, and gives an overview of the partial publication 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. When modifying an event state the PUA keeps the "id" attributes of tuples consistent. 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]. If the partial publication is applied to the initial publication the full event state is always published. In case of the "modify" operation either the partial or full event state is published. When the PUA decides to start partial publications the PUA publishes first 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. Lonnfors, et al. Expires November 15, 2004 [Page 4] Internet-Draft Partial Publication May 2004 When a presence agent receives a partial publication the PA looks 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 tuples 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 to form a basis for an event state and version information before publishing one or more partial event states. Additionally, the PUA MUST NOT change the content type between the full and partial event state publications. 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". o The value of the "version" attribute is initialized. o The full presence information related to the publication context Lonnfors, et al. Expires November 15, 2004 [Page 5] Internet-Draft Partial Publication May 2004 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 tuples compared to the previously published event states (the PA's local copy of the full event state) are included. (Note that removed tuples are not considered as changed tuples in this case.) New tuples are also included. 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], e.g., the PUA includes all the information in every publication. o When there are changes, which lead to a removal of tuples from the previously published event states, the values of the "id" attributes of removed tuple elements are listed in the element as defined in the PIDF Extension for Partial Presence [2]. When the PA has discovered errors 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 sequence within 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 functionality described as follows apply. Lonnfors, et al. Expires November 15, 2004 [Page 6] 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 values of the "id" attributes of all tuple elements 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], e.g., the PA stores the information as received in the publication. The stored presence information is a 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" attributes of published tuple elements to the "id" values stored from the previous publications. If an id in the publication matches a stored tuple id the content of the stored tuple is replaced with the newly received one. If an id does not match those stored in the local copy the content of the tuple and its "id" are stored as new information in the local copy. o If the published presence document includes the "removed" element the PA removes the tuples which identifiers are listed from the local storage. Lonnfors, et al. Expires November 15, 2004 [Page 7] Internet-Draft Partial Publication May 2004 o Tuples, which are not included in the published document, remain unchanged in the local copy. 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 attribute's value higher than the locally stored value by more than one or the value is equal or smaller than the stored one), 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 errors. Lonnfors, et al. Expires November 15, 2004 [Page 8] Internet-Draft Partial Publication May 2004 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. Changes since the version 00 o Texts aligned with the draft-ietf-sip-publish-03. o Overview of Partial Publication chapter rewritten. o The term "publication context" redefined. Lonnfors, et al. Expires November 15, 2004 [Page 9] Internet-Draft Partial Publication May 2004 o Clarified that a PUA must publish a full event state using the partial publication mechanism before publishing partial event states. o Usage of the element clarified. o Exceptional cases updated and added. o Several editorial changes. o References updated. 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-00 (work in progress), January 2004. [3] Niemi, A., "Event State Publication Extension to the Session Initiation Protocol (SIP)", draft-ietf-sip-publish-03 (work in progress), February 2004. [4] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and J. Peterson, "CPIM presence information data format", draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003. 7.2 Informative references [5] Campbell, B., "SIMPLE Presence Publication Requirements", draft-ietf-simple-publish-reqs-00 (work in progress), February 2003. [6] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. Lonnfors, et al. Expires November 15, 2004 [Page 10] Internet-Draft Partial Publication May 2004 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 Aki Niemi Nokia P.O. Box 321 NOKIA GROUP, FIN 00045 Finland Phone: +358 50 389 1644 EMail: aki.niemi@nokia.com Lonnfors, et al. Expires November 15, 2004 [Page 11] Internet-Draft Partial Publication May 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 November 15, 2004 [Page 12]