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) PA watcher PUA watcher PUBLISH NOTIFY everything "vague" CPL

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

4. Example I'm in a boring meeting open sip:secretary@example.com assistant My secretary open meeting office quiet inactive 2003-01-27T17:30:00Z sip:someone@example.com

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 closed 2003-01-27T17:30:00Z 2003-01-27T19:30:00Z

6. Device capabilities Describes capabilities of device represented by tuple Any caller-preferences feature tag voice message

7. Groups Allow presentity to represent groups, not just individuals, each with their own status open open sip:alice@example.com ….

8. Open issues – group model Groups can have presence, too ("sales is present"), as aggregate –labeled via group 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 (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: 1.All share same AOR (e.g., sip:alice@example.com ); selection via CP availability of caller preferences 2.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 3.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

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