SIMPLE WG                                                    M. Lonnfors
Internet-Draft                                     Nokia Research Center
Expires: July 21, 2004                                       E. Leppanen
                                                            H. Khartabil
                                                                   Nokia
                                                        January 21, 2004


     Presence Information Data format (PIDF) Extension for Partial
                                Presence
                draft-ietf-simple-partial-pidf-format-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 July 21, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

   Presence Information Document Format (PIDF) specifies 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.



Lonnfors, et al.         Expires July 21, 2004                  [Page 1]

Internet-Draft                Partial PIDF                  January 2004


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   <removed> element  . . . . . . . . . . . . . . . . . . . . .  4
   3.3.1 <t_id> element . . . . . . . . . . . . . . . . . . . . . . .  5
   4.    Usage of 'application/pidf-partial+xml'  . . . . . . . . . .  5
   5.    IANA Considerations  . . . . . . . . . . . . . . . . . . . .  5
   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'  . . . . . . . . . . .  6
   6.    Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   7.    XML Schema . . . . . . . . . . . . . . . . . . . . . . . . .  9
   8.    Interoperability Considerations  . . . . . . . . . . . . . . 10
   9.    Security Considerations  . . . . . . . . . . . . . . . . . . 11
   10.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
         Normative references . . . . . . . . . . . . . . . . . . . . 11
         Informative references . . . . . . . . . . . . . . . . . . . 11
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12
         Intellectual Property and Copyright Statements . . . . . . . 13



























Lonnfors, et al.         Expires July 21, 2004                  [Page 2]

Internet-Draft                Partial PIDF                  January 2004


1. Introduction

   Presence Information Document Format (PIDF) specifies 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 in <tuple> 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 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 [2]. In addition
   following terms are defined:

   Full presence document: Presence document which contains all presence
      information that is available about the particular presentity to
      the watcher in question. The full presence document can be
      represented by MIME type 'application/pidf+xml' and 'application/
      partial-pidf+xml' when the "state" attribute is set to value
      "full".

   Partial presence document: Document which represents only a fragment
      of the full presence document. Partial presence documents can only
      be understood in the context of the full presence document i.e. a
      partial presence document modifies the local copy of the full
      presence document. MIME type 'application/partial-pidf+xml"
      document represent partial presence document when the "state"
      attribute contains value "partial".





Lonnfors, et al.         Expires July 21, 2004                  [Page 3]

Internet-Draft                Partial PIDF                  January 2004


3. Structure of partial PIDF documents

   The mechanism for implementing the partial PIDF consists of defining
   a new MIME type. The new MIME type is named as 'application/
   pidf-partial+xml'. It is similar to PIDF [4] except that it adds new
   XML attributes to the <presence> element in order to enable the
   partial PIDF. The new XML attributes are "version" and "state". The
   new MIME type also introduces a new XML element called "removed".

   Implementations using this document format must follow guidelines
   specified in [4] i.e. 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' defined by [6] and
   extended by [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 <presence> element.

   The "version" attribute is a sequence number that is progressively
   incremented between subsequent documents i.e. a more resent document
   has higher "version" value than a previously received one. The
   recipient of the document can use "version" attribute to properly
   order received documents. Version start at 0, and is incremented by
   one for each new document. Versions MUST be representable using a 32
   bit integer.

3.2 "state" attribute

   Every presence document compliant with this specification MUST
   include "state" attribute in <presence> element. It can have values:
   'full' or 'partial'.

   The "state" attribute indicates the nature of the presence
   information included in the document, whether it contains full or
   partial presence document 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].

3.3 <removed> element




Lonnfors, et al.         Expires July 21, 2004                  [Page 4]

Internet-Draft                Partial PIDF                  January 2004


   This element is used to carry a list of tuples which have been
   removed. The <removed> element contains any number of <t_id> elements
   each of which has the value of the "id" attribute of the tuple which
   has been removed.

3.3.1 <t_id> element

   If document contains <removed> element it MUST contain at least one
   <t_id> 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 'application/
   pidf-partial+xml' MIME type MUST be constructed according to
   following logic:

   o  If the presence document represents full presence document the
      "state" attribute MUST be set to value "full". In this case the
      rest of the presence document is contructed as defined in PIDF
      [4].

   o  If the presence document represents partial presence document the
      "state" attribute MUST be set to value "partial". The presence
      document MUST only contain tuples which have changed compared to
      last time the presence document was delivered i.e. it must contain
      new tuples and modified tuples. Tuples MUST be included completely
      i.e. including only a fragment of the tuple is not allowed. Tuples
      which have not changed MUST NOT be included. If some tuples have
      been removed "id" attributes of those tuples must be listed under
      <removed> element.

   In the scope of this document the partial presence documents apply
   only to the <tuple> elements and everything what is contained inside
   those elements i.e. tuples are considered to be atomic data elements.
   All other elements defined in PIDF [4] which are child elements to
   the <presence> element (only the <note> element has been defined)
   MUST be included in every presence document.

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].




Lonnfors, et al.         Expires July 21, 2004                  [Page 5]

Internet-Draft                Partial PIDF                  January 2004


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.

      Interoperability considerations: none

      Published specification: [[[RFCXXXX]]] this document

      Applications which use this media type: SIP-based presence systems

      Additional information:

         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 <simple@ietf.org>.


5.2 URN sub-namespace registration for
    'urn:ietf:params:xml:ns:pidf-partial'




Lonnfors, et al.         Expires July 21, 2004                  [Page 6]

