Data model and RPID Henning Schulzrinne Columbia University
Data model and RPID Henning Schulzrinne Columbia University IETF 61 (November 2004) SIMPLE 1
Requirements • • • Allow for uncertainty Allow for smart watchers (and dumb PAs) Allow different composition policies Support forward compatibility Support lossless Pas Well-defined meaning IETF 61 (November 2004) SIMPLE 2
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 IETF 61 (November 2004) SIMPLE 3
Multi-stage architecture PUBLISH (only to mobile. com) mobile. com PA personal. org SUBSCRIBE NOTIFY utility. com PA IETF 61 (November 2004) SIMPLE 4
Example: <timed-status> • <ts: timed-status from="2003 -08 -15 T 10: 20: 00. 000 -05: 00" until="2003 -08 -22 T 19: 30: 00. 000 -05: 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> </person> IETF 61 (November 2004) SIMPLE 5
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 IETF 61 (November 2004) SIMPLE 6
Model: tuple identification • Agreement: every tuple has a presentityunique 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 IETF 61 (November 2004) SIMPLE 7
Model: source meta-data • Later, Later but need to plan ahead • Meta data = • Affected by <person> decision and composition policy – source of information – type of entry (measured vs. manual) – trustworthiness – update frequency, … IETF 61 (November 2004) SIMPLE 8
Model: source meta-data • Option 1 (multiple): <person> <source>s 1</source> </person> <source>s 2</source> </person> IETF 61 (November 2004) • Option 2 (one <person>): <person> <mood source=“s 1”><happy/></mood> <mood source=“s 2”><sad/></mood> </person> <source> <mood><happy/></mood> </source> <mood><sad/></mood> </source> </person> SIMPLE 9
Notes on extensions • Meta data is instance of general extensibility problem • Option 2 a may violate (RPID or similar) schema • Option 2 b 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) IETF 61 (November 2004) SIMPLE 10
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 IETF 61 (November 2004) SIMPLE 11
<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 IETF 61 (November 2004) SIMPLE 12
RPID: Changes • • Alignment with data model <idle> <user-input> <timezone> To do: fix schema and examples IETF 61 (November 2004) SIMPLE 13
RPID: <sphere> • Sphere = part of my life (set of people) – • “I’m wearing my parent hat right now” Some differences of understandings: 1. “information to be delivered when I’m in work/play/travel mode” – more similar to <class> 2. “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? IETF 61 (November 2004) SIMPLE 14
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> IETF 61 (November 2004) SIMPLE 15
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 IETF 61 (November 2004) SIMPLE 16
- Slides: 16