Sorry for the slow delay in responding to this email. Given John's statement
"the WG has NOT decided on the format for the expression of the LO, but XML
has certainly been discussed as a strong candidate. Even more generally, I
think that many in the geopriv WG would be open to using, or at least being
compatible with, P3P etc"
I would suggest that the group also consider the work of the OpenGIS
consortium in relation to the OpenGIS Geography Markup Language (Version
3.0). GML is a set of XML schemas for encoding (for transport or storage)
geometry (points, lines, ellipses, polygons, splines, etc), metadata about
location, coordinate reference systems, and many other aspects related to
location. GML is being used more and more for the encoding and transport of
location based information across the Internet. Many GIS vendors have
implemented the ability to generate and consume GML. Further, the Open
Mobile Alliance (OMA) has incorporated the coordinate reference system and
geometry schemas into the Mobile Location Platform API. Finally, a number of
OGC members are now implementing the OGC Location Services core set of
interface specifications. These specs use the same geometry and CRS schemas.
Just a thought.
Regards
Carl Reed
OGC
----- Original Message -----
From: John Morris <jmorris@cdt.org>
To: Joseph Reagle <reagle@w3.org>
Cc: <jmpolk@cisco.com>; <jon.peterson@neustar.biz>;
<dmulligan@law.berkeley.edu>; <Jorge.Cuellar@mchp.siemens.de>;
<public-p3p-spec@w3.org>; <geopriv@mail.apps.ietf.org>
Sent: Wednesday, April 09, 2003 4:05 PM
Subject: Re: [BH] Comments on draft-ietf-geopriv-reqs-03
> Joe,
>
> Let me offer my 2 cents in reaction to your comments. Then, for the
> benefit of the "beyond http" P3P task force in the W3C (a new effort
> that I am just joining within the W3C), I will add at the end of this
> message my quick personal overview of where geopriv is now and where
> it is likely to go. I encourage anyone on the geopriv list to
> correct or supplement my overview.
>
> John Morris
>
> At 3:13 PM -0400 4/9/03, Joseph Reagle wrote:
> >I've reviewed [1] as part of my background research for the "Beyond-HTTP"
> >P3P taskforce [2]. I'm not presently able to draw any conclusions with
> >respect to [2] but I think it's an interesting document and have two
> >comments.
> >
> >[1] http://www.ietf.org/internet-drafts/draft-ietf-geopriv-reqs-03.txt
> >[2] http://www.w3.org/P3P/2003/04-beyond-http.html
> >
> >[[[
> > 5.2. The Location Object and Using Protocol
> > ...
> > Location Object (LO): This data contains the Location Information
> > of the Target, and other fields including an identity or
> > pseudonym of the Target, time information, core Privacy Rules,
> > authenticators, etc. ...
> >
> > Nothing is said about the semantics of a missing field. For
> > instance, a partially filled object MAY be understood implicitly as
> > the request to complete it....
> >]]]
> >
> >Since a LO contains the core Privacy Rules, one should *not* permit the
> >absence of the privacy rule syntax to result in ambigous semantic
> >interpretation [3].
> >
> >[3] http://www.w3.org/TR/md-policy-design#_Semantic_Clarity
>
> I agree -- and I think that the working assumption of the geopriv WG
> addresses this point. I believe there is agreement in the WG that
> the default rule is that location should receive a high level of
> privacy protection in the absence of rules to the contrary. In other
> words, the protocol will default to "do not disclose" unless a
> Privacy Rule (in the LO or external) would permit disclosure.
>
> But having said that, I cannot locate anywhere where this default
> assumption is clearly articulated in a WG document. If it is not, we
> need to add it.
>
> >[[[
> > 5.5. Privacy Rules
> > ...A full set of Privacy Rules will likely include both rules that
have
> > only one possible technical meaning, and rules that will be affected
> > by a locality's prevailing laws and customs.
> >]]]
> >
> >This, and the example, makes it sound as if these were disjoint sets.
"You
> >may not store my location for more than 2 days" is very clear even if it
is
> >overridden by other (legal) rules. This paragraph seems to be confusing
the
> >articulation of a non-ambiguous rule with the an a posteriori
> >interpretation of all operative rules that might exceed the knowledge of
> >the Rule Maker or Location Recipient beforehand.
>
> I agree that this discussion warrants clarification. The goal was
> not to suggest two exclusive sets:
>
> 1. technically unambiguous rules, and
> 2. rules that will be affected by local law, etc.
>
> Instead, the goal was to acknowledge that (a) some rules can be
> expressed in technically unambiguous terms, while (b) other rules
> will not be clear without resort to an applicable legal norm. But
> both types of rules (a+b) can certainly be affected or overridden by
> a local law. What we were concerned about was to make clear that
> the set of (b) rules were still valuable to include even if they did
> not have a single unambiguous technical meaning. But in any event,
> the clarification you suggest is worthwhile. I'll work on some
> specific language to address the two points raised here.
>
> Let me change gears and give the BH/P3P task force a quick overview of
geopriv:
>
> Greatly summarizing the geopriv charter [4], the mission of the WG is
> to create a privacy protecting protocol to be used when location
> information is transmitted. In the language of the WG, the WG is
> creating a "Location Object" [LO] which will be able to contain both
> location information and privacy rules (or a pointer to external
> privacy rules). The protocol must be usable in situations with
> constrained devices with low bandwidth and/or computing power. The
> WG is approaching a final requirements draft [5].
>
> That draft says that the Location Object must be able to carry a
> limited set of privacy rules, and must be able to refer to an
> external set of rules as well. There is not final agreement on
> precisely what privacy rules will be built into a LO, but the most
> recent proposal of some WG participants (including me) is found at
> [6]. Even a couple of elements in that version, however, are in a
> state of flux (something that I will try to bring back to the geopriv
> list shortly).
>
> Looking more broadly, the WG has NOT decided on the format for the
> expression of the LO, but XML has certainly been discussed as a
> strong candidate. Even more generally, I think that many in the
> geopriv WG would be open to using, or at least being compatible with,
> P3P, so long as that goal did not slow down geopriv's already slow
> (but significantly accelerating) progress to date.
>
> Let me know if there are more specific points about geopriv that the
> public-p3p-spec@w3.org wants to know at this point..... John
>
> [4] http://www.ietf.org/html.charters/geopriv-charter.html
> [5] http://www.ietf.org/internet-drafts/draft-ietf-geopriv-reqs-03.txt
> [6] http://www.ietf.org/internet-drafts/draft-morris-geopriv-core-01.txt
Received on Fri Apr 25 17:21:57 2003
This archive was generated by hypermail 2.1.8 : Thu Jan 22 2004 - 12:32:24 EST