A Uniform Resource Identifier for Geographic Locations ('geo' URI)
draft-ietf-geopriv-geo-uri-07

[Ballot discuss]
Why does a document defining the 'geo' URI scheme provide mappings to GML? It seems to me that such mappings belong in a separate document, because they have nothing to do with the URI definition.

[Ballot comment]
Authors emailed Graham Klyne directly and he just confirms that his Expert Review is done (approved).


Previously a DISCUSS from Lisa:

Similarly, is there a possible way to limit 'u' so that the URIs are more frequently comparable?  I'm making up stuff at this point, but lets say there's a few classes of devices that half roughly 1m uncertainty, 10m uncertainty and 100m uncertainty.  If those classes of devices used those values rather than an uncertainty of 7.4m or 14m, then u values would match up more frequently.

For example, geo:13.4125,103.8667;u=9 and geo:13.4125,103.8667;u=10 are completely different by the current rules. But if implementers were encouraged to prefer u=1, u=10 and u=100 over other values, then both implementers would choose u=10 as close enough, and the URIs would be equivalent.  Just add text that encourages those values (or other even better values, with the authors' greater domain knowledge).

Final point:  I found some excellent advice here:
http://nih.blogspot.com/2009/11/defining-new-uri-or-urn-scheme-properly.html
"Provide more examples of actual URIs or URNs than you think people will need. Along with an example, explain how that example would be assigned, derived, and if applicable, dereferenced."

[Ballot comment]
Authors emailed Graham Klyne directly and he just confirms that his Expert Review is done (approved).


Previously a DISCUSS from Lisa:

Similarly, is there a possible way to limit 'u' so that the URIs are more frequently comparable?  I'm making up stuff at this point, but lets say there's a few classes of devices that half roughly 1m uncertainty, 10m uncertainty and 100m uncertainty.  If those classes of devices used those values rather than an uncertainty of 7.4m or 14m, then u values would match up more frequently.

For example, geo:13.4125,103.8667;u=9 and geo:13.4125,103.8667;u=10 are completely different by the current rules. But if implementers were encouraged to prefer u=1, u=10 and u=100 over other values, then both implementers would choose u=10 as close enough, and the URIs would be equivalent.  Just add text that encourages those values (or other even better values, with the authors' greater domain knowledge).

[Ballot discuss]
This is a good document and I will be voting Yes once my issues (which are mostly minor) are resolved/discussed:

Taking over the DISCUSS from Lisa (slightly reworded):

Final point:  I found some excellent advice here:
http://nih.blogspot.com/2009/11/defining-new-uri-or-urn-scheme-properly.html
"Provide more examples of actual URIs or URNs than you think people will need. Along with an example, explain how that example would be assigned, derived, and if applicable, dereferenced."

At present, the spec only contains one minimal example of URIs.  URI schemes are often implemented by people who just scan examples and infer how to interpret them (or at best, read a couple paragraphs where they can't just guess) so it's important to include examples of optional parameters and of comparison.

[Ballot comment]
Authors emailed Graham Klyne directly and he just confirms that his Expert Review is done (approved).


Previously a DISCUSS from Lisa:

Similarly, is there a possible way to limit 'u' so that the URIs are more frequently comparable?  I'm making up stuff at this point, but lets say there's a few classes of devices that half roughly 1m uncertainty, 10m uncertainty and 100m uncertainty.  If those classes of devices used those values rather than an uncertainty of 7.4m or 14m, then u values would match up more frequently.

For example, geo:13.4125,103.8667;u=9 and geo:13.4125,103.8667;u=10 are completely different by the current rules. But if implementers were encouraged to prefer u=1, u=10 and u=100 over other values, then both implementers would choose u=10 as close enough, and the URIs would be equivalent.  Just add text that encourages those values (or other even better values, with the authors' greater domain knowledge).

[Ballot discuss]
This is a good document and I will be voting Yes once my issues (which are mostly minor) are resolved/discussed:

Taking over the DISCUSS from Lisa (slightly reworded):

The "/" character looks like it can be used in parameters.  We should check the URI spec but I believe that is not recommended -- "/" is supposed to be a path delimiter.

Final point:  I found some excellent advice here:
http://nih.blogspot.com/2009/11/defining-new-uri-or-urn-scheme-properly.html
"Provide more examples of actual URIs or URNs than you think people will need. Along with an example, explain how that example would be assigned, derived, and if applicable, dereferenced."

At present, the spec only contains one minimal example of URIs.  URI schemes are often implemented by people who just scan examples and infer how to interpret them (or at best, read a couple paragraphs where they can't just guess) so it's important to include examples of optional parameters and of comparison.

[Ballot comment]
Previously a DISCUSS from Lisa:

Similarly, is there a possible way to limit 'u' so that the URIs are more frequently comparable?  I'm making up stuff at this point, but lets say there's a few classes of devices that half roughly 1m uncertainty, 10m uncertainty and 100m uncertainty.  If those classes of devices used those values rather than an uncertainty of 7.4m or 14m, then u values would match up more frequently.

For example, geo:13.4125,103.8667;u=9 and geo:13.4125,103.8667;u=10 are completely different by the current rules. But if implementers were encouraged to prefer u=1, u=10 and u=100 over other values, then both implementers would choose u=10 as close enough, and the URIs would be equivalent.  Just add text that encourages those values (or other even better values, with the authors' greater domain knowledge).

[Ballot discuss]
This is a good document and I will be voting Yes once my issues (which are mostly minor) are resolved/discussed:

Taking over the DISCUSS from Lisa (slightly reworded):

I didn't find an expert review in email or in the document history.  Was one done?  RFC4395 requires expert review even for URI schemes registered in IETF consensus documents.  I believe it hasn't been done because there's no provisional entry for geo in the IANA schemes table.

The "/" character looks like it can be used in parameters.  We should check the URI spec but I believe that is not recommended -- "/" is supposed to be a path delimiter.

Final point:  I found some excellent advice here:
http://nih.blogspot.com/2009/11/defining-new-uri-or-urn-scheme-properly.html
"Provide more examples of actual URIs or URNs than you think people will need. Along with an example, explain how that example would be assigned, derived, and if applicable, dereferenced."

At present, the spec only contains one minimal example of URIs.  URI schemes are often implemented by people who just scan examples and infer how to interpret them (or at best, read a couple paragraphs where they can't just guess) so it's important to include examples of optional parameters and of comparison.

[Ballot discuss]
This is a good document and I will be voting Yes once my issues (which are mostly minor) are resolved/discussed:

Taking over the DISCUSS from Lisa (slightly reworded):

I didn't find an expert review in email or in the document history.  Was one done?  RFC4395 requires expert review even for URI schemes registered in IETF consensus documents.  I believe it hasn't been done because there's no provisional entry for geo in the IANA schemes table.


(I note that I definitely agree textual comparison is more likely to work and be realistically definable than any algorithm which involves mathematical operations.  It would be a rathole to try to define if two geographical points are "the same" or nearby; instead the previous and next comments focus on making text comparison work more reliably.)

Similarly, is there a possible way to limit 'u' so that the URIs are more frequently comparable?  I'm making up stuff at this point, but lets say there's a few classes of devices that half roughly 1m uncertainty, 10m uncertainty and 100m uncertainty.  If those classes of devices used those values rather than an uncertainty of 7.4m or 14m, then u values would match up more frequently.

For example, geo:13.4125,103.8667;u=9 and geo:13.4125,103.8667;u=10 are completely different by the current rules. But if implementers were encouraged to prefer u=1, u=10 and u=100 over other values, then both implementers would choose u=10 as close enough, and the URIs would be equivalent.  Just add text that encourages those values (or other even better values, with the authors' greater domain knowledge).

The "/" character looks like it can be used in parameters.  We should check the URI spec but I believe that is not recommended -- "/" is supposed to be a path delimiter.

Final point:  I found some excellent advice here:
http://nih.blogspot.com/2009/11/defining-new-uri-or-urn-scheme-properly.html
"Provide more examples of actual URIs or URNs than you think people will need. Along with an example, explain how that example would be assigned, derived, and if applicable, dereferenced."

At present, the spec only contains one minimal example of URIs.  URI schemes are often implemented by people who just scan examples and infer how to interpret them (or at best, read a couple paragraphs where they can't just guess) so it's important to include examples of optional parameters and of comparison.

[Ballot comment]
1) The URI registration template is missing the "Security considerations" section.

2)
            crslabel      = "wgs84" / labeltext

Just to double check: these are case-insensitive?

I am also agreeing with Robert's comment which is similar. Note that case-insensitivity affects how URIs are compared for equality.

3)
            pnum          = 1*DIGIT [ "." 1*DIGIT ]
            num          = [ "-" ] pnum

So you want "-0" to be valid?
If yes, please state that explicitly in the document.

4)
8.3.1.  Registry Contents

  o  Reference to the definition of the CRS itself, preferably as well
      known URNs (if available).

This sentence is not readable, especially the part after the comma.
Did you mean ", preferably together with known URNs (if available)"?

5)
9.2.  Location Privacy

  A 'geo' URI by itself is just an opaque reference to a physical
  location, expressed by a set of spatial oordinates.  This does not

typo: coordinates

6) 11.2.  Informative References

  [WGS84]    National Imagery and Mapping Agency, "Department of
              Defense World Geodetic System 1984, Third Edition",
              NIMA TR8350.2, January 2000.

This looks like a Normative Reference, but I can be convinced otherwise.

[Ballot discuss]
This is a good document and I will be voting Yes once my issues (which are mostly minor) are resolved/discussed:

1) 8.2.2.  Registration Policy

  The Registration Policy for 'geo' URI Parameters and their value
  definitions shall be "Specification Required, Designated Expert", as
  defined in [RFC5226].

Specification Required already implies Designated Expert.
I assume registrations through Designated Expert (without a specification) are not allowed?

2) 8.3.2.  Registration Policy

  The registration policy for the "'geo' URI 'crs' Parameter Values"
  Registry shall be "Specification Required, IESG Approval" as defined

Are "Specification Required" and "IESG Approval" two equal alternatives, or are both required at the same time?

---------------------------------------

Taking over the DISCUSS from Lisa (slightly reworded):

I didn't find an expert review in email or in the document history.  Was one done?  RFC4395 requires expert review even for URI schemes registered in IETF consensus documents.  I believe it hasn't been done because there's no provisional entry for geo in the IANA schemes table.

It seems that the ability to have different forms is a requirement to give flexibility.  However, that requirement weakens the ability of the URI to be textually compared to see if two people are at the same or nearby location.  Can the preference for WGS-84 be explained in those terms to implementers?  If implementers prefer WGS-84, then textual comparison will be possible more frequently.

Suggestion to address this:
This spec discourages use of alternate coordination systems in use cases where comparison is an important function.

(I note that I definitely agree textual comparison is more likely to work and be realistically definable than any algorithm which involves mathematical operations.  It would be a rathole to try to define if two geographical points are "the same" or nearby; instead the previous and next comments focus on making text comparison work more reliably.)

Similarly, is there a possible way to limit 'u' so that the URIs are more frequently comparable?  I'm making up stuff at this point, but lets say there's a few classes of devices that half roughly 1m uncertainty, 10m uncertainty and 100m uncertainty.  If those classes of devices used those values rather than an uncertainty of 7.4m or 14m, then u values would match up more frequently.

For example, geo:13.4125,103.8667;u=9 and geo:13.4125,103.8667;u=10 are completely different by the current rules. But if implementers were encouraged to prefer u=1, u=10 and u=100 over other values, then both implementers would choose u=10 as close enough, and the URIs would be equivalent.  Just add text that encourages those values (or other even better values, with the authors' greater domain knowledge).

The "/" character looks like it can be used in parameters.  We should check the URI spec but I believe that is not recommended -- "/" is supposed to be a path delimiter.

"Future specifications of additional parameters
  might allow the introduction of non-ASCII values."
--> It should be stated that these would have to be ASCII-encoded in some way.  GEO URI handling libraries should know up front what character ranges to expect, and the ABNF currently defines that as ASCII only.  The additional of an optional parameter with Unicode values needn't break that if the Unicode values are encoded in an appropriate ASCII encoding.

Final point:  I found some excellent advice here:
http://nih.blogspot.com/2009/11/defining-new-uri-or-urn-scheme-properly.html
"Provide more examples of actual URIs or URNs than you think people will need. Along with an example, explain how that example would be assigned, derived, and if applicable, dereferenced."

At present, the spec only contains one minimal example of URIs.  URI schemes are often implemented by people who just scan examples and infer how to interpret them (or at best, read a couple paragraphs where they can't just guess) so it's important to include examples of optional parameters and of comparison.

[Ballot discuss]
I didn't find an expert review in email or in the document history.  Was one done?  RFC4395 requires expert review even for URI schemes registered in IETF consensus documents.  I believe it hasn't been done because there's no provisional entry for geo in the IANA schemes table.

It seems that the ability to have different forms is a requirement to give flexibility.  However, that requirement weakens the ability of the URI to be textually compared to see if two people are at the same or nearby location.  Can the preference for WGS-84 be explained in those terms to implementers?  If implementers prefer WGS-84, then textual comparison will be possible more frequently. 

(I note that I definitely agree textual comparison is more likely to work and be realistically definable than any algorithm which involves mathematical operations.  It would be a rathole to try to define if two geographical points are "the same" or nearby; instead the previous and next comments focus on making text comparison work more reliably.)

Similarly, is there a possible way to limit 'u' so that the URIs are more frequently comparable?  I'm making up stuff at this point, but lets say there's a few classes of devices that half roughly 1m uncertainty, 10m uncertainty and 100m uncertainty.  If those classes of devices used those values rather than an uncertainty of 7.4m or 14m, then u values would match up more frequently.

For example, geo:13.4125,103.8667;u=9 and geo:13.4125,103.8667;u=10 are completely different by the current rules. But if implementers were encouraged to prefer u=1, u=10 and u=100 over other values, then both implementers would choose u=10 as close enough, and the URIs would be equivalent.  Just add text that encourages those values (or other even better values, with the authors' greater domain knowledge).

The "/" character looks like it can be used in parameters.  We should check the URI spec but I believe that is not recommended -- "/" is supposed to be a path delimiter.

"Future specifications of additional parameters
  might allow the introduction of non-ASCII values."
--> It should be stated that these would have to be ASCII-encoded in some way.  GEO URI handling libraries should know up front what character ranges to expect, and the ABNF currently defines that as ASCII only.  The additional of an optional parameter with Unicode values needn't break that if the Unicode values are encoded in an appropriate ASCII encoding.

Final point:  I found some excellent advice here:
http://nih.blogspot.com/2009/11/defining-new-uri-or-urn-scheme-properly.html
"Provide more examples of actual URIs or URNs than you think people will need. Along with an example, explain how that example would be assigned, derived, and if applicable, dereferenced."

At present, the spec only contains one minimal example of URIs.  URI schemes are often implemented by people who just scan examples and infer how to interpret them (or at best, read a couple paragraphs where they can't just guess) so it's important to include examples of optional parameters and of comparison.

[Ballot comment]
1) The URI registration template is missing the "Security considerations" section.

2)
            crslabel      = "wgs84" / labeltext

Just to double check: these are case-insensitive?

I am also agreeing with Robert's comment which is similar. Note that case-insensitivity affects how URIs are compared for equality.

3)
            pnum          = 1*DIGIT [ "." 1*DIGIT ]
            num          = [ "-" ] pnum

So you want "-0" to be valid?
If yes, please state that explicitly in the document.

4)
8.3.1.  Registry Contents

  o  Reference to the definition of the CRS itself, preferably as well
      known URNs (if available).

This sentence is not readable, especially the part after the comma.
Did you mean ", preferably together with known URNs (if available)"?

5)
9.2.  Location Privacy

  A 'geo' URI by itself is just an opaque reference to a physical
  location, expressed by a set of spatial oordinates.  This does not

