[secdir] SECDIR review of draft-ietf-geopriv-geo-uri-04

["Laganier, Julien" <[e-mail]>]

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.

Document Abstract:

   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
   known.

   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.

--julien