1 / 8

Presence Processing Model

Presence Processing Model. Jonathan Rosenberg Cisco Systems. Changes. This draft represents the bottom half of the previous data model Contains things PUA and servers DO as opposed to what data means Few other changes to this document besides the split.

mquijada
Télécharger la présentation

Presence Processing 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 Processing Model Jonathan Rosenberg Cisco Systems

  2. Changes • This draft represents the bottom half of the previous data model • Contains things PUA and servers DO as opposed to what data means • Few other changes to this document besides the split

  3. Issue #1: Composing unknown attributes • Only thing compositor can do is select one value • Any other choice may not be schema compliant • Alternative: define an <ambigous> element to encapsulate different values?

  4. Issue #2: Overrides • Still need to define how this is done… • Proposal: • If there are two services/persons/devices with same INSTANCE ID, take the most recent one • Otherwise, override is dictated by composition policy

  5. Issue #3: Lying • Current draft models this as composition policy, but • We run composition policy after privacy • Can’t introduce new information after privacy, so either • Post-privacy processing isn’t composition policy driven • Lying not part of composition policy • Proposal • Lying is a source policy

  6. Source Policies • Specifies the set of presence documents considered as input to the processing process • Default: all documents with presentity ID matching the user • Lying: use a specific fixed document • Aliasing: use all documents with presentity IDs matching all known aliases for watcher • Source policy can be per-watcher

  7. Authorization policy conditions can be based on dynamic state <sphere> for example Authorization policies can specify composition rules or source policies that define presence document Thus its circular Need to break the circle OPTION 1: compute presence doc that would be sent to presentity themselves OPTION 2: compute presence doc that would be sent to a special identity OPTION 3: disallow this condition somehow Others? Issue #4: Computing document for selecting auth policy

  8. Discuss registration data as input Define union compositor Using device information to compute service states Presence federation Choosing pres vs. SIP URI in various places Considerations for aliases Provisioned data, ala call forwarding, as input to composition Other topics to address

More Related