rfc 3863 presence information data format (pidf).htm

有关IMS SIP及Presence应用的RFC文档包

       <A href="http://tools.ietf.org/html/rfc3863#section-4.1">4.1</A>.  XML Format Definitions . . . . . . . . . . . . . . . . .  <A href="http://tools.ietf.org/html/rfc3863#page-6">6</A>



<SPAN class=grey>Sugano, et al.              Standards Track                     [Page 1]</SPAN>
<A id=page-2 href="http://tools.ietf.org/html/rfc3863#page-2" name=page-2><SPAN class=break> </SPAN></A>
<SPAN class=grey><A href="http://tools.ietf.org/html/rfc3863">RFC 3863</A>            Presence Information Data Format         August 2004</SPAN>


             <A href="http://tools.ietf.org/html/rfc3863#section-4.1.1">4.1.1</A>. The &lt;presence&gt; element. . . . . . . . . . . . . .  <A href="http://tools.ietf.org/html/rfc3863#page-6">6</A>
             <A href="http://tools.ietf.org/html/rfc3863#section-4.1.2">4.1.2</A>. The &lt;tuple&gt; element . . . . . . . . . . . . . . .  <A href="http://tools.ietf.org/html/rfc3863#page-7">7</A>
             <A href="http://tools.ietf.org/html/rfc3863#section-4.1.3">4.1.3</A>. The &lt;status&gt; element. . . . . . . . . . . . . . .  <A href="http://tools.ietf.org/html/rfc3863#page-8">8</A>
             <A href="http://tools.ietf.org/html/rfc3863#section-4.1.4">4.1.4</A>. The &lt;basic&gt; element . . . . . . . . . . . . . . .  <A href="http://tools.ietf.org/html/rfc3863#page-8">8</A>
             <A href="http://tools.ietf.org/html/rfc3863#section-4.1.5">4.1.5</A>. The &lt;contact&gt; element . . . . . . . . . . . . . .  <A href="http://tools.ietf.org/html/rfc3863#page-8">8</A>
             <A href="http://tools.ietf.org/html/rfc3863#section-4.1.6">4.1.6</A>. The &lt;note&gt; element. . . . . . . . . . . . . . . .  <A href="http://tools.ietf.org/html/rfc3863#page-9">9</A>
             <A href="http://tools.ietf.org/html/rfc3863#section-4.1.7">4.1.7</A>. The &lt;timestamp&gt; element . . . . . . . . . . . . .  <A href="http://tools.ietf.org/html/rfc3863#page-9">9</A>
       <A href="http://tools.ietf.org/html/rfc3863#section-4.2">4.2</A>.  Presence Information Extensibility . . . . . . . . . . . <A href="http://tools.ietf.org/html/rfc3863#page-10">10</A>
             <A href="http://tools.ietf.org/html/rfc3863#section-4.2.1">4.2.1</A>. XML Namespaces Background . . . . . . . . . . . . <A href="http://tools.ietf.org/html/rfc3863#page-10">10</A>
             <A href="http://tools.ietf.org/html/rfc3863#section-4.2.2">4.2.2</A>. XML Namespaces In Presence Information. . . . . . <A href="http://tools.ietf.org/html/rfc3863#page-11">11</A>
             <A href="http://tools.ietf.org/html/rfc3863#section-4.2.3">4.2.3</A>. Handling Of Unrecognized Element Names. . . . . . <A href="http://tools.ietf.org/html/rfc3863#page-12">12</A>
             <A href="http://tools.ietf.org/html/rfc3863#section-4.2.4">4.2.4</A>. Status Value Extensibility. . . . . . . . . . . . <A href="http://tools.ietf.org/html/rfc3863#page-12">12</A>
             <A href="http://tools.ietf.org/html/rfc3863#section-4.2.5">4.2.5</A>. Standardizing Status Extensions . . . . . . . . . <A href="http://tools.ietf.org/html/rfc3863#page-13">13</A>
       <A href="http://tools.ietf.org/html/rfc3863#section-4.3">4.3</A>.  Examples . . . . . . . . . . . . . . . . . . . . . . . . <A href="http://tools.ietf.org/html/rfc3863#page-14">14</A>
             <A href="http://tools.ietf.org/html/rfc3863#section-4.3.1">4.3.1</A>. Default Namespace with Status Extensions. . . . . <A href="http://tools.ietf.org/html/rfc3863#page-14">14</A>
             <A href="http://tools.ietf.org/html/rfc3863#section-4.3.2">4.3.2</A>. Presence with Other Extension Elements. . . . . . <A href="http://tools.ietf.org/html/rfc3863#page-15">15</A>
             <A href="http://tools.ietf.org/html/rfc3863#section-4.3.3">4.3.3</A>. Example Mandatory To Understand Elements. . . . . <A href="http://tools.ietf.org/html/rfc3863#page-16">16</A>
       <A href="http://tools.ietf.org/html/rfc3863#section-4.4">4.4</A>.  XML Schema Definitions . . . . . . . . . . . . . . . . . <A href="http://tools.ietf.org/html/rfc3863#page-16">16</A>
   <A href="http://tools.ietf.org/html/rfc3863#section-5">5</A>.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . <A href="http://tools.ietf.org/html/rfc3863#page-18">18</A>
       <A href="http://tools.ietf.org/html/rfc3863#section-5.1">5.1</A>.  Content-type registration for 'application/pidf+xml' . . <A href="http://tools.ietf.org/html/rfc3863#page-18">18</A>
       <A href="http://tools.ietf.org/html/rfc3863#section-5.2">5.2</A>.  URN sub-namespace registration for
             'urn:ietf:params:xml:ns:pidf'. . . . . . . . . . . . . . <A href="http://tools.ietf.org/html/rfc3863#page-19">19</A>
       <A href="http://tools.ietf.org/html/rfc3863#section-5.3">5.3</A>.  URN sub-namespace registration for
             'urn:ietf:params:xml:ns:pidf:status' . . . . . . . . . . <A href="http://tools.ietf.org/html/rfc3863#page-20">20</A>
   <A href="http://tools.ietf.org/html/rfc3863#section-6">6</A>.  Security Considerations. . . . . . . . . . . . . . . . . . . . <A href="http://tools.ietf.org/html/rfc3863#page-21">21</A>
   <A href="http://tools.ietf.org/html/rfc3863#section-7">7</A>.  Internationalization Considerations. . . . . . . . . . . . . . <A href="http://tools.ietf.org/html/rfc3863#page-22">22</A>
   <A href="http://tools.ietf.org/html/rfc3863#section-8">8</A>.  References . . . . . . . . . . . . . . . . . . . . . . . . . . <A href="http://tools.ietf.org/html/rfc3863#page-22">22</A>
       <A href="http://tools.ietf.org/html/rfc3863#section-8.1">8.1</A>.  Normative References . . . . . . . . . . . . . . . . . . <A href="http://tools.ietf.org/html/rfc3863#page-22">22</A>
       <A href="http://tools.ietf.org/html/rfc3863#section-8.2">8.2</A>.  Informative References . . . . . . . . . . . . . . . . . <A href="http://tools.ietf.org/html/rfc3863#page-23">23</A>
   Appendix A. Document Type Definitions. . . . . . . . . . . . . . . <A href="http://tools.ietf.org/html/rfc3863#page-25">25</A>
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . <A href="http://tools.ietf.org/html/rfc3863#page-26">26</A>
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . <A href="http://tools.ietf.org/html/rfc3863#page-28">28</A>