typo: coordinates

6) 11.2.  Informative References

  [WGS84]    National Imagery and Mapping Agency, "Department of
              Defense World Geodetic System 1984, Third Edition",
              NIMA TR8350.2, January 2000.

This looks like a Normative Reference, but I can be convinced otherwise.

[Ballot discuss]
This is a good document and I will be voting Yes once my issues (which are mostly minor) are resolved/discussed:

1) 8.2.2.  Registration Policy

  The Registration Policy for 'geo' URI Parameters and their value
  definitions shall be "Specification Required, Designated Expert", as
  defined in [RFC5226].

Specification Required already implies Designated Expert.
I assume registrations through Designated Expert (without a specification) are not allowed?

2) 8.3.2.  Registration Policy

  The registration policy for the "'geo' URI 'crs' Parameter Values"
  Registry shall be "Specification Required, IESG Approval" as defined

Are "Specification Required" and "IESG Approval" two equal alternatives, or are both required at the same time?

[Ballot comment]
1) The URI registration template is missing the "Security considerations" section.

2)
            crslabel      = "wgs84" / labeltext

Just to double check: these are case-insensitive?

I am also agreeing with Robert's comment which is similar. Note that case-insensitivity affects how URIs are compared for equality.

3)
            pnum          = 1*DIGIT [ "." 1*DIGIT ]
            num          = [ "-" ] pnum

