Network Working Group
INTERNET-DRAFT                                                H. Sugano
                                                            S. Fujimoto

Expires: February 2002                                      August 2001

                 CPIM Presence Information Data Format

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   Please send comments to the authors or to the
   discussion list.

Copyright Notice

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


   This memo proposes a common presence format specification for
   discussion in the IMPP WG.  It also contains a list of issues raised
   in the IMPP mailing list so far to accelerate the discussions.

Sugano et al.                                                   [Page 1]

INTERNET DRAFT            CPIM Presence Format               August 2001

1.     Introduction

   The IMPP working group has been trying to build CPIM specifications
   to achieve interoperability of IM and Presence services between
   different protocol domains.  In particular, The work on CPIM Message
   Format [CPIM-MSG] defines a common format for instant messages, which
   enables secure end-to-end IM exchange.  For the presence service,
   although the group has agreed that there should be a common format
   for presence informantion, there has been very little discussion on
   the concrete format for that.

   This memo proposes a CPIM common presence format specification for
   discussion in the group.  It also contains a list of issues raised in
   the IMPP mailing list so far to accelerate the discussions.

2.     Assumptions and design decisions

   We took the starting point of our consideration from the minutes of
   the discussion in the IETF50 IMPP meeting. Thus, the payload content
   for (common) presence information should include:

       presentity URL
       list of contact URLs
            status (open,closed)
            human readable comment
            relative priority
       presentity human readable comment - independent of any contact

   Note that extensibility is required to the format and that it was
   also agreed in the IETF50 meeting that XML should be used for the
   payload format.

   Then, we took the following assumptions for the design.

     (a) A presence payload should be able to be transported securely from
         presentity to watchers.
     (b) A presence server may add some metadata and it may sign or
         encrypt the presence payload.
     (c) Presence tuples from different sources (presentities) may be
         transported in a single NOTIFY message.

   Based on these assumptions, we adopted our overall design decisions
   as follows:

     (1) A presence payload is in XML [XML]. This follows the agreement
         in the IETF50 meeting.

Sugano et al.                                                   [Page 2]

INTERNET DRAFT            CPIM Presence Format               August 2001

     (2) A presence payload is accompanied with RFC822 style headers for
         metadata [RFC822].
     (3) Multiple presence payloads can be enclosed using MIME multipart

3.     Overall Presence Information Data Structure

   For an overall presence information data format, we propose to reuse
   "message/cpim" content type defined by the CPIM message format
   document [CPIM-MSG] and define some new headers for content-related
   metadata and an XML payload format for presence information.  Note
   that this content can optionally be signed or encrypted using MIME
   security multiparts in conjunction with an appropriate security

   Thus, the complete presence information data looks like this:

      m: Content-type: message/cpim
      h: (message-metadata-headers)
      e: (encapsulated MIME entity containing presence payload)

   where, "m:", "s:", "h:", "e:" have the same meaning as defined in the
   CPIM-MSGFMT document and only used to indicate the different parts of
   the presence data.

   Message metadata used for presence information is a subset of those
   defined by the MSGFMT document.

3.1.   Content Part

   The content part of this object, the e: part of the above schema,
   further contains presence payloads with the content headers.  The
   content header part includes the Content-type header, whose value
   indicates whether it contains a single presence payload or multiple
   presence payloads.

   This memo defines a new content type "application/cpim-pidf+xml" for
   an XML-encoded presence payload.  The Content-type header has the
   value application/cpim-pidf+xml when the content part contains a
   single presence payload.

   If the content part contains multiple presence payloads, the value of
   the Content-type header MUST be multipart/mixed.  Each part of the
   multipart entity itself will be an application/cpim-pidf+xml type

Sugano et al.                                                   [Page 3]

INTERNET DRAFT            CPIM Presence Format               August 2001

   object and each part contains content headers for its payload.  It
   can optionally be a signed or encrypted MIME entity using the MIME
   security multiparts in conjunction with an appropriate security

4.     XML-encoded Presence Data Format

   This section defines an XML-encoded presence data format of the
   content type application/cpim-pidf+xml for presence payloads. A
   presence payload of this type is expected to be produced by the
   presentity (the source of the presence information) and transported
   to the watchers by the presence servers or gateways without any
   interpretation or modification.

4.1.   General Design

   The format is designed to align with the agreement in the IMPP group
   so far described in the section 2.   A single payload contains a list
   of presence tuples and other information related to the presentity.

4.2.   XML Format Definitions

   An application/cpim-pidf+xml object is a well formed XML document.

4.2.1. The <presence> element

   The root element of the application/cpim-pidf+xml object is defined
   as <presence>.  This element contains one or more <tuple> elements
   and an optional <timestamp> element.  The reason that the <timestamp>
   is optional is that it is sometimes needed to hide the timestamp of
   the presence information change.

   The <presence> element SHOULD contain an 'xmlns' attribute to
   indicate the namespace of this version of presence payloads.

