1 / 10

Presence Data Model

Presence Data Model. Jonathan Rosenberg. Changes in -02. Split out data and processing models Allow multiple devices, services, person with same URI/device ID Each has a unique instance ID = id attribute Done for ambiguity only Available IM, not voice is still one service

seymourd
Télécharger la présentation

Presence Data Model

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. Presence Data Model Jonathan Rosenberg

  2. Changes in -02 • Split out data and processing models • Allow multiple devices, services, person with same URI/device ID • Each has a unique instance ID = id attribute • Done for ambiguity only • Available IM, not voice is still one service • Timestamp and note are meta-data for humans to resolve ambiguity

  3. Updated Data Model +--------------------------------------------------------------------+ | | | +----------------+ | | +----------------+| | | | || | | | || | | | Person || | | | ||\ | | /| |+ \ | | / +----------------+ \ | | / | \ | | / | \ | | / | \ | | / | \ | | / | \ | | V V V | | +----------------+ +----------------+ +----------------+ | | +----------------+| +----------------+| +----------------+| | | | || | || | || | | | || | || | || | | | Service || | Service || | Service || | | | || | || | || | | | |+ | |+ | |+ | | +----------------+ +----------------+ +----------------+ | | \ / \ | | \ / \ | | \ / \ | | V V V | | +----------------+ +----------------+ | | +----------------+| +----------------+| | | | || | || | | | || | || | | | Device || | Device || | | | || | || | | | |+ | |+ | | +----------------+ +----------------+ | | | | | | Presentity (URI) | +--------------------------------------------------------------------+

  4. Timestamp and note allowed for person and device Schema rework (more needed) General document characteristics Meaning independent of transport Infinite composeability Explicit, not Implicit behaviors on watchers One number Checks to make to improve connect probability Note resolution algorithm Can be present in <person> or in document root Resolution like media attributes in SDP Broke service component into pieces Characteristics Reach information Status Relative information Reach information – URI plus other data needed to get to the service defined by the tuple Uniquely identifies a service Changes Continued

  5. Capabilities are not reach information! Remove reference to sparks-service-examples Tel URI dealt with Is allowed as a contact Characteristics/capabilities need to be applicable for all URI resolvable from the tel URI Tel URI with enumdi or no enum are ideal Documents Aki’s “available IM, not voice” as a more complex status of a service Service URI in <contact> is defined as URI for reaching the service, data-model doesn’t specify how to populate Service URI to service mapping is many-to-one, URI can change over time UUID no longer preferred, doesn’t work well here, no alternatives defined Person is a single individual, clarified how groups are modeled Discuss how to set URI in <contact> - pres vs. SIP Changes Continued

  6. Changes Continued • Service is defined as anything with a set of properties – reach info, characteristics, status, relative priority • Service summarization is discussed, based on reach information

  7. Issue #1: Service Identifier • The never-ending Doom example • Capabilities won’t be enough to figure out to represent with a “doom icon” on the UI • Brian proposes a service registry • PTT example • Is “floor control required” prescaps enough? • Data Model says • This is summarization • Reach information is ideal for that – URI plus other stuff you “have to know” to reach this service • Other specs can define new reach information • Is that enough? YES • Someone want to define reach info for PTT/games – I am waiting for the draft on PoC!

  8. Issue #2: Available IM, not Audio • How to represent this? • Choice A: basic status that is a boolean function of media sessions • Choice B: only indicate IM capabilitiy and set basic status to open • Data model leaves the door open for choice A, B is allowed of course • Sufficient? YES

  9. Issue #3: Three Dimensions • Henning proposes three dimensions of service • D1: protocols and capabilities • D2: interaction – is it human? Does it announce or record? • D3: content – am I talking to a flight reservation system? Game sounds? • Do we need to model these in the data model? • D1: capabilities • D2+D3: characteristics • Proposal: No action needed in data model

  10. Issue #4: Device ID URN • Proposal to use UUID URN with timestamp of zero • Hokey • What about GRUU instance ID • No – two UA on same device will have different instance ID, same device ID • Instance ID may be a good service instance identifier (id attribute) • MAC is problematic • Changes if interface card changes • Proposal • Describe relationship of GRUU instance ID and ID’s in the data model per above, including data model instance ID • Change instance ID term due to overlap with GRUU term • MAC is still fine, device ID can change -> correlation key property and is highly coupled with mac • Multiple device IDs per service? • Guidance for setting this? -> separate new ID

More Related