Network Working Group                                         H. Sugano
INTERNET-DRAFT                                              S. Fujimoto
                                                                Fujitsu
                                                               G. Klyne
                                                 Baltimore Technologies
                                                             A. Bateman
                                                             VisionTech

Expires: September 2002                                      March 2002


                 CPIM Presence Information Data Format
                   <draft-ietf-impp-cpim-pidf-02.txt>

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.

   Please send comments to the authors or to the impp@iastate.edu
   discussion list.

Copyright Notice

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

Abstract

   This memo specifies CPIM Presence Information Data Format (PIDF) as a
   common presence data format for CPIM-compliant IM/Presence protocols.





Sugano et al.                                                   [Page 1]

INTERNET DRAFT            CPIM Presence Format                March 2002


Table of Content

      1.     Introduction .........................................    3
      1.1.   Terminology and Conventions ..........................    3
      2.     Design Decisions .....................................    4
      2.1.   Minimal Model ........................................    4
      2.2.   Added Features .......................................    5
      2.3.   Encoding Decisions ...................................    5
      2.3.1. Adoption of XML ......................................    5
      2.3.2. Combining Multiple Presence Documents ................    5
      3.     Overview of Presence Information Data Format .........    5
      3.1.   The 'application/cpim-pidf+xml' Content Type .........    5
      3.2.   Presence Information Contents ........................    6
      3.3.   Using Multipart Entity ...............................    6
      4.     XML-encoded Presence Data Format .....................    6
      4.1.   XML Format Definitions ...............................    7
      4.1.1. The <presence> element ...............................    7
      4.1.2. The <presentity> element .............................    7
      4.1.3. The <tuple> element ..................................    7
      4.1.4. The <status> element .................................    7
      4.1.5. The <value> element ..................................    8
      4.1.6. The <contact> element ................................    8
      4.1.7. The <note> element ...................................    8
      4.1.8. The <timestamp> element ..............................    9
      4.2.   Presence Information Extensibility ...................    9
      4.2.1. XML Namespaces Background ............................    9
      4.2.2. XML Namespaces In Presence Information ...............   10
      4.2.3. Handling Of Unrecognized Element Names ...............   10
      4.3.   Examples .............................................   11
      4.3.1. Default Namespace And No Extensions ..................   11
      4.3.2. Example Presence Information Extensions ..............   12
      4.3.3. Example Mandatory To Understand Extensions ...........   12
      4.4.   DTD ..................................................   13
      5.     Wrapping 'application/cpim-pidf+xml' Data ............   14
      5.1.   When Used With 'message/cpim' ........................   14
      5.1.1. The 'From' header ....................................   14
      5.1.2. The 'To' header ......................................   14
      5.1.3. The 'DateTime' header ................................   14
      5.1.4. The 'NS' header ......................................   14
      5.1.5. The 'Require' header .................................   15
      5.2.   When Used With 'multipart/mixed' .....................   15
      5.2.1. The 'Presence-Data-ID' header ........................   15
      5.3.   Examples .............................................   15
      6.     Security Considerations ..............................   16
      7.     IANA Considerations ..................................   17
      8.     References ...........................................   17
      9.     Author's Addresses ...................................   18
      10.     Full Copyright Statement ............................   19



Sugano et al.                                                   [Page 2]

INTERNET DRAFT            CPIM Presence Format                March 2002


1.     Introduction

   The Common Profile for Instant Messaging (CPIM) specifications define
   a set of common operations and various formats to achieve
   interoperability between different Instant Messaging and Presence
   protocols which meet RFC 2779 [RFC2779]. The CPIM core specification
   [CPIM] defines a set of common operations and their parameters to be
   supported by interworking Presence and IM protocols in order to allow
   straightforward gatewaying between them.  The work on CPIM Message
   Format [CPIM-MSG] defines a common format for instant messages, which
   enables secure end-to-end IM exchange through the gateways.

   This memo further defines the CPIM Presence Information Data Format
   (PIDF) as a common presence data format for CPIM-compliant presence
   protocols.  The significance of the common presence format primarily
   resides in the fact that it alleviates the load of gatewaying of
   messages with presence data payloads.  Without such a common presence
   data format, a gateway must process and transform the presence data
   payload from one format to another every time it gateways the
   protocol messages.  Such payload processing aslo disable the validity
   of digitally signed presence data.  Utilizing the common presence
   data format allows secure transfer of the presence payloads across
   the boundary of different protocol domains.

   The format specified in this memo is intended to define the base
   presence format and extensibility required by RFC 2779.  It only
   defines a minimal set of presence status values defined by the IMPP
   Model document [RFC2778].  However, a presence application is able to
   define its own status values using the extensibility framework
   provided by this memo.  Defining such extended status values is
   beyond the scope of this memo.


