rfc 3863 presence information data format (pidf).htm

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

<SPAN class=h3><A name=section-4.1>4.1</A>.  XML Format Definitions</SPAN>

   A PIDF 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., "&lt;?xml version='1.0'
   encoding='UTF-8'?&gt;".  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.

   Every application conformant to this specification MUST accept the
   UTF-8 character encoding to ensure the minimal interoperability.

<SPAN class=h4><A name=section-4.1.1>4.1.1</A>.  The &lt;presence&gt; element</SPAN>

   PIDF elements are associated with the XML namespace name
   'urn:ietf:params:xml:ns:pidf', declared using an xmlns attribute, per
   [<A title='"Namespaces in XML"' href="http://tools.ietf.org/html/rfc3863#ref-XML-NS">XML-NS</A>].  The namespace may be a default namespace, or may be
   associated with some namespace prefix (see <A href="http://tools.ietf.org/html/rfc3863#section-4.2.2">section 4.2.2</A> for
   examples).

   The root of an "application/pidf+xml" object is a &lt;presence&gt; element
   associated with the presence information namespace.  This contains
   any number (including 0) of &lt;tuple&gt; elements, followed by any number
   (including 0) of &lt;note&gt; elements, followed by any number of OPTIONAL
   extension elements from other namespaces.

   The &lt;presence&gt; element MUST have an 'entity' attribute.  The value of
   the 'entity' attribute is the 'pres' URL of the PRESENTITY publishing
   this presence document.

   The &lt;presence&gt; 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:pidf:'.




<SPAN class=grey>Sugano, et al.              Standards Track                     [Page 6]</SPAN>
<A id=page-7 href="http://tools.ietf.org/html/rfc3863#page-7" name=page-7><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>


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

<SPAN class=h4><A name=section-4.1.2>4.1.2</A>.  The &lt;tuple&gt; element</SPAN>

   The &lt;tuple&gt; element carries a PRESENCE TUPLE, consisting of a
   mandatory &lt;status&gt; element, followed by any number of OPTIONAL
   extension elements (possibly from other namespaces), followed by an
   OPTIONAL &lt;contact&gt; element, followed by any number of OPTIONAL &lt;note&gt;
   elements, followed by an OPTIONAL &lt;timestamp&gt; element.

   Tuples provide a way of segmenting presence information.  Protocols
   or applications may choose to segment the presence information
   associated with a presentity for any number of reasons - for example,
   because components of the full presence information for a presentity
   have come from distinct devices or different applications on the same
   device, or have been generated at different times.  Tuples should be
   preferred over other manners of segmenting presence information such
   as creating multiple PIDF instances.

   The &lt;tuple&gt; element MUST contain an 'id' attribute which is used to
   distinguish this tuple from other tuples in the same PRESENTITY.  The
   value of an 'id' attribute MUST be unique within 'id' attribute
   values of other tuples for the same PRESENTITY.  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 is an
   arbitrary string, and has no significance beyond providing a means to
   distinguish &lt;tuple&gt; values, as noted above.

   The &lt;contact&gt; element is OPTIONAL because a PRESENTITY might need to
   hide its COMMUNICATION ADDRESS or there might be tuples not related
   to any COMMUNICATION MEANS.  Tuples that contain a &lt;basic&gt; status
   element SHOULD contain a &lt;contact&gt; address.  Tuples MAY contain
   conflicting presence status - one &lt;tuple&gt; might provide a &lt;basic&gt;
   &lt;status&gt; of OPEN, and another &lt;tuple&gt; in the same PIDF could contain
   a &lt;basic&gt; &lt;status&gt; of CLOSED, even if they both contain the same
   &lt;contact&gt; address.

   The manner in which segmented presence information is understood by
   the WATCHER USER AGENT is highly dependent on the capabilities of the
   WATCHER USER AGENT and the presence application in question.  In the
   absence of any application-specific or protocol-specific
   understanding of the meaning of tuples, WATCHER USER AGENTS MAY obey
   the following guidelines.  WATCHER USER AGENTS should note which
   tuples in the PIDF have changed their state since the last





<SPAN class=grey>Sugano, et al.              Standards Track                     [Page 7]</SPAN>
<A id=page-8 href="http://tools.ietf.org/html/rfc3863#page-8" name=page-8><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>


   notification by correlating the 'id' of each &lt;tuple&gt; with those
   received in previous notifications and comparing both &lt;status&gt; values
   and &lt;timestamp&gt; elements in the tuples, if any are present.

<SPAN class=h4><A name=section-4.1.3>4.1.3</A>.  The &lt;status&gt; element</SPAN>

   The &lt;status&gt; element contains one OPTIONAL &lt;basic&gt; element, followed
   by any number of OPTIONAL extension elements (possibly from other
   namespaces), under the restriction that at least one child element
   appears in the &lt;status&gt; element.  These children elements of &lt;status&gt;
   contain status values of this tuple.  By allowing multiple status
   values in a single &lt;tuple&gt; element, different types of status values,
   e.g., reachability and location, can be represented by a &lt;tuple&gt;.
   See <A href="http://tools.ietf.org/html/rfc3863#section-4.3">Section 4.3</A> for an example with multiple status values.

   This memo only defines the &lt;basic&gt; status value element.  Other
   status values may be included using the standard extensibility
   framework (see <A href="http://tools.ietf.org/html/rfc3863#section-4.2.4">Section 4.2.4</A>).  Applications encountering
   unrecognized elements within &lt;status&gt; may ignore them, unless they
   carry a mustUnderstand="true" or mustUnderstand="1" attribute (see
   <A href="http://tools.ietf.org/html/rfc3863#section-4.2.3">section 4.2.3</A>).

   Note that, while the &lt;status&gt; element MUST have at least one status
   value element, this status value might not be the &lt;basic&gt; element.