So you want "-0" to be valid?
If yes, please state that explicitly in the document.

4)
8.3.1.  Registry Contents

  o  Reference to the definition of the CRS itself, preferably as well
      known URNs (if available).

This sentence is not readable, especially the part after the comma.
Did you mean ", preferably together with known URNs (if available)"?

5)
9.2.  Location Privacy

  A 'geo' URI by itself is just an opaque reference to a physical
  location, expressed by a set of spatial oordinates.  This does not

typo: coordinates

6) 11.2.  Informative References

  [WGS84]    National Imagery and Mapping Agency, "Department of
              Defense World Geodetic System 1984, Third Edition",
              NIMA TR8350.2, January 2000.

This looks like a Normative Reference, but I can be convinced otherwise.

[Ballot discuss]
This is a good document and I will be voting Yes once my issues (which are mostly minor) are resolved/discussed:

1) 8.2.2.  Registration Policy

  The Registration Policy for 'geo' URI Parameters and their value
  definitions shall be "Specification Required, Designated Expert", as
  defined in [RFC5226].

Specification Required already implies Designated Expert.
I assume registrations through Designated Expert (without a specification) are not allowed?

2) 8.3.2.  Registration Policy

  The registration policy for the "'geo' URI 'crs' Parameter Values"
  Registry shall be "Specification Required, IESG Approval" as defined