1.1.   Terminology and Conventions

   This memo makes use of the vocabulary defined in the IMPP Model
   document [RFC2778].  Terms such as CLOSED, INSTANT MESSAGE, OPEN,
   PRESENCE SERVICE, PRESENTITY, WATCHER, and WATCHER USER AGENT in the
   memo are used in the same meaning as defined therein.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
   "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
   interpreted as described in RFC 2119 [RFC2119].

   [[[Editorial comments and questions about outstanding issues are
   provided in triple brackets like this.  These working comments should
   be resolved and removed prior to final publication.]]]




Sugano et al.                                                   [Page 3]

INTERNET DRAFT            CPIM Presence Format                March 2002


2.     Design Decisions

   We have adopted the IMPP Model and Requirements documents [RFC2778,
   RFC2779] as the starting point of our discussion. The two RFCs
   contains some statements about presence information, which can be
   regarded as a basic set of constraints for the format design.  Also,
   we took the minimalist approach to the design based on them.
   Starting from the minimal model, only the features that are necessary
   to solve particular problems were combined.


2.1.   Minimal Model

   This specification is based on the minimal model extracted from the
   IMPP Model and Requirements documents.  The model consists of the
   following items.  Each of them is accompanied with the corresponding
   RFCs and their section numbers as its gounds, e.g. (RFC2778:Sec.2.4)
   refers to Section 2.4 of RFC 2778.

   (a) PRESENCE INFORMATION consists of one or more PRESENCE TUPLES,
       where a PRESENCE TUPLE consists of a STATUS, an optional
       COMMUNICATION ADDRESS, and optional OTHER PRESENCE MARKUP.
       (RFC2778:Sec.3)

   (b) STATUS has at least the mutually-exclusive values OPEN and
       CLOSED, which have meaning for the acceptance of INSTANT
       MESSAGES, and may have meaning for other COMMUNICATION MEANS.
       There may be other values of STATUS that do not imply anything
       about INSTANT MESSAGE acceptance. These other values of STATUS
       may be combined with OPEN and CLOSED or they may be mutually-
       exclusive with those values. (RFC2778:Sec.3, RFC2779:Sec.4.4.1-
       4.4.3)

   (c) STATUS may consist of single or multiple values. (RFC2778:Sec.2.4)

   (d) There must be a means of extending the common presence format
       to represent additional information not included in the common
       format.  The extension and registration mechanisms must be
       defined for presence information schema, including new STATUS
       conditions and new forms for OTHER PRESENCE MARKUP. (RFC2779:
       Sec.3.1.4-3.1.5)

   (e) The common presence format must include a means to uniquely
       identify the PRESENTITY whose PRESENCE INFORMATION is reported.
       (RFC2779:Sec.3.1.2)

   (f) The common presence format must allow the source of the presence
       data (i.e. PRESENTITY) to utilize some security mechanism (e.g.



Sugano et al.                                                   [Page 4]

INTERNET DRAFT            CPIM Presence Format                March 2002


       digital signature or encryption) for the secure transportation
       of the data. (RFC2779:Sec.5.2.1, 5.3.1, 5.3.3)

   (g) The common presence format must be extensible to represent
       additional information not defined in this memo. (RFC2779:
       Sec.3.1.4)


2.2.   Added Features

   In addition to the minimal model described above, the format
   specified in this specification has the following extra features.
   [TBD: Needs more explanations]

   (a) Relative priorities of contact addresses.

   (b) Timestamping


2.3.   Encoding Decisions

2.3.1. Adoption of XML

   The CPIM Presence Information Data Format encodes presence
   information in XML (eXtensible Markup Language [XML]). Because XML
   provides an excellent framework to contain structured data such as
   PRESENCE INFORMATION and inherently extensible, it is supposed to be
   more desirable for our purpose than other format such as vCard.

   [TBD]

