1. Henning Schulzrinne Columbia University
Data model and RPID
Henning Schulzrinne
Columbia University
IETF61 (November 2004)
SIMPLE

2. Requirements Allow for uncertainty
Allow for smart watchers (and dumb PAs)
Allow different composition policies
Support forward compatibility
Support lossless Pas
Well-defined meaning
IETF61 (November 2004)
SIMPLE

3. Can we build forward-compatible PAs and composers?
PA may not be aware of XML schema details
assume only knows drafts of today: <tuple>, <service>, <device>
e.g., imagine pre-<timed-status> implementation
can only keep one element (most recent)
i.e., forces information loss
May want to delegate filtering and element-level manipulation to other entity
IETF61 (November 2004)
SIMPLE

4. Multi-stage architecture
PUBLISH
(only to mobile.com)
mobile.com PA
personal.org
SUBSCRIBE
NOTIFY
utility.com PA
IETF61 (November 2004)
SIMPLE

5. Example: <timed-status>
<ts:timed-status from=" T10:20: :00" until=" T19:30: :00"> <basic>closed</basic> </ts:timed-status>
How do you compose multiple sources without information loss?
Adding layers doesn’t help unless it is done now:
<person> <view> </view> </person>
IETF61 (November 2004)
SIMPLE

6. Model: Minimal composer
Agreement: don’t specify composer detail, but some minimal model(s)
Two models proposed:
smart: combines contradictory information (pivoting), removing
requires some understanding of XML schema
dumb: concatenates published elements within <presentity>
requires only knowing <tuple>, <person>, <device>
No need to exhaustive, but worried about excluding particular
IETF61 (November 2004)
SIMPLE

7. Model: tuple identification
Agreement: every tuple has a presentity-unique identifier
All composition policies MUST replace <> with the same ID
Disagreement: are there other unique, mandatory-to-replace identifiers
Proposal: no, but any composition policy MAY use anything for pivoting, including URIs
IETF61 (November 2004)
SIMPLE

8. Model: source meta-data
Later, but need to plan ahead
Meta data =
source of information
type of entry (measured vs. manual)
trustworthiness
update frequency, …
Affected by <person> decision and composition policy
IETF61 (November 2004)
SIMPLE

9. Model: source meta-data
Option 1 (multiple):
Option 2 (one <person>):
<person> <source>s1</source> </person> <person> <source>s2</source> </person>
<person>
<mood source=“s1”><happy/></mood>
<mood source=“s2”><sad/></mood>
</person>
<source>
<mood><happy/></mood>
</source>
<mood><sad/></mood>
IETF61 (November 2004)
SIMPLE

10. Notes on extensions
Meta data is instance of general extensibility problem
Option 2a may violate (RPID or similar) schema
Option 2b is not backward-compatible even though <source> is optional information
but would be acceptable if defined as part of data model now (but would require more complicated composer)
IETF61 (November 2004)
SIMPLE

11. Model: <person> uncertainty
Multiple sources of data for person data
calendar
manual entry
body sensors
Composer may not have any reliable way to identify “correct” information
Delegate to (human) watcher, possibly with other context information
IETF61 (November 2004)
SIMPLE

12. <sphere>
For published variables that serve as rule selection input into privacy policy, need to determine which of conflicting variables is used
Motivation: composition (output) and selection are logically separate
Proposal: allow separate algorithm
e.g., ordering (work > play)
most recent
IETF61 (November 2004)
SIMPLE

13. RPID: Changes Alignment with data model
<idle>  <user-input>
<timezone>
To do: fix schema and examples
IETF61 (November 2004)
SIMPLE

14. RPID: <sphere> Sphere = part of my life (set of people)
“I’m wearing my parent hat right now”
Some differences of understandings:
“information to be delivered when I’m in work/play/travel mode”
more similar to <class>
“I’m in IETF sphere right now”
in PUBLISH  may be used by composer to select appropriate elements or receivers
Original intent was (2)
Agreement?
IETF61 (November 2004)
SIMPLE

15. RPID: Enumerations
Enumeration in <mood>, <activities>, <privacy>, <service-class>
Agreement: use substitution groups <mood> <happy/> <sad/> </mood>
Open issue: user-level extensions (i.e., not requiring implementation changes)
escape hatch: <notes>stoned</notes>
IETF61 (November 2004)
SIMPLE

16. RPID: timezone
Allow watcher to determine whether it’s night or day for presentity
Current draft: Olsen database of time zone names (America/New_York)
Problem: often unknown and not explicitly configured
e.g., mobile phones
difficult to translate back to time offset
Proposal: use UTC offset instead
minor problem: DST transitions
IETF61 (November 2004)
SIMPLE