Are "Specification Required" and "IESG Approval" two equal alternatives, or are both required at the same time?

[Ballot discuss]
I didn't find an expert review in email or in the document history.  Was one done?  RFC4395 requires expert review even for URI schemes registered in IETF consensus documents.  I believe it hasn't been done because there's no provisional entry for geo in the IANA schemes table.

It seems that the ability to have different forms is a requirement to give flexibility.  However, that requirement weakens the ability of the URI to be compared to see if two people are at the same or nearby location.  Can the preference for WGS-84 be explained in those terms to implementers?  If implementers prefer WGS-84, then comparison will be possible more frequently. 

Similarly, is there a possible way to limit 'u' so that the URIs are more frequently comparable?  I'm making up stuff at this point, but lets say there's a few classes of devices that half roughly 1m uncertainty, 10m uncertainty and 100m uncertainty.  If those classes of devices used those values rather than an uncertainty of 7.4m or 14m, then u values would match up more frequently.

The "/" looks like it can be used in parameters.  We should check the URI spec but I believe that is not recommended. 

"Future specifications of additional parameters
  might allow the introduction of non-ASCII values."
--> It should be stated that these would have to be ASCII-encoded in some way.  GEO URI handling libraries should know up front what character ranges to expect, and the ABNF currently defines that as ASCII only.  The additional of an optional parameter with Unicode values needn't break that if the Unicode values are encoded in an appropriate ASCII encoding.

