draft-schulzrinne-geopriv-presence-lo-00

1
draft-schulzrinne-geopriv-presence-lo-00

• Henning Schulzrinne
• Columbia University

2
Meta comments

• Explore a particular philosophy, not provide all
  details
• Try to fit with related work in SIMPLE and
  elsewhere
• Design considerations to follow also open
  issues that need some resolution

3
Design considerations

• Allow two modes of delivery
• single LO with complete rule set (A-L)
• external rule set (incl. MIME)
• Reason delivery and storage flexibility
• does not increase processing complexity
• "bundling" (MIME or single LO) reduces failure
  probability and delay
• but makes separate security treatment harder

4
Design considerations

• Applicable to access restrictions for general
  information about people (e.g., presentities),
  not just geoloc
• boundary is often fuzzy
• e.g., "activity" in RPIDS can be subject to
  privacy and retention concerns
• design for generality, allow restriction to
  domain
• Treat rules as first-class elements
• rules are subject to retention and distribution
  rules themselves ? allows for full use of rules
  without crude divisions (personal vs.
  non-personal)
• Re-use calsch for timing rules

5
Location information

• support both geospatial and civil locations
• geospatial includes vectors ("heading") and paths
  (points in time)
• uses OpenGIS GML format for geospatial
• needs profiling (500 pages)
• homebrew for civil
• until external reference is found
• probably want union with Cuellar et al. format

6
Example geo in PIDF
lt?xml version"1.0" encoding"UTF-8"?gt
ltpresence ... xmlnsgml'http//www.opengis.net/gm
l' xmlnsloc'urnietfparamsxmlnsgeopriv-
loc' entity'presalice_at_example.com'...gt
lttuple id"123"gt ltstatusgt
ltbasicgtopenlt/basicgt ltstatusgt
ltloclocationgt ltgmlPointgt
ltgmlposgt40.85790 73.98857lt/gmlposgt
lt/gmlPointgt lt/loclocationgt
lt/tuplegt lt/presencegt
7
Example civil
ltloclocationgt ltccgtUSlt/ccgt
ltca1 label'state'gtNJlt/ca1gt ltca2
label'county'gtBergenlt/ca2gt ltca3
label'city'gtLeonialt/ca3gt ltca6
label'street'gtWestviewlt/ca6gt
ltcstsgtAvelt/cstsgt ltchnogt313lt/chnogt
ltczipgt10027lt/czipgt lt/loclocationgt
8
Disclosure rules
ltpdisclosure rule"http//example.com/disclosure.
xml"gt ltprule uri"sipbob_at_example.com"gt
ltpmatchgt ltpareagthomelt/pareagt
ltprrule freq"daily" until"20031224T000000Z
" count"10"/gt lt/pmatchgt
ltpactiongt ltpincludegta1lt/pincludegt
ltpincludegta2lt/pincludegt
ltpexcludegtlt/excludegt ltpresolution
latitude"9" longitude"10" altitude"3"/gt
ltpnotify uri"mailtoalice_at_example.com"/gt
lt/pactiongt lt/prulegt ltprule
subject"CUS STWashington LSeattle
OAmazon.com, Inc OUSoftware
CNwww.amazon.com"/gt ltprule
hash-uri"6e8c81b2f0de5e5957871354761b56c5"/gt
ltprule until"2004-05-31T132000.000-0500"
duration"3600"/gt lt/pdisclosuregt
9
Disclosure open issue

• There is no "final" recipient after all, if
  there was, there would be no need for disclosure
  rules
• If recipient only gets A-C, likely that
  disclosure retention will be effectively zero
  since I can't limit it beyond that
• Thus, need to be able to constrain "final"
  recipient of information at finer granularity

10
Additional open issues

• Closely related to authorization
• OASIS
• SIMPLE authorization
• Identification of elements
• suggest trivial subset of XPath (foo/bar/...)
• could use it to make things conditional
• "only include if value is within range" (e.g.,
  within a certain area)
• probably too tedious to be useful