1. RPIDS - Rich Presence Information Data Format for Presence Based on the Session Initiation Protocol (SIP)
Henning Schulzrinne (ed.)
Vijay Gurbani
Krisztian Kiss
Paul Kyzivat
Mikko Lonnfors
Jonathan Rosenberg
SIMPLE WG (IETF 56, San Francisco, March 2003)

2. Motivation/Overview
Richer presence information than basic PIDF (which is just open/closed)
 proprietary systems
while SIP-aware, easily CPIM-translatable
derivable mechanically from calendars, etc.
Merged with caller-preferences-based documents (“prescaps”) for describing presentity properties
Both for publication and notification (but may differ)
watcher
everything PA
PUA
watcher
"vague"
PUBLISH
watcher
NOTIFY
CPL

3. Presence status <class>: presentity, group, device
<category>: activity (on-the-phone, away, appointment, holiday, meal, meeting, steering, in-transit, travel, vacation, busy, permanent-absence)
<placetype>: home, office, public
<privacy>: public, private, quiet
<from>, <until>: status validity
<activity>, <idlesince>: activity for device
<relationship>: family, associate, assistant, supervisor
<label>: permanent label, not to be modified

4. Example <presence … entity="pres:someone@example.com">
<note>I'm in a boring meeting</note>
<tuple id="7c8dcqui">
<status>
<basic>open</basic>
<ep:relationship>assistant</ep:relationship>
</status>
<note>My secretary</note>
</tuple>
<tuple id="18x765">
<status>
<basic>open</basic>
<ep:category>meeting</ep:category>
<ep:placetype>office</ep:placetype>
<ep:privacy>quiet</ep:privacy>
<ep:activity>inactive</ep:activity</ep:activity>
<ep:idlesince> T17:30:00Z</ep:until>
</status>
<contact
</tuple>

5. Timed status PIDF for the here and now
Information may not be available – "was in a meeting an hour ago" (says her calendar)
Cannot extend status since it would confuse PIDF-only watchers
<ep:timed-status>
<basic>closed</basic>
<ep:from> T17:30:00Z</ep:from>
<ep:until> T19:30:00Z</ep:until>

6. Device capabilities
Describes capabilities of device represented by tuple
Any caller-preferences feature tag
<cap:capabilities>
<cap:feature name="Media">
<cap:value>voice</cap:value>
<cap:value negated="true">message</cap:value>
</cap:feature>
</cap:capabilities>

7. Groups
Allow presentity to represent groups, not just individuals, each with their own status
<presence …
<tuple id="478">
<basic>open</basic>
</tuple>
<members>
<presence …
<tuple id="1">
</presence>
<presence ….
</members>

8. Open issues – group model
Groups can have presence, too ("sales is present"), as aggregate
labeled via <contact-type>group</contact-type>
Groups can contain groups
Alternate model (draft-ietf-simple-event-list):
subscribe to group server
group server subscribes to members
returns multipart with member status
somewhat less space-efficient due to MIME header
Recommendation: leave out of RPIDS for now

9. Open issues - label PIDF defines "id" tuple tag
allows to replace changed tuples without sending all the unchanged ones
not clear from spec who modifies (PA?)
Separate "label" tag proposed
similar semantics, but set by presentity and left alone by PA
for policy filtering ("only show 'class=minimal' items when notifying low-bandwidth watchers")
Cf. Cascading Style Sheets:
"id" = unique across document
"class" = type of element

10. Open issues - elements
Currently, all extend <status> (for simplicity)
Complete?
most are extensible via IANA  not meant to completely cover all human activities, but good enough to guide communications reachability and human intuition
Category combinations needed?
"meeting" + "steering" + "vacation" + "meal"?
Reasonably orthogonal?
there will always be combinations that are more likely than others
e.g., category=meeting, privacy=public, placetype=home is not likely, but possible

11. Open issues – what is a tuple?
Three models have been proposed:
All share same AOR (e.g., selection via CP
availability of caller preferences
Custom-generated address for each capability set (maybe several for each device); e.g.,
longevity of address?
tight relationship with proxy server
Contact addresses representing devices; e.g., tel: ,
privacy
how long is address valid? (watcher  address book)
Not necessarily mutually exclusive – need all of them

12. Conclusion
Believed to be reasonably complete representation of typical presence status and capabilities
"what, how, when, where, why, what next"
except for location (later, via GEOPRIV)
Group concept?
Request WG item status