2.3.2. Combining Multiple Presence Documents

   If a presence service needs to combine multiple presence documents as
   opaque data, i.e. without processing the XML contents, in a single
   notification message, the MIME multipart entity is used. The reason
   for using MIME multipart comes from an architectural consideration
   such that each component presence document may come from different
   sources and it might be secured with a MIME security mechanism by the
   presence source.


3.     Overview of Presence Information Data Format

   This section describes an overview of the presence data format
   defined in this memo.

3.1.   The 'application/cpim-pidf+xml' Content Type



Sugano et al.                                                   [Page 5]

INTERNET DRAFT            CPIM Presence Format                March 2002


   This memo defines a new content type "application/cpim-pidf+xml" to
   contain an XML-encoded presence information document which conforms
   to this specification.

   The content type "application/cpim-pidf+xml" MAY have a "charset"
   parameter to indicate the character set and its encoding used in the
   body.  If no "charset" is specified, the application MUST treat the
   body as "UTF-8" encoded.


3.2.   Presence Information Contents

   This subsection outlines types of information included in an
   "application/cpim-pidf+xml" type document. The real definition of the
   content type will be presented in Section 4.

     o PRESENTITY URL: specifies the "pres" URL of the PRESENTITY.
     o List of presence tuples
       - Status: OPEN/CLOSED for Instant Messaging or status for
           other communication means.
       - Communication address: communication means and contact
           address of this tuple. (optional)
       - Relative priority: numerical value specifying the priority
           of this communication address. (optional)
       - Timestamp: timestamp of the change of this tuple.(optional)
       - Human readable comment: free text memo about this tuple
           (optional)
     o PRESENTITY human readable comment: free text memo about the
         PRESENTITY (optional).


3.3.   Using Multipart Entity

   For the purpose of combining multiple presence documents as opaque
   data, the "multipart/mixed" content type MUST be used.  Each part of
   the multipart entity itself SHOULD be an "application/cpim-pidf+xml"
   type MIME entity or a signed or encrypted MIME entity using the MIME
   security multiparts in conjunction with an appropriate security
   scheme.  Section 5.2 describes the usage of the "multipart/mixed"
   content type to convey multiple presence documents.



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



Sugano et al.                                                   [Page 6]

INTERNET DRAFT            CPIM Presence Format                March 2002


   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.   XML Format Definitions

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

4.1.1. The <presence> element

   The root element of the "application/cpim-pidf+xml" object is defined
   as <presence>.  This element contains one <presentity> element, one
   or more <tuple> elements, and an OPTIONAL <note> element.

   The <presence> element SHOULD contain an 'xmlns' attribute to
   indicate the namespace of the version of the presence document.  The
   presence document compliant to this specification MUST have the
   namespace 'urn:ietf:params:cpim-presence:'.

4.1.2. The <presentity> element

   The <presentity> element MUST have an 'id' attribute and has no
   content.  The value of the 'id' attribute is the 'pres' URL of the
   PRESENTITY publishing this PRESENCE INFORMATION.

4.1.3. 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>, <note>, and <timestamp>
   elements.

   The <tuple> element MUST contain an 'id' attribute which is used to
   distinguish this tuple from other tuples in the same XML document.
   The value of an 'id' attribute MUST be a CDATA value, and MUST be
   unique within 'id' attribute values of other tuples in the same
   document.  An 'id' value is used by applications processing the
   presence document to identify the corresponding tuple in the
   previously acquired PRESENCE INFORMATION of the same PRESENTITY.

   The reason the <contact> element is OPTIONAL is that there is a case
   a PRESENTITY might need to hide its communication address or there
   might be tuples not related to any communication means.

4.1.4. The <status> element

   The <status> element contains one or more <value> elements.  It can
   have multiple status values at the same time.  By allowing multiple



Sugano et al.                                                   [Page 7]

INTERNET DRAFT            CPIM Presence Format                March 2002


   status values in a single <tuple> element, different types of status
   values, e.g. reachability and location, can be represented by a
   <tuple>. See Section 4.3 for an example with multiple status values.

