draft-ietf-geopriv-geo-uri-01.txt   draft-ietf-geopriv-geo-uri-02.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: January 4, 2010 OIR-ID Expires: March 5, 2010 September 01, 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-01 draft-ietf-geopriv-geo-uri-02
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 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 January 4, 2010. This Internet-Draft will expire on March 5, 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
skipping to change at page 3, line 7 skipping to change at page 3, line 7
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 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. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. IANA Registration of 'geo' URI Scheme . . . . . . . . . . . . 6
3.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . . 7
3.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 7
3.4. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 8
3.4.1. Coordinate Reference System Identification . . . . . . 8
3.4.2. Component Description for WGS-84 . . . . . . . . . . . 8
3.4.3. Location Uncertainty . . . . . . . . . . . . . . . . . 9
3.4.4. URI Comparison . . . . . . . . . . . . . . . . . . . . 9
3.4.5. Interpretation of Undefined Altitude . . . . . . . . . 10
3.5. Encoding Considerations . . . . . . . . . . . . . . . . . 10
3.6. Applications/Protocols that use this URI Scheme . . . . . 10
3.7. Interopability Considerations . . . . . . . . . . . . . . 11
3.8. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.9. Author/Change controller . . . . . . . . . . . . . . . . . 11
3.10. References . . . . . . . . . . . . . . . . . . . . . . . . 11
4. IANA Registration of 'geo' URI Scheme . . . . . . . . . . . . 7 4. 'geo' URI Parameters Registry . . . . . . . . . . . . . . . . 11
4.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . . 7
4.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 7
4.4. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 9
4.4.1. Coordinate Reference System Identification . . . . . . 9
4.4.2. Component Description for WGS-84 . . . . . . . . . . . 9
4.4.3. URI Comparison . . . . . . . . . . . . . . . . . . . . 10
4.4.4. Interpretation of Undefined Altitude . . . . . . . . . 10
4.5. Encoding Considerations . . . . . . . . . . . . . . . . . 10
4.6. Applications/protocols That Use This URI Scheme . . . . . 11
4.7. Interopability Considerations . . . . . . . . . . . . . . 11
4.8. Security Considerations . . . . . . . . . . . . . . . . . 11
4.9. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.10. Author/Change controller . . . . . . . . . . . . . . . . . 12
4.11. References . . . . . . . . . . . . . . . . . . . . . . . . 12
5. URI Operations . . . . . . . . . . . . . . . . . . . . . . . . 12 5. URI Operations . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Use Cases and Examples . . . . . . . . . . . . . . . . . . . . 12 6. Use Cases and Examples . . . . . . . . . . . . . . . . . . . . 13
6.1. Plain 'geo' URI Example . . . . . . . . . . . . . . . . . 12 6.1. Plain 'geo' URI Example . . . . . . . . . . . . . . . . . 13
6.2. Hyperlink . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Hyperlink . . . . . . . . . . . . . . . . . . . . . . . . 13
6.3. 'geo' URI in 2-dimensional barcode . . . . . . . . . . . . 13 6.3. 'geo' URI in 2-dimensional barcode . . . . . . . . . . . . 14
7. GML Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. 'geo' URI without altitude to GML 'Point' . . . . . . . . 14
7.2. 'geo' URI with Altitude to GML 'Point' . . . . . . . . . . 14
7.3. GML 'Point' without Altitude to 'geo' URI . . . . . . . . 14
7.4. GML 'Point' with Altitude to 'geo' URI . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9.1. Invalid Locations . . . . . . . . . . . . . . . . . . . . 16
9.2. Location Privacy . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Change Log
[Note to editors: This section is to be removed before publication -
XML source available on request]
draft-ietf-geopriv-geo-uri-01 7. GML Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 14
o added parameters to ABNF 7.1. 2D GML 'Point' . . . . . . . . . . . . . . . . . . . . . . 15
o added optional 'crs' parameter to allow future use of other CRSes 7.2. 3D GML 'Point' . . . . . . . . . . . . . . . . . . . . . . 15
o Many other changes to not preclude the future specification of 7.3. GML 'Circle' . . . . . . . . . . . . . . . . . . . . . . . 15
other CRSes. 7.4. GML 'Sphere' . . . . . . . . . . . . . . . . . . . . . . . 16
o some typos fixes - credits Bill McQuillan
draft-ietf-geopriv-geo-uri-00 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
o submitted as WG item 8.1. 'geo' URI Scheme . . . . . . . . . . . . . . . . . . . . . 16
o changed IPR text because of text used from RFC 4395 8.2. URI Parameter Registry . . . . . . . . . . . . . . . . . . 17
o added considerations for comparing +180/-180 longitude URIs 8.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 17
o some editorial changes 8.2.2. Registration Policy . . . . . . . . . . . . . . . . . 17
draft-mayrhofer-geopriv-geo-uri-01 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
o added terminology text about WGS-84 (credits Carl Reed) 9.1. Invalid Locations . . . . . . . . . . . . . . . . . . . . 18
o removed "resolution" / "uncertainty" text 9.2. Location Privacy . . . . . . . . . . . . . . . . . . . . . 18
o added considerations regarding poles 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
o added text about invalid URIs
draft-mayrhofer-geopriv-geo-uri-00 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
o Initial version under new name, reverting to "plain" lat/lon 11.1. Normative References . . . . . . . . . . . . . . . . . . . 19
scheme, with the "tiling" scheme moved to seperate draft 11.2. Informative References . . . . . . . . . . . . . . . . . . 19
(potentially published as "draft-mayrhofer-geopriv-geotile-uri").
refer to draft-mayrhofer-geo-uri-01 for the history of this
document.
o Added GML mapping section
draft-mayrhofer-geo-uri-01 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 19
o removed parameters
draft-mayrhofer-geo-uri-00 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
o initial draft
2. 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.
Over the past few years, fast emerging location aware applications Over the past few years, fast emerging location aware applications
and location based services were observable on the Internet. Most and location based services were observable on the Internet. Most
web search engines use geographic information, and a vivid open web search engines use geographic information, and a vivid open
source mapping community brought an enormous momentum into location source mapping community brought an enormous momentum into location
aware technology. A wide range and former to professionals exclusive aware technology. A wide range of tools and data sets which formerly
tools and data were provided free of charge for an everyday use on were accessible to professional only became available for a wider
the mass market. 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 or trigger further services based on a particular information about a particular location on earth or trigger further
place on earth shouldn't be any harder for users than clicking on a services shouldn't be any harder than clicking on a 'mailto:' link
'mailto:' link and write an email straight away. 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 a coordinate identifies geographic locations (a physical resource) in a coordinate
references system (CRS), per default in World Geodetic System 1984 references system (CRS), per default in World Geodetic System 1984
(WGS-84) [WGS84]. The optional "crs" URI parameter described below (WGS-84) [WGS84]. The scheme provides the textual representation of
may be used by future specifications to define the use of other the location's spatial coordinates in either two or three dimensions
CRSes. However, such definitions are out of scope of this document. (latitude, longitude, and optionally altitude for the default CRS of
WGS-84).
'Geo' URIs identify a geographic location using a textual Such URIs are independent from a specific protocol, application, or
representation of the location's spatial coordinates in either two or data format, and can be used in any other protocol or data format
three dimensions (latitude, longitude, and optionally altitude for that supports inclusion of arbitrary URIs.
the default CRS of WGS-84). Such URIs are independent from a
specific protocol, application, or data format, and can be used in
any other protocol or data format 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. The provision of more of a spatial location - a single point in a well known CRS. The
complex geometries or locations described by civic addresses is out provision of more complex geometries or locations described by civic
of scope of this document. addresses is out of scope of this document.
The optional "crs" URI parameter described below may be used by
future specifications to define the use of CRSes other than WGS-84.
This is primarily intended to cope with the case of another CRS
replacing WGS-84 as the predominantly used one, rather than allowing
the arbitrary use of thousands of CRSes for the URI (which would
clearly affect interopability). The definition of "crs" values
beyond the default of "wgs84" is therefore out of scope of this
document.
Note: The choice of WGS-84 as the default CRS is based on the Note: The choice of WGS-84 as the default CRS is based on the
widespread availability of Global Positioning System (GPS) devices, widespread availability of Global Positioning System (GPS) devices,
which use the WGS-84 reference system. It is anticipated that such which use the WGS-84 reference system. It is anticipated that such
devices serve as one of the primary data sources for authoring 'geo' devices serve as one of the primary data sources for authoring 'geo'
URIs, hence the adoption of the native GPS reference system for the URIs, hence the adoption of the native GPS reference system for the
URI scheme. Also, many other data formats for representing 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). projection involved). It is also believed that the burden of
potentially required spatial transformations should be put on the
author rather then the consumer of 'geo' URI instances.
3. 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 here represented as a
skipping to change at page 7, line 30 skipping to change at page 6, line 47
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].
4. IANA Registration of 'geo' URI Scheme 3. IANA Registration of 'geo' URI Scheme
This section contains the fields required for the URI scheme This section contains the fields required for the URI scheme
registration, following the guidelines in section 5.4 of [RFC4395]. registration, following the guidelines in section 5.4 of [RFC4395].
4.1. URI Scheme Name 3.1. URI Scheme Name
geo geo
4.2. Status 3.2. Status
permanent permanent
4.3. URI Scheme Syntax 3.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) [RFC5234]:
geo-URI = geo-scheme ":" geo-path geo-URI = geo-scheme ":" geo-path
geo-scheme = "geo" geo-scheme = "geo"
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 / parameter p = crsp / uncp / parameter
crsp = ";crs=" crslabel crsp = ";crs=" crslabel
crslabel = "wgs84" crslabel = "wgs84" / labeltext
uncp = ";u=" pnum
parameter = ";" pname [ "=" pvalue ] parameter = ";" pname [ "=" pvalue ]
pname = 1*( alphanum / '-' ) pname = labeltext
pvalue = 1*paramchar pvalue = 1*paramchar
paramchar = p-unreserved / unreserved / pct-encoded paramchar = p-unreserved / unreserved / pct-encoded
num = [ "-" ] 1*DIGIT [ "." 1*DIGIT ] labeltext = 1*( alphanum / "-" )
pnum = 1*DIGIT [ "." 1*DIGIT ]
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
The optional "crs" parameter MUST NOT appear more than once. If Both "crs" and "u" parameters MUST NOT appear more than once each.
other parameters are also given, the "crs" parameter MUST be given The "crs" and "u" parameters MUST be given before any other
first. The definition of other parameters besides "crs" is out of parameters that may be defined in future extensions. The "crs"
scope for this document. parameter MUST be given first if both "crs" and "u" are used. The
definition of other parameters, and "crs" values beyond the default
Future documents proposing the use of other CRSes may update the value of "wgs84" is out of scope of this document. Section 8.2
definition of the 'crslabel' component. discusses the IANA registration of such additional 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: its 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 ]
4.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 on earth in the in a coordinate reference system, spatial location on earth identified by the geographic coordinates
identified by the geographic coordinates encoded in the URI. encoded in the URI.
4.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 the 'coordinates' component depends on the CRS of
the URI. The CRS itself is identified by the optional 'crs' the URI. The CRS itself is identified by the optional 'crs'
parameter the default. A URI instance uses the default WGS-84 CRS if parameter. A URI instance uses the default WGS-84 CRS if the 'crs'
the 'crs' parameter is either missing, or contains the value of parameter is either missing, or contains the value of 'wgs84'. Other
'wgs84'. Other 'crs' values are not currently defined, but may be 'crs' values are currently not defined, but may be specified by
specified by future documents. future documents.
Interpretation of coordinates in a wrong CRS produces invalid Interpretation of coordinates in a 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 attempt to ignore the 'crs' parameter if given, and MUST NOT interpret the
interpret the 'coordinates' component of given in an unknown CRS. 'coordinates' component without considering and understanding 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.
4.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 4.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 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 "longitude" component MUST contain the longitude 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. identified altitude 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, 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 from -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.
4.4.3. URI Comparison 3.4.3. Location 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
identify the location of a particular subject, uncertainty indicates
the uncertainty with which the identified location of the subject is
known.
The 'u' parameter is optional and it can appear only once. If
uncertainty is not specified, this indicates that uncertainty is
unknown or unspecified. If the intent is to indicate a specific
point in space, uncertainty MAY be set to zero. Zero uncertainty and
absent uncertainty are never the same thing.
Note: The number of significant digits of the value in the
'coordinates' component MUST NOT be interpreted as an indication to
uncertainty.
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 their
'coord-a', 'coord-b' and 'coord-c' values are mathematically 'coord-a', 'coord-b', 'coord-c' and 'u' values are mathematically
identical. identical.
Two 'geo' URIs use the same CRS if: Two URIs use the same CRS if both have the 'crs' parameter omitted,
o their 'crslabel' components are identical or both have the same 'crs' parameter value, or one has the 'crs'
o or if neither URIs contain a 'crs' parameter (in which case both parameter omitted while the other URI specifies the default CRS
URIs use WGS-84) explicitely with a 'crs' parameter value of "wgs84".
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 For the default CRS of WGS-84, the following definitions apply in
additionally: addition:
o Where the 'latitude' component of a 'geo' URI is set to either 90 o Where the 'latitude' component of a 'geo' URI is set to either 90
or -90 degrees, the 'longitude' component MUST be ignored in or -90 degrees, the 'longitude' component MUST be ignored in
comparison operations. comparison operations ("poles case").
o A 'longitude' component of 180 degrees MUST be considered equal a 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 ("date line" case).
An URI with undefined (missing) 'coord-c' (altitude) value MUST NOT An URI with undefined (missing) 'coord-c' (altitude) value MUST NOT
be considered equal to an URI containing an 'coord-c' value, even if be considered equal to an URI containing an 'coord-c' value, even if
the remaining values 'coord-a' and 'coord-b' are equivalent. the remaining values 'coord-a', 'coord-b' and 'u' are equivalent.
4.4.4. 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' 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 mistaken to refer to "ground elevation".
4.5. Encoding Considerations 3.5. Encoding Considerations
The 'coordinates' path component of the 'geo' URI (see Section 4.3) The 'coordinates' path component of the 'geo' URI (see Section 3.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 'coord-a', It is RECOMMENDED that for readability the contents of 'coord-a',
'coord-b' and 'coord-c' subcomponents are never percent encoded. 'coord-b' and 'coord-c' subcomponents, as well as the 'crs' and 'u'
parameters are never percent encoded.
4.6. Applications/protocols That Use This URI Scheme Regarding internationalization, the currently specified components do
allow for ASCII characters exclusively, and therefore don't require
internationalization- Future specifications of additional parameters
might allow for introduction of non-ASCII values. Such
specifications MUST describe internationalization considerations for
those parameters and their values.
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.
4.7. Interopability Considerations 3.7. Interopability Considerations
As with any other new URI scheme, the 'geo' URI requires support in
client applications. Users of applications which are not aware of
the 'geo' scheme are likely unable to make direct use of the
information in the URI. However, the simple structure of the 'geo'
URI would even allow manual dereference by users.
Poorly authored 'geo' URI instances could contain whitespace and
values with leading plus signs ("+"), which is not allowed according
to the ABNF. Clients SHOULD, however, try to dereference such URIs
after removing such whitespace and plus signs.
This specification does not define a query component. Future Like other new URI schemes, the 'geo' URI requires support in client
revisions might define such components, using the "?" character to applications. Users of applications which are not aware of the 'geo'
delimit query components from the path component specified above. scheme are likely unable to make direct use of the information in the
Clients MUST be prepared to encounter such 'geo' URI instances, and URI. However, the simple structure of the 'geo' URI would even allow
MUST reduce the URI to the components specified in Section 4.3 before manual dereference by humans.
they dereference the URI.
Clients MUST NOT attempt to dereference URIs given in an CRS that is Clients MUST NOT attempt to dereference URIs given in an CRS that is
unknown to the client, because doing so would produce entirely bogus unknown to the client, because doing so would produce entirely bogus
results. results.
Authors of 'geo' URIs should carefully check that coordinate Authors of 'geo' URIs should carefully check that coordinate
components are set in the specified order, since wrong order of those components are set in the right CRS and in the specified order, since
components is a commonly observed mistake and produces completely wrong order of those components (or use of coordinates in a different
bogus locations. CRS without transformation) are commonly observed mistakes producing
completely bogus locations.
4.8. Security Considerations
See Section 9 of [insert reference to this document] The number of digits in the coordinates values MUST NOT be
interpreted as an indication to a certain level of accuracy or
uncertainty.
4.9. Contact 3.8. Contact
Christian Spanring (mailto:cspanring@gmail.at, http://spanring.eu/ ), Alexander Mayrhofer <alexander.mayrhofer@nic.at>
Alexander Mayrhofer (mailto:alexander.mayrhofer@nic.at, Christian Spanring <cspanring@gmail.com>
http://timatio.com/ )
4.10. 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.
4.11. 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
This specification creates a new IANA Registry named "'geo' URI
Parameters Registry". Parameters for the 'geo' URI and values for
these parameters MUST be registered with IANA to prevent namespace
collisions, and provide interopability.
Some parameters accept values that are constrained by a syntax
definition only, while others accept values from a predefined set
only. Some parameters might not accept any values at all ("flag"
type parameter).
The registration of values is REQUIRED for parameters that accept
values from a predefined set only.
The specification of a parameter MUST fully explain the syntax,
intended usage and semantics of the parameter. This ensures
interopability between independent implementations.
For parameters that are neither restricted to a set of predefined
values nor of the "flag" type described above, the syntax of allowed
values MUST be described in the specification, for example by using
ABNF.
Documents defining new parameters (or new values for existing
parameters) MUST register them with IANA, as explained in
Section 8.2.
The 'geo' URI Parameter Registry contains a column named "Value
Restriction" that describes whether or not a parameter accepts a
value, and whether values are restricted to a predefined set. That
column accepts the following values:
o "No value": The parameter does not accept any values, and is to be
used as a "flag" only.
o "Predefined": The parameter does accept values from a predefined
set only, as specified in a RFC or other permanent and readily
available public specification.
o "Constrained": The parameter accepts arbitrary values that are
only constrained by a syntax as specified in a RFC or other
permanent and readily available public specification.
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 is then ('geo-path' in the ABNF). Further use of those coordinates (and the
up to the application processing the URI, and might depend on the uncertainty value from the 'u' parameter) is then up to the
context of the URI. application processing the URI, and might depend on the context of
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 web mapping
service of the user's choice, and display a map of the location service 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
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
The following 3-dimensional 'geo' URI example references to the The following 3-dimensional 'geo' URI example references to the
office location of one of the authors in Vienna, Austria: office location of one of the authors in Vienna, Austria:
geo:48.2010,16.3695,183 geo:48.2010,16.3695,183
A user could type the data extracted from this URI into a electronic A user could type the data extracted from this URI into a electronic
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
48.198634,16.371648;crs=wgs84'>Karlskirche</a>. <a href='geo:48.198634,16.371648;crs=wgs84'>Karlskirche</a>.
A web brower could extract the coordinates from the HTML snippet, and A web browser could extract the coordinates from the HTML snippet,
offer the user various options (based on configuration, context), for and offer the user various options (based on configuration, context),
example: for 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 Note that the URI in this example also makes use of the explicit
specification of the CRS by using the 'crs' URI 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, uses the camera on his 1. User identifies such a barcode on a flyer and uses the camera on
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, the user follows the navgiation 3. Using the builtin GPS receiver, the user follows the navgiation
instructions from his phone to reach the destination 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 transpose 'geo' URIs from and to GML instructions on how to transpose 'geo' URIs from and to GML
documents. documents. The instructions in this section are not normative.
A 'geo' URI can be mapped from a GML "point", and any 'geo' URI can For the following sections, "%lat%", "%lon%", "%alt%" and "%unc%" are
be mapped to a GML "point" (given that both support the CRS used). placeholders for latitude, longitude, altitude and uncertainty
For the following sections, "%lat%", "%lon%" and "%alt%" are values. The mappings use WGS-84, and are defined in the following
placeholders for latitude, longitude, and altitude values. Mappings sections.
are defined as follows:
7.1. 'geo' URI without altitude to GML 'Point' Note: GML documents in other reference systems could be used as well
if a transformation into "urn:ogc:def:crs:EPSG::4979" or
"urn:ogc:def:crs:EPSG::4326" is defined and applied before the
mapping step. Such transformations are typically not lossless.
An instance of a WGS 84 'geo' URI without the altitude element is GML uses the 'double' type from XML schema, and the mapping examples
mapped to a two-dimensional GML "Point" as follows: assume that numbers in the form of "3.32435e2" in GML are properly
converted to decimal when placed in the 'geo' URI.
7.1. 2D GML 'Point'
A 2D GML 'Point' [RFC5491] is constructed from a 'geo' URI that has
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
uncertainty parameter.
'geo' URI: 'geo' URI:
geo:%lat%,%lon% geo:%lat%,%lon%
GML document: GML document:
<?xml version="1.0" encoding="UTF-8"> <Point srsName="urn:ogc:def:crs:EPSG::4326"
<Point srsDimension="2"
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' 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'
URI with zero uncertainty.
A WGS 84 'geo' URI instance with the altitude element is mapped to a 7.2. 3D GML 'Point'
three-dimensional GML "Point" as follows:
A 3D GML 'Point' [RFC5491] is constructed from a 'geo' URI that has
three coordinates and an uncertainty parameter that is absent or
zero. A GML point is always converted to a 'geo' URI that has no
uncertainty parameter.
'geo' URI: 'geo' URI:
geo:%lat%,%lon%,%alt% geo:%lat%,%lon%,%alt%
GML document: GML document:
<?xml version="1.0" encoding="UTF-8"> <Point srsName="urn:ogc:def:crs:EPSG::4979"
<Point srsDimension="3"
srsName="urn:ogc:def:crs:EPSG:6.6: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 'Point' without Altitude to 'geo' URI 7.3. GML 'Circle'
A GML 'Point' in the reference system identified as
"urn:ogc:def:crs:EPSG:6.6:4326" is mapped to a 'geo' URI as follows:
GML document:
<?xml version="1.0" encoding="UTF-8"> A GML 'Circle' [RFC5491] is constructed from a 'geo' URI that has two
<Point srsDimension="2" coordinates and an uncertainty parameter that is present and non-
srsName="urn:ogc:def:crs:EPSG:6.6:4326" zero.
xmlns="http://www.opengis.net/gml">
<pos>%lat% %lon%</pos>
</Point>
'geo' URI: 'geo' URI:
geo:%lat%,%lon% geo:%lat%,%lon%;u=%unc%
Note: GML documents in other reference systems MAY be used as well if
a transformation into "urn:ogc:def:crs:EPSG:6.6:4326" is defined and
applied before the mapping step.
7.4. GML 'Point' with Altitude to 'geo' URI GML document:
A GML 'Point' in the reference system identified as <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326"
"urn:ogc:def:crs:EPSG:6.6:4979" is mapped to a 'geo' URI as follows: xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0">
<gml:pos>%lat% %lon%</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
%unc%
</gs:radius>
</gs:Circle>
GML document: 7.4. GML 'Sphere'
<?xml version="1.0" encoding="UTF-8"> A GML 'sphere' [RFC5491] is constructed from a 'geo' URI that has
<Point srsDimension="3" three coordinates and an uncertainty parameter that is present and
srsName="urn:ogc:def:crs:EPSG:6.6:4979" non-zero.
xmlns="http://www.opengis.net/gml">
<pos>%lat% %lon% %alt%</pos>
</Point>
'geo' URI: 'geo' URI:
geo:%lat%,%lon%,%alt% geo:%lat%,%lon%,%alt%;u=%unc%
Note: GML 'Point' instances in other reference systems could be used GML document:
as well if a transformation into "urn:ogc:def:crs:EPSG:6.6:4979" is
defined and applied before the mapping step. It should be noted that <gs:Sphere srsName="urn:ogc:def:crs:EPSG::4979"
such reprojections are typically not lossless because of the limited xmlns:gml="http://www.opengis.net/gml"
accuracy of the mathematical calculations involved. xmlns:gs="http://www.opengis.net/pidflo/1.0">
<gml:pos>%lat% %lon% %alt%</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
%unc%
</gs:radius>
</gs:Sphere>
8. IANA Considerations 8. IANA Considerations
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 4. are contained in Section 3.
8.2. URI Parameter Registry
This document creates a new IANA Registry named "geo URI Parameters",
according to the information in Section 4 and the definition in this
section.
8.2.1. Registry Contents
When registering a new 'geo' URI Parameter, the following information
MUST be provided:
o Name of the Parameter.
o Whether the Parameter accepts no value ("No value"), values from a
predefined set ("Predefined"), or values constrained by a syntax
only ("Constrained").
o Reference to the RFC or other permanent and readily available
public specification defining the parameters and the new values.
When registering a new value for an existing 'geo' URI Parameter, the
following information MUST be provided:
o Name of the Parameter.
o Reference to the RFC or other permanent and readily available
public specification defining the new values.
The following table provides the initial values for this registry:
Parameter Name Value Restriction Reference(s)
----------------------------------------------------------
crs Predefined [RFCxxxx]
u Constrained [RFCxxxx]
[Note to RFC Editor: Replace RFCxxxx with reference to this document]
8.2.2. Registration Policy
The Registration Policy for 'geo' URI Parameters and their value
definitions shall be "Specification Required, Designated Expert", as
defined in [RFC5226].
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 4.3) makes it possible to construct valid The URI syntax (Section 3.3) makes it possible to construct 'geo'
'geo' URIs which don't identify a valid location on earth. URIs which don't identify a valid location on earth. Applications
Applications MUST NOT use URIs which such invalid values, and SHOULD MUST NOT use URIs with such values, and SHOULD warn the user when
warn the user when such URIs are encountered. such URIs are encountered.
An example of such an invalid URI would be <geo:94,0> (latitude An example of such an URI refering to an invalid location would be
"beyond" north pole). <geo:94,0> (latitude "beyond" north pole).
9.2. Location Privacy 9.2. Location Privacy
Location information about individuals is an extremely sensitive A 'geo' URI by itself is just an opaque reference to a physical
topic, especially when location is combined with Personally location, expressed by a set of spatial oordinates. This does not
Identifyable Information (PII). Authors of 'geo' URIs MUST consider fit the "Location Information" definition according to Section 5.2 of
data protection and privacy before publishing such URIs. GEOPRIV Requirements [RFC3693], because there is not necessarily a
"Device" involved.
However, it should be noted that a 'geo' URI by itself is just opaque Because there is also no way to specify the identity of a "Target" in
location information, and privacy considerations typically arise only a 'geo' URI by itself, it does also not fit the specification of an
when such opaque location information is put in context by combining "Location Object" (Section 5.2 of RFC3693).
it with other information (for example, embedding it within a message
to reflect the current location of a person). However, by putting a 'geo' URI into a context that allows
identification of a "Target", the URI might become part of a
"Location Object", and would then be subject to GEOPRIV rules.
Therefore, Publishers of 'geo' URIs that are put into such contexts
MUST consider privacy issues, particularly in cases where a URI
instance is combined with Personally Identifyable Information (PII)
with the intent to describe the location of a Target that is a
person.
10. Acknowledgements 10. Acknowledgements
The authors wish to acknowledge the helpful contributions from Carl Martin Thomson has provided significant text around the definition of
Reed, Bill McQuillan, Martin Kofal, Andrew Turner, Kim Sanders and the "uncertainty" parameter and the GML mappings.
Ted Hardie.
The authors further wish to acknowledge the helpful contributions
from Carl Reed, Bill McQuillan, Martin Kofal, Andrew Turner, Kim
Sanders, Ted Hardie, Culllen Jennings, Klaus Darilion and Bjorn
Hoehrmann.
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.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
A., Peterson, J., Sparks, R., Handley, M., and E. Presence Information Data Format Location Object (PIDF-LO)
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Usage Clarification, Considerations, and Recommendations",
June 2002. RFC 5491, March 2009.
11.2. Informative References 11.2. Informative References
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 115, Registration Procedures for New URI Schemes", BCP 115,
RFC 4395, February 2006. RFC 4395, February 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[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
[Note to editors: This section is to be removed before publication -
XML source available on request]
draft-ietf-geopriv-geo-uri-02
o Added IANA registry for 'geo' URI Parameters and values
o Moved change log to appendix
o Added "u" parameter to ABNF, restructred ABNF slightly
o Added new section describing uncertainty
o Changed mapping examples, added some for uncertainty
o Added text that number of digits shouldn't be confused with
uncertainty or accuracy
o marked GML mappings as non-normative based on URI expert review
advice
o added internationalization consideration section
o various other changes based on Expert Review
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
o submitted as WG item
o changed IPR text because of text used from RFC 4395
o added considerations for comparing +180/-180 longitude URIs
o some editorial changes
draft-mayrhofer-geopriv-geo-uri-01
o added terminology text about WGS-84 (credits Carl Reed)
o removed "resolution" / "uncertainty" text
o added considerations regarding poles
o added text about invalid URIs
draft-mayrhofer-geopriv-geo-uri-00
o Initial version under new name, reverting to "plain" lat/lon
scheme, with the "tiling" scheme moved to seperate draft
(potentially published as "draft-mayrhofer-geopriv-geotile-uri").
refer to draft-mayrhofer-geo-uri-01 for the history of this
document.
o Added GML mapping section
draft-mayrhofer-geo-uri-01
o removed parameters
draft-mayrhofer-geo-uri-00
o initial draft
Authors' Addresses Authors' Addresses
Alexander Mayrhofer Alexander Mayrhofer
nic.at GmbH nic.at GmbH
Karlsplatz 1/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://www.nic.at/
Christian Spanring Christian Spanring
OIR-ID GmbH 5 Crawford St
Franz-Josefs-Kai 27 Cambridge 02139
Wien A-1010
Phone: +43 1 5338747 36 Phone: +1 617 800 7885
Email: cspanring@gmail.com Email: christian@spanring.eu
URI: http://www.oir.at/ URI: http://www.spanring.eu/
 End of changes. 105 change blocks. 
280 lines changed or deleted 437 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/