4.2.2. The <tuple> element

   The <tuple> element is used to carry a piece of presence information
   defined as PRESENCE TUPLE in RFC2778.  Thus, it contains a mandatory
   <status> element and optional <contact>, and <note> elements.

   The <tuple> element MUST contain a 'name' attribute which is used to
   distinguish this tuple from other tuples of the same presentity.  The
   value of 'name' attribute MUST be unique in a single presentity.

4.2.3. The <status> element

Sugano et al.                                                   [Page 4]

INTERNET DRAFT            CPIM Presence Format               August 2001

   The <status> element contains a mandatory <value> element and an
   optional <detail> element.

4.2.4. The <value> element

   The <value> element contains a CDATA value, which is either "open" or
   "closed".   The value "open" means the availability of the contact
   means in a general sense and "closed" means it is unavailable.

4.2.5. The <detail> element

   The <detail> element contains a CDATA value which describes the
   detailed status of the contact means.  This element has a mandatory
   attribute 'type' and an optional attribute 'schema'.  The 'type'
   attribute indicates the type of this tuple and the values of the
   <detail> element varies dependent on the type value.  The optional
   its possible values, which is usually a DTD.

4.2.6. The <contact> element

   The <contact> element contains a URL of the contact address.  It
   optionally has a 'priority' attribute, whose value means a relative
   priority of this contact address over the others.  The value of the
   attribute MUST be an integer ranged from 0 to 255 and the smaller
   integer means the higher priority.

4.2.7. The <note> element

   The <note> element contains a CDATA value, which is usually used for
   a human readable comment related to this tuple.

4.2.8. The <timestamp> element

   The <timestamp> element contains a CDATA value which is a string
   indicating the date and time of the status change of this tuple.  The
   value of this element MUST follow the IMPP datetime format [?].

4.3.   Example

   <presence xmlns="">
     <tuple name="im-1">
         <detail type="im"
       <contact priority="2"></contact>

Sugano et al.                                                   [Page 5]

INTERNET DRAFT            CPIM Presence Format               August 2001

       <note>I'll be in Tokyo tomorrow</note>
     <tuple name="email">
       <contact priority="1"></contact>

4.4.   DTD

   Data Type Definition of the application/cpim-pidf+xml format.

   <!ENTITY % URL         "CDATA">
   <!ENTITY % URI         "CDATA">
   <!ENTITY % NOTE        "CDATA">

   <!ELEMENT presence ((tuple+),timestamp?)>
   <!ATTLIST presence
               xmlns     %URI;     #IMPLIED

   <!ELEMENT tuple (status,contact?,note?)>
   <!ATTLIST tuple
               name %TUPLENAME #REQUIRED

   <!ELEMENT status (value,detail?)>

   <!ELEMENT value ("open"|"closed")>

   <!ATTLIST detail
               type   %DETAILTYPE; #REQUIRED
               schema %URI;        #IMPLIED

   <!ELEMENT contact %URL;>
   <!ATTLIST contact
               priority %PRIORITY; #IMPLIED

   <!ELEMENT note %NOTE;>

Sugano et al.                                                   [Page 6]

INTERNET DRAFT            CPIM Presence Format               August 2001

   <!ELEMENT timestamp %DATETIME;>

5.     Header Definitions

   This section defines a set of headers which are used to convey the
   metadata.  All the metadata, both message and content headers, are
   produced by the presence server.

5.1.   Message Headers

   Among the headers defined by the CPIM message format document [CPIM-
   MSG], we use the following headers to convey the presence

5.1.1. The 'From' header

   The 'From' header contains the address (pres: URL) of the presentity.
   This header is mandatory.

5.1.2. The 'To' header

   The 'To' header contains the address (pres: URL) of the watcher.
   This header is optional.

5.1.3. The 'DateTime' header

   The 'DateTime' header contains a character string of the format
   defined as IMPP datetime format [DateTime].  This value indicates the
   date and time at which the content part is created.

5.1.4. The 'NS' header

   The "NS" header is used to declare a local namespace prefix as
   defined by [CPIM-MSG].

5.1.5. The 'Require' header

   The "Require" header is used to specify a header or feature that must
   be implemented by the receiver, as defined by [CPIM-MSG].

5.2.   Content Headers

5.2.1. The 'Content-Type' header

   The 'Content-Type' header contains the type of the content.

Sugano et al.                                                   [Page 7]

INTERNET DRAFT            CPIM Presence Format               August 2001

5.2.2. The 'Presence-Data-ID' header

   The 'Presence-Data-ID' header contains the label for the unit of
   update.  This header will be used for indicating the part is
   replacement of the part which contained in previous NOTIFICATION with
   same 'Presence-Data-ID' value.

5.2.3. The 'Presence-Modified' header

   The 'Presence-Modified' header has no value.  This header MAY be used
   only in the NOTIFICATION message if it contains the multipart
   presence payloads.  The existence of this header indicates that this
   part has caused the notification.