4.1.5. The <value> element

   The <value> element contains a CDATA value and has OPTIONAL 'type'
   and 'schema' attributes.  The value is case-sensitive. The 'type'
   attribute indicates the type of this value which restrict the range
   of the values in which the content CDATA value varies.   The 'schema'
   attribute is a URL pointing to the definition of the type and its
   possible values, which is usually a DTD.

   If the type attribute does not appear, the application MUST treat the
   element as if the type is 'urn:ietf:params:cpim-presence:status-
   type:basic', i.e.  the 'basic' type whose possible values are either
   "open" or "closed".  The values "open" and "closed" has the same
   meaning as OPEN and CLOSED defined in RFC 2778 respectively, and
   stand for availability of receiving insatnt messages if the <tuple>
   is for an instant messaging address.  They also have meanings of
   general availability for other communication means. But, this memo
   does not specify them in detail.

   When a new 'type' is defined, it MUST specify the purpose of this
   type, range of values, the exact meaning of each value, and
   description of possible dependencies with other types if exists.

4.1.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. If the 'priority' attribute is
   omitted, applications MUST understand that the contact address has
   the lowest priority.  If the 'priority' value is out of the range,
   applications just SHOULD ignore the value and process it as it is
   omitted.

   It is RECOMMENDED that applications handles a tuple with higher
   priority than another one so that the priority is recognizable by
   users.  How to handle tuples with the same priority is up to
   implementations.

4.1.7. The <note> element

   The <note> element contains a CDATA value, which is usually used for
   a human readable comment.  A <note> element MAY appear as a child



Sugano et al.                                                   [Page 8]

INTERNET DRAFT            CPIM Presence Format                March 2002


   element of <presence> and as that of the <tuple> element.  In the
   former case, the comment is about the PRESENTITY and, in the latter
   case, the comment is regarding the particular tuple.

4.1.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
   [DateTime].


4.2.   Presence Information Extensibility

   The presence information extensibility framework is based on XML
   namespaces [XML-NS].

4.2.1. XML Namespaces Background

   All elements and some attributes are associated with a "namespace",
   which is in turn associated with a globally unique URI.  Any
   developer can introduce their own element names, avoiding conflict by
   choosing an appropriate namespace URI.

   Within the presence data, element or attribute names are associated
   with a particular namespace by a namespace prefix, which is a leading
   part of the name, followed by a colon (":"); e.g.

      <prefix:element-name ...> ... </prefix:element-name>

   Where, 'prefix' is the header name prefix, 'element-name' is a name
   which is scoped by the namespace associated with 'prefix'.  Note that
   the choice of 'prefix' is quite arbitrary;  it is the corresponding
   URI that defines the naming scope.  Two different prefixes associated
   with the same namespace URI refer to the same namespace.

   A default namespace can be declared for XML elements without a
   namespace prefix.  The default namespace does NOT apply to attribute
   names, but interpretation of an unprefixed attribute can be
   determined by the containing element.

   A namespace is identified by a URI.  In this usage, the URI is used
   simply as a globally unique identifier, and there is no requirement
   that it can be used to retrieve a web resource, or for any other
   purpose.  Any legal globally unique URI MAY be used to identify a
   namespace.  (By "globally unique", we mean constructed according to
   some set of rules so that it is reasonable to expect that nobody else
   will use the same URI for a different purpose.)



Sugano et al.                                                   [Page 9]

INTERNET DRAFT            CPIM Presence Format                March 2002


   For further details, see the XML namespace specification [XML-NS].

4.2.2. XML Namespaces In Presence Information

   A URI used as a namespace identifier in PRESENCE INFORMATION data
   MUST be a full absolute-URI, per RFC 2396 [URI].  (Relative URIs and
   URI- references containing fragment identifiers MUST NOT be used for
   this purpose.)

   The namespace URI for elements defined by this specification is a URN
   [URN], using the namespace identifier 'ietf' defined by [URN-NS-IETF]
   and extended by [URN-SUB-NS]:

     urn:ietf:params:cpim-presence:

   Thus, simple presence data might be thus:

       <impp:presence xmlns:impp="urn:ietf:params:cpim-presence:">
         <impp:presentity id="pres:shingo@jp.fujitsu.com">
         <impp:tuple id="mobile-phone">
           <impp:status>
             <impp:value>open</impp:value>
           </impp:status>
           <impp:contact priority="9">tel:09012345678</impp:contact>
         </impp:tuple>
       </impp:presence>

   or, using a default XML namespace:

       <presence xmlns="urn:ietf:params:cpim-presence:">
         <presentity id="pres:shingo@jp.fujitsu.com">
         <tuple id="mobile-phone">
           <status>
             <value>open</value>
           </status>
           <contact priority="9">tel:09012345678</contact>
         </tuple>
       </presence>


