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

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

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

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

Example: <timed-status> <ts:timed-status from="2003-08-15T10:20:00.000-05:00" until="2003-08-22T19: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> </view> </person> IETF61 (November 2004) SIMPLE

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

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

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

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

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

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

<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

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

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

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

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