One document matched: draft-ietf-geopriv-geo-uri-02.txt
Differences from draft-ietf-geopriv-geo-uri-01.txt
GEOPRIV -- Geographic A. Mayrhofer
Location/Privacy Working Group nic.at
Internet-Draft C. Spanring
Expires: March 5, 2010 September 01, 2009
A Uniform Resource Identifier for Geographic Locations ('geo' URI)
draft-ietf-geopriv-geo-uri-02
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 5, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Mayrhofer & Spanring Expires March 5, 2010 [Page 1]
Internet-Draft 'geo' URI Scheme September 2009
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document specifies an Uniform Resource Identifier (URI) for
geographic locations using the 'geo' scheme name. A 'geo' URI
identifies a physical location in a two- or three-dimensional
coordinate reference system in a compact, simple, human-readable, and
protocol independent way. The default coordinate reference system
used is WGS-84.
Mayrhofer & Spanring Expires March 5, 2010 [Page 2]
Internet-Draft 'geo' URI Scheme September 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
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. 'geo' URI Parameters Registry . . . . . . . . . . . . . . . . 11
5. URI Operations . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Use Cases and Examples . . . . . . . . . . . . . . . . . . . . 13
6.1. Plain 'geo' URI Example . . . . . . . . . . . . . . . . . 13
6.2. Hyperlink . . . . . . . . . . . . . . . . . . . . . . . . 13
6.3. 'geo' URI in 2-dimensional barcode . . . . . . . . . . . . 14
7. GML Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. 2D GML 'Point' . . . . . . . . . . . . . . . . . . . . . . 15
7.2. 3D GML 'Point' . . . . . . . . . . . . . . . . . . . . . . 15
7.3. GML 'Circle' . . . . . . . . . . . . . . . . . . . . . . . 15
7.4. GML 'Sphere' . . . . . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8.1. 'geo' URI Scheme . . . . . . . . . . . . . . . . . . . . . 16
8.2. URI Parameter Registry . . . . . . . . . . . . . . . . . . 17
8.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 17
8.2.2. Registration Policy . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9.1. Invalid Locations . . . . . . . . . . . . . . . . . . . . 18
9.2. Location Privacy . . . . . . . . . . . . . . . . . . . . . 18
Mayrhofer & Spanring Expires March 5, 2010 [Page 3]
Internet-Draft 'geo' URI Scheme September 2009
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Mayrhofer & Spanring Expires March 5, 2010 [Page 4]
Internet-Draft 'geo' URI Scheme September 2009
1. Introduction
An increasing number of Internet protocols and data formats are
extended by specifications for adding spatial (geographic) location.
In most cases, latitude as well as longitude of simple points are
added as new attributes to existing data structures. However, all
those methods are very specific to a certain data format or protocol,
and don't provide a protocol independent, compact and generic way to
refer to a physical geographic location.
Over the past few years, fast emerging location aware applications
and location based services were observable on the Internet. Most
web search engines use geographic information, and a vivid open
source mapping community brought an enormous momentum into location
aware technology. A wide range of tools and data sets which formerly
were accessible to professional only became available for a wider
audience.
The 'geo' URI scheme is another step into that direction and aims to
facilitate, support and standardize the problem of location
identification in geospatial services and applications. Accessing
information about a particular location on earth or trigger further
services shouldn't be any harder than clicking on a 'mailto:' link
and write an email straight away.
According to [RFC3986], a Uniform Resource Identifier (URI) is "a
compact sequence of characters that identifies an abstract or
physical resource". The 'geo' URI scheme defined in this document
identifies geographic locations (a physical resource) in a coordinate
references system (CRS), per default in World Geodetic System 1984
(WGS-84) [WGS84]. The scheme provides the textual representation of
the location's spatial coordinates in either two or three dimensions
(latitude, longitude, and optionally altitude for 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
strictly focused on the simplest, but also most common representation
of a spatial location - a single point in a well known CRS. The
provision of more complex geometries or locations described by civic
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
Mayrhofer & Spanring Expires March 5, 2010 [Page 5]
Internet-Draft 'geo' URI Scheme September 2009
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
widespread availability of Global Positioning System (GPS) devices,
which use the WGS-84 reference system. It is anticipated that such
devices serve as one of the primary data sources for authoring 'geo'
URIs, hence the adoption of the native GPS reference system for the
URI scheme. Also, many other data formats for representing
geographic locations use the WGS-84 reference system, which makes
transposing from and to such data formats less error prone (no re-
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.
2. Terminology
Geographic locations in this document are defined using WGS 84 (World
Geodetic System 1984), equivalent to the International Association of
Oil & Gas Producers (OGP) Surveying and Positioning Committee EPSG
(European Petroleum Survey Group) code 4326 (2 dimensions) and 4979
(3 dimensions). This document does not assign responsibilities for
coordinate transformations from and to other Spatial Reference
Systems.
A 2-dimensional WGS-84 coordinate value is here represented as a
comma-delimited latitude/longitude pair, measured in decimal degrees
(un-projected). A 3-dimensional WGS-84 coordinate value is here
represented by appending a comma-delimited altitude value in meters
to such pairs.
Latitudes range from -90 to 90 and longitudes range from -180 to 180.
Coordinates in the Southern and Western hemispheres as well as
altitudes below the WGS-84 reference geoid are signed negative with a
leading dash.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. IANA Registration of 'geo' URI Scheme
This section contains the fields required for the URI scheme
Mayrhofer & Spanring Expires March 5, 2010 [Page 6]
Internet-Draft 'geo' URI Scheme September 2009
registration, following the guidelines in section 5.4 of [RFC4395].
3.1. URI Scheme Name
geo
3.2. Status
permanent
3.3. URI Scheme Syntax
The syntax of the 'geo' URI scheme is specified below in Augmented
Backus-Naur Form (ABNF) [RFC5234]:
geo-URI = geo-scheme ":" geo-path
geo-scheme = "geo"
geo-path = coordinates *p
coordinates = coord-a "," coord-b [ "," coord-c ]
coord-a = num
coord-b = num
coord-c = num
p = crsp / uncp / parameter
crsp = ";crs=" crslabel
crslabel = "wgs84" / labeltext
uncp = ";u=" pnum
parameter = ";" pname [ "=" pvalue ]
pname = labeltext
pvalue = 1*paramchar
paramchar = p-unreserved / unreserved / pct-encoded
labeltext = 1*( alphanum / "-" )
pnum = 1*DIGIT [ "." 1*DIGIT ]
num = [ "-" ] pnum
unreserved = alphanum / mark
mark = "-" / "_" / "." / "!" / "~" / "*" /
"'" / "(" / ")"
pct-encoded = "%" HEXDIG HEXDIG
p-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$"
alphanum = ALPHA / DIGIT
Both "crs" and "u" parameters MUST NOT appear more than once each.
The "crs" and "u" parameters MUST be given before any other
parameters that may be defined in future extensions. The "crs"
parameter MUST be given first if both "crs" and "u" are used. The
definition of other parameters, and "crs" values beyond the default
Mayrhofer & Spanring Expires March 5, 2010 [Page 7]
Internet-Draft 'geo' URI Scheme September 2009
value of "wgs84" is out of scope of this document. Section 8.2
discusses the IANA registration of such additional parameters and
values.
In case the URI identifies a location in the default CRS of WGS-84,
its sub-components are further restricted as follows:
coord-a = latitude
coord-b = longitude
coord-c = altitude
latitude = [ "-" ] 1*2DIGIT [ "." 1*DIGIT ]
longitude = [ "-" ] 1*3DIGIT [ "." 1*DIGIT ]
altitude = [ "-" ] 1*DIGIT [ "." 1*DIGIT ]
3.4. URI Scheme Semantics
Data contained in a 'geo' URI identifies a physical resource: A
spatial location on earth identified by the geographic coordinates
encoded in the URI.
3.4.1. Coordinate Reference System Identification
The semantics of the 'coordinates' component depends on the CRS of
the URI. The CRS itself is identified by the optional 'crs'
parameter. A URI instance uses the default WGS-84 CRS if the 'crs'
parameter is either missing, or contains the value of 'wgs84'. Other
'crs' values are currently not defined, but may be specified by
future documents.
Interpretation of coordinates in a wrong CRS produces invalid
location information. Consumers of 'geo' URIs therefore MUST NOT
ignore the 'crs' parameter if given, and MUST NOT interpret the
'coordinates' component without considering and understanding the
'crs' parameter value.
The following component description refers to the use of the default
CRS (WGS-84) only. Future documents specifying other 'crs' parameter
values MUST provide similar descriptions for the 'coordinates' sub-
components in the described CRS.
3.4.2. Component Description for WGS-84
The "latitude", "longitude" and "altitude" components as specified in
the URI scheme syntax ( Section 3.3) are to be used as follows:
Mayrhofer & Spanring Expires March 5, 2010 [Page 8]
Internet-Draft 'geo' URI Scheme September 2009
o The "latitude" component MUST contain the latitude of the
identified location in decimal degrees in the reference system
WGS-84.
o The "longitude" component MUST contain the longitude of the
identified location in decimal degrees in the reference system
WGS-84.
o If present, the OPTIONAL "altitude" component MUST contain the
identified altitude in meters in the reference system WGS-84.
If the altitude of the location is unknown, the "altitude" component
MUST NOT be present in the URI. Specifically, unknown altitude MUST
NOT be represented by setting the 'altitude' component to "0" (or any
other arbitrary value).
The "longitude" components of coordinate values reflecting the poles
(latitude set to -90 or 90 degrees) SHOULD be set to "0", although
consumers of "geo" URIs MUST accept such URIs with any longitude
value from -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
90 degrees MUST be considered invalid.
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
'coord-a', 'coord-b', 'coord-c' and 'u' values are mathematically
identical.
Two URIs use the same CRS if both have the 'crs' parameter omitted,
Mayrhofer & Spanring Expires March 5, 2010 [Page 9]
Internet-Draft 'geo' URI Scheme September 2009
or both have the same 'crs' parameter value, or one has the 'crs'
parameter omitted while the other URI specifies the default CRS
explicitely with a 'crs' parameter value of "wgs84".
For the default CRS of WGS-84, the following definitions apply in
addition:
o Where the 'latitude' component of a 'geo' URI is set to either 90
or -90 degrees, the 'longitude' component MUST be ignored in
comparison operations ("poles case").
o A 'longitude' component of 180 degrees MUST be considered equal a
'longitude' component of -180 degrees for the purpose of URI
comparison ("date line" case).
An URI with undefined (missing) 'coord-c' (altitude) value MUST NOT
be considered equal to an URI containing an 'coord-c' value, even if
the remaining values 'coord-a', 'coord-b' and 'u' are equivalent.
3.4.5. Interpretation of 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
physical surface at the given 'latitude' and 'longitude' coordinate.
However, as defined above, altitudes are relative to the WGS-84
reference geoid rather than earth's surface. Hence, an altitude
value of 0 MUST NOT be mistaken to refer to "ground elevation".
3.5. Encoding Considerations
The 'coordinates' path component of the 'geo' URI (see Section 3.3)
uses a comma (",") as a delimiter for subcomponents. This delimiter
MUST NOT be percent encoded.
It is RECOMMENDED that for readability the contents of 'coord-a',
'coord-b' and 'coord-c' subcomponents, as well as the 'crs' and 'u'
parameters are never percent encoded.
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
identification independent of a specific application or protocol.
Mayrhofer & Spanring Expires March 5, 2010 [Page 10]
Internet-Draft 'geo' URI Scheme September 2009
Examples of potential protocol mappings and use cases can be found in
Section 6.
3.7. Interopability Considerations
Like other new URI schemes, 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 humans.
Clients MUST NOT attempt to dereference URIs given in an CRS that is
unknown to the client, because doing so would produce entirely bogus
results.
Authors of 'geo' URIs should carefully check that coordinate
components are set in the right CRS and in the specified order, since
wrong order of those components (or use of coordinates in a different
CRS without transformation) are commonly observed mistakes producing
completely bogus locations.
The number of digits in the coordinates values MUST NOT be
interpreted as an indication to a certain level of accuracy or
uncertainty.
3.8. Contact
Alexander Mayrhofer <alexander.mayrhofer@nic.at>
Christian Spanring <cspanring@gmail.com>
3.9. Author/Change controller
The 'geo' URI scheme is registered under the IETF part of the URI
tree. As such, change control is up to the IETF.
3.10. References
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
Mayrhofer & Spanring Expires March 5, 2010 [Page 11]
Internet-Draft 'geo' URI Scheme September 2009
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
Currently, just one operation on a 'geo' URI is defined - location
dereference: In that operation, a client dereferences the URI by
extracting the geographical coordinates from the URI path component
('geo-path' in the ABNF). Further use of those coordinates (and the
uncertainty value from the 'u' parameter) is then up to the
application processing the URI, and might depend on the context of
the URI.
An application may then use this location information for various
purposes, for example:
Mayrhofer & Spanring Expires March 5, 2010 [Page 12]
Internet-Draft 'geo' URI Scheme September 2009
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
o A navigational device such as a Global Positioning System (GPS)
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.1. Plain 'geo' URI Example
The following 3-dimensional 'geo' URI example references to the
office location of one of the authors in Vienna, Austria:
geo:48.2010,16.3695,183
A user could type the data extracted from this URI into a electronic
navigation device, or even use it to locate the identified location
on a paper map.
6.2. Hyperlink
'geo' URIs (like any other URI scheme) could also be embedded as
hyperlinks in web pages. A Hyper Text Markup Language (HTML) snippet
with such a hyperlink could look like:
<p>one of Vienna's popular sights is the
<a href='geo:48.198634,16.371648;crs=wgs84'>Karlskirche</a>.
A web browser could extract the coordinates from the HTML snippet,
and offer the user various options (based on configuration, context),
for example:
o Display a small map thumbnail when the mouse pointer hovers over
the link.
o Switch to a mapping service of the user's choice once the link is
selected.
o Locate nearby resources, for example by comparing the 'geo' URI
with locations extracted from GeoRSS feeds the user has subscribed
to.
Mayrhofer & Spanring Expires March 5, 2010 [Page 13]
Internet-Draft 'geo' URI Scheme September 2009
o Convert the coordinates to a format suitable for uploading to a
navigation device.
Note that the URI in this example also makes use of the explicit
specification of the CRS by using the 'crs' parameter.
6.3. 'geo' URI in 2-dimensional barcode
Due to it's short length, a 'geo' URI could easily be encoded in
2-dimensional barcodes. Such barcodes could be printed on business
cards, flyers, paper maps and subsequently used by mobile devices,
for example as follows:
1. User identifies such a barcode on a flyer and uses the camera on
his mobile phone to photograph and decode the barcode
2. The mobile phone dereferences the 'geo' URI, and offers the user
to calculate a navigation route to the identified location.
3. Using the builtin GPS receiver, the user follows the navgiation
instructions to reach the location
7. GML Mappings
The Geographic Markup Language (GML) by the Open Geospatial
Consortium (OGC) is a set of XML schemas to represent geographical
features. Since GML is widely accepted, this document includes
instructions on how to transpose 'geo' URIs from and to GML
documents. The instructions in this section are not normative.
For the following sections, "%lat%", "%lon%", "%alt%" and "%unc%" are
placeholders for latitude, longitude, altitude and uncertainty
values. The mappings use WGS-84, and are defined in the following
sections.
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.
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
converted to decimal when placed in the 'geo' URI.
Mayrhofer & Spanring Expires March 5, 2010 [Page 14]
Internet-Draft 'geo' URI Scheme September 2009
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:%lat%,%lon%
GML document:
<Point srsName="urn:ogc:def:crs:EPSG::4326"
xmlns="http://www.opengis.net/gml">
<pos>%lat% %lon%</pos>
</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.
7.2. 3D GML 'Point'
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:%lat%,%lon%,%alt%
GML document:
<Point srsName="urn:ogc:def:crs:EPSG::4979"
xmlns="http://www.opengis.net/gml">
<pos>%lat% %lon% %alt%</pos>
</Point>
7.3. GML 'Circle'
A GML 'Circle' [RFC5491] is constructed from a 'geo' URI that has two
coordinates and an uncertainty parameter that is present and non-
zero.
Mayrhofer & Spanring Expires March 5, 2010 [Page 15]
Internet-Draft 'geo' URI Scheme September 2009
'geo' URI:
geo:%lat%,%lon%;u=%unc%
GML document:
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326"
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>
7.4. GML 'Sphere'
A GML 'sphere' [RFC5491] is constructed from a 'geo' URI that has
three coordinates and an uncertainty parameter that is present and
non-zero.
'geo' URI:
geo:%lat%,%lon%,%alt%;u=%unc%
GML document:
<gs:Sphere srsName="urn:ogc:def:crs:EPSG::4979"
xmlns:gml="http://www.opengis.net/gml"
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.1. 'geo' URI Scheme
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
(RFC 4395) [RFC4395]. The definitions required for the assignment
are contained in Section 3.
Mayrhofer & Spanring Expires March 5, 2010 [Page 16]
Internet-Draft 'geo' URI Scheme September 2009
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
Because the 'geo' URI is not tied to any specific protocol, and
identifies a physical location rather than a network resource, most
of the general security considerations on URIs (Section 7 of RFC
3986) do not apply. However, the following (additional) issues
apply:
Mayrhofer & Spanring Expires March 5, 2010 [Page 17]
Internet-Draft 'geo' URI Scheme September 2009
9.1. Invalid Locations
The URI syntax (Section 3.3) makes it possible to construct 'geo'
URIs which don't identify a valid location on earth. Applications
MUST NOT use URIs with such values, and SHOULD warn the user when
such URIs are encountered.
An example of such an URI refering to an invalid location would be
<geo:94,0> (latitude "beyond" north pole).
9.2. Location Privacy
A 'geo' URI by itself is just an opaque reference to a physical
location, expressed by a set of spatial oordinates. This does not
fit the "Location Information" definition according to Section 5.2 of
GEOPRIV Requirements [RFC3693], because there is not necessarily a
"Device" involved.
Because there is also no way to specify the identity of a "Target" in
a 'geo' URI by itself, it does also not fit the specification of an
"Location Object" (Section 5.2 of RFC3693).
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
Martin Thomson has provided significant text around the definition of
the "uncertainty" parameter and the GML mappings.
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
Mayrhofer & Spanring Expires March 5, 2010 [Page 18]
Internet-Draft 'geo' URI Scheme September 2009
11.1. Normative References
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009.
11.2. Informative References
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 115,
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
Defense World Geodetic System 1984, Third Edition",
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
Mayrhofer & Spanring Expires March 5, 2010 [Page 19]
Internet-Draft 'geo' URI Scheme September 2009
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
Mayrhofer & Spanring Expires March 5, 2010 [Page 20]
Internet-Draft 'geo' URI Scheme September 2009
Authors' Addresses
Alexander Mayrhofer
nic.at GmbH
Karlsplatz 1/2/9
Wien A-1010
Austria
Phone: +43 1 5056416 34
Email: alexander.mayrhofer@nic.at
URI: http://www.nic.at/
Christian Spanring
5 Crawford St
Cambridge 02139
Phone: +1 617 800 7885
Email: christian@spanring.eu
URI: http://www.spanring.eu/
Mayrhofer & Spanring Expires March 5, 2010 [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-24 05:05:15 |