4.2.3. Handling Of Unrecognized Element Names

   Except as noted below, a processor of PRESENCE INFORMATION MUST
   ignore any XML element with an unrecognized name (i.e. having an
   unrecognized namespace URI, or an unrecognized local name within that
   namespace). This includes all of the element content, even if it
   appears to use recognized names.




Sugano et al.                                                  [Page 10]

INTERNET DRAFT            CPIM Presence Format                March 2002


   It may be that some extensions must be understood in order for the
   presence information to be properly understood.  In such cases, the
   element name is qualified with a mustUnderstand='YES' attribute,
   which attribute name is associated with the CPIM presence namespace.

     NOTE:  a mustUnderstand='YES' attribute within an element that is
     being ignored is itself ignored.  The writer of nested mandatory-
     to-understand information is responsible for ensuring that any
     enclosing element is also labelled with a mustUnderstand='YES'
     attribute, if necessary.

   This specification defines (section 4.1) elements within the
   'urn:ietf:params:cpim-presence:' namespace that MUST be recognized in
   CPIM presence data.  Processors MUST handle these as described, even
   if they do not carry a mustUnderstand attribute.  The DTD (section
   4.4) indicates those elements that MUST be present in a valid
   presence information document.

   If an agent receives PRESENCE INFORMATION containing an unrecognized
   element with a mustUnderstand='YES' attribute, it should treat the
   entire PRESENCE INFORMATION as unrecognized and not attempt to
   process it.


4.3.   Examples

4.3.1. Default Namespace And No Extensions

   <presence xmlns="urn:ietf:params:cpim-presence:"
             entity="pres:shingo@jp.fujitsu.com"/>
     <tuple id="mobile-im">
       <status>
         <value>open</value>
         <value
           type="urn:ietf:params:cpim-presence:status-type:im">busy</value>
         <value
           type="urn:example-com:cpim-status-type:location"
           schema="http://www.example.com/impp/location.dtd">home</value>
       </status>
       <contact priority="2">im:shingo@mobilecarrier.ne.jp</contact>
       <note>Don't Disturb Please!</note>
       <timestamp>2001-10-27T16:49:29Z</timestamp>
     </tuple>
     <tuple id="email">
       <status>
         <value>open</value>
       </status>
       <contact priority="1">mailto:shingo@jp.fujitsu.com</contact>



Sugano et al.                                                  [Page 11]

INTERNET DRAFT            CPIM Presence Format                March 2002


     </tuple>
     <note>I'll be in Tokyo tomorrow</note>
   </presence>


4.3.2. Example Presence Information Extensions

   <impp:presence xmlns:impp="urn:ietf:params:cpim-presence:"
                  xmlns:myex="http://id.mycompany.com/cpim-presence/"
                  entity="pres:shingo@jp.fujitsu.com">
     <myex:mytag>My extended presentity information</myex:mytag>

     <impp:tuple id="mobile-phone">
       <impp:status>
         <impp:value>open</impp:value>
       </impp:status>
       <myex:mytupleelement>Extended value in tuple</myex:mytupleelement>
       <impp:contact priority="9">tel:09012345678</impp:contact>
     </impp:tuple>
     <impp:tuple id="mobile-im">
       <impp:status>
         <impp:value>open</impp:value>
       </impp:status>
       <impp:contact priority="1">im:shingo@mobilecarrier.ne.jp</impp:contact>
     </impp:tuple>

   </impp:presence>

4.3.3. Example Mandatory To Understand Extensions

   <impp:presence xmlns:impp="urn:iana:impp:presence:"
                  xmlns:myex="http://id.mycompany.com/cpim-presence/"
                  entity="pres:shingo@jp.fujitsu.com">
     <myex:mytag>My extended presentity information</myex:mytag>

     <impp:tuple id="mobile-phone">
       <impp:status>
         <impp:value>open</impp:value>
       </impp:status>
       <myex:complexExtension impp:mustUnderstand='YES'>
         <myex:ex1 impp:mustUnderstand='YES'>val1</myex:ex1>
         <myex:ex2>val2</myex:ex2>
       </myex:mandatoryExtension>
       <impp:contact priority="9">tel:09012345678</impp:contact>
     </impp:tuple>

   </impp:presence>




Sugano et al.                                                  [Page 12]

