?? rfc 4480 rpid rich presence extensions to the presence information data format (pidf).htm
字號:
The <status-icon> element includes a URI pointing to an image (icon)
representing the current status of the person or service. The
watcher MAY use this information to represent the status in a
graphical user interface. Presentities SHOULD provide images of
<SPAN class=grey>Schulzrinne, et al. Standards Track [Page 16]</SPAN>
<A id=page-17 href="http://tools.ietf.org/html/rfc4480#page-17" name=page-17><SPAN class=break> </SPAN></A>
<SPAN class=grey><A href="http://tools.ietf.org/html/rfc4480">RFC 4480</A> RIPD July 2006</SPAN>
sizes and aspect ratios that are appropriate for rendering as an
icon. Support for JPEG, PNG, and GIF formats is RECOMMENDED.
Watchers resolving the URI MUST validate whether the local copy of
the icon is current when receiving a notification, using the standard
cache control mechanism in the URI-identified retrieval protocol.
Example:
<status-icon>http://www.example.com/playing.gif</status-icon>
<SPAN class=h3><A name=section-3.13>3.13</A>. Time Offset</SPAN>
The <time-offset> element describes the number of minutes of offset
from UTC at the person's current location. A positive number
indicates that the local time-of-day is ahead (i.e., east of)
Universal Time, while a negative number indicates that the local
time-of-day is behind (i.e., west of) Universal Time. Transitions
into and out of daylight savings time may temporarily cause a
difference between the true offset from UTC and the time offset
element.
An optional attribute, description, can be used to describe the
offset, e.g., by labeling the time zone. This description is meant
for human consumption.
Publishers on mobile devices SHOULD NOT publish this information
unless they know the time offset information to reflect the current
location. (For example, many laptop users do not update their time
zone when traveling.) Publishers SHOULD update the information
whenever they discover that their UTC offset has changed.
Example:
<time-offset description="America/New_York">-300
</time-offset>
<SPAN class=h3><A name=section-3.14>3.14</A>. User-Input Element</SPAN>
The <user-input> element records the user-input or usage state of the
service or device, based on human user input, e.g., keyboard,
pointing device, or voice. If contained in a <person> element, it
summarizes any user input activity across all services and devices
operated by the presentity. The mechanism for such aggregation is
beyond the scope of this document, but generally reflects the most
recent user input across all devices and services. The element can
assume one of two values, namely, 'active' or 'idle', with an
optional 'last-input' attribute that records when the last user input
<SPAN class=grey>Schulzrinne, et al. Standards Track [Page 17]</SPAN>
<A id=page-18 href="http://tools.ietf.org/html/rfc4480#page-18" name=page-18><SPAN class=break> </SPAN></A>
<SPAN class=grey><A href="http://tools.ietf.org/html/rfc4480">RFC 4480</A> RIPD July 2006</SPAN>
was received. An optional 'idle-threshold' element records how long
the presentity will wait before reporting the service or device to be
idle, measured in seconds.
(A two-state model was chosen since it would otherwise be necessary
to send repeated last-input updates during continuous activity.)
A service that wants to indicate user input activity sends a <user-
input> 'active' indication when the user has provided user input
within a configurable interval of time, the idle-threshold. If the
user ceases to provide input and the idle-threshold has elapsed, the
tuple is marked with a <user-input> 'idle' indication instead,
optionally including the time of last activity in the 'last-input'
attribute. An example is below:
<user-input idle-threshold="600"
last-input="2004-10-21T13:20:00.000-05:00">idle</user-input>
Depending on device or service capabilities, user input may be
detected only for a particular application, i.e., when the
application has user focus or when a user has sent a message or
placed a call, or can be based on user input across all applications
running on one end system.
The <user-input> element may be used by a watcher, typically in
combination with other data, to estimate how likely a user is to
answer when contacting the service. A tuple that has not been used
in a while may still be OPEN, but a watcher may choose to first
contact a URI in a tuple that is both OPEN and has been used more
recently.
The <user-input> attribute can be omitted if the presentity wants to
indicate that the device has not been used for a while, but does not
want to reveal the precise duration, as in the following:
<user-input>idle</user-input>
Configuration MUST include the option to omit the 'last-input'
attribute.
<SPAN class=h2><A name=section-4>4</A>. Example</SPAN>
The example below describes the presentity
'pres:someone@example.com', which has a SIP contact,
'sip:someone@example.com', representing a service. It also has a
device contact, as an email box. The presentity is in a meeting, in
a public office setting. The 'until' information indicates that he
will be there until 5:30 pm local time. The presentity also has an
<SPAN class=grey>Schulzrinne, et al. Standards Track [Page 18]</SPAN>
<A id=page-19 href="http://tools.ietf.org/html/rfc4480#page-19" name=page-19><SPAN class=break> </SPAN></A>
<SPAN class=grey><A href="http://tools.ietf.org/html/rfc4480">RFC 4480</A> RIPD July 2006</SPAN>
assistant, sip:secretary@example.com, who happens to be available for
communications.
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:lt="urn:ietf:params:xml:ns:location-type"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
entity="pres:someone@example.com">
<tuple id="bs35r9">
<status>
<basic>open</basic>
</status>
<dm:deviceID>urn:device:0003ba4811e3</dm:deviceID>
<rpid:relationship><rpid:self/></rpid:relationship>
<rpid:service-class><rpid:electronic/></rpid:service-class>
<contact priority="0.8">im:someone@mobile.example.net</contact>
<note xml:lang="en">Don't Disturb Please!</note>
<note xml:lang="fr">Ne derangez pas, s'il vous plait</note>
<timestamp>2005-10-27T16:49:29Z</timestamp>
</tuple>
<tuple id="ty4658">
<status>
<basic>open</basic>
</status>
<rpid:relationship><rpid:assistant/></rpid:relationship>
<contact priority="1.0">mailto:secretary@example.com</contact>
</tuple>
<tuple id="eg92n8">
<status>
<basic>open</basic>
</status>
<dm:deviceID>urn:x-mac:0003ba4811e3</dm:deviceID>
<rpid:class>email</rpid:class>
<rpid:service-class><rpid:electronic/></rpid:service-class>
<rpid:status-icon>http://example.com/mail.png</rpid:status-icon>
<contact priority="1.0">mailto:someone@example.com</contact>
</tuple>
<note>I'll be in Tokyo next week</note>
<dm:device id="pc147">
<rpid:user-input idle-threshold="600"
last-input="2004-10-21T13:20:00-05:00">idle</rpid:user-input>
<dm:deviceID>urn:device:0003ba4811e3</dm:deviceID>
<SPAN class=grey>Schulzrinne, et al. Standards Track [Page 19]</SPAN>
<A id=page-20 href="http://tools.ietf.org/html/rfc4480#page-20" name=page-20><SPAN class=break> </SPAN></A>
<SPAN class=grey><A href="http://tools.ietf.org/html/rfc4480">RFC 4480</A> RIPD July 2006</SPAN>
<dm:note>PC</dm:note>
</dm:device>
<dm:person id="p1">
<rpid:activities from="2005-05-30T12:00:00+05:00"
until="2005-05-30T17:00:00+05:00">
<rpid:note>Far away</rpid:note>
<rpid:away/>
</rpid:activities>
<rpid:class>calendar</rpid:class>
<rpid:mood>
<rpid:angry/>
<rpid:other>brooding</rpid:other>
</rpid:mood>
<rpid:place-is>
<rpid:audio>
<rpid:noisy/>
</rpid:audio>
</rpid:place-is>
<rpid:place-type><lt:residence/></rpid:place-type>
<rpid:privacy><rpid:unknown/></rpid:privacy>
<rpid:sphere>bowling league</rpid:sphere>
<rpid:status-icon>http://example.com/play.gif</rpid:status-icon>
<rpid:time-offset>-240</rpid:time-offset>
<dm:note>Scoring 120</dm:note>
<dm:timestamp>2005-05-30T16:09:44+05:00</dm:timestamp>
</dm:person>
</presence>
<SPAN class=h2><A name=section-5>5</A>. XML Schema Definitions</SPAN>
The RPID schema is shown below. Due to limitations in composing
schemas, not all XML documents that validate against the schema below
are semantically valid RPID documents. In particular, the schema
allows each element to appear anyhere in PIDF or data-model elements;
Table 1 restricts where these elements can appear for semantically
valid RPID documents. Elements that do not have from/until
parameters MUST NOT appear more than once in each <person>, <tuple>,
or <device>.
<SPAN class=h3><A name=section-5.1>5.1</A>. urn:ietf:params:xml:ns:pidf:rpid</SPAN>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf:rpid"
xmlns="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
<SPAN class=grey>Schulzrinne, et al. Standards Track [Page 20]</SPAN>
<A id=page-21 href="http://tools.ietf.org/html/rfc4480#page-21" name=page-21><SPAN class=break> </SPAN></A>
<SPAN class=grey><A href="http://tools.ietf.org/html/rfc4480">RFC 4480</A> RIPD July 2006</SPAN>
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:simpleType name="activeIdle">
<xs:restriction base="xs:string">
<xs:enumeration value="active"/>
<xs:enumeration value="idle"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="activities">
<xs:annotation>
<xs:documentation>
Describes what the person is currently doing, expressed as
an enumeration of activity-describing elements. A person
can be engaged in multiple activities at the same time,
e.g., traveling and having a meal.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="note" type="Note_t" minOccurs="0"
maxOccurs="unbounded" />
<xs:choice>
<xs:element name="unknown" type="empty" minOccurs="0"/>
<xs:sequence maxOccurs="unbounded">
<xs:choice&g