Re: GEOPRIV and the W3C Geolocation API

Hi Andrei

> I have a question about this: doesn't it seem a little odd to state "I
> want your API to be compatible with specification X" as a goal? I'm a
> little puzzled as to how this can be a fair goal. 

Actually, this doesn't seem odd to me at all.  If you were designing API 
  for sending email, you would definitely want it to be compatible with 
  RFC 2821 (SMTP) and RFC 2822 (E-mail formats).  If you were designing 
an API for getting information over HTTP, you would want it to be 
compatible with RFC 2616.  (Most such APIs have the above properties!) 
It doesn't seem that much of a stretch to say that it would be good for 
a Geolocation API be compatible with RFC 4119.

> However, the decision can only be made on technical grounds and not
> with arguments such as "if you don't use GeoPriv, privacy will be
> ignored". My suggestion is that we should continue the discussion on
> the above thread and aim to reach a conclusion once all the evidence
> has been produced.

If it sounded like I was making that argument, I apologize.  All I'm 
saying is that this group should make some provision for privacy in the 
API, for example, by designating a place for privacy rules in location 
objects.  The specific rules in RFC 3693/4119 are a baseline set, and 
explicitly intended to be extended with richer semantics.  The important 
thing is that there be a way to include privacy preferences along with 
location information, however those preferences might be expressed.

Please also keep in mind that GEOPRIV isn't just about privacy.  GEOPRIV 
standards also have very robust support for both geodetic and civic 
location, in addition to the privacy features.  Ignoring this whole 
debate on privacy, it seems like a good idea to re-use the work the 
GEOPRIV has done on civic location, which is a genuinely difficult 
problem for which they've got a pretty good solution.

--Richard

Received on Tuesday, 11 November 2008 14:43:14 UTC