INTERNET DRAFT            CPIM Presence Format                March 2002


   Here, <myex:complexExtension>, <myex:ex1> must be understood, but
   <myex:mytag> and <myex:ex2> may be ignored if they are not
   recognized.


4.4.   DTD

   This section gives the Data Type Definition of the
   "application/cpim-pidf+xml" format.  The DTD here is presented only
   for the purpose of description of the format in a well-known method.

   <!ENTITY % URL         "CDATA">
   <!ENTITY % URI         "CDATA">
   <!ENTITY % TUPLEID     "CDATA">
   <!ENTITY % DATETIME    "CDATA">
   <!ENTITY % VALUETYPE   "CDATA">
   <!ENTITY % PRIORITY    "CDATA">
   <!ENTITY % NOTE        "CDATA">

   <!ELEMENT presence ((tuple+),note?)>
   <!ATTLIST presence
             xmlns     %URI;     "urn:ietf:params:cpim-presence:"
             entity    %URL;     #REQUIRED
   >

   <!ELEMENT tuple (status,contact?,note?,timestamp?)>
   <!ATTLIST tuple
             id   %TUPLEID;      #REQUIRED
   >

   <!ELEMENT status (value+)>
   <!ELEMENT value CDATA>
   <!ATTLIST value
             type %VALUETYPE;
                  "urn:ietf:params:cpim-presence:status-type:basic"
             schema %URI;        #IMPLIED
   >

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

   <!ELEMENT note %NOTE;>

   <!ELEMENT timestamp %DATETIME;>





Sugano et al.                                                  [Page 13]

INTERNET DRAFT            CPIM Presence Format                March 2002


5.     Wrapping 'application/cpim-pidf+xml' Data

   This section profiles the use of the CPIM common message format
   [CPIM-MSG] for use when conveying PRESENCE INFORMATION (per [CPIM-
   MSG], section 6).  Also, it describes a way to contain multiple
   "application/cpim-pidf+xml" documents in a MIME multipart entity.


5.1.   When Used With 'message/cpim'

   In order to use the CPIM Message Format, headers needed for this
   usage must be defined [CPIM-MSG].  Among the headers defined by the
   CPIM message format document, the following headers MAY be used to
   convey the PRESENCE INFORMATION.  The default namespace and namespace
   prefix implicitly defined are same as defined in the 'message/cpim'
   specification document.

5.1.1. The 'From' header

   The 'From' header contains the address (pres: URL) of the PRESENTITY
   as the publisher of the contained PRESENCE INFORMATION.  Any
   application compliant to this specification MUST recognize the 'From'
   header.

   This use of 'From' may be considered redundant in the presence of
   <presentity> element in the presence document.  This header is needed
   when the presence server explicitly states the publisher regardless
   of the content of presence documents.


5.1.2. The 'To' header

   The 'To' header contains the address (pres: URL) of the WATCHER as
   the target of the NOTIFY message containing this presence document.
   Any application compliant to this specification MUST recognize the
   'To' header.

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.  The 'DateTime'
   header MUST be present as a 'message/cpim' metadata header if the
   message contains an "application/cpim-pidf+xml" object.  It MUST also
   be recognized by any application compliant to this specification.

5.1.4. The 'NS' header




Sugano et al.                                                  [Page 14]

INTERNET DRAFT            CPIM Presence Format                March 2002


   The "NS" header is used to declare a local namespace prefix as
   defined by [CPIM-MSG].  Any application compliant to this
   specification MUST recognize the 'NS' header.

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].  Any
   application compliant to this specification MUST recognize the
   'Require' header.


5.2.   When Used With 'multipart/mixed'

   When multiple presence documents are combined within a single
   notification message, the 'multipart/mixed' content type MUST be
   used.  Each multipart SHOULD contain a 'Presence-Data-ID' header
   defined as follows.

5.2.1. The 'Presence-Data-ID' header

   The 'Presence-Data-ID' header contains the label for the unit of
   update.  Each labelled unit replaces any previously-received unit
   that had teh same Presence-Data-ID value.


5.3.   Examples

   The following example is the message/cpim object containing two
   presence payloads.  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

     From: pres:shingo@jp.fujitsu.com
     To: pres:suga@flab.fujitsu.co.jp
     DateTime: 2001-06-01T08:35:44+09:00

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

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

     <presence xmlns="urn:ietf:params:cpim-presence:">



