SIMPLE WG M. Lonnfors Internet-Draft E. Leppanen Expires: October 19, 2004 H. Khartabil Nokia April 20, 2004 Presence Information Data format (PIDF) Extension for Partial Presence draft-ietf-simple-partial-pidf-format-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 October 19, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The presence Information Document Format (PIDF) specifies the baseline XML based format for describing presence information. One of the characteristic of the PIDF is that document always needs to carry all presence information available for the presentity. In some environments where low bandwidth and high latency links can exist it is often beneficial to limit the amount of information that is transported over the network. This document introduces a new MIME type which enables transporting of only changed parts of the PIDF Lonnfors, et al. Expires October 19, 2004 [Page 1] Internet-Draft Partial PIDF April 2004 based presence information. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Structure of partial PIDF documents . . . . . . . . . . . . . 4 3.1 "version" attribute . . . . . . . . . . . . . . . . . . . 4 3.2 "state" attribute . . . . . . . . . . . . . . . . . . . . 4 3.3 element . . . . . . . . . . . . . . . . . . . . 5 3.3.1 element . . . . . . . . . . . . . . . . . . . . 5 4. Usage of 'application/pidf-partial+xml' . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5.1 Content-type registration for 'application/pidf-partial+xml' . . . . . . . . . . . . . . 6 5.2 URN sub-namespace registration for 'urn:ietf:params:xml:ns:pidf-partial' . . . . . . . . . . 7 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Interoperability Considerations . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 11.1 Normative references . . . . . . . . . . . . . . . . . . . . 12 11.2 Informative references . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 14 Lonnfors, et al. Expires October 19, 2004 [Page 2] Internet-Draft Partial PIDF April 2004 1. Introduction The presence Information Document Format (PIDF) specifies the baseline XML based format for describing presence information. One of the characteristic of the PIDF is that document always needs to carry all presence information available for the presentity. In some environments where low bandwidth and high latency links can exist it is often beneficial to limit the amount of information that is transported over the network. This document introduces a new MIME type which enables transporting of only changed parts of the PIDF based presence information. This new MIME type works at the element level so that it allows indicating if new tuples have been added, previously received tuples have changed, or that some tuples have been removed. These modifications are always relative to previously received presence information. This document introduces a new MIME-Type 'application/ pidf-partial+xml' which is based on the PIDF presence data format [4] but is enhanced to support partial presence documents. 2. 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 memo makes use of the vocabulary defined in RFC2778 [2]. In addition, the following terms are defined: Full presence document: A presence document that contains all the presentity's presence information that is available to a particular watcher. A full presence document can be encoded according to the MIME type 'application/pidf+xml' or, if the "state" attribute is set to "full", it can also be encoded according to the MIME type 'application/pidf-partial+xml'. Partial presence document: A presence document that represents a fragment of the full presence document. A partial presence documents can only be understood in the context of the full presence document, i.e., a partial presence document modifies a local copy of the full presence document. The MIME type 'application/pidf-partial+xml" document represent a partial presence document when the "state" attribute is set to "partial". Lonnfors, et al. Expires October 19, 2004 [Page 3] Internet-Draft Partial PIDF April 2004 3. Structure of partial PIDF documents The mechanism for implementing the partial PIDF requires defining a new MIME type. The new MIME type is named as 'application/ pidf-partial+xml'. It is similar to the 'application/pidf+xml' [4] except that it adds new XML attributes to the element in order to enable the partial PIDF. These new XML attributes are "version" and "state". The new MIME type also introduces a new XML "removed" element. Implementations using this document format must follow guidelines specified in the CPIM presence information data format [4] i.e. the XML document MUST be well formed and SHOULD be valid. Presence documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. This specification makes use of XML namespaces for identifying presence documents and document fragments. The namespace URI for elements defined by this specification is a URN [5], using the namespace identifier 'ietf' specified in RFC 2648 [6] and extended by RFC3688 [7]. This URN is: urn:ietf:params:xml:ns:pidf-partial 3.1 "version" attribute Every presence document compliant with this specification MUST include the "version" attribute in element. The "version" attribute contains a sequence number that is progressively incremented between subsequent documents i.e. a more recent document has higher "version" value than a previous one. The recipient of the document can use "version" attribute to properly order received documents. The version starts with value 0, and is incremented by one for each new document. Implementations MUST support a 32 bit integer in the version number. 3.2 "state" attribute Every presence document compliant with this specification MUST include a "state" attribute in the element. the "state" attribute can be set to values: 'full' or 'partial'. The "state" attribute indicates the nature of the presence information included in the document, i.e., whether it contains a full or a partial state corresponding to the cases when the full presence information or only changed parts of the presence information are delivered. The use of these attributes is similar to the watcher information template package [8]. Lonnfors, et al. Expires October 19, 2004 [Page 4] Internet-Draft Partial PIDF April 2004 3.3 element This element is used to carry a list of tuples that are no longer present in the presence document. The element may contain any number of elements, each of which has the value of the "id" attribute of the tuple which has been removed. The element has only semantics for partial presence documents, thus, the element MUST NOT be included if "state" attribute has value "full". 3.3.1 element If a presence document contains a element, then it MUST contain at least one element. This element contains the tuple ID as indicated by the "id" attribute of the tuple that has been removed. 4. Usage of 'application/pidf-partial+xml' Presence documents which are compliant with the 'application/ pidf-partial+xml' MIME type MUST be constructed according to following logic: o All tuple ids used in the presence document MUST be unique within a document. This means tuple ids both in elements and in elements. o If the presence document represents the full presence state the "state" attribute MUST be set to "full" and the "version" attribute MUST be set to the value 0. The rest of the presence document is constructed as defined in the PIDF [4]. A presence document that contains a full presence state MUST not contain element. o If the presence document represents a partial presence state the "state" attribute MUST be set to "partial". The presence document SHOULD only contain those tuples that have changed compared to last time the presence document was delivered, i.e., the presence document contains new, modified, and removed tuples. Once a tuple is included in the presence document, the whole tuple including all the child elements and attributes MUST be included. Implementations MUST NOT include a partial tuple. Tuples which have not changed SHOULD NOT be included. If some tuples have been removed "id" attributes of those tuples MUST be listed using elements under element. Within the scope of this document tuples are considered to be atomic data elements. This means that if a presence document contains an Lonnfors, et al. Expires October 19, 2004 [Page 5] Internet-Draft Partial PIDF April 2004 update to an existing tuple, the whole new tuple replaces the old one. Partial presence documents can only indicate changes in tuples (a tuple is new, modified, removed), since this are the only elements that contains identities to refer to. Other child elements to the element defined in the PIDF [4] or in its extensions MUST always be included in partial presence document with its updated value, unless the element is removed from the presence information. 5. IANA Considerations This memo calls for IANA to: o register a new XML namespace URN per [7]. o register new a content type 'application/pidf-partial+xml' per RFC2048 [11]. 5.1 Content-type registration for 'application/pidf-partial+xml' MIME media type name: application MIME subtype name: pidf-partial+xml Mandatory parameters: none Optional parameters: charset Indicates the character encoding of enclosed XML. Default is UTF-8. Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [9], section 3.2. Security considerations: This content type is designed to carry presence data, which may be considered private information. Appropriate precautions should be adopted to limit disclosure of this information. Please refer to [[[RFCXXXX]]] security considerations section for more information. Interoperability considerations: none Published specification: [[[RFCXXXX]]] this document Applications which use this media type: SIP-based presence systems Additional information: Lonnfors, et al. Expires October 19, 2004 [Page 6] Internet-Draft Partial PIDF April 2004 Magic Number: None File Extension: .xml Macintosh file type code: "TEXT" Personal and email address for further information: Mikko Lonnfors, mikko.lonnfors@nokia.com Intended usage: LIMITED USE Author/Change controller: This specification is a work item of the IETF SIMPLE working group, with mailing list address . 5.2 URN sub-namespace registration for 'urn:ietf:params:xml:ns:pidf-partial' URI: urn:ietf:params:xml:ns:pidf-partial Description: This is the XML namespace for XML elements defined by [[[RFCXXXX]]] to describe the 'application/pidf-partial+xml' content type for partial PIDF. Registrant Contact: IETF, SIMPLE working group, Mikko Lonnfors, XML: Lonnfors, et al. Expires October 19, 2004 [Page 7] Internet-Draft Partial PIDF April 2004 BEGIN PIDF extension for partial PIDF