<SPAN class=h2><A name=section-1>1</A>.  Introduction</SPAN>

   The Common Profiles for Instant Messaging (CPIM) [<A title='"Common Profile for Instant Messaging (CPIM)"' href="http://tools.ietf.org/html/rfc3863#ref-CPIM">CPIM</A>] and Presence
   (CPP) [<A title='"Common Presence for Presence (CPP)"' href="http://tools.ietf.org/html/rfc3863#ref-CPP">CPP</A>] specifications define a set of operations and parameters
   to achieve interoperability between different Instant Messaging and
   Presence protocols which meet <A href="http://tools.ietf.org/html/rfc2779">RFC 2779</A> [<A title='"Instant Messaging / Presence Protocol Requirements"' href="http://tools.ietf.org/html/rfc2779">RFC2779</A>].

   This memo further defines the Presence Information Data Format (PIDF)
   as a common presence data format for CPP-compliant presence
   protocols, allowing presence information to be transferred across
   CPP-compliant protocol boundaries without modification, with
   attendant benefits for security and performance.






<SPAN class=grey>Sugano, et al.              Standards Track                     [Page 2]</SPAN>
<A id=page-3 href="http://tools.ietf.org/html/rfc3863#page-3" name=page-3><SPAN class=break> </SPAN></A>
<SPAN class=grey><A href="http://tools.ietf.org/html/rfc3863">RFC 3863</A>            Presence Information Data Format         August 2004</SPAN>


   The format specified in this memo defines the base presence format
   and extensibility required by <A href="http://tools.ietf.org/html/rfc2779">RFC 2779</A>.  It defines a minimal set of
   presence status values defined by the IMPP Model document [<A title='"A Model for Presence and Instant Messaging"' href="http://tools.ietf.org/html/rfc2778">RFC2778</A>].
   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 defines only the format for a presence data
   payload and the extensibility framework for it.  How the presence
   data is transferred within a specific protocol frame would be defined
   separately in a protocol specification.