Sugano et al.                                                  [Page 15]

INTERNET DRAFT            CPIM Presence Format                March 2002


       <presentity id="pres:shingo@jp.fujitsu.com">
       <tuple id="pc-im">
         <status>
           <value>open</value>
           <value
             type="urn:ietf:params:cpim-presence:status-type:im">AWAY</value>
         </status>
         <contact priority="2">im:shingo@jp.fujitsu.com</contact>
         <note>Boss Meeting</note>
       </tuple>
       <tuple id="email">
         <status>
           <value>open</value>
         </status>
         <contact priority="1">mailto:shingo@jp.fujitsu.com</contact>
       </tuple>
     </presence>
     --PRESENCE-BLOCKS
     Content-Type: application/cpim-pidf+xml
     Presence-Data-ID: part2

     <presence xmlns="urn:ietf:params:cpim-presence:">
       <presentity id="pres:shingo@jp.fujitsu.com">
       <tuple id="mobile-phone">
         <status>
           <value>open</value>
         </status>
         <contact priority="9">tel:09012345678</contact>
       </tuple>
       <tuple id="mobile-im">
         <status>
           <value>open</value>
           <value
             type="urn:ietf:params:cpim-presence:status-type:location"
             schema="http://www.example.com/impp/location.dtd">HOME</value>
         </status>
         <contact priority="2">im:shingo@mobilecarrier.ne.jp</contact>
       </tuple>
     </presence>
     --PRESENCE-BLOCKS--


6.     Security Considerations

   The proposed format for conveying PRESENCE INFORMATION is so designed
   that it could be adaptable in circumstances under various security
   requirements.




Sugano et al.                                                  [Page 16]

INTERNET DRAFT            CPIM Presence Format                March 2002


   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.

7.     IANA Considerations

   [[[Will need a registration template per [URN-SUB-NS], for the URN
   sub-namespace 'urn:ietf:params:cpim-presence:']]]


8.     References

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

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

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

   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
   Requirement Levels", RFC 2119, BCP 14, March 1997.

   [XML] T. Bray, J. Paoli, C. Sperberg-McQueen and E. Maler,
   "Extensible Markup Language (XML) 1.0 (Second Edition)",
   W3C Recommendation, October 2000,
   <http://www.w3.org/TR/2000/REC-xml-20001006>

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

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



Sugano et al.                                                  [Page 17]

INTERNET DRAFT            CPIM Presence Format                March 2002


   [XML-NS] Tim Bray, Dave Hollander, and Andrew Layman "Namespaces in
   XML", W3C recommendation: xml-names, 14 January 1999,
   <http://www.w3.org/TR/REC-xml-names>

   [URI] T. Berners-Lee, R.T.Fielding and L. Masinter, "Uniform
   Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

   [URN] R. Moats, "URN Syntax", RFC 2141, May 1997.

   [URN-NS-IETF]  R. Moats, "A URN Namespace for IETF Documents", RFC
   2648, August 1999.

   [URN-SUB-NS]  M. Mealling, L. Masinter, T. Hardie and G. Klyne,
   "An IETF URN Sub-namespace for Registered Protocol Parameters",
   Internet-Draft draft-mealling-iana-urn-01, Work in Progress.



9.     Author's Addresses

   Hiroyasu Sugano
   Fujitsu Laboratories Ltd.
   64, Nishiwaki
   Ohkubo-cho
   Akashi 674
   Japan
   E-mail: sugano.h@jp.fujitsu.com

   Shingo Fujimoto
   Fujitsu Laboratories Ltd.
   64, Nishiwaki
   Ohkubo-cho
   Akashi 674
   Japan
   E-mail: shingo_fujimoto@jp.fujitsu.com

   Graham Klyne
   Baltimore Technologies - Content Security Group,
   1310 Waterside,
   Arlington Business Park
   Theale
   Reading, RG7 4SA
   United Kingdom.
   Telephone: +44 118 903 8000
   Facsimile: +44 118 903 9000
   E-mail: GK@ACM.ORG

   Adrian Bateman



Sugano et al.                                                  [Page 18]

INTERNET DRAFT            CPIM Presence Format                March 2002


   VisionTech Limited
   Colton, Staffordshire, WS15 3LD
   United Kingdom
   E-mail: bateman@acm.org


10.     Full Copyright Statement

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

   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
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


















Sugano et al.                                                  [Page 19]