draft-ietf-geopriv-geo-uri-07.txt   rfc5870.txt 
GEOPRIV -- Geographic A. Mayrhofer Internet Engineering Task Force (IETF) A. Mayrhofer
Location/Privacy Working Group IPCom Request for Comments: 5870 IPCom
Internet-Draft C. Spanring Category: Standards Track C. Spanring
Intended status: Standards Track April 14, 2010 ISSN: 2070-1721 June 2010
Expires: October 16, 2010
A Uniform Resource Identifier for Geographic Locations ('geo' URI) A Uniform Resource Identifier for Geographic Locations ('geo' URI)
draft-ietf-geopriv-geo-uri-07
Abstract Abstract
This document specifies a Uniform Resource Identifier (URI) for This document specifies a Uniform Resource Identifier (URI) for
geographic locations using the 'geo' scheme name. A 'geo' URI geographic locations using the 'geo' scheme name. A 'geo' URI
identifies a physical location in a two- or three-dimensional identifies a physical location in a two- or three-dimensional
coordinate reference system in a compact, simple, human-readable, and coordinate reference system in a compact, simple, human-readable, and
protocol-independent way. The default coordinate reference system protocol-independent way. The default coordinate reference system
used is WGS-84. used is the World Geodetic System 1984 (WGS-84).
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on October 16, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5870.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 22 skipping to change at page 3, line 8
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. IANA Registration of the 'geo' URI Scheme . . . . . . . . . . 6
3. IANA Registration of 'geo' URI Scheme . . . . . . . . . . . . 6
3.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . . 6 3.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . . 6
3.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 6 3.3. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 6
3.4. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 7 3.4. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 7
3.4.1. Coordinate Reference System Identification . . . . . . 7 3.4.1. Coordinate Reference System Identification . . . . . . 7
3.4.2. Component Description for WGS-84 . . . . . . . . . . . 8 3.4.2. Component Description for WGS-84 . . . . . . . . . . . 8
3.4.3. Location Uncertainty . . . . . . . . . . . . . . . . . 8 3.4.3. Location Uncertainty . . . . . . . . . . . . . . . . . 8
3.4.4. URI Comparison . . . . . . . . . . . . . . . . . . . . 9 3.4.4. URI Comparison . . . . . . . . . . . . . . . . . . . . 9
3.4.5. Interpretation of Undefined Altitude . . . . . . . . . 10 3.4.5. Interpretation of Undefined Altitude . . . . . . . . . 10
3.5. Encoding Considerations . . . . . . . . . . . . . . . . . 10 3.5. Encoding Considerations . . . . . . . . . . . . . . . . . 10
3.6. Applications/Protocols that use this URI Scheme . . . . . 10 3.6. Applications/Protocols That Use This URI Scheme . . . . . 11
3.7. Interopability Considerations . . . . . . . . . . . . . . 11 3.7. Interoperability Considerations . . . . . . . . . . . . . 11
3.8. Security Considerations . . . . . . . . . . . . . . . . . 11 3.8. Security Considerations . . . . . . . . . . . . . . . . . 11
3.9. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.9. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.10. Author/Change controller . . . . . . . . . . . . . . . . . 11 3.10. Author/Change Controller . . . . . . . . . . . . . . . . . 12
3.11. References . . . . . . . . . . . . . . . . . . . . . . . . 11 3.11. References . . . . . . . . . . . . . . . . . . . . . . . . 12
4. 'geo' URI Parameters Registry . . . . . . . . . . . . . . . . 12
4. 'geo' URI Parameters Registry . . . . . . . . . . . . . . . . 11 5. URI Operations . . . . . . . . . . . . . . . . . . . . . . . . 13
5. URI Operations . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Use Cases and Examples . . . . . . . . . . . . . . . . . . . . 13 6. Use Cases and Examples . . . . . . . . . . . . . . . . . . . . 13
6.1. Plain 'geo' URI Example . . . . . . . . . . . . . . . . . 13 6.1. Plain 'geo' URI Example . . . . . . . . . . . . . . . . . 13
6.2. Hyperlink . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Hyperlink . . . . . . . . . . . . . . . . . . . . . . . . 14
6.3. 'geo' URI in 2-dimensional barcode . . . . . . . . . . . . 14 6.3. 'geo' URI in 2-Dimensional Barcode . . . . . . . . . . . . 15
6.4. Comparison Examples . . . . . . . . . . . . . . . . . . . 15 6.4. Comparison Examples . . . . . . . . . . . . . . . . . . . 15
7. GML Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. GML Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.1. 2D GML 'Point' . . . . . . . . . . . . . . . . . . . . . . 17
7.1. 2D GML 'Point' . . . . . . . . . . . . . . . . . . . . . . 16 7.2. 3D GML 'Point' . . . . . . . . . . . . . . . . . . . . . . 17
7.2. 3D GML 'Point' . . . . . . . . . . . . . . . . . . . . . . 16
7.3. GML 'Circle' . . . . . . . . . . . . . . . . . . . . . . . 17 7.3. GML 'Circle' . . . . . . . . . . . . . . . . . . . . . . . 17
7.4. GML 'Sphere' . . . . . . . . . . . . . . . . . . . . . . . 17 7.4. GML 'Sphere' . . . . . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8.1. 'geo' URI Scheme . . . . . . . . . . . . . . . . . . . . . 18 8.1. 'geo' URI Scheme . . . . . . . . . . . . . . . . . . . . . 18
8.2. URI Parameter Registry . . . . . . . . . . . . . . . . . . 18 8.2. URI Parameter Registry . . . . . . . . . . . . . . . . . . 19
8.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 18 8.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 19
8.2.2. Registration Policy . . . . . . . . . . . . . . . . . 19 8.2.2. Registration Policy . . . . . . . . . . . . . . . . . 19
8.3. Sub-Registry for 'crs' Parameter . . . . . . . . . . . . . 19 8.3. Sub-Registry for 'crs' Parameter . . . . . . . . . . . . . 20
8.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 19 8.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 20
8.3.2. Registration Policy . . . . . . . . . . . . . . . . . 20 8.3.2. Registration Policy . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9.1. Invalid Locations . . . . . . . . . . . . . . . . . . . . 20 9.1. Invalid Locations . . . . . . . . . . . . . . . . . . . . 21
9.2. Location Privacy . . . . . . . . . . . . . . . . . . . . . 20 9.2. Location Privacy . . . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
An increasing number of Internet protocols and data formats are An increasing number of Internet protocols and data formats are
extended by specifications for adding spatial (geographic) location. extended by specifications for adding spatial (geographic) location.
In most cases, latitude as well as longitude of simple points are In most cases, latitude as well as longitude of simple points are
added as new attributes to existing data structures. However, all added as new attributes to existing data structures. However, all
those methods are very specific to a certain data format or protocol, those methods are very specific to a certain data format or protocol,
and don't provide a protocol-independent, compact and generic way to and don't provide a protocol-independent, compact, and generic way to
refer to a physical geographic location. refer to a physical geographic location.
Location-aware applications and location-based services are fast Location-aware applications and location-based services are fast
emerging on the Internet. Most web search engines use geographic emerging on the Internet. Most web search engines use geographic
information, and a vivid open source mapping community has brought an information, and a vivid open source mapping community has brought an
enormous momentum into location aware technology. A wide range of enormous momentum into location aware technology. A wide range of
tools and data sets which formerly were accessible to professionals tools and data sets that formerly were accessible to professionals
only have became available to a wider audience. only recently have become available to a wider audience.
The 'geo' URI scheme is another step into that direction and aims to The 'geo' URI scheme is another step in that direction and aims to
facilitate, support and standardize the problem of location facilitate, support, and standardize the problem of location
identification in geospatial services and applications. Accessing identification in geospatial services and applications. Accessing
information about a particular location or triggering further information about a particular location or triggering further
services shouldn't be any harder than clicking on a 'mailto:' link services shouldn't be any harder than clicking on a 'mailto:' link
and writing an email straight away. and writing an email straight away.
According to [RFC3986], a Uniform Resource Identifier (URI) is "a According to [RFC3986], a Uniform Resource Identifier (URI) is "a
compact sequence of characters that identifies an abstract or compact sequence of characters that identifies an abstract or
physical resource". The 'geo' URI scheme defined in this document physical resource". The 'geo' URI scheme defined in this document
identifies geographic locations (physical resources) in a coordinate identifies geographic locations (physical resources) in a coordinate
reference system (CRS), per default the World Geodetic System 1984 reference system (CRS), which is, by default, the World Geodetic
(WGS-84) [WGS84]. The scheme provides the textual representation of System 1984 (WGS-84) [WGS84]. The scheme provides the textual
the location's spatial coordinates in either two or three dimensions representation of the location's spatial coordinates in either two or
(latitude, longitude, and optionally altitude for the default CRS of three dimensions (latitude, longitude, and optionally altitude for
WGS-84). An example of such an 'geo' URI follows: the default CRS of WGS-84). An example of such a 'geo' URI follows:
geo:13.4125,103.8667 geo:13.4125,103.8667
Such URIs are independent from a specific protocol, application, or Such URIs are independent from a specific protocol, application, or
data format, and can be used in any other protocol or data format data format, and can be used in any other protocol or data format
that supports inclusion of arbitrary URIs. that supports inclusion of arbitrary URIs.
For the sake of usability, the definition of the URI scheme is For the sake of usability, the definition of the URI scheme is
strictly focused on the simplest, but also most common representation strictly focused on the simplest, but also most common representation
of a spatial location - a single point in a well known CRS. The of a spatial location -- a single point in a well known CRS. The
provision of more complex geometries or locations described by civic provision of more complex geometries or locations described by civic
addresses is out of scope of this document. addresses is out of scope of this document.
The optional 'crs' URI parameter described below may be used by The optional 'crs' URI parameter described below may be used by
future specifications to define the use of CRSes other than WGS-84. future specifications to define the use of CRSes other than WGS-84.
This is primarily intended to cope with the case of another CRS This is primarily intended to cope with the case of another CRS
replacing WGS-84 as the predominantly used one, rather than allowing replacing WGS-84 as the predominantly used one, rather than allowing
the arbitrary use of thousands of CRSes for the URI (which would the arbitrary use of thousands of CRSes for the URI (which would
clearly affect interopability). The definition of 'crs' values clearly affect interoperability). The definition of 'crs' values
beyond the default of "wgs84" is therefore out of scope of this beyond the default of "wgs84" is therefore out of scope of this
document. document.
This spec discourages use of alternate CRSes in use cases where This specification discourages use of alternate CRSes in use cases
comparison is an important function. where comparison is an important function.
Note: The choice of WGS-84 as the default CRS is based on the Note: The choice of WGS-84 as the default CRS is based on the
widespread availability of Global Positioning System (GPS) devices, widespread availability of Global Positioning System (GPS) devices,
which use the WGS-84 reference system. It is anticipated that such which use the WGS-84 reference system. It is anticipated that such
devices will serve as one of the primary data sources for authoring devices will serve as one of the primary data sources for authoring
'geo' URIs, hence the adoption of the native GPS reference system for 'geo' URIs, hence the adoption of the native GPS reference system for
the URI scheme. Also, many other data formats for representing the URI scheme. Also, many other data formats for representing
geographic locations use the WGS-84 reference system, which makes geographic locations use the WGS-84 reference system, which makes
transposing from and to such data formats less error prone (no re- transposing from and to such data formats less error prone (no re-
projection involved). It is also believed that the burden of projection involved). It is also believed that the burden of
potentially required spatial transformations should be put on the potentially required spatial transformations should be put on the
author rather then the consumer of 'geo' URI instances. author rather then the consumer of 'geo' URI instances.
Because of their similar structure, 'geo' URI instances can also be
mapped from and to certain ISO 6709 [ISO.6709.2008] string
representations of geographic point locations.
2. Terminology 2. Terminology
Geographic locations in this document are defined using WGS-84 (World Geographic locations in this document are defined using WGS-84 (World
Geodetic System 1984), equivalent to the International Association of Geodetic System 1984), which is equivalent to the International
Oil & Gas Producers (OGP) Surveying and Positioning Committee EPSG Association of Oil & Gas Producers (OGP) Surveying and Positioning
(European Petroleum Survey Group) code 4326 (2 dimensions) and 4979 Committee EPSG (European Petroleum Survey Group) codes 4326 (2
(3 dimensions). This document does not assign responsibilities for dimensions) and 4979 (3 dimensions). This document does not assign
coordinate transformations from and to other Spatial Reference responsibilities for coordinate transformations from and to other
Systems. Spatial Reference Systems.
A 2-dimensional WGS-84 coordinate value is represented here as a A 2-dimensional WGS-84 coordinate value is represented here as a
comma-delimited latitude/longitude pair, measured in decimal degrees comma-delimited latitude/longitude pair, measured in decimal degrees
(un-projected). A 3-dimensional WGS-84 coordinate value is (un-projected). A 3-dimensional WGS-84 coordinate value is
represented here by appending a comma-delimited altitude value in represented here by appending a comma-delimited altitude value in
meters to such pairs. meters to such pairs.
Latitudes range from -90 to 90 and longitudes range from -180 to 180. Latitudes range from -90 to 90 and longitudes range from -180 to 180.
Coordinates in the Southern and Western hemispheres as well as Coordinates in the Southern and Western hemispheres as well as
altitudes below the WGS-84 reference geoid are signed negative with a altitudes below the WGS-84 reference geoid (depths) are signed
leading dash. negative with a 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].
3. IANA Registration of 'geo' URI Scheme 3. IANA Registration of the '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].
3.1. URI Scheme Name 3.1. URI Scheme Name
geo geo
3.2. Status 3.2. Status
permanent permanent
3.3. URI Scheme Syntax 3.3. URI Scheme Syntax
skipping to change at page 6, line 52 skipping to change at page 7, line 7
labeltext = 1*( alphanum / "-" ) labeltext = 1*( alphanum / "-" )
pnum = 1*DIGIT [ "." 1*DIGIT ] pnum = 1*DIGIT [ "." 1*DIGIT ]
num = [ "-" ] pnum num = [ "-" ] pnum
unreserved = alphanum / mark unreserved = alphanum / mark
mark = "-" / "_" / "." / "!" / "~" / "*" / mark = "-" / "_" / "." / "!" / "~" / "*" /
"'" / "(" / ")" "'" / "(" / ")"
pct-encoded = "%" HEXDIG HEXDIG pct-encoded = "%" HEXDIG HEXDIG
p-unreserved = "[" / "]" / ":" / "&" / "+" / "$" p-unreserved = "[" / "]" / ":" / "&" / "+" / "$"
alphanum = ALPHA / DIGIT alphanum = ALPHA / DIGIT
Parameter names are case insensitive, use of the lowercase Parameter names are case insensitive, but use of the lowercase
representation is PREFERRED. Case sensitivity of non-numeric representation is preferred. Case sensitivity of non-numeric
parameter values MUST be described in the specification of the parameter values MUST be described in the specification of the
respective parameter. For the 'crs' parameter, values are case respective parameter. For the 'crs' parameter, values are case
insensitive, and lowercase is PREFERRED. insensitive, and lowercase is preferred.
Both 'crs' and 'u' parameters MUST NOT appear more than once each. Both 'crs' and 'u' parameters MUST NOT appear more than once each.
The 'crs' and 'u' parameters MUST be given before any other The 'crs' and 'u' parameters MUST be given before any other
parameters that may be defined in future extensions. The 'crs' parameters that may be defined in future extensions. The 'crs'
parameter MUST be given first if both 'crs' and 'u' are used. The parameter MUST be given first if both 'crs' and 'u' are used. The
definition of other parameters, and <crslabel> values beyond the definition of other parameters, and <crslabel> values beyond the
default value of "wgs84" is out of scope of this document. default value of "wgs84" is out of the scope of this document.
Section 8.2 discusses the IANA registration of such additional Section 8.2 discusses the IANA registration of such additional
parameters and values. parameters and values.
The value of "-0" for <num> is allowed, and identical to "0". The value of "-0" for <num> is allowed and is identical to "0".
In case the URI identifies a location in the default CRS of WGS-84, In case the URI identifies a location in the default CRS of WGS-84,
the <coordinates> sub-components are further restricted as follows: the <coordinates> sub-components are further restricted as follows:
coord-a = latitude coord-a = latitude
coord-b = longitude coord-b = longitude
coord-c = altitude coord-c = altitude
latitude = [ "-" ] 1*2DIGIT [ "." 1*DIGIT ] latitude = [ "-" ] 1*2DIGIT [ "." 1*DIGIT ]
longitude = [ "-" ] 1*3DIGIT [ "." 1*DIGIT ] longitude = [ "-" ] 1*3DIGIT [ "." 1*DIGIT ]
skipping to change at page 8, line 10 skipping to change at page 8, line 14
<coordinates> sub-components without considering and understanding <coordinates> sub-components without considering and understanding
the 'crs' parameter value. the 'crs' parameter value.
The following component description refers to the use of the default The following component description refers to the use of the default
CRS (WGS-84) only. Future documents specifying other 'crs' parameter CRS (WGS-84) only. Future documents specifying other 'crs' parameter
values MUST provide similar descriptions for the <coordinates> sub- values MUST provide similar descriptions for the <coordinates> sub-
components in the described CRS. components in the described CRS.
3.4.2. Component Description for WGS-84 3.4.2. Component Description for WGS-84
The <latitude>, <longitude> and <altitude> components as specified in The <latitude>, <longitude>, and <altitude> components as specified
the URI scheme syntax (Section 3.3) are to be used as follows: in the URI scheme syntax (Section 3.3) are to be used as follows:
o <latitude> MUST contain the latitude of the identified location in o <latitude> MUST contain the latitude of the identified location in
decimal degrees in the reference system WGS-84. decimal degrees in the reference system WGS-84.
o <longitude> MUST contain the longitude of the identified location o <longitude> MUST contain the longitude of the identified location
in decimal degrees in the reference system WGS-84. in decimal degrees in the reference system WGS-84.
o If present, the OPTIONAL <altitude> MUST contain the altitude of o If present, the OPTIONAL <altitude> MUST contain the altitude of
the identified location in meters in the reference system WGS-84. the identified location in meters in the reference system WGS-84.
If the altitude of the location is unknown, <altitude> (and the comma If the altitude of the location is unknown, <altitude> (and the comma
before) MUST NOT be present in the URI. Specifically, unknown before) MUST NOT be present in the URI. Specifically, unknown
altitude MUST NOT be represented by setting <altitude> to "0" (or any altitude MUST NOT be represented by setting <altitude> to "0" (or any
other arbitrary value). other arbitrary value).
The <longitude> of coordinate values reflecting the poles (<latitude> The <longitude> of coordinate values reflecting the poles (<latitude>
set to -90 or 90 degrees) SHOULD be set to "0", although consumers of set to -90 or 90 degrees) SHOULD be set to "0", although consumers of
skipping to change at page 9, line 4 skipping to change at page 9, line 11
The 'u' parameter is optional and it can appear only once. If it is The 'u' parameter is optional and it can appear only once. If it is
not specified, this indicates that uncertainty is unknown or not specified, this indicates that uncertainty is unknown or
unspecified. If the intent is to indicate a specific point in space, unspecified. If the intent is to indicate a specific point in space,
<uval> MAY be set to zero. Zero uncertainty and absent uncertainty <uval> MAY be set to zero. Zero uncertainty and absent uncertainty
are never the same thing. are never the same thing.
The single uncertainty value is applied to all dimensions given in The single uncertainty value is applied to all dimensions given in
the URI. the URI.
Note: The number of digits of the values in <coordinates> MUST NOT be Note: The number of digits of the values in <coordinates> MUST NOT be
interpreted as an indication to uncertainty. interpreted as an indication to the level of uncertainty.
3.4.4. URI Comparison 3.4.4. URI Comparison
Comparison of URIs intends to determine whether two URI strings are Comparison of URIs intends to determine whether two URI strings are
equivalent and identify the same resource (rather than comparing the equivalent and identify the same resource (rather than comparing the
resources themselves). Therefore, a comparison of two 'geo' URIs resources themselves). Therefore, a comparison of two 'geo' URIs
does not compare spatial objects, but only the strings (URIs) does not compare spatial objects, but only the strings (URIs)
identifying those objects. identifying those objects.
The term "mathematically identical" used below specifies that some The term "mathematically identical" used below specifies that some
skipping to change at page 9, line 26 skipping to change at page 9, line 33
than strings to account for the variety in string representations of than strings to account for the variety in string representations of
identical numbers (for example, the strings "43.10" and "43.1" are identical numbers (for example, the strings "43.10" and "43.1" are
different, but represent the same number). different, but represent the same number).
Two 'geo' URIs are equal only if they fulfill all of the following Two 'geo' URIs are equal only if they fulfill all of the following
general comparison rules: general comparison rules:
o Both URIs use the same CRS, which means that either both have the o Both URIs use the same CRS, which means that either both have the
'crs' parameter omitted, or both have the same <crslabel> value, 'crs' parameter omitted, or both have the same <crslabel> value,
or one has the 'crs' parameter omitted while the other URI or one has the 'crs' parameter omitted while the other URI
specifies the default CRS explicitely with a <crslabel> value of specifies the default CRS explicitly with a <crslabel> value of
"wgs84". "wgs84".
o Their <coord-a>, <coord-b>, <coord-c> and 'u' values are o Their <coord-a>, <coord-b>, <coord-c> and 'u' values are
mathematically identical (including absent <uval> meaning mathematically identical (including absent <uval> meaning
undefined 'u' value). undefined 'u' value).
o Their sets of other parameters are equal, with comparison o Their sets of other parameters are equal, with comparison
operations applied on each parameter as described in its operations applied on each parameter as described in its
respective specification. respective specification.
Parameter order is not significant for URI comparison. Parameter order is not significant for URI comparison.
Since new parameters may be registered over time, legacy Since new parameters may be registered over time, legacy
implementations of the 'geo' URI might encounter unknown parameters. implementations of the 'geo' URI might encounter unknown parameters.
In such cases, the following rules apply: In such cases, the following rules apply:
skipping to change at page 9, line 44 skipping to change at page 10, line 8
Parameter order is not significant for URI comparison. Parameter order is not significant for URI comparison.
Since new parameters may be registered over time, legacy Since new parameters may be registered over time, legacy
implementations of the 'geo' URI might encounter unknown parameters. implementations of the 'geo' URI might encounter unknown parameters.
In such cases, the following rules apply: In such cases, the following rules apply:
o Two 'geo' URIs with unknown parameters are equivalent only if the o Two 'geo' URIs with unknown parameters are equivalent only if the
same set of unknown parameter names appears in each URI, and their same set of unknown parameter names appears in each URI, and their
values are bitwise identical after percent-decoding. values are bitwise identical after percent-decoding.
o Otherwise, the comparison operation for the respective URIs is o Otherwise, the comparison operation for the respective URIs is
undefined (since the legacy implementation is not be aware of the undefined (since the legacy implementation cannot be aware of the
comparison rules for those parameters). comparison rules for those parameters).
Designers of future extension parameters should take this into Designers of future extension parameters should take this into
account when choosing the comparison rules for new parameters. account when choosing the comparison rules for new parameters.
A URI with undefined (missing) <coord-c> (altitude) value MUST NOT be A URI with an undefined (missing) <coord-c> (altitude) value MUST NOT
considered equal to a URI containing a <coord-c>, even if the be considered equal to a URI containing a <coord-c>, even if the
remaining <coord-a>, <coord-b>, and their 'u' values are equivalent. remaining <coord-a>, <coord-b>, and 'u' values are equivalent.
For the default CRS of WGS-84, the following comparison rules apply For the default CRS of WGS-84, the following comparison rules apply
additionally: additionally:
o Where <latitude> of a 'geo' URI is set to either 90 or -90 o Where <latitude> of a 'geo' URI is set to either 90 or -90
degrees, <longitude> MUST be ignored in comparison operations degrees, <longitude> MUST be ignored in comparison operations
("poles case"). ("poles case").
o A <longitude> of 180 degrees MUST be considered equal to o A <longitude> of 180 degrees MUST be considered equal to
<longitude> of -180 degrees for the purpose of URI comparison <longitude> of -180 degrees for the purpose of URI comparison
("date line" case). ("date line" case).
3.4.5. Interpretation of Undefined Altitude 3.4.5. Interpretation of Undefined Altitude
A consumer of a 'geo' URI in the WGS-84 CRS with undefined <altitude> A consumer of a 'geo' URI in the WGS-84 CRS with undefined <altitude>
MAY assume that the URI refers to the respective location on Earth's MAY assume that the URI refers to the respective location on Earth's
physical surface at the given latitude and longitude. physical surface at the given latitude and longitude.
skipping to change at page 10, line 34 skipping to change at page 10, line 48
reference geoid rather than Earth's surface. Hence, an <altitude> reference geoid rather than Earth's surface. Hence, an <altitude>
value of 0 MUST NOT be mistaken to refer to "ground elevation". value of 0 MUST NOT be mistaken to refer to "ground elevation".
3.5. Encoding Considerations 3.5. Encoding Considerations
The <coordinates> path component of the 'geo' URI (see Section 3.3) The <coordinates> path component of the 'geo' URI (see Section 3.3)
uses a comma (",") as the delimiter for subcomponents. This uses a comma (",") as the delimiter for subcomponents. This
delimiter MUST NOT be percent-encoded. delimiter MUST NOT be percent-encoded.
It is RECOMMENDED that for readability the contents of <coord-a>, It is RECOMMENDED that for readability the contents of <coord-a>,
<coord-b> and <coord-c> as well as <crslabel> and <uval> are never <coord-b>, and <coord-c> as well as <crslabel> and <uval> are never
percent-encoded. percent-encoded.
Regarding internationalization, the currently specified components do Regarding internationalization, the currently specified components do
allow for ASCII characters exclusively, and therefore don't require allow for ASCII characters exclusively, and therefore don't require
internationalization. Future specifications of additional parameters internationalization. Future specifications of additional parameters
might allow the introduction of non-ASCII values. Such might allow the introduction of non-ASCII values. Such
specifications MUST describe internationalization considerations for specifications MUST describe internationalization considerations for
those parameters and their values, and MUST require percent-encoding those parameters and their values, and MUST require percent-encoding
of non-ASCII values. of non-ASCII values.
3.6. Applications/Protocols that use this URI Scheme 3.6. Applications/Protocols That Use This URI Scheme
As many other URI scheme definitions, the 'geo' URI provides resource As many other URI scheme definitions, the 'geo' URI provides resource
identification independent of a specific application or protocol. identification independent of a specific application or protocol.
Examples of potential protocol mappings and use cases can be found in Examples of potential protocol mappings and use cases can be found in
Section 6. Section 6.
3.7. Interopability Considerations 3.7. Interoperability Considerations
Like other new URI schemes, the 'geo' URI requires support in client Like other new URI schemes, the 'geo' URI requires support in client
applications. Users of applications which are not aware of the 'geo' applications. Users of applications that are not aware of the 'geo'
scheme are likely not able to make direct use of the information in scheme are likely not able to make direct use of the information in
the URI. However, a client can make indirect use by passing around the URI. However, a client can make indirect use by passing around
'geo' URIs even without understanding the format and semantics of the 'geo' URIs, even without understanding the format and semantics of
scheme. Additionally, the simple structure of 'geo' URIs would allow the scheme. Additionally, the simple structure of 'geo' URIs would
even manual dereference by humans. allow even manual dereference by humans.
Clients MUST NOT attempt to dereference 'geo' URIs given in an CRS Clients MUST NOT attempt to dereference 'geo' URIs given in a CRS
that is unknown to the client, because doing so would produce that is unknown to the client, because doing so would produce
entirely bogus results. entirely bogus results.
Authors of 'geo' URIs should carefully check that coordinate Authors of 'geo' URIs should carefully check that coordinate
components are set in the right CRS and in the specified order, since components are set in the right CRS and in the specified order, since
wrong order of those components (or use of coordinates in a different the wrong order of those components (or use of coordinates in a
CRS without transformation) are commonly observed mistakes producing different CRS without transformation) are commonly observed mistakes
completely bogus locations. producing completely bogus locations.
The number of digits in the <coordinates> values MUST NOT be The number of digits in the <coordinates> values MUST NOT be
interpreted as an indication to a certain level of accuracy or interpreted as an indication of a certain level of accuracy or
uncertainty. uncertainty.
3.8. Security Considerations 3.8. Security Considerations
See Section 9 of [insert reference to this document] See Section 9 of RFC 5870.
3.9. Contact 3.9. Contact
Alexander Mayrhofer <axelm@ipcom.at>, <http://geouri.org/> Alexander Mayrhofer <axelm@ipcom.at>, <http://geouri.org/>
Christian Spanring <christian@spanring.eu> Christian Spanring <christian@spanring.eu>
3.10. Author/Change controller 3.10. Author/Change Controller
The 'geo' URI scheme is registered under the IETF part of the URI The 'geo' URI scheme is registered under the IETF part of the URI
tree. As such, change control is up to the IETF. tree. As such, change control is up to the IETF.
3.11. References 3.11. References
RFC XXXX [change to RFC number once assigned] RFC 5870
4. 'geo' URI Parameters Registry 4. 'geo' URI Parameters Registry
This specification creates a new IANA Registry named "'geo' URI This specification creates a new IANA Registry named "'geo' URI
Parameters Registry" for the <parameter> component of the URI. Parameters" registry for the <parameter> component of the URI.
Parameters for the 'geo' URI and values for these parameters MUST be Parameters for the 'geo' URI and values for these parameters MUST be
registered with IANA to prevent namespace collisions, and provide registered with IANA to prevent namespace collisions and provide
interopability. interoperability.
Some parameters accept values that are constrained by a syntax Some parameters accept values that are constrained by a syntax
definition only, while others accept values from a predefined set definition only, while others accept values from a predefined set
only. Some parameters might not accept any values at all ("flag" only. Some parameters might not accept any values at all ("flag"
type parameters). type parameters).
The registration of values is REQUIRED for parameters that accept The registration of values is REQUIRED for parameters that accept
values from a predefined set. values from a predefined set.
The specification of a parameter MUST fully explain the syntax, The specification of a parameter MUST fully explain the syntax,
intended usage and semantics of the parameter. This ensures intended usage, and semantics of the parameter. This ensures
interopability between independent implementations. interoperability between independent implementations.
For parameters that are neither restricted to a set of predefined For parameters that are neither restricted to a set of predefined
values nor of the "flag" type described above, the syntax of allowed values nor the "flag" type described above, the syntax of allowed
values MUST be described in the specification, for example by using values MUST be described in the specification, for example by using
ABNF. ABNF.
Documents defining new parameters (or new values for existing Documents defining new parameters (or new values for existing
parameters) MUST register them with IANA, as explained in parameters) MUST register them with IANA, as explained in
Section 8.2. Section 8.2.
The 'geo' URI Parameter Registry contains a column named "Value The 'geo' URI Parameter Registry contains a column named "Value
Restriction" that describes whether or not a parameter accepts a Restriction" that describes whether or not a parameter accepts a
value, and whether values are restricted to a predefined set. That value, and whether values are restricted to a predefined set. That
column accepts the following values: column accepts the following values:
o "No value": The parameter does not accept any values, and is to be o "No value": The parameter does not accept any values and is to be
used as a "flag" only. used as a "flag" only.
o "Predefined": The parameter does accept values from a predefined o "Predefined": The parameter does accept values from a predefined
set only, as specified in a RFC or other permanent and readily set only, as specified in an RFC or other permanent and readily
available public specification. available public specification.
o "Constrained": The parameter accepts arbitrary values that are o "Constrained": The parameter accepts arbitrary values that are
only constrained by a syntax as specified in a RFC or other only constrained by a syntax as specified in an RFC or other
permanent and readily available public specification. permanent and readily available public specification.
Section 8.2.1 contains the initial contents of the Registry. Section 8.2.1 contains the initial contents of the Registry.
5. URI Operations 5. URI Operations
Currently, just one operation on a 'geo' URI is defined - location Currently, just one operation on a 'geo' URI is defined - location
dereference: In that operation, a client dereferences the URI by dereference: in that operation, a client dereferences the URI by
extracting the geographical coordinates from the URI path component extracting the geographical coordinates from the URI path component
<geo-path>. Further use of those coordinates (and the uncertainty <geo-path>. Further use of those coordinates (and the uncertainty
value from <uval>) is then up to the application processing the URI, value from <uval>) is then up to the application processing the URI,
and might depend on the context of 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 mapping service o A web browser could use that information to open a mapping service
of the user's choice, and display a map of the location. of the user's choice, and display a map of the location.
o A navigational device such as a Global Positioning System (GPS) o A navigational device such as a Global Positioning System (GPS)
receiver could offer the user to start navigation to the location. receiver could offer the user the ability to start navigation to
the location.
Note that the examples and use cases aboves as well as in the next Note that the examples and use cases above as well as in the next
section are non-normative, and provided for information only. section are non-normative, and are 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
skipping to change at page 13, line 31 skipping to change at page 13, line 50
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
Resolution of the URI returns the following information: Resolution of the URI returns the following information:
o The 'crs' parameter is not given in the URI, which means that the o The 'crs' parameter is not given in the URI, which means that the
URI uses the default CRS of WGS-84. URI uses the default CRS of WGS-84.
o The URI includes <coord-c>, is hence 3-dimensional, and therefore o The URI includes <coord-c>, is hence 3-dimensional, and therefore
uses 'urn:ogc:def:crs:EPSG::4979' as the WGS-84 CRS identifier. uses 'urn:ogc:def:crs:EPSG::4979' as the WGS-84 CRS identifier.
o The <coord-a> value (latitude in WGS-84) is set to '48.2010' o The <coord-a> value (latitude in WGS-84) is set to '48.2010'
decimal degrees. decimal degrees.
o The <coord-b> value (longitude in WGS-84) is set to '16.3695' o The <coord-b> value (longitude in WGS-84) is set to '16.3695'
decimal degrees. decimal degrees.
o The <coord-c> value (altitude in WGS-84) is set to 183 meters. o The <coord-c> value (altitude in WGS-84) is set to 183 meters.
o Uncertainty is undefined. o Uncertainty is undefined.
A user could type the data extracted from this URI into a electronic A user could type the data extracted from this URI into an 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 <p>one of Vienna's popular sights is the
<a href='geo:48.198634,16.371648;crs=wgs84;u=40'>Karlskirche</a>. <a href='geo:48.198634,16.371648;crs=wgs84;u=40'>Karlskirche</a>.
Resolution of the URI returns the following information: Resolution of the URI returns the following information:
o The 'crs' is given in the URI, and sets the CRS used in the URI to o The 'crs' is given in the URI and sets the CRS used in the URI to
WGS-84 explicitely. WGS-84 explicitly.
o The URI does omit <coord-c>, is hence 2-dimensional, and therefore o The URI does omit <coord-c>, is hence 2-dimensional, and therefore
uses 'urn:ogc:def:crs:EPSG::4326' as the WGS-84 CRS identifier. uses 'urn:ogc:def:crs:EPSG::4326' as the WGS-84 CRS identifier.
o The <coord-a> value (latitude in WGS-84) is set to '48.198634' o The <coord-a> value (latitude in WGS-84) is set to '48.198634'
decimal degrees. decimal degrees.
o The <coord-b> value (longitude in WGS-84) is set to '16.371648' o The <coord-b> value (longitude in WGS-84) is set to '16.371648'
decimal degrees. decimal degrees.
o The <coord-c> (altitude) value is undefined, hence the client MAY
assume the identified location to be on Earth's physical surface. o The <coord-c> (altitude) value is undefined; therefore, the client
MAY assume the identified location to be on Earth's physical
surface.
o The 'u' parameter is included in the URI, setting uncertainty to o The 'u' parameter is included in the URI, setting uncertainty to
40 meters. 40 meters.
A web browser could use this information from the HTML snippet, and A web browser could use this information 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 to which the user has
to. subscribed.
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' 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, and paper maps, and subsequently used by mobile
for example as follows: devices, for example as follows:
1. User identifies such a barcode on a flyer and uses the camera on 1. User identifies such a barcode on a flyer and uses the camera on
his mobile phone to photograph and decode the barcode. his mobile phone to photograph and decode the barcode.
2. The mobile phone dereferences the 'geo' URI, and offers the user 2. The mobile phone dereferences the 'geo' URI, and offers the user
to calculate a navigation route to the identified location. the ability to calculate a navigation route to the identified
location.
3. Using the builtin GPS receiver, the user follows the navgiation 3. Using the builtin GPS receiver, the user follows the navigation
instructions to reach the location. instructions to reach the location.
6.4. Comparison Examples 6.4. Comparison Examples
This section provides examples of URI comparison. Note that the This section provides examples of URI comparison. Note that the
unknown parameters 'foo' and 'bar' and unregistered 'crs' values in unknown parameters 'foo' and 'bar' and unregistered 'crs' values in
this section are used for illustrative purposes only, and their this section are used for illustrative purposes only, and their
inclusion in the examples below does not constitute any formal inclusion in the examples below does not constitute any formal
parameter definition or registration request. parameter definition or registration request.
skipping to change at page 15, line 25 skipping to change at page 16, line 4
this section are used for illustrative purposes only, and their this section are used for illustrative purposes only, and their
inclusion in the examples below does not constitute any formal inclusion in the examples below does not constitute any formal
parameter definition or registration request. parameter definition or registration request.
o The two URIs <geo:90,-22.43;crs=WGS84> and <geo:90,46> are equal, o The two URIs <geo:90,-22.43;crs=WGS84> and <geo:90,46> are equal,
because both use the same CRS, and even though the longitude because both use the same CRS, and even though the longitude
values are different, both reflect a location on the north pole values are different, both reflect a location on the north pole
(special "poles" rule for WGS-84 applies - longitude is to be (special "poles" rule for WGS-84 applies - longitude is to be
ignored). Note that the 'crs' parameter values are case ignored). Note that the 'crs' parameter values are case
insensitive. insensitive.
o The URIs <geo:22.300;-118.44> and <geo:22.3;-118.4400> are equal, o The URIs <geo:22.300;-118.44> and <geo:22.3;-118.4400> are equal,
because their coordinate components are mathematically identical because their coordinate components are mathematically identical.
o The set of <geo:66,30;u=6.500;FOo=this%2dthat> and <geo: o The set of <geo:66,30;u=6.500;FOo=this%2dthat> and <geo:
66.0,30;u=6.5;foo=this-that> are identical, because the value of 66.0,30;u=6.5;foo=this-that> are identical, because the value of
the unknown parameter 'foo' is bitwise identical after percent- the unknown parameter 'foo' is bitwise identical after percent-
decoding, parameter names are case insensitive, and coordinates decoding; parameter names are case insensitive, and coordinates
and uncertainty are mathematically identical. and uncertainty are mathematically identical.
o The comparison operation on <geo:70,20;foo=1.00;bar=white> and o The comparison operation on <geo:70,20;foo=1.00;bar=white> and
<geo:70,20;foo=1;bar=white> in a legacy implementation is <geo:70,20;foo=1;bar=white> in a legacy implementation is
undefined, because the normalization rules for 'foo' are not undefined, because the normalization rules for 'foo' are not
known, and hence the implementation cannot identify whether or not known, and hence the implementation cannot identify whether or not
'1.00' is identical to '1' for the 'foo' parameter. '1.00' is identical to '1' for the 'foo' parameter.
o Comparing <geo:47,11;foo=blue;bar=white> and <geo: o Comparing <geo:47,11;foo=blue;bar=white> and <geo:
47,11;bar=white;foo=blue> returns true, because parameter order is 47,11;bar=white;foo=blue> returns true, because parameter order is
insignificant in comparison operations insignificant in comparison operations.
o The comparison operation on <geo:22,0;bar=Blue> and <geo: o The comparison operation on <geo:22,0;bar=Blue> and <geo:
22,0;BAR=blue> is undefined, because even though parameter names 22,0;BAR=blue> is undefined, because even though parameter names
are case insensitive, this is not neccessarily the case for the are case insensitive, this is not necessarily the case for the
values of the unknown 'bar' parameter. values of the unknown 'bar' parameter.
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 that represent geographical
features. Since GML is widely accepted, this document includes features. Since GML is widely accepted, this document includes
instructions on how to transform 'geo' URIs from and to GML instructions on how to transform 'geo' URIs from and to GML
fragments. The instructions in this section are not normative. fragments. The instructions in this section are not normative.
For the following sections, "%lat%", "%lon%", "%alt%" and "%unc%" are For the following sections, "%lat%", "%lon%", "%alt%", and "%unc%"
placeholders for latitude, longitude, altitude and uncertainty are placeholders for latitude, longitude, altitude, and uncertainty
values, respectively. The mappings use WGS-84, and are defined in values, respectively. The mappings use WGS-84 and are defined in the
the following sections. following sections.
Note: GML fragments in other reference systems could be used as well Note: GML fragments in other reference systems could be used as well
if a transformation into "urn:ogc:def:crs:EPSG::4979" or if a transformation into "urn:ogc:def:crs:EPSG::4979" or
"urn:ogc:def:crs:EPSG::4326" is defined and applied before the "urn:ogc:def:crs:EPSG::4326" is defined and applied before the
mapping step. Such transformations are typically not lossless. mapping step. Such transformations are typically not lossless.
GML uses the 'double' type from XML schema, and the mapping examples GML uses the 'double' type from XML schema, and the mapping examples
assume that numbers in the form of "3.32435e2" in GML are properly assume that numbers in the form of "3.32435e2" in GML are properly
converted to fixed point when placed into the 'geo' URI. converted to fixed point when placed into the 'geo' URI.
skipping to change at page 18, line 20 skipping to change at page 18, line 45
<gml:pos>%lat% %lon% %alt%</gml:pos> <gml:pos>%lat% %lon% %alt%</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001"> <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
%unc% %unc%
</gs:radius> </gs:radius>
</gs:Sphere> </gs:Sphere>
8. IANA Considerations 8. IANA Considerations
8.1. 'geo' URI Scheme 8.1. 'geo' URI Scheme
This document requests assignment of the 'geo' URI scheme in the IETF This document creates the 'geo' URI scheme in the IETF part of the
part of the URI scheme tree, according to the guidelines in BCP 115 URI scheme tree, according to the guidelines in BCP 115 (RFC 4395)
(RFC 4395) [RFC4395]. The definitions required for the assignment [RFC4395]. The definitions required for the assignment are contained
are contained in Section 3. in Section 3.
8.2. URI Parameter Registry 8.2. URI Parameter Registry
This document creates a new IANA Registry named "'geo' URI This document creates a new IANA Registry named "'geo' URI
Parameters", according to the information in Section 4 and the Parameters", according to the information in Section 4 and the
definition in this section. definition in this section.
8.2.1. Registry Contents 8.2.1. Registry Contents
When registering a new 'geo' URI Parameter, the following information When registering a new 'geo' URI Parameter, the following information
skipping to change at page 18, line 37 skipping to change at page 19, line 17
This document creates a new IANA Registry named "'geo' URI This document creates a new IANA Registry named "'geo' URI
Parameters", according to the information in Section 4 and the Parameters", according to the information in Section 4 and the
definition in this section. definition in this section.
8.2.1. Registry Contents 8.2.1. Registry Contents
When registering a new 'geo' URI Parameter, the following information When registering a new 'geo' URI Parameter, the following information
MUST be provided: MUST be provided:
o Name of the Parameter. o Name of the Parameter.
o Whether the Parameter accepts no value ("No value"), values from a o Whether the Parameter accepts no value ("No value"), values from a
predefined set ("Predefined"), or values constrained by a syntax predefined set ("Predefined"), or values constrained by a syntax
only ("Constrained"). only ("Constrained").
o Reference to the RFC or other permanent and readily available o Reference to the RFC or other permanent and readily available
public specification defining the parameters and the new values. public specification defining the parameters and the new values.
Unless specific instructions exists for a Parameter (like the Unless specific instructions exist for a Parameter (like the
definition of a Sub-registry), the following information MUST be definition of a Sub-registry), the following information MUST be
provided when registering new values for existing "Predefined" 'geo' provided when registering new values for existing "Predefined" 'geo'
URI Parameters: URI Parameters:
o Name of the Parameter. o Name of the Parameter.
o Reference to the RFC or other permanent and readily available o Reference to the RFC or other permanent and readily available
public specification defining the new values. public specification defining the new values.
The following table provides the initial values for this registry: The following table provides the initial values for this registry:
Parameter Name Value Restriction Reference(s) Parameter Name Value Restriction Reference(s)
---------------------------------------------------------- ----------------------------------------------------------
crs Predefined [RFCxxxx] crs Predefined [RFC5870]
u Constrained [RFCxxxx] u Constrained [RFC5870]
[Note to RFC Editor: Replace RFCxxxx with reference to this document]
8.2.2. Registration Policy 8.2.2. Registration Policy
The Registration Policy for 'geo' URI Parameters and their value The Registration Policy for 'geo' URI Parameters and their value
definitions shall be "Specification Required" (which implies definitions is "Specification Required" (which implies "Designated
"Designated Expert"), as defined in [RFC5226]. Expert"), as defined in [RFC5226].
8.3. Sub-Registry for 'crs' Parameter 8.3. Sub-Registry for 'crs' Parameter
This document creates a new IANA Sub-registry named "'geo' URI 'crs' This document creates a new IANA Sub-registry named "'geo' URI 'crs'
Parameter Values", based on the Registry specified in Section 8.2 and Parameter Values", based on the Registry specified in Section 8.2 and
the information in this section and Section 4. The syntax of the the information in this section and Section 4. The syntax of the
'crs' parameter is constrained by the ABNF given in Section 3.3. 'crs' parameter is constrained by the ABNF given in Section 3.3.
8.3.1. Registry Contents 8.3.1. Registry Contents
skipping to change at page 19, line 33 skipping to change at page 20, line 18
Parameter Values", based on the Registry specified in Section 8.2 and Parameter Values", based on the Registry specified in Section 8.2 and
the information in this section and Section 4. The syntax of the the information in this section and Section 4. The syntax of the
'crs' parameter is constrained by the ABNF given in Section 3.3. 'crs' parameter is constrained by the ABNF given in Section 3.3.
8.3.1. Registry Contents 8.3.1. Registry Contents
When registering a new value for the 'crs' parameter, the following When registering a new value for the 'crs' parameter, the following
information MUST be provided: information MUST be provided:
o Value of the parameter. o Value of the parameter.
o Reference to the RFC or other permanent and readily available o Reference to the RFC or other permanent and readily available
public specification defining the use of the CRS in the scope of public specification defining the use of the CRS in the scope of
the 'geo' URI. The specification should contain information that the 'geo' URI. The specification should contain information that
is similar to the WGS-84-specific text given in this document. is similar to the WGS-84-specific text given in this document.
o Reference to the definition document of the CRS. If a URN is o Reference to the definition document of the CRS. If a URN is
assigned to the CRS, the use of such URN as reference is assigned to the CRS, the use of such URN as reference is
preferred. Note that different URNs may exist for the preferred. Note that different URNs may exist for the
2-dimensional and 3-dimensional case. 2-dimensional and 3-dimensional case.
The following table provides the initial values for this registry: The following table provides the initial values for this registry:
crs Value Reference(s) CRS definition(s) crs Value CRS definition(s) Reference(s)
----------------------------------------------------------- -----------------------------------------------------------
wgs84 [RFCxxxx] urn:ogc:def:crs:EPSG::4326 wgs84 urn:ogc:def:crs:EPSG::4326 [RFC5870]
urn:ogc:def:crs:EPSG::4979 urn:ogc:def:crs:EPSG::4979 [RFC5870]
[Note to RFC Editor: Replace RFCxxxx with reference to this document]
8.3.2. Registration Policy 8.3.2. Registration Policy
The registration policy for the "'geo' URI 'crs' Parameter Values" The registration policy for the "'geo' URI 'crs' Parameter Values"
Registry shall require both "Specification Required" and "IESG Registry shall require both "Specification Required" and "IESG
Approval" as defined in [RFC5226]. Approval", as defined in [RFC5226].
Section 1 contains some text about the motivation when to introduce Section 1 contains some text about the motivation for when to
new 'crs' values. introduce new 'crs' values.
9. Security Considerations 9. Security Considerations
Because the 'geo' URI is not tied to any specific protocol and Because the 'geo' URI is not tied to any specific protocol and
identifies a physical location rather than a network resource, most identifies a physical location rather than a network resource, most
of the general security considerations on URIs (Section 7 of RFC of the general security considerations on URIs (Section 7 of RFC
3986) do not apply. However, the following (additional) issues 3986) do not apply. However, the following (additional) issues
apply: apply:
9.1. Invalid Locations 9.1. Invalid Locations
The URI syntax (Section 3.3) makes it possible to construct 'geo' The URI syntax (Section 3.3) makes it possible to construct 'geo'
URIs which don't identify a valid location. Applications MUST NOT URIs that don't identify a valid location. Applications MUST NOT use
use URIs with such values, and SHOULD warn the user when such URIs URIs with such values and SHOULD warn the user when such URIs are
are encountered. encountered.
An example of such an URI referring to an invalid location would be An example of such a URI referring to an invalid location would be
<geo:94,0> (latitude "beyond" north pole). <geo:94,0> (latitude "beyond" north pole).
9.2. Location Privacy 9.2. Location Privacy
A 'geo' URI by itself is just an opaque reference to a physical A 'geo' URI by itself is just an opaque reference to a physical
location, expressed by a set of spatial coordinates. This does not location, expressed by a set of spatial coordinates. This does not
fit the "Location Information" definition according to Section 5.2 of fit the "Location Information" definition according to Section 5.2 of
GEOPRIV Requirements [RFC3693], because there is not necessarily a GEOPRIV Requirements [RFC3693], because there is not necessarily a
"Device" involved. "Device" involved.
Because there is also no way to specify the identity of a "Target" Because there is also no way to specify the identity of a "Target"
within the confines of a 'geo' URI, it also does not fit the within the confines of a 'geo' URI, it also does not fit the
specification of an "Location Object" (Section 5.2 of RFC 3693). specification of a "Location Object" (Section 5.2 of RFC 3693).
However, if a 'geo' URI is used in a context where it identifies the However, if a 'geo' URI is used in a context where it identifies the
location of a Target, it becomes part of a Location Object and is location of a Target, it becomes part of a Location Object and is
therefore subject to GEOPRIV rules. therefore subject to GEOPRIV rules.
Therefore, when 'geo' URIs are put into such contexts, the privacy Therefore, when 'geo' URIs are put into such contexts, the privacy
requirements of RFC 3693 MUST be met. requirements of RFC 3693 MUST be met.
10. Acknowledgements 10. Acknowledgements
Martin Thomson has provided significant text around the definition of Martin Thomson has provided significant text around the definition of
the "uncertainty" parameter and the GML mappings. the "uncertainty" parameter and the GML mappings.
The authors further wish to acknowledge the helpful contributions The authors further wish to acknowledge the helpful contributions
from Carl Reed, Bill McQuillan, Martin Kofal, Andrew Turner, Kim from Carl Reed, Bill McQuillan, Martin Kofal, Andrew Turner, Kim
Sanders, Ted Hardie, Cullen Jennings, Klaus Darilion, Bjorn Sanders, Ted Hardie, Cullen Jennings, Klaus Darilion, Bjoern
Hoehrmann, Alissa Cooper and Ivan Shmakov. Hoehrmann, Alissa Cooper, and Ivan Shmakov.
Alfred Hoenes has provided an extremely helpful in-depth review of Alfred Hoenes has provided an extremely helpful in-depth review of
the document. the document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
skipping to change at page 22, line 6 skipping to change at page 22, line 41
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004. J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[WGS84] National Imagery and Mapping Agency, "Department of [WGS84] National Imagery and Mapping Agency, "Department of
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 [ISO.6709.2008]
International Organization for Standardization, "Standard
[Note to editors: This section is to be removed before publication - representation of geographic point location by
XML source available on request] coordinates", ISO Standard 6709, 2008.
draft-ietf-geopriv-geo-uri-07
o Additonal text in URI comparison explaining what is being compared
o fixed typo in comparison example
draft-ietf-geopriv-geo-uri-06
o Addressed remaining IESG evaluation comments:
o comparison rules for unknown parameters
o extended examples
draft-ietf-geopriv-geo-uri-05
o Addressed IESG evaluation comments (some)
draft-ietf-geopriv-geo-uri-04
o Added "crs" URI parameter registry
o Added example URI to Introduction
o Changed quoting of parameters according to Alfred Hoenes' comments
draft-ietf-geopriv-geo-uri-03
o Updated privacy considerations section as per Alissa's comments
o Added text on uncertainty applied to all given dimensions
o various editorial changes
o Changed ABNF to reflect order of parameters (CRS first, then U,
then others
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
IPCom GmbH IPCom GmbH
Karlsplatz 1/2/9 Karlsplatz 1/2/9
Wien A-1010 Wien A-1010
Austria Austria
Phone: +43 1 5056416 34 Phone: +43 1 5056416 34
skipping to change at page 24, line 4 skipping to change at page 23, line 16
Alexander Mayrhofer Alexander Mayrhofer
IPCom GmbH IPCom GmbH
Karlsplatz 1/2/9 Karlsplatz 1/2/9
Wien A-1010 Wien A-1010
Austria Austria
Phone: +43 1 5056416 34 Phone: +43 1 5056416 34
Email: alexander.mayrhofer@ipcom.at Email: alexander.mayrhofer@ipcom.at
URI: http://www.ipcom.at/ URI: http://www.ipcom.at/
Christian Spanring Christian Spanring
30 Hancock St 73 Josephine Ave
Somerville 02144 Somerville 02144
Phone: +1 617 863 0360
Email: christian@spanring.eu Email: christian@spanring.eu
URI: http://www.spanring.eu/ URI: http://www.spanring.eu/
 End of changes. 116 change blocks. 
245 lines changed or deleted 187 lines changed or added

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