Skip to main content

A Uniform Resource Identifier for Geographic Locations ('geo' URI)
RFC 5870

Revision differences

Document history

Date Rev. By Action
2022-11-02
07 (System) Received changes through RFC Editor sync (added Errata tag, added Verified Errata tag)
2015-10-14
07 (System) Notify list changed from geopriv-chairs@ietf.org, draft-ietf-geopriv-geo-uri@ietf.org to (None)
2012-08-22
07 (System) post-migration administrative database adjustment to the Yes position for Robert Sparks
2012-08-22
07 (System) post-migration administrative database adjustment to the Yes position for Peter Saint-Andre
2012-08-22
07 (System) post-migration administrative database adjustment to the Yes position for Jari Arkko
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Tim Polk
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Lars Eggert
2010-06-07
07 Cindy Morgan State Changes to RFC Published from RFC Ed Queue by Cindy Morgan
2010-06-07
07 Cindy Morgan [Note]: 'RFC 5870' added by Cindy Morgan
2010-06-06
07 (System) RFC published
2010-04-21
07 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2010-04-21
07 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2010-04-21
07 (System) IANA Action state changed to In Progress from Waiting on Authors
2010-04-20
07 (System) IANA Action state changed to Waiting on Authors from In Progress
2010-04-19
07 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2010-04-16
07 (System) IANA Action state changed to In Progress
2010-04-16
07 Amy Vezza IESG state changed to Approved-announcement sent
2010-04-16
07 Amy Vezza IESG has approved the document
2010-04-16
07 Amy Vezza Closed "Approve" ballot
2010-04-15
07 Peter Saint-Andre [Ballot Position Update] Position for Peter Saint-Andre has been changed to Yes from Discuss by Peter Saint-Andre
2010-04-15
07 Gonzalo Camarillo [Ballot comment]
The acronym WGS should be expanded on its first use in the Abstract.
2010-04-15
07 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded by Gonzalo Camarillo
2010-04-14
07 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert
2010-04-14
07 Peter Saint-Andre [Ballot comment]
The document contains numerous grammatical and typographical errors.
2010-04-14
07 Peter Saint-Andre
[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 …
[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.
2010-04-14
07 Peter Saint-Andre [Ballot Position Update] New position, Discuss, has been recorded by Peter Saint-Andre
2010-04-14
07 (System) New version available: draft-ietf-geopriv-geo-uri-07.txt
2010-04-13
07 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to Yes from Discuss by Alexey Melnikov
2010-04-13
07 Alexey Melnikov
[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 …
[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."
2010-04-13
07 Alexey Melnikov [Ballot discuss]
2010-04-09
07 Robert Sparks Responsible AD has been changed to Robert Sparks from Cullen Jennings
2010-04-09
07 Robert Sparks [Note]: 'Richard Barnes (rbarnes@bbn.com) is the document shepherd.
' added by Robert Sparks
2010-04-09
07 Robert Sparks [Ballot Position Update] Position for Robert Sparks has been changed to Yes from Discuss by Robert Sparks
2010-04-09
06 (System) New version available: draft-ietf-geopriv-geo-uri-06.txt
2010-03-17
07 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to Yes from Discuss by Jari Arkko
2010-03-12
07 Alexey Melnikov
[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 …
[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).
2010-03-12
07 Alexey Melnikov
[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 …
[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.
2010-03-12
07 Alexey Melnikov
[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 …
[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).
2010-03-12
07 Alexey Melnikov
[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 …
[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.
2010-03-07
07 Alexey Melnikov
[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 …
[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).
2010-03-07
07 Alexey Melnikov
[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 …
[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.
2010-03-07
07 Alexey Melnikov [Ballot comment]
2010-03-07
07 Alexey Melnikov
[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 …
[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.
2010-03-06
07 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-03-06
05 (System) New version available: draft-ietf-geopriv-geo-uri-05.txt
2010-02-25
07 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk
2010-02-25
07 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk
2010-02-19
07 (System) Removed from agenda for telechat - 2010-02-18
2010-02-18
07 Cindy Morgan State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan
2010-02-18
07 Lisa Dusseault [Ballot comment]
I have handed my DISCUSS issues over to Alexey
2010-02-18
07 Lisa Dusseault [Ballot discuss]
2010-02-18
07 Lisa Dusseault [Ballot Position Update] Position for Lisa Dusseault has been changed to No Objection from Discuss by Lisa Dusseault
2010-02-18
07 Alexey Melnikov
[Ballot comment]
1) The URI registration template is missing the "Security considerations" section.

2)
            crslabel      = "wgs84" …
[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.
2010-02-18
07 Alexey Melnikov
[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 …
[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.
2010-02-18
07 Lisa Dusseault
[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 …
[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.
2010-02-18
07 Alexey Melnikov
[Ballot comment]
1) The URI registration template is missing the "Security considerations" section.

2)
            crslabel      = "wgs84" …
[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.
2010-02-18
07 Alexey Melnikov
[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 …
[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?
2010-02-18
07 Robert Sparks [Ballot comment]
Please add an explicit statement on whether case is sensitive when comparing parameter names and values.
2010-02-18
07 Robert Sparks [Ballot discuss]
The document is currently silent on whether unknown parameters are included in URI comparisons. (Please do not decide to ignore them).
2010-02-18
07 Alexey Melnikov
[Ballot comment]
1) The URI registration template is missing the "Security considerations" section.

2)
            crslabel      = "wgs84" …
[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.
2010-02-18
07 Alexey Melnikov
[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 …
[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?
2010-02-18
07 Lisa Dusseault
[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 …
[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.
2010-02-18
07 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2010-02-18
07 Lisa Dusseault
[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 …
[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.
2010-02-18
07 Lisa Dusseault [Ballot Position Update] New position, Discuss, has been recorded by Lisa Dusseault
2010-02-18
07 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel
2010-02-18
07 Alexey Melnikov
[Ballot comment]
1) The URI registration template is missing the "Security considerations" section.

2)
            crslabel      = "wgs84" …
[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
2010-02-18
07 Alexey Melnikov
[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 …
[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.
2010-02-18
07 Alexey Melnikov
[Ballot comment]
1) The URI registration template is missing the "Security considerations" section.

2)
            crslabel      = "wgs84" …
[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
2010-02-18
07 Alexey Melnikov
[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 …
[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.
2010-02-18
07 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2010-02-18
07 Jari Arkko
[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 …
[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.
2010-02-18
07 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko
2010-02-17
07 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms
2010-02-16
07 Tim Polk
[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, …
[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.)
2010-02-16
07 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk
2010-02-16
07 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2010-02-16
07 Robert Sparks [Ballot Position Update] Position for Robert Sparks has been changed to Discuss from Yes by Robert Sparks
2010-02-16
07 Robert Sparks [Ballot comment]
Please add an explicit statement on whether case is sensitive when comparing parameter names and values.
2010-02-16
07 Robert Sparks [Ballot Position Update] New position, Yes, has been recorded by Robert Sparks
2010-02-16
07 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2010-02-16
07 Pasi Eronen [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen
2010-02-16
07 Lars Eggert
[Ballot discuss]
Section 3.4.4., paragraph 1:
>    Two 'geo' URIs are equal when they use the same CRS, and ,
>    ,  and …
[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.
2010-02-16
07 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert
2010-02-14
07 Alexey Melnikov
[Ballot comment]
crslabel      = "wgs84" / labeltext

Just to double check: these are case-insensitive?

            pnum      …
[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
2010-02-14
07 Alexey Melnikov
[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 …
[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.
2010-02-14
07 Alexey Melnikov [Ballot Position Update] New position, Discuss, has been recorded by Alexey Melnikov
2010-02-09
07 Cullen Jennings [Note]: 'Richard Barnes (rbarnes@bbn.com) is the document shepherd.
' added by Cullen Jennings
2010-02-09
07 Cullen Jennings Placed on agenda for telechat - 2010-02-18 by Cullen Jennings
2010-02-09
07 Cullen Jennings State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Cullen Jennings
2010-02-09
07 Cullen Jennings [Ballot Position Update] New position, Yes, has been recorded for Cullen Jennings
2010-02-09
07 Cullen Jennings Ballot has been issued by Cullen Jennings
2010-02-09
07 Cullen Jennings Created "Approve" ballot
2009-12-18
07 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2009-12-09
07 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Julien Laganier.
2009-12-04
07 Amy Vezza Last call sent
2009-12-04
07 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2009-12-03
07 Samuel Weiler Request for Last Call review by SECDIR is assigned to Julien Laganier
2009-12-03
07 Samuel Weiler Request for Last Call review by SECDIR is assigned to Julien Laganier
2009-11-30
07 Cullen Jennings Last Call was requested by Cullen Jennings
2009-11-30
07 Cullen Jennings State Changes to Last Call Requested from AD Evaluation::AD Followup by Cullen Jennings
2009-11-30
07 (System) Ballot writeup text was added
2009-11-30
07 (System) Last call text was added
2009-11-30
07 (System) Ballot approval text was added
2009-11-09
07 (System) Sub state has been changed to AD Follow up from New Id Needed
2009-11-09
04 (System) New version available: draft-ietf-geopriv-geo-uri-04.txt
2009-09-30
07 Cullen Jennings State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Cullen Jennings
2009-09-30
07 Cullen Jennings [Note]: 'Richard Barnes (rbarnes@bbn.com) is the document shepherd.
Sent email Sept 30' added by Cullen Jennings
2009-09-30
07 Cullen Jennings State Changes to AD Evaluation from Publication Requested by Cullen Jennings
2009-09-28
07 Amy Vezza
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 …
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.
2009-09-28
07 Amy Vezza Draft Added by Amy Vezza in state Publication Requested
2009-09-28
07 Amy Vezza [Note]: 'Richard Barnes (rbarnes@bbn.com) is the document shepherd.' added by Amy Vezza
2009-09-21
03 (System) New version available: draft-ietf-geopriv-geo-uri-03.txt
2009-09-01
02 (System) New version available: draft-ietf-geopriv-geo-uri-02.txt
2009-07-03
01 (System) New version available: draft-ietf-geopriv-geo-uri-01.txt
2009-06-02
00 (System) New version available: draft-ietf-geopriv-geo-uri-00.txt