Final point:  I found some excellent advice here:
http://nih.blogspot.com/2009/11/defining-new-uri-or-urn-scheme-properly.html
"Provide more examples of actual URIs or URNs than you think people will need. Along with an example, explain how that example would be assigned, derived, and if applicable, dereferenced."

At present, the spec only contains one minimal example of URIs.  URI schemes are often implemented by people who just scan examples and infer how to interpret them (or at best, read a couple paragraphs where they can't just guess) so it's important to include examples of optional parameters and of comparison.

[Ballot discuss]
I didn't find an expert review in email or in the document history.  Was one done?  RFC4395 requires expert review even for URI schemes registered in IETF consensus documents.  I believe it hasn't been done because there's no provisional entry for geo in the IANA schemes table.

[Ballot comment]
1) The URI registration template is missing the "Security considerations" section.

2)
            crslabel      = "wgs84" / labeltext

Just to double check: these are case-insensitive?

I am also agreeing with Robert's comment which is similar. Note that case-insensitivity affects how URIs are compared for equality.

3)
            pnum          = 1*DIGIT [ "." 1*DIGIT ]
            num          = [ "-" ] pnum

So you want "-0" to be valid?
If yes, please state that explicitly in the document.

4)
8.3.1.  Registry Contents

  o  Reference to the definition of the CRS itself, preferably as well
      known URNs (if available).

