📄 rfc 4480 rpid rich presence extensions to the presence information data format (pidf).htm
字号:
<A href="http://tools.ietf.org/html/rfc4480#section-3.12">3.12</A>. Status-Icon Element ......................................<A href="http://tools.ietf.org/html/rfc4480#page-16">16</A>
<A href="http://tools.ietf.org/html/rfc4480#section-3.13">3.13</A>. Time Offset ..............................................<A href="http://tools.ietf.org/html/rfc4480#page-17">17</A>
<A href="http://tools.ietf.org/html/rfc4480#section-3.14">3.14</A>. User-Input Element .......................................<A href="http://tools.ietf.org/html/rfc4480#page-17">17</A>
<A href="http://tools.ietf.org/html/rfc4480#section-4">4</A>. Example ........................................................<A href="http://tools.ietf.org/html/rfc4480#page-18">18</A>
<A href="http://tools.ietf.org/html/rfc4480#section-5">5</A>. XML Schema Definitions .........................................<A href="http://tools.ietf.org/html/rfc4480#page-20">20</A>
<A href="http://tools.ietf.org/html/rfc4480#section-5.1">5.1</A>. urn:ietf:params:xml:ns:pidf:rpid ..........................<A href="http://tools.ietf.org/html/rfc4480#page-20">20</A>
<A href="http://tools.ietf.org/html/rfc4480#section-6">6</A>. Extending RPID .................................................<A href="http://tools.ietf.org/html/rfc4480#page-30">30</A>
<A href="http://tools.ietf.org/html/rfc4480#section-7">7</A>. IANA Considerations ............................................<A href="http://tools.ietf.org/html/rfc4480#page-31">31</A>
<A href="http://tools.ietf.org/html/rfc4480#section-7.1">7.1</A>. URN Sub-Namespace Registration for ........................<A href="http://tools.ietf.org/html/rfc4480#page-31">31</A>
'urn:ietf:params:xml:ns:pidf:rpid'
<A href="http://tools.ietf.org/html/rfc4480#section-7.2">7.2</A>. Schema Registration for Schema ............................<A href="http://tools.ietf.org/html/rfc4480#page-32">32</A>
'urn:ietf:params:xml:ns:pidf:status:rpid'
<A href="http://tools.ietf.org/html/rfc4480#section-8">8</A>. Internationalization Considerations ............................<A href="http://tools.ietf.org/html/rfc4480#page-32">32</A>
<A href="http://tools.ietf.org/html/rfc4480#section-9">9</A>. Security Considerations ........................................<A href="http://tools.ietf.org/html/rfc4480#page-32">32</A>
<A href="http://tools.ietf.org/html/rfc4480#section-10">10</A>. References ....................................................<A href="http://tools.ietf.org/html/rfc4480#page-33">33</A>
<A href="http://tools.ietf.org/html/rfc4480#section-10.1">10.1</A>. Normative References .....................................<A href="http://tools.ietf.org/html/rfc4480#page-33">33</A>
<A href="http://tools.ietf.org/html/rfc4480#section-10.2">10.2</A>. Informative References ...................................<A href="http://tools.ietf.org/html/rfc4480#page-34">34</A>
Appendix A. Acknowledgements .....................................<A href="http://tools.ietf.org/html/rfc4480#page-35">35</A>
<SPAN class=h2><A name=section-1>1</A>. Introduction</SPAN>
The Presence Information Data Format (PIDF) definition [<A title='"Presence Information Data Format (PIDF)"' href="http://tools.ietf.org/html/rfc4480#ref-8">8</A>] describes
a basic presence information data format, encoded as an Extensible
Markup Language (XML) [<A title='"Extensible Markup Language (XML) 1.0 (Third Edition),"' href="http://tools.ietf.org/html/rfc4480#ref-9">9</A>] (SCHEMA-1 [<A title='"XML Schema Part 1: Structures Second Edition"' href="http://tools.ietf.org/html/rfc4480#ref-10">10</A>]) (SCHEMA-2 [<A title='"XML Schema Part 2: Datatypes Second Edition"' href="http://tools.ietf.org/html/rfc4480#ref-11">11</A>]), for
exchanging presence information in systems compliant with the common
model for presence and instant messaging [<A title='"A Model for Presence and Instant Messaging"' href="http://tools.ietf.org/html/rfc4480#ref-5">5</A>]. It consists of a
<presence> root element, zero or more <tuple> elements carrying
presence information including a Uniform Resource Identifier (URI)
for communication, zero or more <note> elements, and zero or more
extension elements from other name spaces. Each tuple defines a
basic status of either "open" or "closed".
<SPAN class=grey>Schulzrinne, et al. Standards Track [Page 2]</SPAN>
<A id=page-3 href="http://tools.ietf.org/html/rfc4480#page-3" name=page-3><SPAN class=break> </SPAN></A>
<SPAN class=grey><A href="http://tools.ietf.org/html/rfc4480">RFC 4480</A> RIPD July 2006</SPAN>
However, it is frequently useful to convey additional information
about a user that needs to be interpreted by an automata, and is
therefore not appropriate to be placed in the <note> element of the
PIDF document, which is typically intended for the human observer.
Therefore, this specification defines extensions to the PIDF document
format for conveying richer presence information. Generally, the
extensions have been chosen to provide features common in existing
presence systems at the time of writing, in addition to elements that
could readily be derived automatically from existing sources of
presence, such as calendaring systems or communication devices, or
sources describing the user's current physical environment.
The presence data model [<A title='"A Data Model for Presence"' href="http://tools.ietf.org/html/rfc4480#ref-16">16</A>] defines the concepts of service, device,
and person as the data elements that are used to model the state of a
presentity. (The term "presentity" is defined in <A href="http://tools.ietf.org/html/rfc2778">RFC 2778</A> [<A title='"A Model for Presence and Instant Messaging"' href="http://tools.ietf.org/html/rfc4480#ref-5">5</A>] and
abbreviates presence entity. A presentity provides presence
information to a presence service.) Services are encoded using the
<tuple> element, defined in PIDF; devices and persons are represented
by the <device> and <person> XML elements, respectively, defined in
the data model [<A title='"A Data Model for Presence"' href="http://tools.ietf.org/html/rfc4480#ref-16">16</A>]. However, neither PIDF nor the data model
defines presence attributes beyond the <basic> status element.
This specification defines additional presence attributes to describe
person, service, and device data elements, summarized as "Rich
Presence Information Data format for presence" (RPID). These
attributes are specified by XML elements that extend the PIDF <tuple>
element and the <device> and <person> elements defined in the data
model.
This extension has two main goals:
1. Provide rich presence information that is at least as powerful as
common commercial presence systems. Such feature-parity
simplifies transition to systems complying with the Common
Profile for Instant Messaging (CPIM) [<A title='"Common Profile for Instant Messaging (CPIM)"' href="http://tools.ietf.org/html/rfc4480#ref-14">14</A>], both in terms of user
acceptance and protocol conversion.
2. Maintain backward-compatibility with PIDF, so that PIDF-only
watchers and gateways can continue to function properly,
naturally without access to the functionality described here.
We make no assumptions as to how the information in the RPID elements
is generated. Experience has shown that users are not always
diligent about updating their presence status. Thus, we want to make
it as easy as possible to derive RPID information from other
information sources, such as personal calendars, the status of
communication devices such as telephones, typing activity, and
<SPAN class=grey>Schulzrinne, et al. Standards Track [Page 3]</SPAN>
<A id=page-4 href="http://tools.ietf.org/html/rfc4480#page-4" name=page-4><SPAN class=break> </SPAN></A>
<SPAN class=grey><A href="http://tools.ietf.org/html/rfc4480">RFC 4480</A> RIPD July 2006</SPAN>
physical presence detectors as commonly found in energy-management
systems.
Many of the elements correspond to data commonly found in personal
calendars. Thus, we attempted to align some of the extensions with
the usage found in calendar formats such as iCal [<A title='"Internet Calendaring and Scheduling Core Object Specification (iCalendar)"' href="http://tools.ietf.org/html/rfc4480#ref-13">13</A>].
The information in a presence document can be generated by a single
entity or can be composed from information published by multiple
entities.
Note that PIDF documents and this extension can be used in two
different contexts, namely, by the presentity to publish its presence
status and by the presence server to notify some set of watchers.
The presence server MAY compose, translate, or filter the published
presence state before delivering customized presence information to
the watcher. For example, it may merge presence information from
multiple presence user agents, remove whole elements, translate
values in elements, or remove information from elements. Mechanisms
that filter calls and other communications to the presentity can
subscribe to this presence information just like a regular watcher
and in turn generate automated rules, such as scripts [<A title='"Call Processing Language (CPL): A Language for User Control of Internet Telephony Services"' href="http://tools.ietf.org/html/rfc4480#ref-15">15</A>], that
govern the actual communications behavior of the presentity. Details
are described in the data model document.
Since RPID is a PIDF XML document, it also uses the content type
application/pidf+xml.
<SPAN class=h2><A name=section-2>2</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/rfc4480#ref-5">5</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/rfc4480#ref-1">1</A>].
<SPAN class=h2><A name=section-3>3</A>. RPID Elements</SPAN>
<SPAN class=h3><A name=section-3.1>3.1</A>. Overview</SPAN>
Some of the RPID elements describe services, some devices, and some
the person. As such, they either extend <tuple>, <device>, or
<person>, respectively. Below, we summarize the RPID elements. The
next sections will then provide more detailed descriptions.
<SPAN class=grey>Schulzrinne, et al. Standards Track [Page 4]</SPAN>
<A id=page-5 href="http://tools.ietf.org/html/rfc4480#page-5" name=page-5><SPAN class=break> </SPAN></A>
<SPAN class=grey><A href="http://tools.ietf.org/html/rfc4480">RFC 4480</A> RIPD July 2006</SPAN>
activities: The <activities> status element enumerates what the
person is doing.
class: An identifier that groups similar person elements, devices,
or services.
deviceID: A device identifier in a tuple references a <device>
element, indicating that this device contributes to the service
described by the tuple.
mood: The <mood> status element indicates the mood of the person.
place-is: The <place-is> status element reports on the properties of
the place the presentity is currently at, such as the levels of
light and noise.
place-type: The <place-type> status elements reports the type of
place the person is located in, such as 'classroom' or 'home'.
privacy: The <privacy> element distinguishes whether the
communication service is likely to be observable by other parties.
relationship: When a service is likely to reach a user besides the
person associated with the presentity, the relationship indicates
how that user relates to the person.
service-class: The <service-class> element describes whether the
service is delivered electronically, is a postal or delivery
service, or describes in-person communications.
sphere: The <sphere> element characterizes the overall current role
of the presentity.
status-icon: The <status-icon> element depicts the current status of
the person or service.
time-offset: The <time-offset> status element quantifies the time
zone the person is in, expressed as the number of minutes away
from UTC.
user-input: The <user-input> element records the user-input or usage
state of the service or device, based on human user input.
The 'From/until?' column in Table 1 indicates by an 'x' that the
element can take 'from' and 'until' attributes. An 'x' in the
'Note?' column marks elements that can include a <note> element. The
usage of these elements within the <person>, <tuple>, and <device>
elements is shown in columns 4 through 6. An 'x' in the respective
<SPAN class=grey>Schulzrinne, et al. Standards Track [Page 5]</SPAN>
<A id=page-6 href="http://tools.ietf.org/html/rfc4480#page-6" name=page-6><SPAN class=break> </SPAN></A>
<SPAN class=grey><A href="http://tools.ietf.org/html/rfc4480">RFC 4480</A> RIPD July 2006</SPAN>
column indicates that the RPID element MAY appear as a child of that
element.
+-----------------+------------+------+----------+---------+----------+
| Element | From/until | Note | <person> | <tuple> | <device> |
| | ? | ? | | | |
+-----------------+------------+------+----------+---------+----------+
| <activities> | x | x | x | | |
| <class> | | | x | x | x |
| <deviceID> | | | | x | |
| <mood> | x | x | x | | |
| <place-is> | x | x | x | | |
| <place-type> | x | x | x | | |
| <privacy> | x | x | x | x | |
| <relationship> | | x | | x | |
| <service-class> | | x | | x | |
| <sphere> | x | | x | | |
| <status-icon> | x | | x | x | |
| <time-offset> | x | | x | | |
| <user-input> | | | x | x | x |
+-----------------+------------+------+----------+---------+----------+
Table 1
In general, it is unlikely that a presentity will publish or announce
all of these elements at the same time. Rather, these elements were
chosen to give the presentity maximum flexibility in deriving this
information from existing sources, such as calendaring tools, device
activity sensors, or location trackers, as well as to manually
configure this information. In either case, there is no guarantee
that the information is accurate, as users forget to update calendars
or may not always adjust the presence information manually.
The namespace URIs for these elements defined by this specification
are URNs [<A title='"URN Syntax"' href="http://tools.ietf.org/html/rfc4480#ref-2">2</A>], using the namespace identifier 'ietf' defined by [<A title='"A URN Namespace for IETF Documents"' href="http://tools.ietf.org/html/rfc4480#ref-4">4</A>]
and extended by [<A title='"The IETF XML Registry"' href="http://tools.ietf.org/html/rfc4480#ref-6">6</A>]:
urn:ietf:params:xml:ns:pidf:rpid
The elements marked with the value 'x' in column 2 of Table 1 MAY be
qualified with the 'from' and 'until' attributes to describe the
absolute time when the element assumed this value and the absolute
time until which this element is expected to be valid. Note that
there can be multiple elements of the same type, whose time ranges
SHOULD NOT overlap.
Elements MAY contain an 'id' attribute that allows to uniquely
reference the element.
<SPAN class=grey>Schulzrinne, et al. Standards Track [Page 6]</SPAN>
<A id=page-7 href="http://tools.ietf.org/html/rfc4480#page-7" name=page-7><SPAN class=break> </SPAN></A>
<SPAN class=grey><A href="http://tools.ietf.org/html/rfc4480">RFC 4480</A> RIPD July 2006</SPAN>
Enumerations can be extended by elements from other namespaces, as
described in <A href="http://tools.ietf.org/html/rfc4480#section-6">Section 6</A>. The <activities>, <mood>, and <place-type>
elements can also take <other> elements containing text, for custom
free-text values specific to an application.
All elements described in this document are optional within PIDF
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -