SIMPLE WG M. Lonnfors Internet-Draft Nokia Research Center Expires: August 6, 2004 E. Leppanen A. Niemi Nokia February 6, 2004 Partial Publication of Presence Information draft-lonnfors-simple-partial-publish-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 6, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The size of the published presence information document may be large. A presence user agent publishes its full event state of presence information in every subsequent publication as specified in "SIP Extensions for Event State Publication" [3]. This is done regardless what 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 Lonnfors, et al. Expires August 6, 2004 [Page 1] Internet-Draft Partial Publication February 2004 reducing the impact of those constrains and to increase 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 Generating PUBLISH Requests . . . . . . . 5 4.3 Presence Agent Processing PUBLISH Requests . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . . . 8 5.2 Access Control . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3 Replay Prevention . . . . . . . . . . . . . . . . . . . . . . 9 5.4 Denial of Service Attacks . . . . . . . . . . . . . . . . . . 9 Normative references . . . . . . . . . . . . . . . . . . . . . 9 Informative references . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . 11 Lonnfors, et al. Expires August 6, 2004 [Page 2] Internet-Draft Partial Publication February 2004 1. Introduction SIP extension for Event State Publication [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 [4] and used by [3]. The presence information is grouped into an arbitrary number of 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 [6]. The size of the published presence information document may be large. As specified in [3] a PUA publishes its full event state of presence information in every subsequent publication. This is done regardless what 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 draft specifies a mechanism called 'partial publication' for the PUA to be able to publish only changed part of presence information compared to the information delivered in the previous publications belonging to the same publication context. Requirements for the partial publication are defined in [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 RFC2778 [6], presence event package [3], and partial PIDF definition [2]. This document introduces the following terms: Publication Context: A sequence of PUBLISH requests which use the same entity-tag value. The publication context is created in the intial publication and ends when the entity-tag value is not available any more (e.g. it has been expired or removed) The publication context concerns the same published event state. 3. Overall Operation This chapter briefly introduces the normal functionality of the event Lonnfors, et al. Expires August 6, 2004 [Page 3] Internet-Draft Partial Publication February 2004 state publication, and gives an overview of the partial publication mechanism. 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 a presence agent. The body of the PUBLISH request carries a full event state of presence information of the PUA. The format ('PIDF') for the event state is defined in [4]. The PA receives and processes the PUBLISH request according to [3]. In case of an initial and successful PUBLISH request the PA assigns an identifier ('entity-tag') to the publication. The PUA uses the entity-tag in subsequent PUBLISH requests for identifying the publication that the request is refreshing, modifying or removing. The subsequent PUBLISH requests are composed according to [3]. When a subsequent PUBLISH request carries modified presence information the values of "id" attributes of tuples remain unchanged. 3.2 Overview of Partial Publication The partial publication mechanism enables the PUA to publish only those parts of presence information that have changed since earlier publications within the same publication context. Thus the partial publication is mostly related to the "modify" operation of the event state publication that according to carries a full event state of a PUA but in case of the partial publication only changed parts of the event state. The partial publication mechanism is applied only to the tuple elements of presence information. This means that the whole content of a tuple is included in the PUBLISH request in any change. The PUA constructs a PUBLISH request using the partial publication mechanism according to [3], [2] and this specification. When a presence agent receives a PUBLISH request having the 'application/pidf-partial+xml' content type the PA looks into the value of the "state" attribute of the presence document (defined in [2]). If the value is set to "full", the presence document is considered to be the full event state for the PUA and sequence of publications in question. If the value is "partial" the presence document may contain new tuple elements, tuple elements which content have changed compared to earlier published tuples, presence information outside the tuple elements and a list of removed tuple elements. Lonnfors, et al. Expires August 6, 2004 [Page 4] Internet-Draft Partial Publication February 2004 4. Client and server operations This document assumes that unless otherwise specified in this document the normal publication behavior is applied as defined in [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. 4.2 Presence User Agent Generating PUBLISH Requests When a presence user agent wants to use partial publication mechanism the PUA MUST use the content type 'application/pidf-partial+xml'. The PUA MUST include the content type in the Content Type header field of the PUBLISH request. The published event state carried in the body of the PUBLISH request is constructed in accordance with [2] and this specification. The logic which a PUA MUST use when constructing the event state carried in the body of the PUBLISH request depends on which operation (defined in [3]) the PUBLISH request is performing. This document specifies different logics for the "initial" and "modify" operations. The PUA MUST publish a full event state for the PUA in the initial publication. The PUA MUST construct the presence document containing the published event state according to the following logic: o The "state" attribute MUST be set to the value "full". o The value of the "version" attribute MUST be initialized to zero. o The full presence information for the PUA MUST be included. When the PUA sends subsequent publications within the same publication context the presence document containing the partial event state MUST be constructed according to the following logic: o The "state" attribute MUST be set to the value "partial". o The value of the "version" attribute MUST be incremented by one compared to the previous publication. o Only the changed tuples compared to the previously published event states SHOULD be included. New tuples MUST be also included. Lonnfors, et al. Expires August 6, 2004 [Page 5] Internet-Draft Partial Publication February 2004 Presence information, which is located outside the tuple elements, MUST be processed as specified in [2] and [3], e.g., the PUA must include 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 MUST be listed in the "removed" element as defined in [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 MUST react to the exceptional cases according to the following logic: o In case the source of the error was the PUA the PUA SHOULD send a corrected PUBLISH request or send a full event state or terminate the publication sequence within the publication context. o If the reason for the error response was that some of the earlier publications are lost from the PA the PUA SHOULD publish a full event state according to the logic described for the "initial" publication, but using the same publication context. o In case the PA did not support the partial publication mechanism the PUA SHOULD use the publication mechanism defined in [3]. OPEN: It is still open whether there will be appropriate error codes available for separating the first two error items. 4.3 Presence Agent Processing PUBLISH Requests If the PUA decided to use the partial publication mechanism the presence agent receives PUBLISH requests with the value 'application/ pidf-partial+xml' in the Content-Type header. If the PA supports the partial publication mechanism the functionality described as follows apply. The PA receives a full event state of a PUA in the initial publication. In this case, the "state" attribute of the presence document formatted as defined in [2] has the value "full". The PA MUST perform the following actions: o The PA MUST initialize an internal version counter related to the particular PUA and publication context to the value of "version" attribute received in the PUBLISH request. Lonnfors, et al. Expires August 6, 2004 [Page 6] Internet-Draft Partial Publication February 2004 o The PA MUST store 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, MUST be processed as specified in [3], e.g., the PA must store 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 of the PUA. When the PA receives subsequent publications within the same publication context, and the PA has not changed the used content type, and the "state" attribute has the value "partial" the PA MUST construct the presence information according to the following logic: o The PA MUST compare the "version" attribute of the presence element with the version information stored from the previously received event state. If the version number is incremented by one the PA continues processing the event state present in the publication. The PA MUST also store the new version number. o The PA MUST compare 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 MUST be replaced with the newly received one in the publication. If an id does not match those stored in the local copy the content of the tuple and it's "id" are stored as new information in the local copy. o If the published presence document includes the "removed" element the PA MUST remove the tuples which identifiers are listed from the local storage. o Tuples, which are not included in the published document, MUST remain unchanged in the local copy. o All presence information which is located outside the tuple elements MUST be processed as specified in [2] and [3], i.e., the PA must replace the existing information with the information received in the publication. Processing of exceptional cases: o In case the PA receives a publication with the "version" attribute's value higher than the locally stored value by more than one, the PA assumes that one or more PUBLISH requests were lost. The PA SHOULD send an error response to the PUA. Lonnfors, et al. Expires August 6, 2004 [Page 7] Internet-Draft Partial Publication February 2004 o If the PA receives a notification with the "state" attribute's value "partial" and the "version" attribute's value is equal or smaller than the locally stored one, it is considered a PUA failure and the PA SHOULD send an error response. 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 process the new content as specified for that content type. 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'. o In case the PA receives a full event state within an existing publication context the PA SHOULD process the request according to the logic specified for the initial publication. OPEN: It is still open which error codes should be used or whether there will be new error codes defined for the first two exceptional cases. 5. Security Considerations This specification relies on publication of event state [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 evesdropper 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 baseline PIDF [4]. Thus, this specification does not introduce any new security conciderations compared to publication of event state [3]. Event state publication related security considerations are extensively discussed in [3] and all those identified security consideration apply to this document as well. Issues described in [3] are briefly reviewed below. 5.1 Confidentiality Confidentiality considerations identified in [3] apply here without any changes. 5.2 Access Control Access control considerations identified in [3] apply here without any changes. Lonnfors, et al. Expires August 6, 2004 [Page 8] Internet-Draft Partial Publication February 2004 5.3 Replay Prevention Replay prevention considerations identified in [3] apply here without any changes. 5.4 Denial of Service Attacks Denial of service attacks considerations identified in [3] apply here without any changes. 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., "Session Initiation Protocol (SIP) Extensions for Event State Publication", draft-ietf-sip-publish-02 (work in progress), January 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. 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. Authors' Addresses Mikko Lonnfors Nokia Research Center Itamerenkatu 11-13 00180 Helsinki Finland Phone: +358 71 8008000 EMail: mikko.lonnfors@nokia.com Lonnfors, et al. Expires August 6, 2004 [Page 9] Internet-Draft Partial Publication February 2004 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 August 6, 2004 [Page 10] Internet-Draft Partial Publication February 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Lonnfors, et al. Expires August 6, 2004 [Page 11] Internet-Draft Partial Publication February 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lonnfors, et al. Expires August 6, 2004 [Page 12]