draft-ietf-geopriv-geo-uri-04.txt   draft-ietf-geopriv-geo-uri-05.txt 
GEOPRIV -- Geographic A. Mayrhofer GEOPRIV -- Geographic A. Mayrhofer
Location/Privacy Working Group nic.at Location/Privacy Working Group IPCom
Internet-Draft C. Spanring Internet-Draft C. Spanring
Expires: May 13, 2010 November 09, 2009 Expires: September 7, 2010 March 06, 2010
A Uniform Resource Identifier for Geographic Locations ('geo' URI) A Uniform Resource Identifier for Geographic Locations ('geo' URI)
draft-ietf-geopriv-geo-uri-04 draft-ietf-geopriv-geo-uri-05
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.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 13, 2010. This Internet-Draft will expire on September 7, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
This document specifies a Uniform Resource Identifier (URI) for This document may contain material from IETF Documents or IETF
geographic locations using the 'geo' scheme name. A 'geo' URI Contributions published or made publicly available before November
identifies a physical location in a two- or three-dimensional 10, 2008. The person(s) controlling the copyright in some of this
coordinate reference system in a compact, simple, human-readable, and material may not have granted the IETF Trust the right to allow
protocol-independent way. The default coordinate reference system modifications of such material outside the IETF Standards Process.
used is WGS-84. Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. IANA Registration of 'geo' URI Scheme . . . . . . . . . . . . 6 3. IANA Registration of 'geo' URI Scheme . . . . . . . . . . . . 6
3.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . . 6 3.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . . 6
3.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 6 3.3. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 6
3.4. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 7 3.4. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 7
3.4.1. Coordinate Reference System Identification . . . . . . 7 3.4.1. Coordinate Reference System Identification . . . . . . 7
3.4.2. Component Description for WGS-84 . . . . . . . . . . . 7 3.4.2. Component Description for WGS-84 . . . . . . . . . . . 8
3.4.3. Location Uncertainty . . . . . . . . . . . . . . . . . 8 3.4.3. Location Uncertainty . . . . . . . . . . . . . . . . . 8
3.4.4. URI Comparison . . . . . . . . . . . . . . . . . . . . 8 3.4.4. URI Comparison . . . . . . . . . . . . . . . . . . . . 9
3.4.5. Interpretation of Undefined Altitude . . . . . . . . . 9 3.4.5. Interpretation of Undefined Altitude . . . . . . . . . 9
3.5. Encoding Considerations . . . . . . . . . . . . . . . . . 9 3.5. Encoding Considerations . . . . . . . . . . . . . . . . . 9
3.6. Applications/Protocols that use this URI Scheme . . . . . 9 3.6. Applications/Protocols that use this URI Scheme . . . . . 10
3.7. Interopability Considerations . . . . . . . . . . . . . . 10 3.7. Interopability Considerations . . . . . . . . . . . . . . 10
3.8. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.8. Security Considerations . . . . . . . . . . . . . . . . . 10
3.9. Author/Change controller . . . . . . . . . . . . . . . . . 10 3.9. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.10. References . . . . . . . . . . . . . . . . . . . . . . . . 10 3.10. Author/Change controller . . . . . . . . . . . . . . . . . 11
3.11. References . . . . . . . . . . . . . . . . . . . . . . . . 11
4. 'geo' URI Parameters Registry . . . . . . . . . . . . . . . . 10 4. 'geo' URI Parameters Registry . . . . . . . . . . . . . . . . 11
5. URI Operations . . . . . . . . . . . . . . . . . . . . . . . . 11 5. URI Operations . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Use Cases and Examples . . . . . . . . . . . . . . . . . . . . 12 6. Use Cases and Examples . . . . . . . . . . . . . . . . . . . . 12
6.1. Plain 'geo' URI Example . . . . . . . . . . . . . . . . . 12 6.1. Plain 'geo' URI Example . . . . . . . . . . . . . . . . . 12
6.2. Hyperlink . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Hyperlink . . . . . . . . . . . . . . . . . . . . . . . . 13
6.3. 'geo' URI in 2-dimensional barcode . . . . . . . . . . . . 13 6.3. 'geo' URI in 2-dimensional barcode . . . . . . . . . . . . 13
7. GML Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. GML Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. 2D GML 'Point' . . . . . . . . . . . . . . . . . . . . . . 14 7.1. 2D GML 'Point' . . . . . . . . . . . . . . . . . . . . . . 14
7.2. 3D GML 'Point' . . . . . . . . . . . . . . . . . . . . . . 14 7.2. 3D GML 'Point' . . . . . . . . . . . . . . . . . . . . . . 14
7.3. GML 'Circle' . . . . . . . . . . . . . . . . . . . . . . . 14 7.3. GML 'Circle' . . . . . . . . . . . . . . . . . . . . . . . 15
7.4. GML 'Sphere' . . . . . . . . . . . . . . . . . . . . . . . 15 7.4. GML 'Sphere' . . . . . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8.1. 'geo' URI Scheme . . . . . . . . . . . . . . . . . . . . . 15 8.1. 'geo' URI Scheme . . . . . . . . . . . . . . . . . . . . . 16
8.2. URI Parameter Registry . . . . . . . . . . . . . . . . . . 16 8.2. URI Parameter Registry . . . . . . . . . . . . . . . . . . 16
8.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 16 8.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 16
8.2.2. Registration Policy . . . . . . . . . . . . . . . . . 16 8.2.2. Registration Policy . . . . . . . . . . . . . . . . . 17
8.3. Sub-Registry for 'crs' Parameter . . . . . . . . . . . . . 16 8.3. Sub-Registry for 'crs' Parameter . . . . . . . . . . . . . 17
8.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 17 8.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 17
8.3.2. Registration Policy . . . . . . . . . . . . . . . . . 17 8.3.2. Registration Policy . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9.1. Invalid Locations . . . . . . . . . . . . . . . . . . . . 17 9.1. Invalid Locations . . . . . . . . . . . . . . . . . . . . 18
9.2. Location Privacy . . . . . . . . . . . . . . . . . . . . . 18 9.2. Location Privacy . . . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 19 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
An increasing number of Internet protocols and data formats are An increasing number of Internet protocols and data formats are
extended by specifications for adding spatial (geographic) location. extended by specifications for adding spatial (geographic) location.
In most cases, latitude as well as longitude of simple points are In most cases, latitude as well as longitude of simple points are
added as new attributes to existing data structures. However, all added as new attributes to existing data structures. However, all
those methods are very specific to a certain data format or protocol, those methods are very specific to a certain data format or protocol,
and don't provide a protocol-independent, compact and generic way to and don't provide a protocol-independent, compact and generic way to
refer to a physical geographic location. refer to a physical geographic location.
skipping to change at page 5, line 12 skipping to change at page 6, line 12
The optional 'crs' URI parameter described below may be used by The optional 'crs' URI parameter described below may be used by
future specifications to define the use of CRSes other than WGS-84. future specifications to define the use of CRSes other than WGS-84.
This is primarily intended to cope with the case of another CRS This is primarily intended to cope with the case of another CRS
replacing WGS-84 as the predominantly used one, rather than allowing replacing WGS-84 as the predominantly used one, rather than allowing
the arbitrary use of thousands of CRSes for the URI (which would the arbitrary use of thousands of CRSes for the URI (which would
clearly affect interopability). The definition of 'crs' values clearly affect interopability). The definition of 'crs' values
beyond the default of "wgs84" is therefore out of scope of this beyond the default of "wgs84" is therefore out of scope of this
document. document.
This spec discourages use of alternate CRSes in use cases where
comparison is an important function.
Note: The choice of WGS-84 as the default CRS is based on the Note: The choice of WGS-84 as the default CRS is based on the
widespread availability of Global Positioning System (GPS) devices, widespread availability of Global Positioning System (GPS) devices,
which use the WGS-84 reference system. It is anticipated that such which use the WGS-84 reference system. It is anticipated that such
devices will serve as one of the primary data sources for authoring devices will serve as one of the primary data sources for authoring
'geo' URIs, hence the adoption of the native GPS reference system for 'geo' URIs, hence the adoption of the native GPS reference system for
the URI scheme. Also, many other data formats for representing the URI scheme. Also, many other data formats for representing
geographic locations use the WGS-84 reference system, which makes geographic locations use the WGS-84 reference system, which makes
transposing from and to such data formats less error prone (no re- transposing from and to such data formats less error prone (no re-
projection involved). It is also believed that the burden of projection involved). It is also believed that the burden of
potentially required spatial transformations should be put on the potentially required spatial transformations should be put on the
skipping to change at page 6, line 49 skipping to change at page 7, line 49
pvalue = 1*paramchar pvalue = 1*paramchar
paramchar = p-unreserved / unreserved / pct-encoded paramchar = p-unreserved / unreserved / pct-encoded
labeltext = 1*( alphanum / "-" ) labeltext = 1*( alphanum / "-" )
pnum = 1*DIGIT [ "." 1*DIGIT ] pnum = 1*DIGIT [ "." 1*DIGIT ]
num = [ "-" ] pnum num = [ "-" ] pnum
unreserved = alphanum / mark unreserved = alphanum / mark
mark = "-" / "_" / "." / "!" / "~" / "*" / mark = "-" / "_" / "." / "!" / "~" / "*" /
"'" / "(" / ")" "'" / "(" / ")"
pct-encoded = "%" HEXDIG HEXDIG pct-encoded = "%" HEXDIG HEXDIG
p-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$" p-unreserved = "[" / "]" / ":" / "&" / "+" / "$"
alphanum = ALPHA / DIGIT alphanum = ALPHA / DIGIT
Both 'crs' and 'u' parameters MUST NOT appear more than once each. Parameter names are case insensitive, use of the lowercase
representation is PREFERRED. Case sensitivity of non-numeric
parameter values MUST be described in the specification of the
respective parameter. For the 'crs' parameter, values are case
insensitive, and lowercase is PREFERRED.
Both 'crs' and 'u' parameters MUST NOT appear more than once each.
The 'crs' and 'u' parameters MUST be given before any other The 'crs' and 'u' parameters MUST be given before any other
parameters that may be defined in future extensions. The 'crs' parameters that may be defined in future extensions. The 'crs'
parameter MUST be given first if both 'crs' and 'u' are used. The parameter MUST be given first if both 'crs' and 'u' are used. The
definition of other parameters, and <crslabel> values beyond the definition of other parameters, and <crslabel> values beyond the
default value of "wgs84" is out of scope of this document. default value of "wgs84" is out of scope of this document.
Section 8.2 discusses the IANA registration of such additional Section 8.2 discusses the IANA registration of such additional
parameters and values. parameters and values.
The value of "-0" for <num> is allowed, and identical to "0".
In case the URI identifies a location in the default CRS of WGS-84, In case the URI identifies a location in the default CRS of WGS-84,
the <coordinates> sub-components are further restricted as follows: the <coordinates> sub-components are further restricted as follows:
coord-a = latitude coord-a = latitude
coord-b = longitude coord-b = longitude
coord-c = altitude coord-c = altitude
latitude = [ "-" ] 1*2DIGIT [ "." 1*DIGIT ] latitude = [ "-" ] 1*2DIGIT [ "." 1*DIGIT ]
longitude = [ "-" ] 1*3DIGIT [ "." 1*DIGIT ] longitude = [ "-" ] 1*3DIGIT [ "." 1*DIGIT ]
altitude = [ "-" ] 1*DIGIT [ "." 1*DIGIT ] altitude = [ "-" ] 1*DIGIT [ "." 1*DIGIT ]
skipping to change at page 8, line 52 skipping to change at page 10, line 12
Note: The number of digits of the values in <coordinates> MUST NOT be Note: The number of digits of the values in <coordinates> MUST NOT be
interpreted as an indication to uncertainty. interpreted as an indication to uncertainty.
3.4.4. URI Comparison 3.4.4. URI Comparison
Two 'geo' URIs are equal when they use the same CRS, and <coord-a>, Two 'geo' URIs are equal when they use the same CRS, and <coord-a>,
<coord-b>, <coord-c> and 'u' value are mathematically identical <coord-b>, <coord-c> and 'u' value are mathematically identical
(including absent <uval> meaning undefined 'u' value). (including absent <uval> meaning undefined 'u' value).
If other parameters are contained in the URIs, the comparison
operation MUST be extended as described in the specification of the
respective parameter. Unknown parameters MUST NOT be ignored.
Two URIs use the same CRS if both have the 'crs' parameter omitted, Two URIs use the same CRS if both have the 'crs' parameter omitted,
or both have the same <crslabel>, or one has the 'crs' parameter or both have the same <crslabel>, or one has the 'crs' parameter
omitted while the other URI specifies the default CRS explicitely omitted while the other URI specifies the default CRS explicitely
with a <crslabel> value of "wgs84". with a <crslabel> value of "wgs84".
For the default CRS of WGS-84, the following definitions apply in For the default CRS of WGS-84, the following definitions apply in
addition: addition:
o Where <latitude> of a 'geo' URI is set to either 90 or -90 o Where <latitude> of a 'geo' URI is set to either 90 or -90
degrees, <longitude> MUST be ignored in comparison operations degrees, <longitude> MUST be ignored in comparison operations
("poles case"). ("poles case").
skipping to change at page 9, line 46 skipping to change at page 11, line 11
It is RECOMMENDED that for readability the contents of <coord-a>, It is RECOMMENDED that for readability the contents of <coord-a>,
<coord-b> and <coord-c> as well as <crslabel> and <uval> are never <coord-b> and <coord-c> as well as <crslabel> and <uval> are never
percent-encoded. percent-encoded.
Regarding internationalization, the currently specified components do Regarding internationalization, the currently specified components do
allow for ASCII characters exclusively, and therefore don't require allow for ASCII characters exclusively, and therefore don't require
internationalization. Future specifications of additional parameters internationalization. Future specifications of additional parameters
might allow the introduction of non-ASCII values. Such might allow the introduction of non-ASCII values. Such
specifications MUST describe internationalization considerations for specifications MUST describe internationalization considerations for
those parameters and their values. those parameters and their values, and MUST require percent-encoding
of non-ASCII values.
3.6. Applications/Protocols that use this URI Scheme 3.6. Applications/Protocols that use this URI Scheme
As many other URI scheme definitions, the 'geo' URI provides resource As many other URI scheme definitions, the 'geo' URI provides resource
identification independent of a specific application or protocol. identification independent of a specific application or protocol.
Examples of potential protocol mappings and use cases can be found in Examples of potential protocol mappings and use cases can be found in
Section 6. Section 6.
3.7. Interopability Considerations 3.7. Interopability Considerations
Like other new URI schemes, the 'geo' URI requires support in client Like other new URI schemes, the 'geo' URI requires support in client
applications. Users of applications which are not aware of the 'geo' applications. Users of applications which are not aware of the 'geo'
scheme are likely not able to make direct use of the information in scheme are likely not able to make direct use of the information in
the URI. However, the simple structure of the 'geo' URI would allow the URI. However, a client can make indirect use by passing around
'geo' URIs even without understanding the format and semantics of the
scheme. Additionally, the simple structure of 'geo' URIs would allow
even manual dereference by humans. even manual dereference by humans.
Clients MUST NOT attempt to dereference 'geo' URIs given in an CRS Clients MUST NOT attempt to dereference 'geo' URIs given in an CRS
that is unknown to the client, because doing so would produce that is unknown to the client, because doing so would produce
entirely bogus results. entirely bogus results.
Authors of 'geo' URIs should carefully check that coordinate Authors of 'geo' URIs should carefully check that coordinate
components are set in the right CRS and in the specified order, since components are set in the right CRS and in the specified order, since
wrong order of those components (or use of coordinates in a different wrong order of those components (or use of coordinates in a different
CRS without transformation) are commonly observed mistakes producing CRS without transformation) are commonly observed mistakes producing
completely bogus locations. completely bogus locations.
The number of digits in the <coordinates> values MUST NOT be The number of digits in the <coordinates> values MUST NOT be
interpreted as an indication to a certain level of accuracy or interpreted as an indication to a certain level of accuracy or
uncertainty. uncertainty.
3.8. Contact 3.8. Security Considerations
Alexander Mayrhofer <axelm@nic.at>, <http://geouri.org/> See Section 9 of [insert reference to this document]
3.9. Contact
Alexander Mayrhofer <axelm@ipcom.at>, <http://geouri.org/>
Christian Spanring <christian@spanring.eu> Christian Spanring <christian@spanring.eu>
3.9. Author/Change controller 3.10. Author/Change controller
The 'geo' URI scheme is registered under the IETF part of the URI The 'geo' URI scheme is registered under the IETF part of the URI
tree. As such, change control is up to the IETF. tree. As such, change control is up to the IETF.
3.10. References 3.11. References
RFC XXXX [change to RFC number once assigned] RFC XXXX [change to RFC number once assigned]
4. 'geo' URI Parameters Registry 4. 'geo' URI Parameters Registry
This specification creates a new IANA Registry named "'geo' URI This specification creates a new IANA Registry named "'geo' URI
Parameters Registry" for the <parameter> component of the URI. Parameters Registry" for the <parameter> component of the URI.
Parameters for the 'geo' URI and values for these parameters MUST be Parameters for the 'geo' URI and values for these parameters MUST be
registered with IANA to prevent namespace collisions, and provide registered with IANA to prevent namespace collisions, and provide
interopability. interopability.
skipping to change at page 16, line 44 skipping to change at page 18, line 17
Parameter Name Value Restriction Reference(s) Parameter Name Value Restriction Reference(s)
---------------------------------------------------------- ----------------------------------------------------------
crs Predefined [RFCxxxx] crs Predefined [RFCxxxx]
u Constrained [RFCxxxx] u Constrained [RFCxxxx]
[Note to RFC Editor: Replace RFCxxxx with reference to this document] [Note to RFC Editor: Replace RFCxxxx with reference to this document]
8.2.2. Registration Policy 8.2.2. Registration Policy
The Registration Policy for 'geo' URI Parameters and their value The Registration Policy for 'geo' URI Parameters and their value
definitions shall be "Specification Required, Designated Expert", as definitions shall be "Specification Required" (which implies
defined in [RFC5226]. "Designated Expert"), as defined in [RFC5226].
8.3. Sub-Registry for 'crs' Parameter 8.3. Sub-Registry for 'crs' Parameter
This document creates a new IANA Sub-registry named "'geo' URI 'crs' This document creates a new IANA Sub-registry named "'geo' URI 'crs'
Parameter Values", based on the Registry specified in Section 8.2 and Parameter Values", based on the Registry specified in Section 8.2 and
the information in this section and Section 4. The syntax of the the information in this section and Section 4. The syntax of the
'crs' parameter is constrained by the ABNF given in Section 3.3. 'crs' parameter is constrained by the ABNF given in Section 3.3.
8.3.1. Registry Contents 8.3.1. Registry Contents
When registering a new value for the 'crs' parameter, the following When registering a new value for the 'crs' parameter, the following
information MUST be provided: information MUST be provided:
o Value of the parameter. o Value of the parameter.
o Reference to the RFC or other permanent and readily available o Reference to the RFC or other permanent and readily available
public specification defining the use of the CRS in the scope of public specification defining the use of the CRS in the scope of
the 'geo' URI. The specification should contain information that the 'geo' URI. The specification should contain information that
is similar to the WGS-84-specific text given in this document. is similar to the WGS-84-specific text given in this document.
o Reference to the definition of the CRS itself, preferably as well o Reference to the definition document of the CRS. If a URN is
known URNs (if available). Note that different URNs may exist for assigned to the CRS, the use of such URN as reference is
the 2-dimensional and 3-dimensional case. preferred. Note that different URNs may exist for the
2-dimensional and 3-dimensional case.
The following table provides the initial values for this registry: The following table provides the initial values for this registry:
crs Value Reference(s) CRS definition(s) crs Value Reference(s) CRS definition(s)
----------------------------------------------------------- -----------------------------------------------------------
wgs84 [RFCxxxx] urn:ogc:def:crs:EPSG::4326 wgs84 [RFCxxxx] urn:ogc:def:crs:EPSG::4326
urn:ogc:def:crs:EPSG::4979 urn:ogc:def:crs:EPSG::4979
[Note to RFC Editor: Replace RFCxxxx with reference to this document] [Note to RFC Editor: Replace RFCxxxx with reference to this document]
8.3.2. Registration Policy 8.3.2. Registration Policy
The registration policy for the "'geo' URI 'crs' Parameter Values" The registration policy for the "'geo' URI 'crs' Parameter Values"
Registry shall be "Specification Required, IESG Approval" as defined Registry shall require both "Specification Required" and "IESG
in [RFC5226]. Approval" as defined in [RFC5226].
Section 1 contains some text about the motivation when to introduce Section 1 contains some text about the motivation when to introduce
new 'crs' values. new 'crs' values.
9. Security Considerations 9. Security Considerations
Because the 'geo' URI is not tied to any specific protocol and Because the 'geo' URI is not tied to any specific protocol and
identifies a physical location rather than a network resource, most identifies a physical location rather than a network resource, most
of the general security considerations on URIs (Section 7 of RFC of the general security considerations on URIs (Section 7 of RFC
3986) do not apply. However, the following (additional) issues 3986) do not apply. However, the following (additional) issues
skipping to change at page 18, line 11 skipping to change at page 19, line 35
URIs which don't identify a valid location. Applications MUST NOT URIs which don't identify a valid location. Applications MUST NOT
use URIs with such values, and SHOULD warn the user when such URIs use URIs with such values, and SHOULD warn the user when such URIs
are encountered. are encountered.
An example of such an URI referring to an invalid location would be An example of such an URI referring to an invalid location would be
<geo:94,0> (latitude "beyond" north pole). <geo:94,0> (latitude "beyond" north pole).
9.2. Location Privacy 9.2. Location Privacy
A 'geo' URI by itself is just an opaque reference to a physical A 'geo' URI by itself is just an opaque reference to a physical
location, expressed by a set of spatial oordinates. This does not location, expressed by a set of spatial coordinates. This does not
fit the "Location Information" definition according to Section 5.2 of fit the "Location Information" definition according to Section 5.2 of
GEOPRIV Requirements [RFC3693], because there is not necessarily a GEOPRIV Requirements [RFC3693], because there is not necessarily a
"Device" involved. "Device" involved.
Because there is also no way to specify the identity of a "Target" Because there is also no way to specify the identity of a "Target"
within the confines of a 'geo' URI, it also does not fit the within the confines of a 'geo' URI, it also does not fit the
specification of an "Location Object" (Section 5.2 of RFC 3693). specification of an "Location Object" (Section 5.2 of RFC 3693).
However, if a 'geo' URI is used in a context where it identifies the However, if a 'geo' URI is used in a context where it identifies the
location of a Target, it becomes part of a Location Object and is location of a Target, it becomes part of a Location Object and is
skipping to change at page 19, line 16 skipping to change at page 20, line 40
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO) Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations", Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009. RFC 5491, March 2009.
11.2. Informative References 11.2. Informative References
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 115, Registration Procedures for New URI Schemes", BCP 35,
RFC 4395, February 2006. RFC 4395, February 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004. J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[WGS84] National Imagery and Mapping Agency, "Department of [WGS84] National Imagery and Mapping Agency, "Department of
skipping to change at page 21, line 8 skipping to change at page 22, line 26
draft-mayrhofer-geo-uri-01 draft-mayrhofer-geo-uri-01
o removed parameters o removed parameters
draft-mayrhofer-geo-uri-00 draft-mayrhofer-geo-uri-00
o initial draft o initial draft
Authors' Addresses Authors' Addresses
Alexander Mayrhofer Alexander Mayrhofer
nic.at GmbH IPCom GmbH
Karlsplatz 1/2/9 Karlsplatz 1/2/9
Wien A-1010 Wien A-1010
Austria Austria
Phone: +43 1 5056416 34 Phone: +43 1 5056416 34
Email: alexander.mayrhofer@nic.at Email: alexander.mayrhofer@nic.at
URI: http://geouri.org/ URI: http://www.ipcom.at/
Christian Spanring Christian Spanring
30 Hancock St 30 Hancock St
Somerville 02144 Somerville 02144
Phone: +1 617 863 0360 Phone: +1 617 863 0360
Email: christian@spanring.eu Email: christian@spanring.eu
URI: http://www.spanring.eu/ URI: http://www.spanring.eu/
 End of changes. 45 change blocks. 
71 lines changed or deleted 99 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/