Last Call Review of draft-ietf-geopriv-geo-uri-
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.
This document specifies a Uniform Resource Identifier (URI) for
geographic locations using the 'geo' scheme name. A 'geo' URI
identifies a physical location in a two- or three-dimensional
coordinate reference system in a compact, simple, human-readable, and
protocol-independent way. The default coordinate reference system
used is WGS-84.
I think the document is fine security wise. I have a couple of questions; mostly to satisfy curiosity:
3.4.3. Location Uncertainty
The 'u' ("uncertainty") parameter indicates the amount of uncertainty
in the location as a value in meters. Where a 'geo' URI is used to
identify the location of a particular object, <uval> indicates the
uncertainty with which the identified location of the subject is
The 'u' parameter is optional and it can appear only once. If it is
not specified, this indicates that uncertainty is unknown or
unspecified. If the intent is to indicate a specific point in space,
<uval> MAY be set to zero. Zero uncertainty and absent uncertainty
are never the same thing.
Shouldn't this MAY be a MUST? (since as you note zero uncertainty and absent uncertainty are never the same thing.)
3.4.4. URI Comparison
Two 'geo' URIs are equal when they use the same CRS, and <coord-a>,
<coord-b>, <coord-c> and 'u' value are mathematically identical
(including absent <uval> meaning undefined 'u' value).
Hmm. About comparison:
I understand that when <uval> is present you are delimiting a sphere of radius <uval> centered on the point (<coord-a>, <coord-b>, <coord-c>).
When <uval> is absent (undefined) the sphere containing can have any radius, thus two geo URIs with same coordinates but undefined <uval> might correspond to a different spheres in which case it seems to me that they shouldn't be said to be equal.
5. URI Operations
Currently, just one operation on a 'geo' URI is defined - location
dereference: In that operation, a client dereferences the URI by
extracting the geographical coordinates from the URI path component
<geo-path>. Further use of those coordinates (and the uncertainty
value from <uval>) is then up to the application processing the URI,
and might depend on the context of the URI.
It seems that the document is also defining an equality comparison operation between geo URIs.