<SPAN class=h4><A name=section-4.1.4>4.1.4</A>.  The &lt;basic&gt; element</SPAN>

   The &lt;basic&gt; element contains one of the following strings: "open" or
   "closed".

   The values "open" and "closed" indicate availability to receive
   INSTANT MESSAGES if the &lt;tuple&gt; is for an instant messaging address.
   They also indicate general availability for other communication
   means, but this memo does not specify these in detail.

   open: In the context of INSTANT MESSAGES, this value means that the
      associated &lt;contact&gt; element, if any, corresponds to an INSTANT
      INBOX that is ready to accept an INSTANT MESSAGE.

   closed: In the context of INSTANT MESSAGES, this value means that
      the associated &lt;contact&gt; element, if any, corresponds to an
      INSTANT INBOX that is unable to accept an INSTANT MESSAGE.

<SPAN class=h4><A name=section-4.1.5>4.1.5</A>.  The &lt;contact&gt; element</SPAN>

   The &lt;contact&gt; 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



<SPAN class=grey>Sugano, et al.              Standards Track                     [Page 8]</SPAN>
<A id=page-9 href="http://tools.ietf.org/html/rfc3863#page-9" name=page-9><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>


   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 assign the
   contact address the lowest priority.  If the 'priority' value is out
   of the range, applications just SHOULD ignore the value and process
   it as if the attribute was not present.

   Applications SHOULD handle contacts with a higher priority as they
   have precedence over those with lower priorities.  How they are
   actually treated is beyond this specification.  Also, how to handle
   contacts with the same priority is up to implementations.

<SPAN class=h4><A name=section-4.1.6>4.1.6</A>.  The &lt;note&gt; element</SPAN>

   The &lt;note&gt; element contains a string value, which is usually used for
   a human readable comment.  A &lt;note&gt; element MAY appear as a child
   element of &lt;presence&gt; or as a child element of the &lt;tuple&gt; element.
   In the former case the comment is about the PRESENTITY and in the
   latter case the comment is regarding the particular tuple.

   Note that, wherever it appears, a &lt;note&gt; element SHOULD NOT be used,
   and interpreted, as a non-interoperable substitute for status of its
   parent element.

   The &lt;note&gt; element SHOULD have a special attribute 'xml:lang' to
   specify the language used in the contents of this element as defined
   in <A href="http://tools.ietf.org/html/rfc3863#section-2.12">Section 2.12</A> of [<A title='"Extensible Markup Language (XML) 1.0 (Second Edition)"' href="http://tools.ietf.org/html/rfc3863#ref-XML">XML</A>].  The value of this attribute is the
   language identifier as defined by [<A title='"Tags for the Identification of Languages"' href="http://tools.ietf.org/html/rfc3066">RFC3066</A>].  It MAY be omitted when
   the language used is implied by the larger context such as the
   encoding information of the contents, such as an xml:lang attribute
   on an enclosing XML element, or a Content-language header [<A title='"Content Language Headers"' href="http://tools.ietf.org/html/rfc3282">RFC3282</A>]
   on an enclosing MIME wrapper.

<SPAN class=h4><A name=section-4.1.7>4.1.7</A>.  The &lt;timestamp&gt; element</SPAN>

   The &lt;timestamp&gt; 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 [<A title='"Date and Time on the Internet: Timestamps"' href="http://tools.ietf.org/html/rfc3339">RFC3339</A>].  Timestamps that
   contain 'T' or 'Z' MUST use the capitalized forms.

   As a security measure, the &lt;timestamp&gt; element SHOULD be included in
   all tuples unless the exact time of the status change cannot be
   determined.  For security guidelines for watchers receiving presence
   information with timestamps, see the Security Considerations.

   A PRESENTITY MUST NOT generate successive &lt;presence&gt; elements
   containing the same timestamp.



<SPAN class=grey>Sugano, et al.              Standards Track                     [Page 9]</SPAN>
<A id=page-10 href="http://tools.ietf.org/html/rfc3863#page-10" name=page-10><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>


<SPAN class=h3><A name=section-4.2>4.2</A>.  Presence Information Extensibility</SPAN>

   The presence information extensibility framework is based on XML
   namespaces [<A title='"Namespaces in XML"' href="http://tools.ietf.org/html/rfc3863#ref-XML-NS">XML-NS</A>].

   <A href="http://tools.ietf.org/html/rfc2779">RFC 2779</A> requires that PIDF have a means of extending &lt;status&gt; values
   beyond &lt;basic&gt;.  These extensions MUST NOT modify how &lt;basic&gt; is to
   be understood, nor change the structure or semantics of PIDF bodies
   themselves.  These extensions merely allow protocols and applications
   to define richer presence data.

<SPAN class=h4><A name=section-4.2.1>4.2.1</A>.  XML Namespaces Background</SPAN>

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

      &lt;prefix:element-name ...&gt; ... &lt;/prefix:element-name&gt;

   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