1 / 16

Data model and RPID

Data model and RPID. Henning Schulzrinne Columbia University. Requirements. Allow for uncertainty Allow for smart watchers (and dumb PAs) Allow different composition policies Support forward compatibility Support lossless Pas Well-defined meaning.

andeana-munoz
Download Presentation

Data model and RPID

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Data model and RPID Henning Schulzrinne Columbia University 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 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 SIMPLE

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

  5. Example: <timed-status> • <ts:timed-statusfrom="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> 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 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 SIMPLE

  8. 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 Model: source meta-data SIMPLE

  9. Option 1 (multiple): Option 2 (one <person>): Model: source meta-data • <person> <source>s1</source></person><person> <source>s2</source></person> <person> <mood source=“s1”><happy/></mood> <mood source=“s2”><sad/></mood> </person> <person> <source> <mood><happy/></mood> </source> <source> <mood><sad/></mood> </source> </person> 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) 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 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 SIMPLE

  13. RPID: Changes • Alignment with data model • <idle>  <user-input> • <timezone> • To do: fix schema and examples 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? 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> 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 SIMPLE

More Related