Internet-Draft                Partial PIDF                  January 2004


      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, <simple@ietf.org>
      Mikko Lonnfors, <mikko.lonnfors@nokia.com>

   XML:

     BEGIN
         <?xml version="1.0"?>
         <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
         "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
         <html xmlns="http://www.w3.org/1999/xhtml
         <head>
              <meta http-equiv="content-type"
              content="text/html;charset=iso-8859-1"/>
              <title>PIDF extension for partial PIDF</title>
         </head>
         <body>
             <h1>Namespace for PIDF extension for partial
                  notifications</h1>
             <h2>application/pidf-partial+xml</h2>
             <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
          </body>
          </html>
     END


6. Examples

   'application/pidf-partial+xml' document which contains full state
   information:













Lonnfors, et al.         Expires July 21, 2004                  [Page 7]

Internet-Draft                Partial PIDF                  January 2004


            <?xml version="1.0" encoding="UTF-8"?>
            <pidf-part:presence xmlns="urn:ietf:params:xml:ns:pidf"
           	xmlns:pidf-part="urn:ietf:params:xml:ns:pidf-partial"
             	entity="pres:someone@example.com" pidf:part:version="1"
             	pidf-part:state="full">

              <tuple id="sg89ae">
                <status><basic>open</basic>
                </status>
                <contact priority="0.8">tel:09012345678
                </contact>
              </tuple>

              <tuple id="cg231jcr">
                <status><basic>open</basic>
                </status>
                <contact priority="1.0">
                      im:pep@example.com</contact>
              </tuple>
              <tuple id="r1230d">
                <status><basic>closed</basic>
                </status>
                <contact priority="0.9">
                      sip:pep@example.com</contact>
              </tuple>
            </presence>

    New 'application/pidf-partial+xml' document which contains partial
   state information:






















Lonnfors, et al.         Expires July 21, 2004                  [Page 8]

Internet-Draft                Partial PIDF                  January 2004


            <?xml version="1.0" encoding="UTF-8"?>
            <pidf-part:presence xmlns="urn:ietf:params:xml:ns:pidf"
           	xmlns:pidf-part="urn:ietf:params:xml:ns:pidf-partial"
   	       entity="pres:someone@example.com" pidf-part:version="2"
   	       pidf-part:state="partial">

       	   <pidf-part:removed><pidf-part:t_id>r1230d</pidf-part:t_id>
       	   </pidf-part:removed>

              <tuple id="cg231jcr">
                <status><basic>closed</basic>
                </status>
                <contact priority="1.0">
                      im:pep@example.com</contact>
                <note xml:lang="en">This is an update of existing
                tuple sent in previous notification</note>
              </tuple>

              <tuple id="wsqw798jcr">
                <status><basic>open</basic>
                </status>
                <contact priority="0.4">
                      im:mac@hut.com</contact>
                <note xml:lang="en">This is a completely new
                tuple not sent in previous notification</note>
              </tuple>
            </presence>



7. XML Schema

   The XML schema for the 'application/pidf-partial+xml' data format.


   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf-partial"
   	xmlns:xs="http://www.w3.org/2001/XMLSchema"
   	xmlns:pidf="urn:ietf:params:xml:ns:pidf"
   	xmlns:tns="urn:ietf:params:xml:ns:pidf-partial"
   	elementFormDefault="qualified"
   	attributeFormDefault="unqualified">

   	<!-- This import brings in the XML language attribute xml:lang-->
   	<xs:import namespace="http://www.w3.org/XML/1998/namespace"
   		schemaLocation="http://www.w3.org/2001/xml.xsd"/>
   	<xs:import namespace="urn:ietf:params:xml:ns:pidf"/>




Lonnfors, et al.         Expires July 21, 2004                  [Page 9]

Internet-Draft                Partial PIDF                  January 2004


   	<xs:element name="presence"
   	 type="tns:partial-presence"/>
   	<xs:complexType name="partial-presence">
   	 <xs:complexContent>
   	  <xs:extension base="pidf:presence">
   	   <xs:sequence>
   	    <xs:element name="removed"
   		 type="tns:removed_tuple"
   		 minOccurs="0"/>
   	    </xs:sequence>
   	    <xs:attribute name="entity"
   		 type="xs:anyURI"
   		 use="required"/>
   	    <xs:attribute name="version"
   		 type="xs:nonNegativeInteger"
   		 use="required"/>
   	    <xs:attribute name="state" use="required">
   	    <xs:simpleType>
   		 <xs:restriction base="xs:string">
   		    <xs:enumeration value="full"/>
   		    <xs:enumeration value="partial"/>
   		 </xs:restriction>
   	     </xs:simpleType>
   		</xs:attribute>
   	   </xs:extension>
   	 </xs:complexContent>
   	</xs:complexType>

   	<xs:complexType name="removed_tuple">
   	  <xs:sequence>
   	    <xs:element name="t_id"
   	     type="xs:ID"
   	     maxOccurs="unbounded"/>
   	  </xs:sequence>
       </xs:complexType>
   </xs:schema>


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
   gateway or another end point does not understand this specification
   it will not be used.



Lonnfors, et al.         Expires July 21, 2004                 [Page 10]

Internet-Draft                Partial PIDF                  January 2004


   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.

10. Acknowledgements

   The authors would like to thank Jose Costa-Requena, Jyrki Aarnos,
   Jonathan Rosenberg, Dean Willis, Kriztian Kiss for their valuable
   comments and contributions.

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.

Informative references

   [7]   Mealling, M., "The IETF XML Registry",
         draft-mealling-iana-xmlns-registry-05 (work in progress), June
         2002.

   [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.



Lonnfors, et al.         Expires July 21, 2004                 [Page 11]

Internet-Draft                Partial PIDF                  January 2004


   [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 Research Center
   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 July 21, 2004                 [Page 12]

Internet-Draft                Partial PIDF                  January 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 July 21, 2004                 [Page 13]

Internet-Draft                Partial PIDF                  January 2004


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Lonnfors, et al.         Expires July 21, 2004                 [Page 14]