RPIDS and tuple issues Henning Schulzrinne with help

RPIDS and tuple issues Henning Schulzrinne with help from Paul Kyzivat SIMPLE WG (Interim Meeting, May 2003)

Open Issues • From IETF 56 SIMPLE minutes: – RPIDS as successor to PIDF? – tuple semantics – labeling elements: uniqueness across time, space, … • Mailing list discussion

Step back: what do we want presence to support? • General notion of reachability for communications • Generally, device-mediated • Also, direct human-human communication (drop in and chat) • Later, maybe status (“X is travelling, so no point in waiting for her to start the meeting”)

How does the system work? • RPIDS document (? ) should spell out at least one scenario presence notification u 1: p 1, p 2|p 3 u 2: p 1, p 4 u 3: p 5, p 6 caller INVITE u 1 Want: p 1, p 2, p 9 p 1 u 1 or u 2 p 1+p 2 u 1 p 5, p 5 u 3 callee

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 • 2. Custom-generated address for each capability set (maybe several for each device); e. g. , sip: x 45 tyu 7@example. com • • 3. longevity of address? tight relationship with proxy server Contact addresses representing devices; e. g. , tel: +1 -555123 -4567, sip: ph 17@alice-employer. com • • • availability of caller preferences privacy how long is address valid? (watcher address book) Not necessarily mutually exclusive – need all of them

Tuple semantics • Tuple represents opaque entity, e. g. , a group – easy, since few characteristics except “this is a group” – intersection or union probably makes little sense • Tuple represents media capability – “reachable by audio” – may be implemented by multiple devices • Tuple represents device (or location) – may become more important as location information increases – can be represented either by host or user part: • direct contact (sip: alice@128. 59. 16. 1) • unique label (sip: alice+4867@columbia. edu)

Tuple semantics home office mobile audio video text yes no yes, but low quality yes can, but inappropriate now can’t preferred • But really N-dimensional hypercube: – arrange by ‘category’, ‘placetype’, ‘privacy’, … • Thus, can’t hope to represent as anything but enumeration • While number of descriptors is large and will grow, number of instances represented is likely to remain smallish (~3 -5? ) – mobile multi-function devices make smaller number of devices seem likely

Tuple perspectives • hide details of user devices (and maybe location or other aspects) – sometimes, address could be used to guess user location or behavior (aol. com home, mobile device traveling) – not all users will have the ability to create injective (1 -1) identities – want centralized policy enforcement point for simplicity – focus on callee control • provide details – description insufficient for informed caller choice – emphasis on caller empowerment

Anonymous tuples • Tuples without contact • Current meaning: face-to-face communications • Needed since presentity URI may not be usable by communications application (e. g. , pres: ) • May also become useful for presence focused on activity – e. g. , track where rescue worker (soldier, nurse, Maytag repairman, …) is and environmental characteristics (heart rate, air temperature, …)

Tuple – resolution? • Hard to anticipate uses – document choices and trade-offs • UI considered solvable: – represent as enumeration or table (matrix) with properties in either case – use <note> to provide hints • Can’t rely on caller preferences for the near future – should we require support on caller side for disambiguation? (Opinion: policy issue)

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? ) and what its lifetime is • 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 (CSS): – "id" = unique across document – "class" = type of element

Proposal: Labeling • Support class parameter/label: – – – similar to <div class=X></div> semantics in HTML and CSS one-to-many: one class, many tuples each tuple can have at most one class inherited (if supported in RPIDS) used for filtering and policy • Identifier (id): – – for identification (replace, edit, delete) of specific tuples unique across all tuples for presentity should not be re-used e. g. , time of initial creation of tuple