Namespace for PIDF extension for partial notifications

application/pidf-partial+xml

See RFCXXXX.

END 6. Examples An 'application/pidf-partial+xml' document that contains full state information: Lonnfors, et al. Expires October 19, 2004 [Page 8] Internet-Draft Partial PIDF April 2004 open tel:09012345678 open im:pep@example.com closed sip:pep@example.com Full state presence document An updated 'application/pidf-partial+xml' document that contains partial state information: Lonnfors, et al. Expires October 19, 2004 [Page 9] Internet-Draft Partial PIDF April 2004 closed im:pep@example.com This is an update of existing tuple sent in previous notification open im:mac@hut.com This is a completely new tuple not sent in previous notification Partial state presence document r1230d 7. XML Schema The XML schema for the 'application/pidf-partial+xml' data format. Lonnfors, et al. Expires October 19, 2004 [Page 10] Internet-Draft Partial PIDF April 2004 8. Interoperability Considerations This specification is not by default compliant with work done in IMPP working group. This means that other systems compliant with CPP [10] will not be by default able to use this specification. However, this will not cause any interoperability problems because all endpoints and gateways must support the default MIME type (application/ pidf+xml) regardless if they support this specification. Thus if a Lonnfors, et al. Expires October 19, 2004 [Page 11] Internet-Draft Partial PIDF April 2004 gateway or another end point does not understand this specification it will not be used. Other CPP compliant (other than SIP based) systems can also support this specification if they have a mechanism to indicate support for it. If they do it is possible to build a gateway which will preserves the end to end integrity with usage of partial PIDF. 9. Security Considerations Presence information may contain highly sensitive information about the presentities. The protocol used to distribute it SHOULD ensure privacy, message integrity and authentication. Furthermore, the protocol should provide access controls which restrict who can see who else's presence information. All security considerations identified for PIDF [4] apply unchanged for this document. 10. Acknowledgements The authors would like to thank Jose Costa-Requena, Jyrki Aarnos, Jonathan Rosenberg, Dean Willis, Miguel Garcia, Kriztian Kiss, Ben Cambell, and Anders kristenssen for their valuable comments and contributions. 11. References 11.1 Normative references [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [3] Rosenberg, J., "SIP Extensions for Presence", draft-ietf-simple-presence-10 (work in progress), January 2003. [4] Sugano, H., "CPIM presence information data format", draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003. [5] Moats, R., "URN syntax", RFC 2141, May 1997. [6] Moats, R., "A URN namespace for IETF documents", RFC 2648, Aug. 1999. 11.2 Informative references [7] Mealling, M., "The IETF XML Registry", RFC 3688, BCP 81, Lonnfors, et al. Expires October 19, 2004 [Page 12] Internet-Draft Partial PIDF April 2004 January 2004. [8] Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", draft-ietf-simple-winfo-package-05 (work in progress), January 2003. [9] Murata, M., "XML media types", RFC 3023, January 2001. [10] Crocker, D. and J. Peterson, "Common Profile for Presence (CPP)", draft-ietf-impp-pres-02.txt (work in progress). [11] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996. Authors' Addresses Mikko Lonnfors Nokia Itamerenkatu 11-13 00180 Helsinki Finland Phone: +358 71 8008000 EMail: mikko.lonnfors@nokia.com Eva Leppanen Nokia P.O BOX 785 Tampere Finland Phone: +358 7180 77066 EMail: eva-maria.leppanen@nokia.com Hisham Khartabil Nokia P.O. Box 321 Helsinki Finland Phone: +358 7180 76161 EMail: hisham.khartabil@nokia.com Lonnfors, et al. Expires October 19, 2004 [Page 13] Internet-Draft Partial PIDF April 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 IETF's procedures with respect to rights in IETF 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 October 19, 2004 [Page 14]