draft-ietf-geopriv-geo-uri-03.txt   draft-ietf-geopriv-geo-uri-04.txt 
GEOPRIV -- Geographic A. Mayrhofer GEOPRIV -- Geographic A. Mayrhofer
Location/Privacy Working Group nic.at Location/Privacy Working Group nic.at
Internet-Draft C. Spanring Internet-Draft C. Spanring
Expires: March 25, 2010 September 21, 2009 Expires: May 13, 2010 November 09, 2009
A Uniform Resource Identifier for Geographic Locations ('geo' URI) A Uniform Resource Identifier for Geographic Locations ('geo' URI)
draft-ietf-geopriv-geo-uri-03 draft-ietf-geopriv-geo-uri-04
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. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 March 25, 2010. This Internet-Draft will expire on May 13, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
This document specifies a Uniform Resource Identifier (URI) for This document specifies a Uniform Resource Identifier (URI) for
geographic locations using the 'geo' scheme name. A 'geo' URI geographic locations using the 'geo' scheme name. A 'geo' URI
identifies a physical location in a two- or three-dimensional identifies a physical location in a two- or three-dimensional
coordinate reference system in a compact, simple, human-readable, and coordinate reference system in a compact, simple, human-readable, and
protocol independent way. The default coordinate reference system protocol-independent way. The default coordinate reference system
used is WGS-84. used is WGS-84.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. IANA Registration of 'geo' URI Scheme . . . . . . . . . . . . 6 3. IANA Registration of 'geo' URI Scheme . . . . . . . . . . . . 6
3.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . . 7 3.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . . 6
3.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 7 3.3. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 6
3.4. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 8 3.4. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 7
3.4.1. Coordinate Reference System Identification . . . . . . 8 3.4.1. Coordinate Reference System Identification . . . . . . 7
3.4.2. Component Description for WGS-84 . . . . . . . . . . . 8 3.4.2. Component Description for WGS-84 . . . . . . . . . . . 7
3.4.3. Location Uncertainty . . . . . . . . . . . . . . . . . 9 3.4.3. Location Uncertainty . . . . . . . . . . . . . . . . . 8
3.4.4. URI Comparison . . . . . . . . . . . . . . . . . . . . 9 3.4.4. URI Comparison . . . . . . . . . . . . . . . . . . . . 8
3.4.5. Interpretation of Undefined Altitude . . . . . . . . . 10 3.4.5. Interpretation of Undefined Altitude . . . . . . . . . 9
3.5. Encoding Considerations . . . . . . . . . . . . . . . . . 10 3.5. Encoding Considerations . . . . . . . . . . . . . . . . . 9
3.6. Applications/Protocols that use this URI Scheme . . . . . 10 3.6. Applications/Protocols that use this URI Scheme . . . . . 9
3.7. Interopability Considerations . . . . . . . . . . . . . . 11 3.7. Interopability Considerations . . . . . . . . . . . . . . 10
3.8. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.8. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.9. Author/Change controller . . . . . . . . . . . . . . . . . 11 3.9. Author/Change controller . . . . . . . . . . . . . . . . . 10
3.10. References . . . . . . . . . . . . . . . . . . . . . . . . 11 3.10. References . . . . . . . . . . . . . . . . . . . . . . . . 10
4. 'geo' URI Parameters Registry . . . . . . . . . . . . . . . . 11 4. 'geo' URI Parameters Registry . . . . . . . . . . . . . . . . 10
5. URI Operations . . . . . . . . . . . . . . . . . . . . . . . . 12 5. URI Operations . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Use Cases and Examples . . . . . . . . . . . . . . . . . . . . 13 6. Use Cases and Examples . . . . . . . . . . . . . . . . . . . . 12
6.1. Plain 'geo' URI Example . . . . . . . . . . . . . . . . . 13 6.1. Plain 'geo' URI Example . . . . . . . . . . . . . . . . . 12
6.2. Hyperlink . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Hyperlink . . . . . . . . . . . . . . . . . . . . . . . . 12
6.3. 'geo' URI in 2-dimensional barcode . . . . . . . . . . . . 14 6.3. 'geo' URI in 2-dimensional barcode . . . . . . . . . . . . 13
7. GML Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. GML Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. 2D GML 'Point' . . . . . . . . . . . . . . . . . . . . . . 15 7.1. 2D GML 'Point' . . . . . . . . . . . . . . . . . . . . . . 14
7.2. 3D GML 'Point' . . . . . . . . . . . . . . . . . . . . . . 15 7.2. 3D GML 'Point' . . . . . . . . . . . . . . . . . . . . . . 14
7.3. GML 'Circle' . . . . . . . . . . . . . . . . . . . . . . . 15 7.3. GML 'Circle' . . . . . . . . . . . . . . . . . . . . . . . 14
7.4. GML 'Sphere' . . . . . . . . . . . . . . . . . . . . . . . 16 7.4. GML 'Sphere' . . . . . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8.1. 'geo' URI Scheme . . . . . . . . . . . . . . . . . . . . . 16 8.1. 'geo' URI Scheme . . . . . . . . . . . . . . . . . . . . . 15
8.2. URI Parameter Registry . . . . . . . . . . . . . . . . . . 17 8.2. URI Parameter Registry . . . . . . . . . . . . . . . . . . 16
8.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 17 8.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 16
8.2.2. Registration Policy . . . . . . . . . . . . . . . . . 17 8.2.2. Registration Policy . . . . . . . . . . . . . . . . . 16
8.3. Sub-Registry for 'crs' Parameter . . . . . . . . . . . . . 16
8.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 17
8.3.2. Registration Policy . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9.1. Invalid Locations . . . . . . . . . . . . . . . . . . . . 18 9.1. Invalid Locations . . . . . . . . . . . . . . . . . . . . 17
9.2. Location Privacy . . . . . . . . . . . . . . . . . . . . . 18 9.2. Location Privacy . . . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 19 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
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.
Location-aware applications and location-based services are fast Location-aware applications and location-based services are fast
emerging on the Internet. Most web search engines use geographic emerging on the Internet. Most web search engines use geographic
information, and a vivid open source mapping community has brought an information, and a vivid open source mapping community has brought an
enormous momentum into location aware technology. A wide range of enormous momentum into location aware technology. A wide range of
tools and data sets which formerly were accessible to professionals tools and data sets which formerly were accessible to professionals
only have became available to a wider audience. only have became available to a wider audience.
The 'geo' URI scheme is another step into that direction and aims to The 'geo' URI scheme is another step into that direction and aims to
facilitate, support and standardize the problem of location facilitate, support and standardize the problem of location
identification in geospatial services and applications. Accessing identification in geospatial services and applications. Accessing
information about a particular location or triggering further information about a particular location or triggering further
services shouldn't be any harder than clicking on a 'mailto:' link services shouldn't be any harder than clicking on a 'mailto:' link
and writing an email straight away. and writing an email straight away.
According to [RFC3986], a Uniform Resource Identifier (URI) is "a According to [RFC3986], a Uniform Resource Identifier (URI) is "a
compact sequence of characters that identifies an abstract or compact sequence of characters that identifies an abstract or
physical resource". The 'geo' URI scheme defined in this document physical resource". The 'geo' URI scheme defined in this document
identifies geographic locations (physical resources) in a coordinate identifies geographic locations (physical resources) in a coordinate
references system (CRS), per default in World Geodetic System 1984 reference system (CRS), per default the World Geodetic System 1984
(WGS-84) [WGS84]. The scheme provides the textual representation of (WGS-84) [WGS84]. The scheme provides the textual representation of
the location's spatial coordinates in either two or three dimensions the location's spatial coordinates in either two or three dimensions
(latitude, longitude, and optionally altitude for the default CRS of (latitude, longitude, and optionally altitude for the default CRS of
WGS-84). WGS-84). An example of such an 'geo' URI follows:
geo:13.4125,103.8667
Such URIs are independent from a specific protocol, application, or Such URIs are independent from a specific protocol, application, or
data format, and can be used in any other protocol or data format data format, and can be used in any other protocol or data format
that supports inclusion of arbitrary URIs. that supports inclusion of arbitrary URIs.
For the sake of usability, the definition of the URI scheme is For the sake of usability, the definition of the URI scheme is
strictly focused on the simplest, but also most common representation strictly focused on the simplest, but also most common representation
of a spatial location - a single point in a well known CRS. The of a spatial location - a single point in a well known CRS. The
provision of more complex geometries or locations described by civic provision of more complex geometries or locations described by civic
addresses is out of scope of this document. addresses is out of scope of this document.
skipping to change at page 6, line 23 skipping to change at page 5, line 26
'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
author rather then the consumer of 'geo' URI instances. author rather then the consumer of 'geo' URI instances.
2. Terminology 2. Terminology
Geographic locations in this document are defined using WGS 84 (World Geographic locations in this document are defined using WGS-84 (World
Geodetic System 1984), equivalent to the International Association of Geodetic System 1984), equivalent to the International Association of
Oil & Gas Producers (OGP) Surveying and Positioning Committee EPSG Oil & Gas Producers (OGP) Surveying and Positioning Committee EPSG
(European Petroleum Survey Group) code 4326 (2 dimensions) and 4979 (European Petroleum Survey Group) code 4326 (2 dimensions) and 4979
(3 dimensions). This document does not assign responsibilities for (3 dimensions). This document does not assign responsibilities for
coordinate transformations from and to other Spatial Reference coordinate transformations from and to other Spatial Reference
Systems. Systems.
A 2-dimensional WGS-84 coordinate value is here represented as a A 2-dimensional WGS-84 coordinate value is represented here as a
comma-delimited latitude/longitude pair, measured in decimal degrees comma-delimited latitude/longitude pair, measured in decimal degrees
(un-projected). A 3-dimensional WGS-84 coordinate value is here (un-projected). A 3-dimensional WGS-84 coordinate value is
represented by appending a comma-delimited altitude value in meters represented here by appending a comma-delimited altitude value in
to such pairs. meters to such pairs.
Latitudes range from -90 to 90 and longitudes range from -180 to 180. Latitudes range from -90 to 90 and longitudes range from -180 to 180.
Coordinates in the Southern and Western hemispheres as well as Coordinates in the Southern and Western hemispheres as well as
altitudes below the WGS-84 reference geoid are signed negative with a altitudes below the WGS-84 reference geoid are signed negative with a
leading dash. leading dash.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 7, line 30 skipping to change at page 6, line 35
geo-path = coordinates p geo-path = coordinates p
coordinates = coord-a "," coord-b [ "," coord-c ] coordinates = coord-a "," coord-b [ "," coord-c ]
coord-a = num coord-a = num
coord-b = num coord-b = num
coord-c = num coord-c = num
p = [ crsp ] [ uncp ] *parameter p = [ crsp ] [ uncp ] *parameter
crsp = ";crs=" crslabel crsp = ";crs=" crslabel
crslabel = "wgs84" / labeltext crslabel = "wgs84" / labeltext
uncp = ";u=" pnum uncp = ";u=" uval
uval = pnum
parameter = ";" pname [ "=" pvalue ] parameter = ";" pname [ "=" pvalue ]
pname = labeltext pname = labeltext
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 = "-" / "_" / "." / "!" / "~" / "*" /
skipping to change at page 7, line 47 skipping to change at page 7, line 4
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. 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 'crs' values beyond the default definition of other parameters, and <crslabel> values beyond the
value of "wgs84" is out of scope of this document. Section 8.2 default value of "wgs84" is out of scope of this document.
discusses the IANA registration of such additional parameters and Section 8.2 discusses the IANA registration of such additional
values. parameters and values.
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,
its 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 ]
3.4. URI Scheme Semantics 3.4. URI Scheme Semantics
Data contained in a 'geo' URI identifies a physical resource: a Data contained in a 'geo' URI identifies a physical resource: a
spatial location identified by the geographic coordinates and the CRS spatial location identified by the geographic coordinates and the CRS
encoded in the URI. encoded in the URI.
3.4.1. Coordinate Reference System Identification 3.4.1. Coordinate Reference System Identification
The semantics of the 'coordinates' component depends on the CRS of The semantics of <coordinates> depends on the CRS of the URI. The
the URI. The CRS itself is identified by the optional 'crs' CRS itself is identified by the optional 'crs' parameter. A URI
parameter. A URI instance uses the default WGS-84 CRS if the 'crs' instance uses the default WGS-84 CRS if the 'crs' parameter is either
parameter is either missing, or contains the value of 'wgs84'. Other missing or contains the value of 'wgs84'. Other <crslabel> values
'crs' values are currently not defined, but may be specified by are currently not defined, but may be specified by future documents.
future documents.
Interpretation of coordinates in the wrong CRS produces invalid Interpretation of coordinates in the wrong CRS produces invalid
location information. Consumers of 'geo' URIs therefore MUST NOT location information. Consumers of 'geo' URIs therefore MUST NOT
ignore the 'crs' parameter if given, and MUST NOT interpret the ignore the 'crs' parameter if given, and MUST NOT interpret the
'coordinates' component without considering and understanding the <coordinates> sub-components without considering and understanding
'crs' parameter value. the 'crs' parameter value.
The following component description refers to the use of the default The following component description refers to the use of the default
CRS (WGS-84) only. Future documents specifying other 'crs' parameter CRS (WGS-84) only. Future documents specifying other 'crs' parameter
values MUST provide similar descriptions for the 'coordinates' sub- values MUST provide similar descriptions for the <coordinates> sub-
components in the described CRS. components in the described CRS.
3.4.2. Component Description for WGS-84 3.4.2. Component Description for WGS-84
The "latitude", "longitude" and "altitude" components as specified in The <latitude>, <longitude> and <altitude> components as specified in
the URI scheme syntax ( Section 3.3) are to be used as follows: the URI scheme syntax (Section 3.3) are to be used as follows:
o The "latitude" component MUST contain the latitude of the
identified location in decimal degrees in the reference system
WGS-84.
o The "longitude" component MUST contain the longitude of the o <latitude> MUST contain the latitude of the identified location in
identified location in decimal degrees in the reference system decimal degrees in the reference system WGS-84.
WGS-84. o <longitude> MUST contain the longitude of the identified location
o If present, the OPTIONAL "altitude" component MUST contain the in decimal degrees in the reference system WGS-84.
identified altitude in meters in the reference system WGS-84. o If present, the OPTIONAL <altitude> MUST contain the altitude of
the identified location in meters in the reference system WGS-84.
If the altitude of the location is unknown, the "altitude" component If the altitude of the location is unknown, <altitude> (and the comma
MUST NOT be present in the URI. Specifically, unknown altitude MUST before) MUST NOT be present in the URI. Specifically, unknown
NOT be represented by setting the 'altitude' component to "0" (or any altitude MUST NOT be represented by setting <altitude> to "0" (or any
other arbitrary value). other arbitrary value).
The "longitude" components of coordinate values reflecting the poles The <longitude> of coordinate values reflecting the poles (<latitude>
(latitude set to -90 or 90 degrees) SHOULD be set to "0", although set to -90 or 90 degrees) SHOULD be set to "0", although consumers of
consumers of "geo" URIs MUST accept such URIs with any longitude 'geo' URIs MUST accept such URIs with any longitude value from -180
value from -180 to 180. to 180.
'geo' URIs with longitude values outside the range of -180 to 180 'geo' URIs with longitude values outside the range of -180 to 180
decimal degrees or with latitude values outside the range of -90 to decimal degrees or with latitude values outside the range of -90 to
90 degrees MUST be considered invalid. 90 degrees MUST be considered invalid.
3.4.3. Location Uncertainty 3.4.3. Location Uncertainty
The 'u' ("uncertainty") parameter indicates the amount of uncertainty The 'u' ("uncertainty") parameter indicates the amount of uncertainty
in the location as a value in meters. Where a 'geo' URI is used to in the location as a value in meters. Where a 'geo' URI is used to
identify the location of a particular object, uncertainty indicates identify the location of a particular object, <uval> indicates the
the uncertainty with which the identified location of the subject is uncertainty with which the identified location of the subject is
known. known.
The 'u' parameter is optional and it can appear only once. If The 'u' parameter is optional and it can appear only once. If it is
uncertainty is not specified, this indicates that uncertainty is not specified, this indicates that uncertainty is unknown or
unknown or unspecified. If the intent is to indicate a specific unspecified. If the intent is to indicate a specific point in space,
point in space, uncertainty MAY be set to zero. Zero uncertainty and <uval> MAY be set to zero. Zero uncertainty and absent uncertainty
absent uncertainty are never the same thing. are never the same thing.
The single uncertainty value is applied to all dimensions given in The single uncertainty value is applied to all dimensions given in
the URI. the URI.
Note: The number of digits of the value in the 'coordinates' Note: The number of digits of the values in <coordinates> MUST NOT be
component 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 their Two 'geo' URIs are equal when they use the same CRS, and <coord-a>,
'coord-a', 'coord-b', 'coord-c' and 'u' values are mathematically <coord-b>, <coord-c> and 'u' value are mathematically identical
identical. (including absent <uval> meaning undefined 'u' value).
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 'crs' parameter value, or one has the 'crs' or both have the same <crslabel>, or one has the 'crs' parameter
parameter omitted while the other URI specifies the default CRS omitted while the other URI specifies the default CRS explicitely
explicitely with a 'crs' parameter 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 the 'latitude' component of a 'geo' URI is set to either 90 o Where <latitude> of a 'geo' URI is set to either 90 or -90
or -90 degrees, the 'longitude' component MUST be ignored in degrees, <longitude> MUST be ignored in comparison operations
comparison operations ("poles case"). ("poles case").
o A 'longitude' component of 180 degrees MUST be considered equal to o A <longitude> of 180 degrees MUST be considered equal to
a 'longitude' component of -180 degrees for the purpose of URI <longitude> of -180 degrees for the purpose of URI comparison
comparison ("date line" case). ("date line" case).
An URI with undefined (missing) 'coord-c' (altitude) value MUST NOT A URI with undefined (missing) <coord-c> (altitude) value MUST NOT be
be considered equal to an URI containing an 'coord-c' value, even if considered equal to a URI containing a <coord-c>, even if the
the remaining 'coord-a', 'coord-b' and 'u' values are equivalent. remaining <coord-a>, <coord-b>, and their 'u' values are equivalent.
3.4.5. Interpretation of Undefined Altitude 3.4.5. Interpretation of Undefined Altitude
A consumer of a 'geo' URI in the WGS-84 CRS with undefined 'altitude' A consumer of a 'geo' URI in the WGS-84 CRS with undefined <altitude>
MAY assume that the URI refers to the respective location on Earth's MAY assume that the URI refers to the respective location on Earth's
physical surface at the given 'latitude' and 'longitude' coordinates. physical surface at the given latitude and longitude.
However, as defined above, altitudes are relative to the WGS-84 However, as defined above, altitudes are relative to the WGS-84
reference geoid rather than Earth's surface. Hence, an altitude reference geoid rather than Earth's surface. Hence, an <altitude>
value of 0 MUST NOT be mistaken to refer to "ground elevation". value of 0 MUST NOT be mistaken to refer to "ground elevation".
3.5. Encoding Considerations 3.5. Encoding Considerations
The 'coordinates' path component of the 'geo' URI (see Section 3.3) The <coordinates> path component of the 'geo' URI (see Section 3.3)
uses a comma (",") as the delimiter for subcomponents. This uses a comma (",") as the delimiter for subcomponents. This
delimiter MUST NOT be percent encoded. delimiter MUST NOT be percent-encoded.
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' subcomponents, as well as the 'crs' and 'u' <coord-b> and <coord-c> as well as <crslabel> and <uval> are never
parameters 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 for 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.
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, the simple structure of the 'geo' URI would allow
even manual dereference by humans. even manual dereference by humans.
skipping to change at page 11, line 14 skipping to change at page 10, line 16
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, the simple structure of the 'geo' URI would allow
even manual dereference by humans. even manual dereference by humans.
Clients MUST NOT attempt to dereference URIs given in an CRS that is Clients MUST NOT attempt to dereference 'geo' URIs given in an CRS
unknown to the client, because doing so would produce entirely bogus that is unknown to the client, because doing so would produce
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. Contact
Alexander Mayrhofer <alexander.mayrhofer@nic.at> Alexander Mayrhofer <axelm@nic.at>, <http://geouri.org/>
Christian Spanring <cspanring@gmail.com> Christian Spanring <christian@spanring.eu>
3.9. Author/Change controller 3.9. 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.10. 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". Parameters for the 'geo' URI and values for Parameters Registry" for the <parameter> component of the URI.
these parameters MUST be registered with IANA to prevent namespace Parameters for the 'geo' URI and values for these parameters MUST be
collisions, and provide interopability. registered with IANA to prevent namespace collisions, and provide
interopability.
Some parameters accept values that are constrained by a syntax Some parameters accept values that are constrained by a syntax
definition only, while others accept values from a predefined set definition only, while others accept values from a predefined set
only. Some parameters might not accept any values at all ("flag" only. Some parameters might not accept any values at all ("flag"
type parameter). type parameters).
The registration of values is REQUIRED for parameters that accept The registration of values is REQUIRED for parameters that accept
values from a predefined set only. values from a predefined set.
The specification of a parameter MUST fully explain the syntax, The specification of a parameter MUST fully explain the syntax,
intended usage and semantics of the parameter. This ensures intended usage and semantics of the parameter. This ensures
interopability between independent implementations. interopability between independent implementations.
For parameters that are neither restricted to a set of predefined For parameters that are neither restricted to a set of predefined
values nor of the "flag" type described above, the syntax of allowed values nor of the "flag" type described above, the syntax of allowed
values MUST be described in the specification, for example by using values MUST be described in the specification, for example by using
ABNF. ABNF.
skipping to change at page 12, line 44 skipping to change at page 11, line 47
only constrained by a syntax as specified in a RFC or other only constrained by a syntax as specified in a RFC or other
permanent and readily available public specification. permanent and readily available public specification.
Section 8.2.1 contains the initial contents of the Registry. Section 8.2.1 contains the initial contents of the Registry.
5. URI Operations 5. URI Operations
Currently, just one operation on a 'geo' URI is defined - location Currently, just one operation on a 'geo' URI is defined - location
dereference: In that operation, a client dereferences the URI by dereference: In that operation, a client dereferences the URI by
extracting the geographical coordinates from the URI path component extracting the geographical coordinates from the URI path component
('geo-path' in the ABNF). Further use of those coordinates (and the <geo-path>. Further use of those coordinates (and the uncertainty
uncertainty value from the 'u' parameter) is then up to the value from <uval>) is then up to the application processing the URI,
application processing the URI, and might depend on the context of and might depend on the context of the URI.
the URI.
An application may then use this location information for various An application may then use this location information for various
purposes, for example: purposes, for example:
o A web browser could use that information to open a web mapping o A web browser could use that information to open a mapping service
service of the user's choice, and display a map of the location of the user's choice, and display a map of the location.
o A navigational device such as a Global Positioning System (GPS) o A navigational device such as a Global Positioning System (GPS)
receiver could offer the user to start navigation to the location. receiver could offer the user to start navigation to the location.
Note that the examples and use cases aboves as well as in the next Note that the examples and use cases aboves as well as in the next
section are non-normative, and provided for information only. section are non-normative, and provided for information only.
6. Use Cases and Examples 6. Use Cases and Examples
6.1. Plain 'geo' URI Example 6.1. Plain 'geo' URI Example
skipping to change at page 13, line 36 skipping to change at page 12, line 37
6.2. Hyperlink 6.2. Hyperlink
'geo' URIs (like any other URI scheme) could also be embedded as 'geo' URIs (like any other URI scheme) could also be embedded as
hyperlinks in web pages. A Hyper Text Markup Language (HTML) snippet hyperlinks in web pages. A Hyper Text Markup Language (HTML) snippet
with such a hyperlink could look like: with such a hyperlink could look like:
<p>one of Vienna's popular sights is the <p>one of Vienna's popular sights is the
<a href='geo:48.198634,16.371648;crs=wgs84'>Karlskirche</a>. <a href='geo:48.198634,16.371648;crs=wgs84'>Karlskirche</a>.
A web browser could extract the coordinates from the HTML snippet, A web browser could extract the coordinates from the HTML snippet and
and offer the user various options (based on configuration, context), offer the user various options (based on configuration, context), for
for example: example:
o Display a small map thumbnail when the mouse pointer hovers over o Display a small map thumbnail when the mouse pointer hovers over
the link. the link.
o Switch to a mapping service of the user's choice once the link is o Switch to a mapping service of the user's choice once the link is
selected. selected.
o Locate nearby resources, for example by comparing the 'geo' URI o Locate nearby resources, for example by comparing the 'geo' URI
with locations extracted from GeoRSS feeds the user has subscribed with locations extracted from GeoRSS feeds the user has subscribed
to. to.
skipping to change at page 14, line 19 skipping to change at page 13, line 19
specification of the CRS by using the 'crs' parameter. specification of the CRS by using the 'crs' parameter.
6.3. 'geo' URI in 2-dimensional barcode 6.3. 'geo' URI in 2-dimensional barcode
Due to it's short length, a 'geo' URI could easily be encoded in Due to it's short length, a 'geo' URI could easily be encoded in
2-dimensional barcodes. Such barcodes could be printed on business 2-dimensional barcodes. Such barcodes could be printed on business
cards, flyers, paper maps and subsequently used by mobile devices, cards, flyers, paper maps and subsequently used by mobile devices,
for example as follows: for example as follows:
1. User identifies such a barcode on a flyer and uses the camera on 1. User identifies such a barcode on a flyer and uses the camera on
his mobile phone to photograph and decode the barcode his mobile phone to photograph and decode the barcode.
2. The mobile phone dereferences the 'geo' URI, and offers the user 2. The mobile phone dereferences the 'geo' URI, and offers the user
to calculate a navigation route to the identified location. to calculate a navigation route to the identified location.
3. Using the builtin GPS receiver, the user follows the navgiation 3. Using the builtin GPS receiver, the user follows the navgiation
instructions to reach the location instructions to reach the location.
7. GML Mappings 7. GML Mappings
The Geographic Markup Language (GML) by the Open Geospatial The Geographic Markup Language (GML) by the Open Geospatial
Consortium (OGC) is a set of XML schemas to represent geographical Consortium (OGC) is a set of XML schemas to represent geographical
features. Since GML is widely accepted, this document includes features. Since GML is widely accepted, this document includes
instructions on how to transform 'geo' URIs from and to GML instructions on how to transform 'geo' URIs from and to GML
documents. The instructions in this section are not normative. fragments. The instructions in this section are not normative.
For the following sections, "%lat%", "%lon%", "%alt%" and "%unc%" are For the following sections, "%lat%", "%lon%", "%alt%" and "%unc%" are
placeholders for latitude, longitude, altitude and uncertainty placeholders for latitude, longitude, altitude and uncertainty
values, respectively. The mappings use WGS-84, and are defined in values, respectively. The mappings use WGS-84, and are defined in
the following sections. the following sections.
Note: GML documents in other reference systems could be used as well Note: GML fragments in other reference systems could be used as well
if a transformation into "urn:ogc:def:crs:EPSG::4979" or if a transformation into "urn:ogc:def:crs:EPSG::4979" or
"urn:ogc:def:crs:EPSG::4326" is defined and applied before the "urn:ogc:def:crs:EPSG::4326" is defined and applied before the
mapping step. Such transformations are typically not lossless. mapping step. Such transformations are typically not lossless.
GML uses the 'double' type from XML schema, and the mapping examples GML uses the 'double' type from XML schema, and the mapping examples
assume that numbers in the form of "3.32435e2" in GML are properly assume that numbers in the form of "3.32435e2" in GML are properly
converted to decimal when placed into the 'geo' URI. converted to fixed point when placed into the 'geo' URI.
7.1. 2D GML 'Point' 7.1. 2D GML 'Point'
A 2D GML 'Point' [RFC5491] is constructed from a 'geo' URI that has A 2D GML 'Point' [RFC5491] is constructed from a 'geo' URI that has
two coordinates and an uncertainty ('u') parameter that is absent or two coordinates and an uncertainty ('u') parameter that is absent or
zero. A GML point is always converted to a 'geo' URI that has no zero. A GML point is always converted to a 'geo' URI that has no
uncertainty parameter. uncertainty parameter.
'geo' URI: 'geo' URI:
geo:%lat%,%lon% geo:%lat%,%lon%
GML document: GML fragment:
<Point srsName="urn:ogc:def:crs:EPSG::4326" <Point srsName="urn:ogc:def:crs:EPSG::4326"
xmlns="http://www.opengis.net/gml"> xmlns="http://www.opengis.net/gml">
<pos>%lat% %lon%</pos> <pos>%lat% %lon%</pos>
</Point> </Point>
Note that a 'geo' URI with an uncertainty value of zero is converted Note that a 'geo' URI with an uncertainty value of zero is converted
to a GML 'Point', but a GML 'Point' cannot be translated to a 'geo' to a GML 'Point', but a GML 'Point' cannot be translated to a 'geo'
URI with zero uncertainty. URI with zero uncertainty.
skipping to change at page 15, line 38 skipping to change at page 14, line 38
A 3D GML 'Point' [RFC5491] is constructed from a 'geo' URI that has A 3D GML 'Point' [RFC5491] is constructed from a 'geo' URI that has
three coordinates and an uncertainty parameter that is absent or three coordinates and an uncertainty parameter that is absent or
zero. A GML point is always converted to a 'geo' URI that has no zero. A GML point is always converted to a 'geo' URI that has no
uncertainty parameter. uncertainty parameter.
'geo' URI: 'geo' URI:
geo:%lat%,%lon%,%alt% geo:%lat%,%lon%,%alt%
GML document: GML fragment:
<Point srsName="urn:ogc:def:crs:EPSG::4979" <Point srsName="urn:ogc:def:crs:EPSG::4979"
xmlns="http://www.opengis.net/gml"> xmlns="http://www.opengis.net/gml">
<pos>%lat% %lon% %alt%</pos> <pos>%lat% %lon% %alt%</pos>
</Point> </Point>
7.3. GML 'Circle' 7.3. GML 'Circle'
A GML 'Circle' [RFC5491] is constructed from a 'geo' URI that has two A GML 'Circle' [RFC5491] is constructed from a 'geo' URI that has two
coordinates and an uncertainty parameter that is present and non- coordinates and an uncertainty parameter that is present and non-
zero. zero.
'geo' URI: 'geo' URI:
geo:%lat%,%lon%;u=%unc% geo:%lat%,%lon%;u=%unc%
GML document: GML fragment:
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326" <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"> xmlns:gs="http://www.opengis.net/pidflo/1.0">
<gml:pos>%lat% %lon%</gml:pos> <gml:pos>%lat% %lon%</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001"> <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
%unc% %unc%
</gs:radius> </gs:radius>
</gs:Circle> </gs:Circle>
7.4. GML 'Sphere' 7.4. GML 'Sphere'
A GML 'sphere' [RFC5491] is constructed from a 'geo' URI that has A GML 'sphere' [RFC5491] is constructed from a 'geo' URI that has
three coordinates and an uncertainty parameter that is present and three coordinates and an uncertainty parameter that is present and
non-zero. non-zero.
'geo' URI: 'geo' URI:
geo:%lat%,%lon%,%alt%;u=%unc% geo:%lat%,%lon%,%alt%;u=%unc%
GML document: GML fragment:
<gs:Sphere srsName="urn:ogc:def:crs:EPSG::4979" <gs:Sphere srsName="urn:ogc:def:crs:EPSG::4979"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"> xmlns:gs="http://www.opengis.net/pidflo/1.0">
<gml:pos>%lat% %lon% %alt%</gml:pos> <gml:pos>%lat% %lon% %alt%</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001"> <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
%unc% %unc%
</gs:radius> </gs:radius>
</gs:Sphere> </gs:Sphere>
skipping to change at page 17, line 7 skipping to change at page 16, line 7
8.1. 'geo' URI Scheme 8.1. 'geo' URI Scheme
This document requests assignment of the 'geo' URI scheme in the IETF This document requests assignment of the 'geo' URI scheme in the IETF
part of the URI scheme tree, according to the guidelines in BCP 115 part of the URI scheme tree, according to the guidelines in BCP 115
(RFC 4395) [RFC4395]. The definitions required for the assignment (RFC 4395) [RFC4395]. The definitions required for the assignment
are contained in Section 3. are contained in Section 3.
8.2. URI Parameter Registry 8.2. URI Parameter Registry
This document creates a new IANA Registry named "geo URI Parameters", This document creates a new IANA Registry named "'geo' URI
according to the information in Section 4 and the definition in this Parameters", according to the information in Section 4 and the
section. definition in this section.
8.2.1. Registry Contents 8.2.1. Registry Contents
When registering a new 'geo' URI Parameter, the following information When registering a new 'geo' URI Parameter, the following information
MUST be provided: MUST be provided:
o Name of the Parameter. o Name of the Parameter.
o Whether the Parameter accepts no value ("No value"), values from a o Whether the Parameter accepts no value ("No value"), values from a
predefined set ("Predefined"), or values constrained by a syntax predefined set ("Predefined"), or values constrained by a syntax
only ("Constrained"). only ("Constrained").
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 parameters and the new values. public specification defining the parameters and the new values.
When registering a new value for an existing 'geo' URI Parameter, the Unless specific instructions exists for a Parameter (like the
following information MUST be provided: definition of a Sub-registry), the following information MUST be
provided when registering new values for existing "Predefined" 'geo'
URI Parameters:
o Name of the Parameter. o Name 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 new values. public specification defining the new values.
The following table provides the initial values for this registry: The following table provides the initial values for this registry:
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, Designated Expert", as
defined in [RFC5226]. defined in [RFC5226].
8.3. Sub-Registry for 'crs' Parameter
This document creates a new IANA Sub-registry named "'geo' URI 'crs'
Parameter Values", based on the Registry specified in Section 8.2 and
the information in this section and Section 4. The syntax of the
'crs' parameter is constrained by the ABNF given in Section 3.3.
8.3.1. Registry Contents
When registering a new value for the 'crs' parameter, the following
information MUST be provided:
o Value of the parameter.
o Reference to the RFC or other permanent and readily available
public specification defining the use of the CRS in the scope of
the 'geo' URI. The specification should contain information that
is similar to the WGS-84-specific text given in this document.
o Reference to the definition of the CRS itself, preferably as well
known URNs (if available). Note that different URNs may exist for
the 2-dimensional and 3-dimensional case.
The following table provides the initial values for this registry:
crs Value Reference(s) CRS definition(s)
-----------------------------------------------------------
wgs84 [RFCxxxx] urn:ogc:def:crs:EPSG::4326
urn:ogc:def:crs:EPSG::4979
[Note to RFC Editor: Replace RFCxxxx with reference to this document]
8.3.2. Registration Policy
The registration policy for the "'geo' URI 'crs' Parameter Values"
Registry shall be "Specification Required, IESG Approval" as defined
in [RFC5226].
Section 1 contains some text about the motivation when to introduce
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
apply: apply:
9.1. Invalid Locations 9.1. Invalid Locations
The URI syntax (Section 3.3) makes it possible to construct 'geo' The URI syntax (Section 3.3) makes it possible to construct 'geo'
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
skipping to change at page 18, line 25 skipping to change at page 18, line 18
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 oordinates. 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 RFC3693). 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
therefore subject to GEOPRIV rules. therefore subject to GEOPRIV rules.
Therefore, when 'geo' URIs are put into such contexts, the privacy Therefore, when 'geo' URIs are put into such contexts, the privacy
requirements of RFC 3693 MUST be met. requirements of RFC 3693 MUST be met.
10. Acknowledgements 10. Acknowledgements
Martin Thomson has provided significant text around the definition of Martin Thomson has provided significant text around the definition of
the "uncertainty" parameter and the GML mappings. the "uncertainty" parameter and the GML mappings.
The authors further wish to acknowledge the helpful contributions The authors further wish to acknowledge the helpful contributions
from Carl Reed, Bill McQuillan, Martin Kofal, Andrew Turner, Kim from Carl Reed, Bill McQuillan, Martin Kofal, Andrew Turner, Kim
Sanders, Ted Hardie, Cullen Jennings, Klaus Darilion, Bjorn Sanders, Ted Hardie, Cullen Jennings, Klaus Darilion, Bjorn
Hoehrmann, Alissa Cooper and Ivan Shmakov. Hoehrmann, Alissa Cooper and Ivan Shmakov.
Alfred Hoenes has provided an extremely helpful in-depth review of
the document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 19, line 38 skipping to change at page 19, line 35
[WGS84] National Imagery and Mapping Agency, "Department of [WGS84] National Imagery and Mapping Agency, "Department of
Defense World Geodetic System 1984, Third Edition", Defense World Geodetic System 1984, Third Edition",
NIMA TR8350.2, January 2000. NIMA TR8350.2, January 2000.
Appendix A. Change Log Appendix A. Change Log
[Note to editors: This section is to be removed before publication - [Note to editors: This section is to be removed before publication -
XML source available on request] XML source available on request]
draft-ietf-geopriv-geo-uri-04
o Added "crs" URI parameter registry
o Added example URI to Introduction
o Changed quoting of parameters according to Alfred Hoenes' comments
draft-ietf-geopriv-geo-uri-03 draft-ietf-geopriv-geo-uri-03
o Updated privacy considerations section as per Alissa's comments o Updated privacy considerations section as per Alissa's comments
o Added text on uncertainty applied to all given dimensions o Added text on uncertainty applied to all given dimensions
o various editorial changes o various editorial changes
o Changed ABNF to reflect order of parameters (CRS first, then U, o Changed ABNF to reflect order of parameters (CRS first, then U,
then others then others
draft-ietf-geopriv-geo-uri-02 draft-ietf-geopriv-geo-uri-02
o Added IANA registry for 'geo' URI Parameters and values o Added IANA registry for 'geo' URI Parameters and values
o Moved change log to appendix o Moved change log to appendix
skipping to change at page 21, line 15 skipping to change at page 21, line 15
Authors' Addresses Authors' Addresses
Alexander Mayrhofer Alexander Mayrhofer
nic.at GmbH nic.at 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://www.nic.at/ URI: http://geouri.org/
Christian Spanring Christian Spanring
5 Crawford St 30 Hancock St
Cambridge 02139 Somerville 02144
Phone: +1 617 800 7885 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. 73 change blocks. 
152 lines changed or deleted 205 lines changed or added

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