6.     Examples

   The following exapmle is the message/cpim object containing two
   presence payload.  It is supposed that the first block is published
   by a PC and the second block is published by a mobile phone, and the
   second block has caused the notification message conveying this
   multipart content.

     Content-Type: message/cpim

     DateTime: 2001-06-01T08:35:44+09:00

     Content-Type: multipart/mixed; boundary="PRESENCE-BLOCKS"

     Content-Type: application/cpim-pidf+xml
     Presence-Data-ID: part1

       <tuple name="im-1">
           <detail type="im"
         <contact priority="2"></contact>
         <note>I'll be in Tokyo tomorrow</note>
       <tuple name="email">

Sugano et al.                                                   [Page 8]

INTERNET DRAFT            CPIM Presence Format               August 2001

     Content-Type: application/cpim-pidf+xml
     Presence-Data-ID: part2

       <tuple name="mobile-phone">
         <contact priority="9">tel:09012345678</contact>
       <tuple name="mobile-im">
         <contact priority="1"></contact>

7.     Security Considerations

   The proposed format for conveying presence information is so designed
   that it could be adaptable in circumstances under various security

   As a typical case, a user publishing his/her presence information may
   want to sign the data to prevent from being corrupted or tampered.
   This will ensure the integrity of presence information in an end-to-
   end manner.  This proposal enables it by allowing MIME multipart
   security framework, such as usage of the multipart/signed data type.

   Another possible scenario is that of third party signing.  If the
   computing power of the terminal device of the publishing user is
   restricted, the server side signing would be sometimes desirable to
   enhance the level of security in distributing presence information.
   This enables to prevent from so-called "the man in the middle"
   attacks when the presence notifications are distributed through the
   proxies or gateways.

Sugano et al.                                                   [Page 9]

INTERNET DRAFT            CPIM Presence Format               August 2001

8.     Discussions

   The authors understand that there are some issues in our proposal to
   be discussed and agreed on for the common presence format. Those
   could be listed as follows;

   (a) Should such server generated metadata as From, To, DateTime in
   this draft be defined as a part of common presence data format?

     This draft proposes to use several headers as server generated
     metadata as a part of common presence data format.  This is because
     it would be necessary to convey these information to the end system
     (UA) as it is.  It would also be desirable to allow server-side
     third party signing for such data.  So, this may induce another
     relating question; is the third party signing on the presence
     service necessary?

   (b) If the answer to (a) is yes , the next issue is what is the best
   format for the metadata (message/cpim or any other?).

     We have adopted the message/cpim format because it can be reused
     with no difficulty to contain such metadata and it is RFC822 based.
     The reason to prefer an RFC822 based format is that it can nicely
     fit with MIME security framework which could be utilized when the
     user agents sign the presence data.

   (c) Extension framework

     In the earlier idea stage, we thought it preferable that local
     extensions could be confined within a special element (<ext>).
     There have been several objections to it which argue XML is
     naturally extensible and we have no need to such an element. We
     have agreed with their arguments and cut this element out.

   (d) XML format

     We need to agree on the details of the XML format itself. In fact,
     there has been proposed an idea to contain multiple contact
     elements in a single tuple element.  Further discussions are

9.     References

   [CPIM] D. Crocker et al., "A Common Profile for Instant Messaging
   (CPIM)", draft-ietf-impp-cpim-01.txt, Work in Progress.

Sugano et al.                                                  [Page 10]

INTERNET DRAFT            CPIM Presence Format               August 2001

   [CPIM-MSG] D. Atkins and G. Klyne, "Common Presence and Instant
   Messaging Message Format", draft-ietf-impp-cpim-msgfmt-03.txt,
   Work in Progress.

   [XML] Extensible Markup Language (XML) 1.0 (Second Edition)., A W3C recommendation,
   October 2000.

   [RFC822] D. Crocker, "Standard for the format of ARPA Internet text
   messages", RFC 822, STD 11, Aug 1982.

   [MIME] Multipurpose Internet Mail Extensions.  See RFC 822, RFC 2045,
   RFC 2046, RFC 2047, RFC 2048, and RFC 2049.

   [RFC2778] M. Day, J. Rosenberg, H. Sugano, "A Model for Presence and
   Instant Messaging", RFC 2778, February 2000.

   [RFC2779] M.Day, S.Aggarwal, G.Mohr, and J.Vincent, "Instant
   Messaging / Presence Protocol Requirements", RFC 2779, February 2000.

   [SMIME] P. Hoffman, Ed, "S/MIME Version 3 Message Specification",
   RFC2633, June 1999.

   [DateTime] G. Klyne and C.Newman, "Date and Time on the Internet:
   Timestamps", draft-ietf-impp-datetime-04.txt, Work in Progress.

10.     Author's Addresses

   H. Sugano
   Fujitsu Laboratories Ltd.
   64, Nishiwaki
   Akashi 674

   S. Fujimoto
   Fujitsu Laboratories Ltd.
   64, Nishiwaki
   Akashi 674

11.     Full Copyright Statement

Sugano et al.                                                  [Page 11]

INTERNET DRAFT            CPIM Presence Format               August 2001

   Copyright (C) The Internet Society (2001).  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

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an

Sugano et al.                                                  [Page 12]