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)

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

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

Example <presence … entity="pres:someone@example.com"> <note>I'm in a boring meeting</note> <tuple id="7c8dcqui"> <status> <basic>open</basic> <contact>sip:secretary@example.com</contact> <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>2003-01-27T17:30:00Z</ep:until> </status> <contact priority="0.8">sip:someone@example.com</contact> </tuple>

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>2003-01-27T17:30:00Z</ep:from> <ep:until>2003-01-27T19:30:00Z</ep:until>

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>

Groups Allow presentity to represent groups, not just individuals, each with their own status <presence … entity="pres:engineering@example.com"> <tuple id="478"> <basic>open</basic> </tuple> <members> <presence … entity="pres:alice@example.com"> <tuple id="1"> <contact>sip:alice@example.com</contact> </presence> <presence entity="pres:bob@example.com"> …. </members>

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

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

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

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

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