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

IETF61 (November 2004) SIMPLE2 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) SIMPLE3 Can we build forward-compatible PAs and composers? PA may not be aware of XML schema details –assume only knows drafts of today:,, –e.g., imagine pre- 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) SIMPLE4 Multi-stage architecture mobile.com PA personal.org utility.com PA PUBLISH (only to mobile.com) SUBSCRIBE NOTIFY

IETF61 (November 2004) SIMPLE5 Example: closed How do you compose multiple sources without information loss? Adding layers doesn’t help unless it is done now: –

IETF61 (November 2004) SIMPLE6 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 requires only knowing,, No need to exhaustive, but worried about excluding particular

IETF61 (November 2004) SIMPLE7 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) SIMPLE8 Model: source meta-data LaterLater, but need to plan ahead Meta data = –source of information –type of entry (measured vs. manual) –trustworthiness –update frequency, … Affected by decision and composition policy

IETF61 (November 2004) SIMPLE9 Model: source meta-data Option 1 (multiple):Option 2 (one ): s1 s2

IETF61 (November 2004) SIMPLE10 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 is optional information –but would be acceptable if defined as part of data model now (but would require more complicated composer)

IETF61 (November 2004) SIMPLE11 Model: 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) SIMPLE12 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) SIMPLE13 RPID: Changes Alignment with data model  To do: fix schema and examples

IETF61 (November 2004) SIMPLE14 RPID: 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 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?

IETF61 (November 2004) SIMPLE15 RPID: Enumerations Enumeration in,,, Agreement: use substitution groups Open issue: user-level extensions (i.e., not requiring implementation changes) –escape hatch: stoned

IETF61 (November 2004) SIMPLE16 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