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 –Timestamp and note are meta-data for humans to resolve ambiguity

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

Changes Continued 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 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 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 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 - pres vs. SIP

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

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!

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

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

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