This sentence is not readable, especially the part after the comma.
Did you mean ", preferably together with known URNs (if available)"?

5)
9.2.  Location Privacy

  A 'geo' URI by itself is just an opaque reference to a physical
  location, expressed by a set of spatial oordinates.  This does not

typo: coordinates

[Ballot discuss]
This is a good document and I will be voting Yes once my issues (which are mostly minor) are resolved/discussed:

1) 8.2.2.  Registration Policy

  The Registration Policy for 'geo' URI Parameters and their value
  definitions shall be "Specification Required, Designated Expert", as
  defined in [RFC5226].

Specification Required already implies Designated Expert.
I assume registrations through Designated Expert (without a specification) are not allowed?

2) 8.3.2.  Registration Policy

  The registration policy for the "'geo' URI 'crs' Parameter Values"
  Registry shall be "Specification Required, IESG Approval" as defined

Are "Specification Required" and "IESG Approval" two equal alternatives, or are both required at the same time?

3) 11.2.  Informative References

  [WGS84]    National Imagery and Mapping Agency, "Department of
              Defense World Geodetic System 1984, Third Edition",
              NIMA TR8350.2, January 2000.

This looks like a Normative Reference.

[Ballot comment]
1) The URI registration template is missing the "Security considerations" section.

2)
            crslabel      = "wgs84" / labeltext

Just to double check: these are case-insensitive?

3)
            pnum          = 1*DIGIT [ "." 1*DIGIT ]
            num          = [ "-" ] pnum

So you want "-0" to be valid?
If yes, please state that explicitly in the document.

4)
8.3.1.  Registry Contents

  o  Reference to the definition of the CRS itself, preferably as well
      known URNs (if available).

This sentence is not readable, especially the part after the comma.
Did you mean ", preferably together with known URNs (if available)"?

5)
9.2.  Location Privacy

  A 'geo' URI by itself is just an opaque reference to a physical
  location, expressed by a set of spatial oordinates.  This does not

typo: coordinates

[Ballot discuss]
This is a good document and I will be voting Yes once my issues (which are mostly minor) are resolved/discussed:

1) 8.2.2.  Registration Policy

  The Registration Policy for 'geo' URI Parameters and their value
  definitions shall be "Specification Required, Designated Expert", as
  defined in [RFC5226].

Specification Required already implies Designated Expert.
I assume registrations through Designated Expert (without a specification) are not allowed?

2) 8.3.2.  Registration Policy

  The registration policy for the "'geo' URI 'crs' Parameter Values"
  Registry shall be "Specification Required, IESG Approval" as defined

Are "Specification Required" and "IESG Approval" two equal alternatives, or are both required at the same time?

3) 11.2.  Informative References

  [WGS84]    National Imagery and Mapping Agency, "Department of
              Defense World Geodetic System 1984, Third Edition",
              NIMA TR8350.2, January 2000.

This looks like a Normative Reference.

[Ballot discuss]
This is a GREAT document, and much needed. Thank
you for writing it!

I will ballot Yes, however, there was one small issue
that I wanted to draw your attention to first:

  Like other new URI schemes, the 'geo' URI requires support in client
  applications.  Users of applications which are not aware of the 'geo'
  scheme are likely not able to make direct use of the information in
  the URI.

This ignores IMO a very important client application: passing Geo
URIs around from one place to another. A client need not understand
the format to do it.

[Ballot discuss]
Section 5 states that just one operation is defined: location dereference.  However, section 3.4.4
describes URI comparison rules.  Perhaps I am missing something, but that seems like two
operations to me.  Perhaps I misunderstand "operation" in this context?

(I will clear on the call regardless of how the sponsoring AD wants to resolve this.)