<SPAN class=h3><A name=section-1.1>1.1</A>.  Terminology and Conventions</SPAN>

   This memo makes use of the vocabulary defined in the IMPP Model
   document [<A title='"A Model for Presence and Instant Messaging"' href="http://tools.ietf.org/html/rfc2778">RFC2778</A>].  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 <A href="http://tools.ietf.org/html/bcp14">BCP 14</A>, <A href="http://tools.ietf.org/html/rfc2119">RFC 2119</A> [<A title='"Key words for use in RFCs to Indicate Requirement Levels"' href="http://tools.ietf.org/html/rfc2119">RFC2119</A>].

<SPAN class=h2><A name=section-2>2</A>.  Design Decisions</SPAN>

   We have adopted the IMPP Model and Requirements documents [RFC2778,
   <A href="http://tools.ietf.org/html/rfc2779">RFC2779</A>] as the starting point of our discussion.  The two RFCs
   contain 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 included.

<SPAN class=h3><A name=section-2.1>2.1</A>. Minimal Model</SPAN>

   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.,
   (<A href="http://tools.ietf.org/html/rfc2778">RFC2778</A>:Sec.2.4) refers to <A href="http://tools.ietf.org/html/rfc2778#section-2.4">Section&nbsp;2.4 of RFC 2778</A>.

   (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.  Note
       that the CONTACT ADDRESS in a COMMUNICATIONS ADDRESS is
       understood in this document to refer only to a URI
       (<A href="http://tools.ietf.org/html/rfc2778">RFC2778</A>:Sec.3).



<SPAN class=grey>Sugano, et al.              Standards Track                     [Page 3]</SPAN>
<A id=page-4 href="http://tools.ietf.org/html/rfc3863#page-4" name=page-4><SPAN class=break> </SPAN></A>
<SPAN class=grey><A href="http://tools.ietf.org/html/rfc3863">RFC 3863</A>            Presence Information Data Format         August 2004</SPAN>


   (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 (<A href="http://tools.ietf.org/html/rfc2778">RFC2778</A>:Sec.3, <A href="http://tools.ietf.org/html/rfc2779">RFC2779</A>:Sec.4.4.1-
       4.4.3).

   (c) STATUS may consist of single or multiple values.(<A href="http://tools.ietf.org/html/rfc2778">RFC2778</A>: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
       (<A href="http://tools.ietf.org/html/rfc2779">RFC2779</A>: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
       (<A href="http://tools.ietf.org/html/rfc2779">RFC2779</A>:Sec.3.1.2).

   (f) The common presence format must allow the PRESENTITY to secure
       presence information sent to a WATCHER.  The format must allow
       integrity, confidentiality and authentication properties to be
       applied to presence information (<A href="http://tools.ietf.org/html/rfc2779">RFC2779</A>:Sec5.2.1, 5.2.4, 5.3.1,
       5.3.3).

<SPAN class=h3><A name=section-2.2>2.2</A>.  Added Features</SPAN>

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

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

   (b) The presence format is 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 is
        delayed.  It can also be used to detect a replay attack,
        independent of the underlying signature mechanism.  Note that
        this mechanism does not assume any global time synchronization
        system for watchers and presentities (see Appendix A of <A href="http://tools.ietf.org/html/rfc2779">RFC2779</A>,
        8.1.4 A7), but rather assumes that the minimum length of time
        that might pass before presence information is considered stale



<SPAN class=grey>Sugano, et al.              Standards Track                     [Page 4]</SPAN>
<A id=page-5 href="http://tools.ietf.org/html/rfc3863#page-5" name=page-5><SPAN class=break> </SPAN></A>
<SPAN class=grey><A href="http://tools.ietf.org/html/rfc3863">RFC 3863</A>            Presence Information Data Format         August 2004</SPAN>


        is long enough that minor variations among system clocks will
        not lead to misjudgments of the freshness of presence
        information.

<SPAN class=h3><A name=section-2.3>2.3</A>.  XML Encoding Decision</SPAN>

   The Presence Information Data Format encodes presence information in
   XML (eXtensible Markup Language [<A title='"Extensible Markup Language (XML) 1.0 (Second Edition)"' href="http://tools.ietf.org/html/rfc3863#ref-XML">XML</A>]).  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 [<A title='"vCard MIME Directory Profile"' href="http://tools.ietf.org/html/rfc3863#ref-vCard">vCard</A>].

<SPAN class=h2><A name=section-3>3</A>.  Overview of Presence Information Data Format</SPAN>

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

<SPAN class=h3><A name=section-3.1>3.1</A>.  The 'application/pidf+xml' Content Type</SPAN>

   This memo defines a new content type "application/pidf+xml" for an
   XML MIME entity that contains presence information.  This
   specification follows the recommendations and conventions described
   in [<A title='"XML Media Types"' href="http://tools.ietf.org/html/rfc3023">RFC3023</A>], including the naming convention of the type ('+xml'
   suffix) and the usage of the 'charset' parameter.

   Although it is defined as optional, use of the 'charset' parameter is
   RECOMMENDED.  If the 'charset' parameter is not specified, conforming
   XML processors MUST follow the requirements in <A href="http://tools.ietf.org/html/rfc3863#section-4.3.3">section 4.3.3</A> of
   [<A title='"Extensible Markup Language (XML) 1.0 (Second Edition)"' href="http://tools.ietf.org/html/rfc3863#ref-XML">XML</A>].

<SPAN class=h3><A name=section-3.2>3.2</A>.  Presence Information Contents</SPAN>

   This subsection outlines the information in an "application/pidf+xml"
   document.  A full definition of the PIDF content is in <A href="http://tools.ietf.org/html/rfc3863#section-4">Section 4</A>.

   o PRESENTITY URL: specifies the "pres" URL of the PRESENTITY.
   o List of PRESENCE TUPLES
     - Identifier: token to identify this tuple within the presence
       information.
     - STATUS: OPEN/CLOSED and/or extension status values.
     - 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)




<SPAN class=grey>Sugano, et al.              Standards Track                     [Page 5]</SPAN>
<A id=page-6 href="http://tools.ietf.org/html/rfc3863#page-6" name=page-6><SPAN class=break> </SPAN></A>
<SPAN class=grey><A href="http://tools.ietf.org/html/rfc3863">RFC 3863</A>            Presence Information Data Format         August 2004</SPAN>


   o PRESENTITY human readable comment: free text memo about the
       PRESENTITY (optional).

<SPAN class=h2><A name=section-4>4</A>.  XML-encoded Presence Data Format</SPAN>

   This section defines an XML-encoded presence information data format
   (PIDF) for use with CPP compliant systems.  A presence payload in
   this format 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.