RPIDS and tuple issues

1
RPIDS and tuple issues

• Henning Schulzrinne
• with help from Paul Kyzivat
• SIMPLE WG (Interim Meeting, May 2003)

2
Open Issues

• From IETF56 SIMPLE minutes
• RPIDS as successor to PIDF?
• tuple semantics
• labeling elements uniqueness across time, space,
  
• Mailing list discussion

3
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)

4
How does the system work?

• RPIDS document (?) should spell out at least one
  scenario

presence notification
u1 p1,p2p3 u2 p1,p4 u3p5,p6
p1 ? u1 or u2 p1p2 ? u1 p5, p5 ? u3
INVITE u1 Want p1,p2,p9
caller
callee
5
Open issues what is a tuple?

• Three models have been proposed
• All share same AOR (e.g., sipalice_at_example.com)
  selection via CP
• availability of caller preferences
• Custom-generated address for each capability set
  (maybe several for each device) e.g.,
  sipx45tyu7_at_example.com
• longevity of address?
• tight relationship with proxy server
• Contact addresses representing devices e.g.,
  tel[phone], sipph17_at_alice-employer.com
• privacy
• how long is address valid? (watcher ? address
  book)
• Not necessarily mutually exclusive need all of
  them

6
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 (sipalice_at_128.59.16.1)
• unique label (sipalice4867_at_columbia.edu)

7
Tuple semantics
audio video text
home yes yes no
office yes yes, but low quality yes
mobile can, but inappropriate now cant preferred

• But really N-dimensional hypercube
• arrange by category, placetype, privacy,
• Thus, cant 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

8
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

9
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, )

10
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 ltnotegt to provide hints
• Cant rely on caller preferences for the near
  future
• should we require support on caller side for
  disambiguation? (Opinion policy issue)

11
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 'classminimal'
  items when notifying low-bandwidth watchers")
• Cf. Cascading Style Sheets (CSS)
• "id" unique across document
• "class" type of element

12
Proposal Labeling

• Support class parameter/label
• similar to ltdiv classXgtlt/divgt 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