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

Expires: November 2002                                         May 2002

              Common Presence and Instant Messaging (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 (2002).  All Rights Reserved.


   This memo specifies the Common Presence and Instant Messaging (CPIM)
   Presence Information Data Format (PIDF) as a common presence data

Sugano et al.                                                   [Page 1]

INTERNET DRAFT            CPIM Presence Format                  May 2002

   format for CPIM-compliant Instant Messaging and Presence protocols,
   and also defines a new media type "application/cpim-pidf+xml" to
   represent the XML MIME entity for PIDF.

Sugano et al.                                                   [Page 2]

INTERNET DRAFT            CPIM Presence Format                  May 2002

Table of Content

      1.     Introduction .........................................    4
      1.1.   Terminology and Conventions ..........................    4
      2.     Design Decisions .....................................    5
      2.1.   Minimal Model ........................................    5
      2.2.   Added Features .......................................    6
      2.3.   XML Encoding Decision ................................    6
      3.     Overview of Presence Information Data Format .........    6
      3.1.   The 'application/cpim-pidf+xml' Content Type .........    7
      3.2.   Presence Information Contents ........................    7
      4.     XML-encoded Presence Data Format .....................    7
      4.1.   XML Format Definitions ...............................    7
      4.1.1. The <presence> element ...............................    8
      4.1.2. The <tuple> element ..................................    8
      4.1.3. The <status> element .................................    9
      4.1.4. The <basic> element ..................................    9
      4.1.5. The <contact> element ................................    9
      4.1.6. The <note> element ...................................   10
      4.1.7. The <timestamp> element ..............................   10
      4.2.   Presence Information Extensibility ...................   10
      4.2.1. XML Namespaces Background ............................   10
      4.2.2. XML Namespaces In Presence Information ...............   11
      4.2.3. Handling Of Unrecognized Element Names ...............   12
      4.2.4. Status Value Extensibility ...........................   13
      4.3.   Examples .............................................   13
      4.3.1. Default Namespace with Status Extensions .............   13
      4.3.2. Presence with Other Extension Elements ...............   14
      4.3.3. Example Mandatory To Understand Extensions ...........   15
      4.4.   XML Schema Definitions ...............................   15
      5.     IANA Considerations ..................................   17
      5.1.   Content-type registration for 'application/cpim-pidf+xml'
                 ..................................................   17
      5.2.   URN sub-namespace registration for
                 'urn:ietf:params:xml:ns:cpim-pidf' ...............   18
      6.     Security Considerations ..............................   19
      7.     Internationalization Considerations ..................   19
      8.     Normative References .................................   20
      9.     Informative References ...............................   21
      10.     Authors' Addresses ..................................   21
      11.     Appendix A. Document Type Definitions ...............   22
      12.     Full Copyright Statement ............................   23

Sugano et al.                                                   [Page 3]

INTERNET DRAFT            CPIM Presence Format                  May 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 also disables 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.

   Note also that this memo only defines the format for a presence data
   payload only and how the presence data is transferred within a
   specific protocol frame would be defined in actual protocol

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

Sugano et al.                                                   [Page 4]

INTERNET DRAFT            CPIM Presence Format                  May 2002

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

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 a number of 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 have been 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 grounds, 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

   (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-

   (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:

   (e) The common presence format must include a means to uniquely

Sugano et al.                                                   [Page 5]

INTERNET DRAFT            CPIM Presence Format                  May 2002

       identify the PRESENTITY whose PRESENCE INFORMATION is reported.

   (f) The common presence format must allow the source of the presence
       data (i.e. PRESENTITY) to utilize some security mechanism (e.g.
       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:

2.2.   Added Features

   In addition to the minimal model described above, the format
   specified in this specification has the following features.

   (a) Relative priorities of contact addresses should be specifiable
       in order to allow the source of PRESENCE INFORMATION to tell the
       receiver (WATCHER USER AGENTS) its preference over multiple contact

   (b) The presence format should be able to contain the timestamp of
       the creation of the PRESENCE INFORMATION.  The timestamp in the
       presence document lets the receiver know the time of the creation
       of the data even if the message containing it arrives late for
       some reason.  It can also be used to detect a replay attack,
       independent of the underlying signature mechanism.

2.3.   XML Encoding Decision

   The CPIM Presence Information Data Format encodes presence
   information in XML (eXtensible Markup Language [XML]), which is
   rapidly gaining broad acceptance as a syntactic framework to encode
   structured data transferred over the Internet.  Regarding the
   features of PRESENCE INFORMATION discussed above, such that it has a
   hierarchical structure and it should be fully extensible, XML is
   considered as the most desirable framework over other candidates such
   as vCard [RFC2426].

3.     Overview of Presence Information Data Format

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

Sugano et al.                                                   [Page 6]

INTERNET DRAFT            CPIM Presence Format                  May 2002

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

   This memo defines a new content type "application/cpim-pidf+xml" to
   represent an XML MIME entity which encodes a presence information
   document conformant to this specification.  Because the new content
   type is XML-based, this specification follows the recommendations and
   conventions described in [RFC3023], including the naming convention
   of the type ('+xml' suffix) and the usage of the 'charset' parameter.

   As for the 'charset' parameter, although it is defined as optional,
   the use of that parameter is STRONGLY RECOMMENDED.  If the 'charset'
   parameter is not specified, conforming XML processors to [XML] MUST
   follow the requirements in section 4.3.3 of [XML].

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
     o PRESENTITY human readable comment: free text memo about the
         PRESENTITY (optional).

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

Sugano et al.                                                   [Page 7]

INTERNET DRAFT            CPIM Presence Format                  May 2002

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

   It MUST have the XML declaration and it SHOULD contain an encoding
   declaration in the XML declaration, e.g. "<?XML version='1.0'
   encoding='UTF-8'?>". If the charset parameter of the MIME content
   type declaration is present and it is different from the encoding
   declaration, the charset parameter takes precedence.

4.1.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,
   followed by any number (including 0) of OPTIONAL <note> elements,
   followed by any number of OPTIONAL extension elements from other

   The <presence> element MUST have an 'entity' attribute. The value of
   the 'entity' attribute is the 'pres' URL of the PRESENTITY publishing
   this presence document.

   The <presence> element MUST contain a namespace declaration ('xmlns')
   to indicate the namespace on which the presence document is based.
   The presence document compliant to this specification MUST have the
   namespace 'urn:ietf:params:xml:ns:cpim-pidf:'.

   It MAY contain other namespace declarations for the extensions used
   in the presence XML document.

4.1.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 one
   mandatory <status> element, followed by any number of OPTIONAL
   extension elements from other namespaces, followed by one OPTIONAL
   <contact> elements, followed by any number of OPTIONAL <note>
   elements, followed by one OPTIONAL <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 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 value of the 'id' attribute SHOULD be
   treated as just a CDATA value (no semantics).

Sugano et al.                                                   [Page 8]

INTERNET DRAFT            CPIM Presence Format                  May 2002

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

4.1.3. The <status> element

   The <status> element contains one OPTIONAL <basic> elements, followed
   by any number of OPTIONAL extension elements from other namespaces,
   under the restriction that at least one child element appears in the
   <status> element.  These children elements of <status> contain status
   values of this tuple. By allowing multiple 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.

   This memo only defines the <basic> status value element. Other status
   values may be included using the standard extensibility framework
   (see Section 4.2.4). Applications encountering unrecognized elements
   within <status> may ignore them, unless they carry a
   mustUnderstand="true" or mustUnderstand="1" attribute (see section

   Note that, while the <status> element MUST have at least one status
   value element, this status value may not be the <basic> element.

4.1.4. The <basic> element

   The <basic> element contains one of the following strings: "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 instant 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.

4.1.5. 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 a decimal number between 0 and 1 inclusive with at
   most 3 digits after the decimal point.  Higher values indicate higher
   priority. Examples of priority values are 0, 0.021, 0.5, 1.00. If the
   'priority' attribute is omitted, applications MUST understand that
   the contact address has the lowest priority.  If the 'priority' value

Sugano et al.                                                   [Page 9]

INTERNET DRAFT            CPIM Presence Format                  May 2002

   is out of the range, applications just SHOULD ignore the value and
   process it as if the attribute was not present.

   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

4.1.6. The <note> element

   The <note> element contains a string value, which is usually used for
   a human readable comment.  A <note> element MAY appear as a child
   element of <presence> or as a child element 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.

   The <note> element SHOULD have a special attribute 'xml:lang' to
   specify the language used in the contents of this element as defined
   in Section 2.12 of [XML].  The value of this attribute is the
   language indentifier as defined by [RFC 1766]. It MAY be omitted when
   the language used is implied by the larger context such as the
   encoding information of the contents, e.g. the 'Shift_JIS' encoding
   imples the language 'ja'.

4.1.7. The <timestamp> element

   The <timestamp> element contains 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].

   While the IMPP datetime format allows use of either 'z' or 'Z' and
   also 't' or 'T', XML Schema's dateTime requires using only 'T' and
   'Z'. Timestamps that contain 'T' or 'Z' MUST use the capitalized
   forms [XMLSchema2].

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

Sugano et al.                                                  [Page 10]

INTERNET DRAFT            CPIM Presence Format                  May 2002

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

   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 [XML-Registry]:


   Thus, simple presence data might be thus:

     <?xml version="1.0" encoding="UTF-8"?>
     <impp:presence xmlns:impp="urn:ietf:params:xml:ns:cpim-pidf"

Sugano et al.                                                  [Page 11]

INTERNET DRAFT            CPIM Presence Format                  May 2002

       <impp:tuple id="mobile-phone">
         <impp:contact priority="0.8">tel:09012345678</impp:contact>

   or, using a default XML namespace:

     <?xml version="1.0" encoding="UTF-8"?>
     <presence xmlns="urn:ietf:params:xml:ns:cpim-pidf"
       <tuple id="mobile-phone">
         <contact priority="0.8">tel:09012345678</contact>

   As is generally the case in XML, the xmlns attribute can be used on
   any element in the presence information to define either the default
   namespace or a namespace associated with a namespace prefix.

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.

   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='true' or
   mustUnderstand='1' attribute, which attribute name is associated with
   the CPIM presence namespace.

     NOTE:  a mustUnderstand='true' or mustUnderstand='1' 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='true' or mustUnderstand='1' attribute, if

Sugano et al.                                                  [Page 12]

INTERNET DRAFT            CPIM Presence Format                  May 2002

   This specification defines (section 4.1) elements within the
   'urn:ietf:params:xml:ns:cpim-pidf' 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 XML Schema
   Definition (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='true' (or '1') attribute, it should
   treat the entire PRESENCE INFORMATION as unrecognized and not attempt
   to process it.

4.2.4. Status Value Extensibility

   This memo only defines the <basic> status value with values of "open"
   and "closed". Other status values are possible using the standard
   namespace-based extensibility rules defined above.

   For example, a location status value might be included thus:

     <?xml version="1.0" encoding="UTF-8"?>
     <presence xmlns="urn:ietf:params:xml:ns:cpim-pidf"
       <tuple id="im">

   Some new status values will 'extend' the value of the <basic>
   element. For example, a status value defined for use with instant
   messaging may include values such as 'away', 'busy' and 'offline'. In
   order that some level of interoperability be maintained with user
   agents that don't recognise the new extension, the <basic> status
   value must also be included. This means that extensions are not
   obligated to define a mapping from each of their values to OPEN or

4.3.   Examples

4.3.1. Default Namespace with Status Extensions

Sugano et al.                                                  [Page 13]

INTERNET DRAFT            CPIM Presence Format                  May 2002

   <?xml version="1.0" encoding="UTF-8"?>
   <presence xmlns="urn:ietf:params:xml:ns:cpim-pidf"
     <tuple id="mobile-im">
       <contact priority="0.8"></contact>
       <note xml:lang="en">Don't Disturb Please!</note>
       <note xml:lang="fr">Ne derangez pas, s'il vous plait</note>
     <tuple id="email">
       <contact priority="1.0"></contact>
     <note>I'll be in Tokyo next week</note>

4.3.2. Presence with Other Extension Elements

   <?xml version="1.0" encoding="UTF-8"?>
   <impp:presence xmlns:impp="urn:ietf:params:xml:ns:cpim-pidf"
     <impp:tuple id="mobile-phone">
       <myex:mytupleelement>Extended value in tuple</myex:mytupleelement>
       <impp:contact priority="0.65">tel:09012345678</impp:contact>
     <impp:tuple id="mobile-im">
       <impp:contact priority="1.0">
     <myex:mytag>My extended presentity information</myex:mytag>

Sugano et al.                                                  [Page 14]

INTERNET DRAFT            CPIM Presence Format                  May 2002

4.3.3. Example Mandatory To Understand Extensions

   <?xml version="1.0" encoding="UTF-8"?>
   <impp:presence xmlns:impp="urn:ietf:params:xml:ns:cpim-pidf"
     <impp:tuple id="mobile-phone">
       <myex:complexExtension impp:mustUnderstand="1">
         <myex:ex1 impp:mustUnderstand="1">val1</myex:ex1>
       <impp:contact priority="0.725">tel:09012345678</impp:contact>
     <myex:mytag>My extended presentity information</myex:mytag>

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

4.4.   XML Schema Definitions

   This section gives the XML Schema Definition [XMLSchema1] of the
   "application/cpim-pidf+xml" format.  This is presented as a formal
   definition of the "application/cpim-pidf+xml" format.  Note that the
   XML Schema definition is not intended to be used with on-the-fly
   validation of the presence XML document.

   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema targetNamespace="urn:ietf:params:xml:ns:cpim-pidf"

     <!-- This import brings in the XML language attribute xml:lang-->
     <xs:import namespace=""

     <xs:element name="presence" type="tns:presence"/>

     <xs:complexType name="presence">
         <xs:element name="tuple" type="tns:tuple"

Sugano et al.                                                  [Page 15]

INTERNET DRAFT            CPIM Presence Format                  May 2002

         <xs:element name="note" type="tns:note" minOccurs="0"
         <xs:any namespace="##other" processContents="lax" minOccurs="0"
       <xs:attribute name="entity" type="xs:anyURI" use="required"/>

     <xs:complexType name="tuple">
         <xs:element name="status" type="tns:status"/>
         <xs:any namespace="##other" processContents="lax" minOccurs="0"
         <xs:element name="contact" type="tns:contact" minOccurs="0"/>
         <xs:element name="note" type="tns:note" minOccurs="0"
         <xs:element name="timestamp" type="xs:dateTime" minOccurs="0"/>
       <xs:attribute name="id" type="xs:ID" use="required"/>

     <xs:complexType name="status">
         <xs:element name="basic" type="tns:basic" minOccurs="0"/>
         <xs:any namespace="##other" processContents="lax" minOccurs="0"

     <xs:simpleType name="basic">
       <xs:restriction base="xs:string">
         <xs:enumeration value="open"/>
         <xs:enumeration value="closed"/>

     <xs:complexType name="contact">
         <xs:extension base="xs:anyURI">
           <xs:attribute name="priority" type="tns:qvalue"/>

     <xs:complexType name="note">
         <xs:extension base="xs:string">

Sugano et al.                                                  [Page 16]

INTERNET DRAFT            CPIM Presence Format                  May 2002

           <xs:attribute ref="xml:lang"/>

     <xs:simpleType name="qvalue">
       <xs:restriction base="xs:decimal">
         <xs:pattern value="0(.[0-9]{0,3})?"/>
         <xs:pattern value="1(.0{0,3})?"/>

     <!-- Global Attributes -->
     <xs:attribute name="mustUnderstand" type="xs:boolean" default="0"/>

5.     IANA Considerations

   This memo calls for IANA to:
      - register a new MIME content-type application/cpim-pidf+xml,
        per [RFC 2048],
      - register a new XML namespace URN per [XML-Registry].

   The registration templates for these are below.

5.1.   Content-type registration for 'application/cpim-pidf+xml'

      Subject: Registration of MIME media type application/cpim-pidf+xml

      MIME media type name:  application

      MIME subtype name:     cpim-pidf+xml

      Required 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 [RFC 3023], section 3.2.

      Security considerations:

Sugano et al.                                                  [Page 17]

INTERNET DRAFT            CPIM Presence Format                  May 2002

         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:
         This content type provides a common format for exchange of presence
         information across different CPIM compliant protocols.

      Published specification:
         RFCXXXX (this document)

      Applications which use this media type:
         Presence and instant messaging systems.

      Additional information:

        Magic number(s):
        File extension(s):
        Macintosh File Type Code(s):

      Person & email address to contact for further information:
         Hiroyasu Sugano

      Intended usage:
         LIMITED USE

      Author/Change controller:
         This specification is a work item of the IETF IMPP working group,
         with mailing list address <>.

      Other information:
         This media type is a specialization of application/xml [RFC 3023],
         and many of the considerations described there also apply to

5.2.   URN sub-namespace registration for 'urn:ietf:params:xml:ns:cpim-


         This is the XML namespace URI for XML elements defined by [RFCXXXX]
         to describe CPIM presence information in application/cpim-pidf+xml
         content type.

Sugano et al.                                                  [Page 18]

INTERNET DRAFT            CPIM Presence Format                  May 2002

      Registrant Contact
         IETF, IMPP working group, <>
         Hiroyasu Sugano, <>

           <?xml version="1.0"?>
           <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
           <html xmlns="">
             <meta http-equiv="content-type"
             <meta name="generator" content="Adobe GoLive 6"/>
             <title>Welcome to Adobe GoLive 6</title>
             <h1>Namespace for CPIM presence information</h1>
             <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>

6.     Security Considerations

   Because presence is very privacy-sensitive information, the transport
   protocol for the presence information SHOULD have capabilities to
   protect protocol messages from possible threats, such as
   eavesdropping, corruption, tamper and replay attacks.  The protocols
   SHOULD be able to use security mechanisms which are standardized or
   being standardized in IETF.  However, it depends on the actual
   transport protocols which security mechanisms should be used, and it
   is beyond the scope of this memo.

7.     Internationalization Considerations

   This memo does not specify the use of specific character encodings by
   itself.  However, all the processors MUST be able to use the UTF-8
   encoding because it is one of the mandatory character encodings for
   XML conforming processors and also RFC 2277 requires the handling of
   UTF-8 for the Internet protocols [RFC2277].

   Other character encodings may be used if a particular protocol or
   application using this specification needs them.  In this case, a
   conscious decision is needed about which character encoding(s) to

Sugano et al.                                                  [Page 19]

INTERNET DRAFT            CPIM Presence Format                  May 2002

   allow in order to promote the interoperability.

8.     Normative References

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

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

   [RFC3023] M. Murata, S. St.Laurent, D. Kohn, "XML Media Types",
   RFC 3023, January 2001.

   [XML] T. Bray, J. Paoli, C. Sperberg-McQueen and E. Maler,
   "Extensible Markup Language (XML) 1.0 (Second Edition)",
   W3C Recommendation, October 2000,

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

   [RFC1766] H. Alvestrand, "Tags for the Identification of Languages",
   RFC 1766, March 1995.

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

   [XML-NS] Tim Bray, Dave Hollander, and Andrew Layman "Namespaces in
   XML", W3C recommendation: xml-names, 14 January 1999,

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

   [XML-Registry] M. Mealling, "The IETF XML Registry",
   draft-mealling-iana-xmlns-registry-03, Work in Progress.

   [RFC2277]  H. Alvestrand, "IETF Policy on Character Sets and
   Languages", RFC 2277, BCP 18, January 1998.

Sugano et al.                                                  [Page 20]

INTERNET DRAFT            CPIM Presence Format                  May 2002

   [XMLSchema1] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn,
   "XML Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001,

   [XMLSchema2] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes",
   W3C REC-xmlschema-2, May 2001, <>.

9.     Informative References

   [CPIM] D. Crocker et al., "Common Presence and 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.

   [vCard] F. Dawson and T. Howes, "vCard MIME Directory Profile",
   RFC 2426, September 1998.

10.     Authors' Addresses

   Hiroyasu Sugano
   Fujitsu Laboratories Ltd.
   64, Nishiwaki
   Akashi 674-8555

   Shingo Fujimoto
   Fujitsu Laboratories Ltd.
   64, Nishiwaki
   Akashi 674-8555

   Graham Klyne
   Baltimore Technologies - Content Security Group,
   1310 Waterside,
   Arlington Business Park
   Reading, RG7 4SA
   United Kingdom.
   Telephone: +44 118 903 8000

Sugano et al.                                                  [Page 21]

INTERNET DRAFT            CPIM Presence Format                  May 2002

   Facsimile: +44 118 903 9000
   E-mail: GK@ACM.ORG

   Adrian Bateman
   VisionTech Limited
   Colton, Staffordshire, WS15 3LD
   United Kingdom

   Wayne Carr
   Intel Corporation
   2111 NE 25th Avenue
   Hillsboro, OR 97124

11.     Appendix A. Document Type Definitions

   The Document Type Definition for the "application/cpim-pidf+xml"
   format is described.  The DTD here is presented only for
   informational for those who may not familiar with the XML Schema

   Note: the DTD does not show where extension elements can be added.
   See the XML Schema for that information.

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

   <!ELEMENT presence ((tuple+),note?)>
   <!ATTLIST presence
             xmlns     %URI;     #REQUIRED
             entity    %URL;     #REQUIRED

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

   <!ELEMENT status (basic?)>

Sugano et al.                                                  [Page 22]

INTERNET DRAFT            CPIM Presence Format                  May 2002

   <!ELEMENT basic CDATA>

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

   <!ELEMENT note %NOTE;>

   <!ELEMENT timestamp %DATETIME;>

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

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