draft-ietf-geopriv-geo-uri-00.txt   draft-ietf-geopriv-geo-uri-01.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: December 4, 2009 OIR-ID Expires: January 4, 2010 OIR-ID
June 2, 2009 July 03, 2009
A Uniform Resource Identifier for Geographic Locations ('geo' URI) A Uniform Resource Identifier for Geographic Locations ('geo' URI)
draft-ietf-geopriv-geo-uri-00 draft-ietf-geopriv-geo-uri-01
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 43 skipping to change at page 1, line 43
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 December 4, 2009. This Internet-Draft will expire on January 4, 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 an Uniform Resource Identifier (URI) for This document specifies an 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 by latitude, longitude and optionally identifies a physical location in a two- or three-dimensional
altitude in a compact, simple, human-readable, and protocol coordinate reference system in a compact, simple, human-readable, and
independent way. protocol independent way. The default coordinate reference system
used is WGS-84.
Table of Contents Table of Contents
1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. IANA Registration of 'geo' URI Scheme . . . . . . . . . . . . 7 4. IANA Registration of 'geo' URI Scheme . . . . . . . . . . . . 7
4.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . . 7 4.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . . 7
4.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 7 4.3. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 7
4.4. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 7 4.4. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 9
4.4.1. Component Description . . . . . . . . . . . . . . . . 8 4.4.1. Coordinate Reference System Identification . . . . . . 9
4.4.2. URI Comparison . . . . . . . . . . . . . . . . . . . . 8 4.4.2. Component Description for WGS-84 . . . . . . . . . . . 9
4.4.3. Interpretation of Undefined Altitude . . . . . . . . . 8 4.4.3. URI Comparison . . . . . . . . . . . . . . . . . . . . 10
4.5. Encoding Considerations . . . . . . . . . . . . . . . . . 9 4.4.4. Interpretation of Undefined Altitude . . . . . . . . . 10
4.6. Applications/protocols That Use This URI Scheme . . . . . 9 4.5. Encoding Considerations . . . . . . . . . . . . . . . . . 10
4.7. Interopability Considerations . . . . . . . . . . . . . . 9 4.6. Applications/protocols That Use This URI Scheme . . . . . 11
4.8. Security Considerations . . . . . . . . . . . . . . . . . 9 4.7. Interopability Considerations . . . . . . . . . . . . . . 11
4.9. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.8. Security Considerations . . . . . . . . . . . . . . . . . 11
4.10. Author/Change controller . . . . . . . . . . . . . . . . . 10 4.9. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.11. References . . . . . . . . . . . . . . . . . . . . . . . . 10 4.10. Author/Change controller . . . . . . . . . . . . . . . . . 12
4.11. References . . . . . . . . . . . . . . . . . . . . . . . . 12
5. URI Operations . . . . . . . . . . . . . . . . . . . . . . . . 10 5. URI Operations . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Use Cases and Examples . . . . . . . . . . . . . . . . . . . . 10 6. Use Cases and Examples . . . . . . . . . . . . . . . . . . . . 12
6.1. Plain 'geo' URI Example . . . . . . . . . . . . . . . . . 10 6.1. Plain 'geo' URI Example . . . . . . . . . . . . . . . . . 12
6.2. Hyperlink . . . . . . . . . . . . . . . . . . . . . . . . 10 6.2. Hyperlink . . . . . . . . . . . . . . . . . . . . . . . . 12
6.3. 'geo' URI in 2-dimensional barcode . . . . . . . . . . . . 11 6.3. 'geo' URI in 2-dimensional barcode . . . . . . . . . . . . 13
7. GML Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. GML Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. 'geo' URI without altitude to GML 'Point' . . . . . . . . 12 7.1. 'geo' URI without altitude to GML 'Point' . . . . . . . . 14
7.2. 'geo' URI with Altitude to GML 'Point' . . . . . . . . . . 12 7.2. 'geo' URI with Altitude to GML 'Point' . . . . . . . . . . 14
7.3. GML 'Point' without Altitude to 'geo' URI . . . . . . . . 12 7.3. GML 'Point' without Altitude to 'geo' URI . . . . . . . . 14
7.4. GML 'Point' with Altitude to 'geo' URI . . . . . . . . . . 13 7.4. GML 'Point' with Altitude to 'geo' URI . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9.1. Invalid Locations . . . . . . . . . . . . . . . . . . . . 14 9.1. Invalid Locations . . . . . . . . . . . . . . . . . . . . 16
9.2. Location Privacy . . . . . . . . . . . . . . . . . . . . . 14 9.2. Location Privacy . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Change Log 1. 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-01
o added parameters to ABNF
o added optional 'crs' parameter to allow future use of other CRSes
o Many other changes to not preclude the future specification of
other CRSes.
o some typos fixes - credits Bill McQuillan
draft-ietf-geopriv-geo-uri-00 draft-ietf-geopriv-geo-uri-00
o submitted as WG item o submitted as WG item
o changed IPR text because of text used from RFC 4395 o changed IPR text because of text used from RFC 4395
o added considerations for comparing +180/-180 longitude URIs o added considerations for comparing +180/-180 longitude URIs
o some editorial changes o some editorial changes
draft-mayrhofer-geopriv-geo-uri-01 draft-mayrhofer-geopriv-geo-uri-01
o added terminology text about WGS-84 (credits Carl Reed) o added terminology text about WGS-84 (credits Carl Reed)
o removed "resolution" / "uncertainty" text o removed "resolution" / "uncertainty" text
o added considerations regarding poles o added considerations regarding poles
skipping to change at page 6, line 16 skipping to change at page 6, line 23
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 or trigger further services based on a particular information about or trigger further services based on a particular
place on earth shouldn't be any harder for users than clicking on a place on earth shouldn't be any harder for users than clicking on a
'mailto:' link and write an email straight away. 'mailto:' link and write 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 (a physical resource) in the World identifies geographic locations (a physical resource) in a coordinate
Geodetic System 1984 (WGS-84) [WGS84] reference system. references system (CRS), per default in World Geodetic System 1984
(WGS-84) [WGS84]. The optional "crs" URI parameter described below
may be used by future specifications to define the use of other
CRSes. However, such definitions are out of scope of this document.
'Geo' URIs identify a geographic location using a textual 'Geo' URIs identify a geographic location using a textual
representation of the location's spatial coordinates in either two or representation of the location's spatial coordinates in either two or
three dimensions (latitude, longitude, and optionally altitude). three dimensions (latitude, longitude, and optionally altitude for
Such URIs are independent from a specific protocol, application, or the default CRS of WGS-84). Such URIs are independent from a
data format, and can be used in any other protocol or data format specific protocol, application, or data format, and can be used in
that supports inclusion of arbitrary URIs. any other protocol or data format that supports inclusion of
arbitrary URIs.
The definition of the URI scheme is strictly focused on the most For the sake of usability, the definition of the URI scheme is
simplest representation of a spatial location - a single point. The strictly focused on the simplest, but also most common representation
provision of more complex geometries or locations described by civic of a spatial location - a single point. The provision of more
addresses is out of scope of this document. complex geometries or locations described by civic addresses is out
of scope of this document.
Note: The choice of WGS-84 is based on the widespread availability of Note: The choice of WGS-84 as the default CRS is based on the
Global Positioning System (GPS) devices, which use the WGS-84 widespread availability of Global Positioning System (GPS) devices,
reference system. It is anticipated that such devices serve as one which use the WGS-84 reference system. It is anticipated that such
of the primary data sources for authoring 'geo' URIs, hence the devices serve as one of the primary data sources for authoring 'geo'
adoption of the native GPS reference system for the URI scheme. URIs, hence the adoption of the native GPS reference system for the
Also, many other data formats for representing geographic locations URI scheme. Also, many other data formats for representing
use the WGS-84 reference system, which makes transposing from and to geographic locations use the WGS-84 reference system, which makes
such data formats less error prone (no re-projection involved). transposing from and to such data formats less error prone (no re-
projection involved).
3. Terminology 3. 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 OGP Surveying and Geodetic System 1984), equivalent to the International Association of
Positioning Committee EPSG code 4326 (2 dimensions) and 4979 (3 Oil & Gas Producers (OGP) Surveying and Positioning Committee EPSG
dimensions). This document does not assign responsibilities for (European Petroleum Survey Group) code 4326 (2 dimensions) and 4979
(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 here represented 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 here
represented by appending a comma-delimited altitude value in meters represented by appending a comma-delimited altitude value in meters
to such pairs. 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.
skipping to change at page 7, line 37 skipping to change at page 8, line 7
permanent permanent
4.3. URI Scheme Syntax 4.3. URI Scheme Syntax
The syntax of the 'geo' URI scheme is specified below in Augmented The syntax of the 'geo' URI scheme is specified below in Augmented
Backus-Naur Form (ABNF) [RFC4234]: Backus-Naur Form (ABNF) [RFC4234]:
geo-URI = geo-scheme ":" geo-path geo-URI = geo-scheme ":" geo-path
geo-scheme = "geo" geo-scheme = "geo"
geo-path = geo-location geo-path = coordinates *p
coordinates = coord-a "," coord-b [ "," coord-c ]
geo-location = latitude "," longitude [ "," altitude ] coord-a = num
coord-b = num
coord-c = num
latitude = [ "-" ] 1*2DIGIT [ "." *DIGIT ] p = crsp / parameter
longitude = [ "-" ] 1*3DIGIT [ "." *DIGIT ] crsp = ";crs=" crslabel
altitude = [ "-" ] *DIGIT [ "." *DIGIT ] crslabel = "wgs84"
parameter = ";" pname [ "=" pvalue ]
pname = 1*( alphanum / '-' )
pvalue = 1*paramchar
paramchar = p-unreserved / unreserved / pct-encoded
num = [ "-" ] 1*DIGIT [ "." 1*DIGIT ]
unreserved = alphanum / mark
mark = "-" / "_" / "." / "!" / "~" / "*" /
"'" / "(" / ")"
pct-encoded = "%" HEXDIG HEXDIG
p-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$"
alphanum = ALPHA / DIGIT
The optional "crs" parameter MUST NOT appear more than once. If
other parameters are also given, the "crs" parameter MUST be given
first. The definition of other parameters besides "crs" is out of
scope for this document.
Future documents proposing the use of other CRSes may update the
definition of the 'crslabel' component.
In case the URI identifies a location in the default CRS of WGS-84,
its sub-components are further restricted as follows:
coord-a = latitude
coord-b = longitude
coord-c = altitude
latitude = [ "-" ] 1*2DIGIT [ "." 1*DIGIT ]
longitude = [ "-" ] 1*3DIGIT [ "." 1*DIGIT ]
altitude = [ "-" ] 1*DIGIT [ "." 1*DIGIT ]
4.4. URI Scheme Semantics 4.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 on earth in the WGS-84 references system, identified spatial location on earth in the in a coordinate reference system,
by the geographic coordinates encoded in the URI. identified by the geographic coordinates encoded in the URI.
4.4.1. Component Description 4.4.1. Coordinate Reference System Identification
The semantics of the 'coordinates' component depends on the CRS of
the URI. The CRS itself is identified by the optional 'crs'
parameter the default. A URI instance uses the default WGS-84 CRS if
the 'crs' parameter is either missing, or contains the value of
'wgs84'. Other 'crs' values are not currently defined, but may be
specified by future documents.
Interpretation of coordinates in a wrong CRS produces invalid
location information. Consumers of 'geo' URIs therefore MUST NOT
ignore the 'crs' parameter if given, and MUST NOT attempt to
interpret the 'coordinates' component of given in an unknown CRS.
The following component description refers to the use of the default
CRS (WGS-84) only. Future documents specifying other 'crs' parameter
values MUST provide similar descriptions for the 'coordinates' sub-
components in the described CRS.
4.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 4.3) are to be used as follows: the URI scheme syntax ( Section 4.3) are to be used as follows:
o The "latitude" component MUST contain the latitude of the o The "latitude" component MUST contain the latitude of the
identified location in decimal degrees in the reference system identified location in decimal degrees in the reference system
WGS-84. WGS-84.
o The "latitude" component MUST contain the latitude of the o The "longitude" component MUST contain the longitude of the
identified location in decimal degrees in the reference system identified location in decimal degrees in the reference system
WGS-84. WGS-84.
o If present, the OPTIONAL "altitude" component MUST contain the o If present, the OPTIONAL "altitude" component MUST contain the
WGS-84 altitude of the identified location in meters. WGS-84 altitude of the identified location in meters.
If the altitude of the location is unknown, the "altitude" component If the altitude of the location is unknown, the "altitude" component
MUST NOT be present in the URI. Specifically, unknown altitude MUST MUST NOT be present in the URI. Specifically, unknown altitude MUST
NOT be represented by setting the 'altitude' component to "0" (or any NOT be represented by setting the 'altitude' component to "0" (or any
other arbitrary value). other arbitrary value).
The "longitude" components of coordinate values reflecting the poles The "longitude" components of coordinate values reflecting the poles
(latitude set to -90 or 90 degrees) SHOULD be set to "0", although (latitude set to -90 or 90 degrees) SHOULD be set to "0", although
consumers of "geo" URIs MUST accept such URIs with any longitude consumers of "geo" URIs MUST accept such URIs with any longitude
value between -180 and 180. value between -180 and 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.
4.4.2. URI Comparison 4.4.3. URI Comparison
Two 'geo' URIs are equal when their 'longitude', 'latitude' and Two 'geo' URIs are equal when they use the same CRS, and their
'altitude' values are mathematically identical. Where the 'latitude' 'coord-a', 'coord-b' and 'coord-c' values are mathematically
component of a 'geo' URI is set to either 90 or -90 degrees, the identical.
'longitude' component MUST be ignored in comparison operations. A
'longitude' component of 180 degrees MUST be considered equal a Two 'geo' URIs use the same CRS if:
o their 'crslabel' components are identical
o or if neither URIs contain a 'crs' parameter (in which case both
URIs use WGS-84)
o or if one URI contains a 'crslabel' value of 'wgs84', while the
other URI does not contain a 'crs' parameter (which means that
both URIs use the WGS-84 reference system as well, with one of the
URIs specifying the CRS explicitely)
For the default CRS of WGS-84, the following definitions apply
additionally:
o Where the 'latitude' component of a 'geo' URI is set to either 90
or -90 degrees, the 'longitude' component MUST be ignored in
comparison operations.
o A 'longitude' component of 180 degrees MUST be considered equal a
'longitude' component of -180 degrees for the purpose of URI 'longitude' component of -180 degrees for the purpose of URI
comparison. comparison.
An URI with undefined (missing) 'altitude' value MUST NOT be An URI with undefined (missing) 'coord-c' (altitude) value MUST NOT
considered equal to an URI containing an 'altitude' value, even if be considered equal to an URI containing an 'coord-c' value, even if
the remaining values 'latitude' and 'longitude' are equivalent. the remaining values 'coord-a' and 'coord-b' are equivalent.
4.4.3. Interpretation of Undefined Altitude 4.4.4. Interpretation of Undefined Altitude
A consumer of a 'geo' URI with undefined 'altitude' MAY assume that A consumer of a 'geo' URI in the WGS-84 CRS with undefined 'altitude'
the URI refers to the respective location on earth's physical surface MAY assume that the URI refers to the respective location on earth's
at the given 'latitude' and 'longitude' coordinate. physical surface at the given 'latitude' and 'longitude' coordinate.
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 interpreted as "on earth's surface". value of 0 MUST NOT be interpreted as "on earth's surface".
4.5. Encoding Considerations 4.5. Encoding Considerations
The 'geo-location' path component of the 'geo' URI (see Section 4.3) The 'coordinates' path component of the 'geo' URI (see Section 4.3)
uses a comma (",") as a delimiter for subcomponents. This delimiter uses a comma (",") as a delimiter for subcomponents. This delimiter
MUST NOT be percent encoded. MUST NOT be percent encoded.
It is RECOMMENDED that for readability the contents of 'latitude', It is RECOMMENDED that for readability the contents of 'coord-a',
'longitude' and 'altitude' subcomponents are never percent encoded. 'coord-b' and 'coord-c' subcomponents are never percent encoded.
4.6. Applications/protocols That Use This URI Scheme 4.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.
4.7. Interopability Considerations 4.7. Interopability Considerations
skipping to change at page 9, line 36 skipping to change at page 11, line 28
client applications. Users of applications which are not aware of client applications. Users of applications which are not aware of
the 'geo' scheme are likely unable to make direct use of the the 'geo' scheme are likely unable to make direct use of the
information in the URI. However, the simple structure of the 'geo' information in the URI. However, the simple structure of the 'geo'
URI would even allow manual dereference by users. URI would even allow manual dereference by users.
Poorly authored 'geo' URI instances could contain whitespace and Poorly authored 'geo' URI instances could contain whitespace and
values with leading plus signs ("+"), which is not allowed according values with leading plus signs ("+"), which is not allowed according
to the ABNF. Clients SHOULD, however, try to dereference such URIs to the ABNF. Clients SHOULD, however, try to dereference such URIs
after removing such whitespace and plus signs. after removing such whitespace and plus signs.
This specification does not define any URI parameters nor a query This specification does not define a query component. Future
component. Future revisions might define such parameters, using the revisions might define such components, using the "?" character to
";" and "?" characters to delimit parameter and query components from delimit query components from the path component specified above.
the path component specified above. Clients MUST be prepared to Clients MUST be prepared to encounter such 'geo' URI instances, and
encounter such 'geo' URI instances, and MUST reduce the URI to the MUST reduce the URI to the components specified in Section 4.3 before
components specified in Section 4.3 before they dereference the URI. they dereference the URI.
Clients MUST NOT attempt to dereference URIs given in an CRS that is
unknown to the client, because doing so would produce entirely bogus
results.
Authors of 'geo' URIs should carefully check that coordinate
components are set in the specified order, since wrong order of those
components is a commonly observed mistake and produces completely
bogus locations.
4.8. Security Considerations 4.8. Security Considerations
See Section 9 of [insert reference to this document] See Section 9 of [insert reference to this document]
4.9. Contact 4.9. Contact
Christian Spanring (mailto:cspanring@gmail.at, http://spanring.eu/ ), Christian Spanring (mailto:cspanring@gmail.at, http://spanring.eu/ ),
Alexander Mayrhofer (mailto:alexander.mayrhofer@nic.at, Alexander Mayrhofer (mailto:alexander.mayrhofer@nic.at,
http://timatio.com/ ) http://timatio.com/ )
skipping to change at page 11, line 6 skipping to change at page 13, line 6
navigation device, or even use it to locate the identified location navigation device, or even use it to locate the identified location
on a paper map. on a paper map.
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 <a href='geo: <p>one of Vienna's popular sights is the <a href='geo:
48.198634,16.371648'>Karlskirche</a>. 48.198634,16.371648;crs=wgs84'>Karlskirche</a>.
A web brower could extract the coordinates from the HTML snippet, and A web brower could extract the coordinates from the HTML snippet, and
offer the user various options (based on configuration, context), for offer the user various options (based on configuration, context), 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.
o Convert the coordinates to a format suitable for uploading to a o Convert the coordinates to a format suitable for uploading to a
navigation device navigation device
Note that the URI in this example also makes use of the explicit
specification of the CRS by using the 'crs' URI 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, uses the camera on his 1. User identifies such a barcode on a flyer, uses the camera on his
mobile phone to photograph and decode the barcode mobile phone to photograph and decode the barcode
skipping to change at page 11, line 49 skipping to change at page 14, line 5
instructions from his phone to reach the destination instructions from his phone to reach the destination
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 transpose 'geo' URIs from and to GML instructions on how to transpose 'geo' URIs from and to GML
documents. documents.
A 'geo' URI can be authored from a GML "point", and any 'geo' URI can A 'geo' URI can be mapped from a GML "point", and any 'geo' URI can
be mapped to a GML "point". For the following sections, "%lat%", be mapped to a GML "point" (given that both support the CRS used).
"%lon%" and "%alt%" are placeholders for latitude, longitude, and For the following sections, "%lat%", "%lon%" and "%alt%" are
altitude values. Mappings are defined as follows: placeholders for latitude, longitude, and altitude values. Mappings
are defined as follows:
7.1. 'geo' URI without altitude to GML 'Point' 7.1. 'geo' URI without altitude to GML 'Point'
An instance of the 'geo' URI without the altitude element is mapped An instance of a WGS 84 'geo' URI without the altitude element is
to a two-dimensional GML "Point" as follows: mapped to a two-dimensional GML "Point" as follows:
'geo' URI: 'geo' URI:
geo:%lat%,%lon% geo:%lat%,%lon%
GML document: GML document:
<?xml version="1.0" encoding="UTF-8"> <?xml version="1.0" encoding="UTF-8">
<Point srsDimension="2" <Point srsDimension="2"
srsName="urn:ogc:def:crs:EPSG:6.6:4326" srsName="urn:ogc:def:crs:EPSG:6.6:4326"
xmlns="http://www.opengis.net/gml"> xmlns="http://www.opengis.net/gml">
<pos>%lat% %lon%</pos> <pos>%lat% %lon%</pos>
</Point> </Point>
7.2. 'geo' URI with Altitude to GML 'Point' 7.2. 'geo' URI with Altitude to GML 'Point'
A 'geo' URI instance with the altitude element is mapped to a three- A WGS 84 'geo' URI instance with the altitude element is mapped to a
dimensional GML "Point" as follows: three-dimensional GML "Point" as follows:
'geo' URI: 'geo' URI:
geo:%lat%,%lon%,%alt% geo:%lat%,%lon%,%alt%
GML document: GML document:
<?xml version="1.0" encoding="UTF-8"> <?xml version="1.0" encoding="UTF-8">
<Point srsDimension="3" <Point srsDimension="3"
srsName="urn:ogc:def:crs:EPSG:6.6:4979" srsName="urn:ogc:def:crs:EPSG:6.6:4979"
skipping to change at page 13, line 31 skipping to change at page 15, line 31
A GML 'Point' in the reference system identified as A GML 'Point' in the reference system identified as
"urn:ogc:def:crs:EPSG:6.6:4979" is mapped to a 'geo' URI as follows: "urn:ogc:def:crs:EPSG:6.6:4979" is mapped to a 'geo' URI as follows:
GML document: GML document:
<?xml version="1.0" encoding="UTF-8"> <?xml version="1.0" encoding="UTF-8">
<Point srsDimension="3" <Point srsDimension="3"
srsName="urn:ogc:def:crs:EPSG:6.6:4979" srsName="urn:ogc:def:crs:EPSG:6.6:4979"
xmlns="http://www.opengis.net/gml"> xmlns="http://www.opengis.net/gml">
<pos>%lat% %lon%</pos> <pos>%lat% %lon% %alt%</pos>
</Point> </Point>
'geo' URI: 'geo' URI:
geo:%lat%,%lon% geo:%lat%,%lon%,%alt%
Note: GML 'Point' instances in other reference systems MAY be used as Note: GML 'Point' instances in other reference systems could be used
well if a transformation into "urn:ogc:def:crs:EPSG:6.6:4979" is as well if a transformation into "urn:ogc:def:crs:EPSG:6.6:4979" is
defined and applied before the mapping step. defined and applied before the mapping step. It should be noted that
such reprojections are typically not lossless because of the limited
accuracy of the mathematical calculations involved.
8. IANA Considerations 8. IANA Considerations
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 4. are contained in Section 4.
9. Security Considerations 9. Security Considerations
skipping to change at page 14, line 30 skipping to change at page 16, line 30
An example of such an invalid URI would be <geo:94,0> (latitude An example of such an invalid URI would be <geo:94,0> (latitude
"beyond" north pole). "beyond" north pole).
9.2. Location Privacy 9.2. Location Privacy
Location information about individuals is an extremely sensitive Location information about individuals is an extremely sensitive
topic, especially when location is combined with Personally topic, especially when location is combined with Personally
Identifyable Information (PII). Authors of 'geo' URIs MUST consider Identifyable Information (PII). Authors of 'geo' URIs MUST consider
data protection and privacy before publishing such URIs. data protection and privacy before publishing such URIs.
However, it should be noted that a 'geo' URI by itself is just opaque
location information, and privacy considerations typically arise only
when such opaque location information is put in context by combining
it with other information (for example, embedding it within a message
to reflect the current location of a person).
10. Acknowledgements 10. Acknowledgements
The authors wish to acknowledge the helpful contributions from Carl The authors wish to acknowledge the helpful contributions from Carl
Reed, Bill McQuillan, Martin Kofal, Andrew Turner and Kim Sanders. Reed, Bill McQuillan, Martin Kofal, Andrew Turner, Kim Sanders and
Ted Hardie.
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
 End of changes. 43 change blocks. 
105 lines changed or deleted 211 lines changed or added

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