Re: [Geopriv] Comments on draft-mayrhofer-geopriv-geo-uri-01

["Alexander Mayrhofer" <[e-mail]>]

Richard, 

Thanks for the review of the document - this is very much appreciated.
Some comments inline.

> I think this draft is pretty sound.  It does what it claims to do, in 
> that it unambiguously represents a point location.  

Yep, that was the original intent. I'm happy that we reached a point
where it's clear what we want to achieve. A lot of applications
(especially those in the fancy "web2.0" world) don't need the
flexibility of PIDF-LO, they simply want means to represent a point as
compact as possible - and especially in mobile applications, short
representations of geographic locations are desired (at least that is
what i heard from implementors of mobile services / devices).

Therefore our original goal was to keep it as simple as possible (also
to keep it user-friendly, and easy to implement)

> I'd like to propose 
> two URI options that I think would help make it more useful 
> and give it 
> better privacy properties:

Note that we had URI parameters in an older version of the draft. Back
then we found out that those were heavily underspecified (because we
didn't have any examples of parameters), and they did complicate the
representation quite a lot (besides adding up on the "byte count" of the
format, which was a concern to some potential implementors). 

Anyway, if you (or the group) feels that some well specified parameters
(like those you mention) are useful, we're happy to add them again. 

> 1. Uncertainty: <geo:38.8,-77.0;uncertainty=40>
> This option would allow add an uncertainty radius (with a 
> fixed unit of 
> measure, say meters) in addition to the point location, effectively 
> referring to a GML Circle.  This would require a change to 
> the BNF and 
> an additional GML translation, but would make these URIs usable in a 
> much wider variety of use cases (point+uncertainty being probably the 
> single most common location format in use in applications today).

We had that idea, but it was when there was a lot of discussion around
3825 regarding that issue, so we decided to leave it out. I'm happy to
add it in *if* we can refer to some specification what "uncertainty" (or
another specification that uses that term) - i've found that
draft-ietf-geopriv-pdif-lo-profile obviously discuses this quite a bit,
so we might simply refer to that one.

A GML mapping would be easy as well, it would be similar to what Hannes
has in his draft-tschofenig-geopriv-dhcp-circle - we would probably copy
some of the specifications there, or refer to them.

> 2. Privacy: 
> <geo:38.8,-77.0;retransmisison-allowed=no;retention-expires=20
> 090403T13:00Z>
> This option would add two privacy rules to a geo URI, with identical 
> allowed values and semantics to the PIDF-LO fields, including the 
> defaults (retransmission=no, retention=ephemeral).  This 
> would require a 
> change in the BNF, and raises the question as to whether the 
> "mappings 
> to GML" should really be "mappings to Geopriv", in the sense 
> of mapping 
> to the <geopriv> element in a PIDF-LO.

The "mappings to GML" came out of a suggestion from Hannes, from what i
remember. Of course it would make sense to map things that are not in
GML, but in GEOPRIV to GEOPRIV semantics.

We specified the "geo" URI originally with the intent that it would
describe locations that are public anyway (like, restaurants, maybe
attractions, etc..), so privacy on the location itself was never much of
a concern. However, i do understand that it is very relevant for a lot
of applications (like location conveyed by an instant messaging client
in the status, etc...)

I still think that most of the applications will use "geo" URIs where
retransmission would be allowed, and they would never expire, so i'm not
really happy with the default values of PIDF-LO. I think that most use
cases of "geo" URIs would rather represent "expires=never" and
"retransmission=yes" - for example hyper links to spatial locations on
the web using a "geo" link, or locations of attractions printed on
flyers and brochures (maybe in a 2d-barcode, so that mobile devices
could easily pick it up). Those "printed" representations will not allow
expiration anyway (and one could argue whether it would be possible to
prevent retransmission...)

That means that most use cases will use exactly the contrary of what
PIDF-LO specifies as defaults - so if we would copy the PIDF-LO
defaults, most use cases would need to use much longer URIs).

I'd happily include privacy flags if the defaults would be "no
expiration, retransmission allowed" - because it would match most use
cases that i am aware of.
 
> I think the privacy options make for a really nice privacy 
> story, too: 
> With them, a geo URI is exactly equivalent to a possession-model 
> location URI, in that they're both equivalent to a PIDF-LO.  
> It's just 
> that with a geo URI, you get to skip the dereference step.  So the 
> privacy considerations are the same as for handling a PIDF-LO, namely 
> "SHOULD transmit it over secure channels and MUST obey the rules".

I agree - with the exception of the default values for parameters - as
outlined above :-)

BTW, would the group want to adopt the draft, or shall we continue as an
independent draft? I'd definitely prefer if the group adopted the draft
(i'd still continue to serve as an editor, of course..).

Alex