📄 rfc 3863 presence information data format (pidf).htm
字号:
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 [<A title='"Namespaces in XML"' href="http://tools.ietf.org/html/rfc3863#ref-XML-NS">XML-NS</A>].
<SPAN class=grey>Sugano, et al. Standards Track [Page 10]</SPAN>
<A id=page-11 href="http://tools.ietf.org/html/rfc3863#page-11" name=page-11><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=h4><A name=section-4.2.2>4.2.2</A>. XML Namespaces In Presence Information</SPAN>
A URI used as a namespace identifier in PRESENCE INFORMATION data
MUST be a full absolute-URI, per <A href="http://tools.ietf.org/html/rfc2396">RFC 2396</A> [<A title='"Uniform Resource Identifiers (URI): Generic Syntax"' href="http://tools.ietf.org/html/rfc3863#ref-URI">URI</A>]. (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
[<A title='"URN Syntax"' href="http://tools.ietf.org/html/rfc3863#ref-URN">URN</A>], using the namespace identifier 'ietf' defined by [<A title='"A URN Namespace for IETF Documents"' href="http://tools.ietf.org/html/rfc3863#ref-URN-NS-IETF">URN-NS-IETF</A>]
and extended by [<A title='"The IETF XML Registry"' href="http://tools.ietf.org/html/rfc3863#ref-XML-Registry">XML-Registry</A>]:
urn:ietf:params:xml:ns:pidf
Thus, simple presence data might be thus:
<?xml version="1.0" encoding="UTF-8"?>
<impp:presence xmlns:impp="urn:ietf:params:xml:ns:pidf"
entity="pres:someone@example.com">
<impp:tuple id="sg89ae">
<impp:status>
<impp:basic>open</impp:basic>
</impp:status>
<impp:contact priority="0.8">tel:+09012345678</impp:contact>
</impp:tuple>
</impp:presence>
, using a default XML namespace:
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="pres:someone@example.com">
<tuple id="sg89ae">
<status>
<basic>open</basic>
</status>
<contact priority="0.8">tel:+09012345678</contact>
</tuple>
</presence>
As is generally the case in XML with namespaces, 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.
<SPAN class=grey>Sugano, et al. Standards Track [Page 11]</SPAN>
<A id=page-12 href="http://tools.ietf.org/html/rfc3863#page-12" name=page-12><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=h4><A name=section-4.2.3>4.2.3</A>. Handling Of Unrecognized Element Names</SPAN>
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 contain elements with recognized names.
Extensions to PIDF are informational in nature - they provide
additional information beyond <basic> status. However, in order to
understand a complex extension, nested elements within an extension
element might need to be marked as mandatory. In such cases, the
element name is qualified with a mustUnderstand='true' or
mustUnderstand='1' attribute. See <A href="http://tools.ietf.org/html/rfc3863#section-4.3.3">section 4.3.3</A> for an example.
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 necessary.
This specification defines (<A href="http://tools.ietf.org/html/rfc3863#section-4.1">section 4.1</A>) elements within the
'urn:ietf:params:xml:ns:pidf' namespace that MUST be recognized in
CPP presence data. Processors MUST handle these as described, even
if they do not carry a mustUnderstand attribute. The XML Schema
Definition (<A href="http://tools.ietf.org/html/rfc3863#section-4.4">section 4.4</A>) indicates those elements that MUST be
present in a valid presence information document.
If an agent receives PRESENCE INFORMATION with a <status> block
containing an unrecognized element with a mustUnderstand='true' (or
'1') attribute, it should treat that entire element and any content
as unrecognized and not attempt to process it.
In order to ensure that minimal implementations can correctly process
basic PIDF information the mustUnderstand attribute MUST be used only
within optional elements nested in a <status> element. This will
ensure that problems processing an extension are restricted to that
extension and do not affect the processing of the basic PIDF
information defined in this specification.
<SPAN class=h4><A name=section-4.2.4>4.2.4</A>. Status Value Extensibility</SPAN>
This memo defines only the <basic> status value with values of "open"
and "closed". Other status values are possible using the standard
namespace-based extensibility rules defined above.
<SPAN class=grey>Sugano, et al. Standards Track [Page 12]</SPAN>
<A id=page-13 href="http://tools.ietf.org/html/rfc3863#page-13" name=page-13><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>
For example, a location status value might be included thus:
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:local="urn:example-com:pidf-status-type"
entity="pres:someone@example.com">
<tuple id="ub93s3">
<status>
<basic>open</basic>
<local:location>home</local:location>
</status>
<contact>im:someone@example.com</contact>
</tuple>
</presence>
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 recognize 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
CLOSED.
<SPAN class=h4><A name=section-4.2.5>4.2.5</A>. Standardizing Status Extensions</SPAN>
Although the existing PIDF definition allows arbitrary elements to
appear in the <status> element, it may be sometimes desirable to
standardize extension status elements and their semantics (the
meanings of particular statuses, how they should be interpreted).
The URN 'urn:ietf:params:xml:ns:pidf:status' has been specified as an
umbrella namespace under which extensions to the <status> PIDF
element should be specified (e.g.,
urn:ietf:params:xml:ns:pidf:status:my-extension). New values under
this namespace MUST be defined by a standards-track RFC.
The following example XML Schema defines an extension for <location>
presence information, which can have the values of 'home', 'office',
or 'car'. If the <location> element were standardized, this document
would be made available in an RFC along with information about the
use of the extension. These extensions should use the namespace
'urn:ietf:params:xml:ns:pidf:status', and each RFC defining an
extension should register an extension name within that namespace
with IANA.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf:status"
xmlns:tns="urn:ietf:params:xml:ns:pidf:status"
<SPAN class=grey>Sugano, et al. Standards Track [Page 13]</SPAN>
<A id=page-14 href="http://tools.ietf.org/html/rfc3863#page-14" name=page-14><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>
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:simpleType name="location">
<xs:restriction base="xs:string">
<xs:enumeration value="home"/>
<xs:enumeration value="office"/>
<xs:enumeration value="car"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
In addition to the XML Schema to validate the extension, registration
of the extension name with IANA, RFCs defining extensions MUST
discuss:
- The domain of applicability of the extension. Is this extension
exclusively valuable to IM clients, telephones, geolocators, etc?
What sorts of presence applications would use this extension and
under what circumstances?
- Semantics for the presence states defined in the extension. What
disposition provokes an automated presentity to declare that it is
in state X, or does a human select X from a drag-down menu? Is
there any general guidance for watchers of presence information
with state Y (for example, how they should best attempt to
communicate with the presentity, if at all, when the principal is
in state Y).
Extensions SHOULD also discuss:
- How, if at all, any presence states defined in the extension
related to <basic>, or to any relevant extension previously
published in an RFC. For example, "state Z implies OPEN, so it
MUST NOT be used if a basic state of CLOSED is expressed", or
"you should use the extension in this document, not the extension
in RFC QQQQ, if your circumstances are as follows...."
<SPAN class=h3><A name=section-4.3>4.3</A>. Examples</SPAN>
<SPAN class=h4><A name=section-4.3.1>4.3.1</A>. Default Namespace with Status Extensions</SPAN>
The following instance document uses a hypothetical 'pidf:im' XML
namespace as an example of the sort of status extension that might be
developed for PIDF.
<SPAN class=grey>Sugano, et al. Standards Track [Page 14]</SPAN>
<A id=page-15 href="http://tools.ietf.org/html/rfc3863#page-15" name=page-15><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>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -