80 likes | 215 Views
Privacy rules for presence. Henning Schulzrinne May 10, 2004 v2.0. Data flow. resolve state contradictions. watcher list. presence information content. PUBLISH. privacy filtering. watcher filter. rate limit. PUBLISH. watcher. PUBLISH. default composition:
E N D
Privacy rules for presence Henning Schulzrinne May 10, 2004 v2.0
Data flow resolve state contradictions watcher list presence information content PUBLISH privacy filtering watcher filter rate limit PUBLISH watcher PUBLISH default composition: remove duplicate tuples remove empty tuples concatenate create view (device, service, …) removes tuples removes elements from tuples
Subscription • Separate filtering and subscription • Logically distinct • some geopriv systems don’t have subscription • but dependent (can’t filter without subscription) • Separate requirements • don’t want it to depend on current state • may not be completely known at subscription time • may allow state probing by repeated subscription • needlessly increases network load
Subscription rules • Conditions • time of day • identity • Outcome • block, confirm, polite-block?, allow
Depend on current presentity state sphere location But probably not activities idle time location type … Two types of rules: tuple selection (class) element selection and transformation Each rule applies to one tuple, not whole presence document Non-empty tuples are then merged using separate local policy initially, can just concatenate non-empty, non-identical tuples Filter rules
Multiple states • Rules depend on state of presentity • may be derived from PUBLISHed information • There may be multiple conflicting or ambiguous states • e.g., location=NY and location=NJ or (state,city) = (NY,Rochester) and (state) = (NY) • Two different spheres • If presentity has multiple states, two solutions: • apply each state to all tuples • keep tuples and elements that are included according to all presentity states • privacy safe • avoids complicated rules where one state overrides another • deals safely with incrementally available state • implementation choice: re-run rules if presentity state changes? • may yield additional notifications • avoid problem by declaring any contradictory state as undefined • undefined does not match any rule that requires that condition
Filter rules • Conditions: • watcher properties • presentity properties (sphere, location) • tuple properties (class, others?) • Two types of filter rules: • include tuple (by class) • is this a condition instead? • include elements (by element name) • Since per-tuple, simple: • list of semantic elements to provide, as tokens • <provide>activities contact</provide>
Example <conditions> <sphere>work</sphere> <identity> <uri>user@example.com</uri> </identity> <class>foobar</class> <uri-scheme>sip</uri-scheme> </conditions> <transformations> <provide>rpid:activities lo:a1</provide> </transformations>