[Ballot discuss]
Section 3.4.4., paragraph 1:
>    Two 'geo' URIs are equal when they use the same CRS, and ,
>    ,  and 'u' value are mathematically identical
>    (including absent  meaning undefined 'u' value).

  DISCUSS: According to this definition, two locations with the same
  coord-a, coord-b and coord-c but different uncertainty parameters will
  NOT be identical. Isn't that counter-intuitive? (I'm guessing that the
  uncertainty parameter is expected to be set based on the positioning
  method.) A more intuitive definition of equivalence would declare two
  locations equal when their  uncertainty spaces intersect.


Section 3.4.4., paragraph 5:

>    A URI with undefined (missing)  (altitude) value MUST NOT be
>    considered equal to a URI containing a , even if the
>    remaining , , and their 'u' values are equivalent.

  DISCUSS: What if the given coord-c is identical to the altitude of the
  Earth's physical location at the given latitude and longitude; are the
  two identical then? (They should be according to the interpretation
  rules in Section 3.4.5.)


Section 9.1., paragraph 1:

>    The URI syntax (Section 3.3) makes it possible to construct 'geo'
>    URIs which don't identify a valid location.  Applications MUST NOT
>    use URIs with such values, and SHOULD warn the user when such URIs
>    are encountered.

  DISCUSS: Then please either tighten the ABNF so that it does not allow
  to express invalid locations (preferred), or otherwise specify which
  locations are valid and which are not.

[Ballot comment]
crslabel      = "wgs84" / labeltext

Just to double check: these are case-insensitive?

            pnum          = 1*DIGIT [ "." 1*DIGIT ]
            num          = [ "-" ] pnum

So you want "-0" to be valid?

8.2.2.  Registration Policy

  The Registration Policy for 'geo' URI Parameters and their value
  definitions shall be "Specification Required, Designated Expert", as
  defined in [RFC5226].

Specification Required already implies Designated Expert.
I assume registrations through Designated Expert (without a specification) are not allowed?


8.3.1.  Registry Contents

  o  Reference to the definition of the CRS itself, preferably as well
      known URNs (if available).

This sentence is not readabl, especially the part after the comma.
Did you mean ", preferably together with known URNs (if available)"?

9.2.  Location Privacy

  A 'geo' URI by itself is just an opaque reference to a physical
  location, expressed by a set of spatial oordinates.  This does not

typo: coordinates

[Ballot discuss]
This is a good document and I will be voting Yes once my issues (which are mostly minor) are resolved/discussed:

1) The URI registration template is missing the "Security considerations" section.

2) 8.3.2.  Registration Policy

  The registration policy for the "'geo' URI 'crs' Parameter Values"
  Registry shall be "Specification Required, IESG Approval" as defined

Are "Specification Required" and "IESG Approval" two equal alternatives, or are both required at the same time?

3) 11.2.  Informative References

  [WGS84]    National Imagery and Mapping Agency, "Department of
              Defense World Geodetic System 1984, Third Edition",
              NIMA TR8350.2, January 2000.

This looks like a Normative Reference.

The GEOPRIV working group requests publication of
draft-ietf-geopriv-geo-uri-03 as Proposed Standard.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

The Document Shepherd for this document is Richard Barnes. The Shepherd
has personally reviewed this version of the document, and believes it is
ready for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

This document has been the subject of a thorough and constructive
discussion within the GEOPRIV working group, which included input from
the Open Geospatial Consortium. I have no concerns about the level of
review this document has received.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

I do not believe that this document requires any special review.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

I have no special concerns about this document. There have been no IPR
disclosures related to the document.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is strong consensus in the working group that this document is a
useful and usable way to transmit location information.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

I am not aware of any extreme discontent or potential appeals related to
this document.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

I have verified that the the document satisfies all ID nits. This
document has been reviewed by the URI-Review list and incorporated their
feedback.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

References are split into normative and informative. All normative
references are RFCs.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The IANA considerations section exists, and provides instructions for
IANA to (1) add the "geo" URI scheme to the URI scheme registry, and (2)
create a new registry for "geo" URI parameters.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

The document contains an ABNF definition for the "geo" URI format, and
representative XML fragments. I have validated the ABNF using the
APPAREA online ABNF validator (). The
XML fragments are not suitable for automated validation, but I have
reviewed them manually for correctness.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

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.

Working Group Summary

There is strong consensus in the working group that this document is a
useful and user-friendly way to transmit location information.

Document Quality

The document has been reviewed by key participants from the GEOPRIV and
OGC communities.