the Affective Knowledge Representation that has been defined by
Lisetti [17]:
A mood enumeration consists of one or more elements using elements
drawn from the list below, a string enclosed in the <other> element,
or IANA-registered values from other namespaces (Section 7).
The <mood> element MAY be qualified with the ’from’ and ’until’
attributes as described in Section 3.1.
o afraid
o amazed
o angry
o annoyed
o anxious
o ashamed
o bored
o brave
o calm
o cold
o confused
o contented
o cranky
o curious
o depressed
o disappointed
o disgusted
o distracted
o embarrassed
o excited
o flirtatious
o frustrated
o grumpy
o guilty
o happy
o hot
o humbled
o humiliated
o hungry
o hurt
o impressed
o in_awe
o in_love
o indignant
o interested
o invincible
o jealous
o lonely
o mean
o moody
o nervous
o neutral
o offended
o other
o playful
o proud
o relieved
o remorseful
o restless
o sad
o sarcastic
o serious
o shocked
o shy
o sick
o sleepy
o stressed
o surprised
o thirsty
o unknown
o worried
Example:
<mood>
<note>I’m ready for the bar BOF!</note>
<sleepy/>
<thirsty/>
</mood>
3.6. Place-is Element
The <place-is> element describes properties of the place the person
is currently at. This offers the watcher an indication of what kind
of communication is likely to be successful. Each major media type
has its own set of attributes. Omitting the element indicates that
the property is unknown.
For audio, we define the following attributes:
noisy: The person is in a place with a level of background noise
that makes audio communications difficult.
ok: The environmental conditions are suitable for audio
communications.
quiet: The person is in a place such as a library, restaurant, place
of worship, or theater that discourages noise, conversation, and
other distractions.
unknown: The place attributes for audio are unknown.
For video, we define the following attributes:
toobright: The person is in a bright place, sufficient for good
rendering on video.
ok: The environmental conditions are suitable for video.
dark: The person is in a dark place, and thus the camera may not be
able to capture a good image.
unknown: The place attributes for video are unknown.
For text (real-time text and instant messaging), we define
uncomfortable: Typing or other text entry is uncomfortable.
inappropriate: Typing or other text entry is inappropriate, e.g.,
since the user is in a vehicle or house of worship.
ok: The environmental conditions are suitable for text-based
communications.
unknown: The place attributes for text are unknown.
This list can be augmented by free-text values in a note or
additional IANA-registered values (Section 7).
The <place-is> element contains other elements, e.g.,
<place-is>
<audio>
<noisy />
</audio>
<video>
<dark />
</video>
</place-is>
The <place-is> element MAY be qualified with the ’from’ and ’until’
attributes as described in Section 3.1.
3.7. Place-type Element
The <place-type> element describes the type of place the person is
currently at. This offers the watcher an indication of what kind of
communication is likely to be appropriate. The initial set of values
is contained in RFC 4589 [12].
This list can be augmented by free-text values or additional IANA-
registered values as described in RFC 4589.
The <place-type> element is a choice of elements, as in
<place-type>
<pt:street/>
</place-type>
The <place-type> element MAY be qualified with the ’from’ and ’until’
attributes as described in Section 3.1.
3.8. Privacy Element
The <privacy> element indicates which types of communication third
parties in the vicinity of the presentity are unlikely to be able to
intercept accidentally or intentionally. This does not in any way
describe the privacy properties of the electronic communication
channel, e.g., properties of the encryption algorithm or the network
protocol used.
audio: Inappropriate individuals are not likely to overhear audio
communications.
text: Inappropriate individuals are not likely to see text
communications.
unknown: This information is unknown.
video: Inappropriate individuals are not likely to see video
communications.
The <privacy> element can be used by logic executing on the
watcher or by a composer to filter, sort and label tuples. For
example, a composer may have rules that limit the publication of
tuples labeled "private" to a select subset of the watchers.
The <privacy> element MAY be qualified with the ’from’ and ’until’
attributes as described in Section 3.1.
Example:
<privacy>
<text/>
<audio/>
</privacy>
3.9. Relationship Element
The <relationship> element extends <tuple> and designates the type of
relationship an alternate contact has with the presentity. This
element is provided only if the tuple refers to somebody other than
the presentity. Relationship values include "family", "friend",
"associate" (e.g., for a colleague), "assistant", "supervisor",
"self", and "unknown". The default is "self".
If a relationship is indicated, the URI in the <contact> element
refers to the entity, such as the assistant, that has a relationship
to the presentity, not the presentity itself.
Like tuples without a <relationship> qualifier, the <contact> element
for tuples labeled with a relationship can contain either a
communication URI such as "im", "sip", "sips", "h323", "tel", or
"mailto", or a presence URI, such as "pres" or "sip".
Example:
<relationship>
<friend/>
</relationship>
3.10. Service Class
The <service-class> element extends <tuple> and designates the type
of service offered.
electronic: Delivery of information by electronic means, i.e.,
without delivering physical objects. Examples include telephone,
fax, email, instant messaging, and SMS.
postal: Delivery by the postal service, e.g., as a letter, parcel,
or postcard. Delivery could be to a post office box or central
mailroom rather than the presentity’s office location, for
example.
courier: Delivery by messenger, overnight delivery, or courier.
Courier-delivered messages are usually delivered to a receptionist
rather than, say, a mailroom or receiving department.
freight: Delivery by freight carrier, typically of larger objects
that are not sent by postal mail or courier. The recipient is
often the shipping department or a loading dock.
in-person: Describes the coordinates for visits in person, as by a
visitor, i.e., usually somebody’s office or residence.
unknown: The type of service is unknown.
Electronic service is implied if omitted. The service types
’postal’, ’courier’, ’freight’, and ’in-person’ MUST NOT be used
unless the contact URI is empty. Additional data elements defined
elsewhere describe the physical service delivery address for the in-
person, postal, or delivery services. Such addresses might be
specified in geospatial coordinates, civic addresses, or some
specialized address format, e.g., for interstellar addresses or a
company-specific delivery system.
Example:
<service-class><postal/></service-class>
3.11. Sphere Element
The <sphere> element designates the current state and role that the
person plays. For example, it might describe whether the person is
in a work mode, at home, or participating in activities related to
some other organization such as the IETF or a church. This document
does not define names for these spheres except for two common ones,
"work" and "home", as well as "unknown".
Spheres allow the person to easily turn on or off certain rules that
depend on what groups of people should be made aware of the person’s
status. For example, if the person is a Boy Scout leader, he might
set the sphere to "scouting" and then have a rule set that allows
other scout masters in his troop to see his presence status. As soon
as he switches his status to "work", "home", or some other sphere,
the fellow scouts would lose access.
The <sphere> element MAY be qualified with the ’from’ and ’until’
attributes as described in Section 3.1.
Example:
<sphere>
<home/>
</sphere>
3.12. Status-Icon Element
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
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>
3.13. Time Offset
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>
3.14. User-Input Element
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
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.
4. Example
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
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>
<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>
5. XML Schema Definitions
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>.
5.1. urn:ietf:params:xml:ns:pidf:rpid
<?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"
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>
<xs:element name="appointment"
type="empty" />
<xs:element name="away"
type="empty" />
<xs:element name="breakfast"
type="empty" />
<xs:element name="busy"
type="empty" />
<xs:element name="dinner"
type="empty" />
<xs:element name="holiday"
type="empty" />
<xs:element name="in-transit"
type="empty" />
<xs:element name="looking-for-work"
type="empty" />
<xs:element name="meal"
type="empty" />
<xs:element name="meeting"
type="empty" />
<xs:element name="on-the-phone"
type="empty" />
<xs:element name="performance"
type="empty" />
<xs:element name="permanent-absence"
type="empty" />
<xs:element name="playing"
type="empty" />
<xs:element name="presentation"
type="empty" />
<xs:element name="shopping"
type="empty" />
<xs:element name="sleeping"
type="empty" />
<xs:element name="spectator"
type="empty" />
<xs:element name="steering"
type="empty" />
<xs:element name="travel"
type="empty" />
<xs:element name="tv"
type="empty" />
<xs:element name="vacation"
type="empty" />
<xs:element name="working"
type="empty" />
<xs:element name="worship"
type="empty" />
<xs:element name="other"
type="Note_t" />
<xs:any namespace="##other"
maxOccurs="unbounded" processContents="lax"/>
</xs:choice>
</xs:sequence>
</xs:choice>
</xs:sequence>
<xs:attributeGroup ref="fromUntil"/>
<xs:attribute name="id" type="xs:ID"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
</xs:element>
<xs:element name="class" type="xs:token">
<xs:annotation>
<xs:documentation>
Describes the class of the service, device or person.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="mood">
<xs:annotation>
<xs:documentation>
Describes the mood of the presentity.
</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"/>
<xs:sequence maxOccurs="unbounded">
<xs:choice>
<xs:element name="afraid"
type="empty"/>
<xs:element name="amazed"
type="empty"/>
<xs:element name="angry"
type="empty"/>
<xs:element name="annoyed"
type="empty"/>