Skip to main content

A Uniform Resource Identifier for Geographic Locations ('geo' URI)
draft-ietf-geopriv-geo-uri-07

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 5870.
Authors Christian Spanring , Alexander Mayrhofer
Last updated 2022-11-02 (Latest revision 2010-04-14)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Proposed Standard
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 5870 (Proposed Standard)
Action Holders
(None)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Robert Sparks
Send notices to (None)
draft-ietf-geopriv-geo-uri-07
GEOPRIV -- Geographic                                       A. Mayrhofer
Location/Privacy Working Group                                     IPCom
Internet-Draft                                               C. Spanring
Intended status: Standards Track                          April 14, 2010
Expires: October 16, 2010

   A Uniform Resource Identifier for Geographic Locations ('geo' URI)
                     draft-ietf-geopriv-geo-uri-07

Abstract

   This document specifies a 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.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   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
   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."

   This Internet-Draft will expire on October 16, 2010.

Copyright Notice

   Copyright (c) 2010 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
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of

Mayrhofer & Spanring    Expires October 16, 2010                [Page 1]
Internet-Draft              'geo' URI Scheme                  April 2010

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5

   3.  IANA Registration of 'geo' URI Scheme  . . . . . . . . . . . .  6
     3.1.  URI Scheme Name  . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Status . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.3.  URI Scheme Syntax  . . . . . . . . . . . . . . . . . . . .  6
     3.4.  URI Scheme Semantics . . . . . . . . . . . . . . . . . . .  7
       3.4.1.  Coordinate Reference System Identification . . . . . .  7
       3.4.2.  Component Description for WGS-84 . . . . . . . . . . .  8
       3.4.3.  Location Uncertainty . . . . . . . . . . . . . . . . .  8
       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.  Security Considerations  . . . . . . . . . . . . . . . . . 11
     3.9.  Contact  . . . . . . . . . . . . . . . . . . . . . . . . . 11
     3.10. Author/Change controller . . . . . . . . . . . . . . . . . 11
     3.11. 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

Mayrhofer & Spanring    Expires October 16, 2010                [Page 2]
Internet-Draft              'geo' URI Scheme                  April 2010

     6.4.  Comparison Examples  . . . . . . . . . . . . . . . . . . . 15

   7.  GML Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 15
     7.1.  2D GML 'Point' . . . . . . . . . . . . . . . . . . . . . . 16
     7.2.  3D GML 'Point' . . . . . . . . . . . . . . . . . . . . . . 16
     7.3.  GML 'Circle' . . . . . . . . . . . . . . . . . . . . . . . 17
     7.4.  GML 'Sphere' . . . . . . . . . . . . . . . . . . . . . . . 17

   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
     8.1.  'geo' URI Scheme . . . . . . . . . . . . . . . . . . . . . 18
     8.2.  URI Parameter Registry . . . . . . . . . . . . . . . . . . 18
       8.2.1.  Registry Contents  . . . . . . . . . . . . . . . . . . 18
       8.2.2.  Registration Policy  . . . . . . . . . . . . . . . . . 19
     8.3.  Sub-Registry for 'crs' Parameter . . . . . . . . . . . . . 19
       8.3.1.  Registry Contents  . . . . . . . . . . . . . . . . . . 19
       8.3.2.  Registration Policy  . . . . . . . . . . . . . . . . . 20

   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
     9.1.  Invalid Locations  . . . . . . . . . . . . . . . . . . . . 20
     9.2.  Location Privacy . . . . . . . . . . . . . . . . . . . . . 20

   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21

   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 21
     11.2. Informative References . . . . . . . . . . . . . . . . . . 21

   Appendix A.  Change Log  . . . . . . . . . . . . . . . . . . . . . 22

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23

Mayrhofer & Spanring    Expires October 16, 2010                [Page 3]
Internet-Draft              'geo' URI Scheme                  April 2010

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.

   Location-aware applications and location-based services are fast
   emerging on the Internet.  Most web search engines use geographic
   information, and a vivid open source mapping community has brought an
   enormous momentum into location aware technology.  A wide range of
   tools and data sets which formerly were accessible to professionals
   only have became available to 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 or triggering further
   services shouldn't be any harder than clicking on a 'mailto:' link
   and writing 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 (physical resources) in a coordinate
   reference system (CRS), per default the 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).  An example of such an 'geo' URI follows:

      geo:13.4125,103.8667

   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.

Mayrhofer & Spanring    Expires October 16, 2010                [Page 4]
Internet-Draft              'geo' URI Scheme                  April 2010

   This is primarily intended to cope with the case of another CRS
   replacing WGS-84 as the predominantly used one, rather than allowing
   the arbitrary use of thousands of CRSes for the URI (which would
   clearly affect interopability).  The definition of 'crs' values
   beyond the default of "wgs84" is therefore out of scope of this
   document.

   This spec discourages use of alternate CRSes in use cases where
   comparison is an important function.

   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 will 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 represented here as a
   comma-delimited latitude/longitude pair, measured in decimal degrees
   (un-projected).  A 3-dimensional WGS-84 coordinate value is
   represented here 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].

Mayrhofer & Spanring    Expires October 16, 2010                [Page 5]
Internet-Draft              'geo' URI Scheme                  April 2010

3.  IANA Registration of 'geo' URI Scheme

   This section contains the fields required for the URI scheme
   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=" uval
             uval          = 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

   Parameter names are case insensitive, use of the lowercase

Mayrhofer & Spanring    Expires October 16, 2010                [Page 6]
Internet-Draft              'geo' URI Scheme                  April 2010

   representation is PREFERRED.  Case sensitivity of non-numeric
   parameter values MUST be described in the specification of the
   respective parameter.  For the 'crs' parameter, values are case
   insensitive, and lowercase is PREFERRED.

   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 <crslabel> values beyond the
   default value of "wgs84" is out of scope of this document.
   Section 8.2 discusses the IANA registration of such additional
   parameters and values.

   The value of "-0" for <num> is allowed, and identical to "0".

   In case the URI identifies a location in the default CRS of WGS-84,
   the <coordinates> 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 identified by the geographic coordinates and the CRS
   encoded in the URI.

3.4.1.  Coordinate Reference System Identification

   The semantics of <coordinates> 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 <crslabel> values
   are currently not defined, but may be specified by future documents.

   Interpretation of coordinates in the 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> sub-components without considering and understanding
   the 'crs' parameter value.

   The following component description refers to the use of the default

Mayrhofer & Spanring    Expires October 16, 2010                [Page 7]
Internet-Draft              'geo' URI Scheme                  April 2010

   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:

   o  <latitude> MUST contain the latitude of the identified location in
      decimal degrees in the reference system WGS-84.
   o  <longitude> MUST contain the longitude of the identified location
      in decimal degrees in the reference system WGS-84.
   o  If present, the OPTIONAL <altitude> MUST contain the altitude of
      the identified location in meters in the reference system WGS-84.

   If the altitude of the location is unknown, <altitude> (and the comma
   before) MUST NOT be present in the URI.  Specifically, unknown
   altitude MUST NOT be represented by setting <altitude> to "0" (or any
   other arbitrary value).

   The <longitude> 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 object, <uval> 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 it is
   not specified, this indicates that uncertainty is unknown or
   unspecified.  If the intent is to indicate a specific point in space,
   <uval> MAY be set to zero.  Zero uncertainty and absent uncertainty
   are never the same thing.

   The single uncertainty value is applied to all dimensions given in
   the URI.

   Note: The number of digits of the values in <coordinates> MUST NOT be

Mayrhofer & Spanring    Expires October 16, 2010                [Page 8]
Internet-Draft              'geo' URI Scheme                  April 2010

   interpreted as an indication to uncertainty.

3.4.4.  URI Comparison

   Comparison of URIs intends to determine whether two URI strings are
   equivalent and identify the same resource (rather than comparing the
   resources themselves).  Therefore, a comparison of two 'geo' URIs
   does not compare spatial objects, but only the strings (URIs)
   identifying those objects.

   The term "mathematically identical" used below specifies that some
   components of the URI MUST be compared as normalized numbers rather
   than strings to account for the variety in string representations of
   identical numbers (for example, the strings "43.10" and "43.1" are
   different, but represent the same number).

   Two 'geo' URIs are equal only if they fulfill all of the following
   general comparison rules:

   o  Both URIs use the same CRS, which means that either both have the
      'crs' parameter omitted, or both have the same <crslabel> value,
      or one has the 'crs' parameter omitted while the other URI
      specifies the default CRS explicitely with a <crslabel> value of
      "wgs84".
   o  Their <coord-a>, <coord-b>, <coord-c> and 'u' values are
      mathematically identical (including absent <uval> meaning
      undefined 'u' value).
   o  Their sets of other parameters are equal, with comparison
      operations applied on each parameter as described in its
      respective specification.

   Parameter order is not significant for URI comparison.

   Since new parameters may be registered over time, legacy
   implementations of the 'geo' URI might encounter unknown parameters.
   In such cases, the following rules apply:

   o  Two 'geo' URIs with unknown parameters are equivalent only if the
      same set of unknown parameter names appears in each URI, and their
      values are bitwise identical after percent-decoding.
   o  Otherwise, the comparison operation for the respective URIs is
      undefined (since the legacy implementation is not be aware of the
      comparison rules for those parameters).

   Designers of future extension parameters should take this into
   account when choosing the comparison rules for new parameters.

   A URI with undefined (missing) <coord-c> (altitude) value MUST NOT be

Mayrhofer & Spanring    Expires October 16, 2010                [Page 9]
Internet-Draft              'geo' URI Scheme                  April 2010

   considered equal to a URI containing a <coord-c>, even if the
   remaining <coord-a>, <coord-b>, and their 'u' values are equivalent.

   For the default CRS of WGS-84, the following comparison rules apply
   additionally:

   o  Where <latitude> of a 'geo' URI is set to either 90 or -90
      degrees, <longitude> MUST be ignored in comparison operations
      ("poles case").
   o  A <longitude> of 180 degrees MUST be considered equal to
      <longitude> of -180 degrees for the purpose of URI comparison
      ("date line" case).

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.

   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 the 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> as well as <crslabel> and <uval> 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 the introduction of non-ASCII values.  Such
   specifications MUST describe internationalization considerations for
   those parameters and their values, and MUST require percent-encoding
   of non-ASCII 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.
   Examples of potential protocol mappings and use cases can be found in
   Section 6.

Mayrhofer & Spanring    Expires October 16, 2010               [Page 10]
Internet-Draft              'geo' URI Scheme                  April 2010

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 not able to make direct use of the information in
   the URI.  However, a client can make indirect use by passing around
   'geo' URIs even without understanding the format and semantics of the
   scheme.  Additionally, the simple structure of 'geo' URIs would allow
   even manual dereference by humans.

   Clients MUST NOT attempt to dereference 'geo' 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.  Security Considerations

   See Section 9 of [insert reference to this document]

3.9.  Contact

      Alexander Mayrhofer <axelm@ipcom.at>, <http://geouri.org/>
      Christian Spanring <christian@spanring.eu>

3.10.  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.11.  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" for the <parameter> component of the URI.
   Parameters for the 'geo' URI and values for these parameters MUST be

Mayrhofer & Spanring    Expires October 16, 2010               [Page 11]
Internet-Draft              'geo' URI Scheme                  April 2010

   registered with IANA to prevent namespace collisions, and provide
   interopability.

   Some parameters accept values that are constrained by a syntax
   definition only, while others accept values from a predefined set
   only.  Some parameters might not accept any values at all ("flag"
   type parameters).

   The registration of values is REQUIRED for parameters that accept
   values from a predefined set.

   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.

   Section 8.2.1 contains the initial contents of the Registry.

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>.  Further use of those coordinates (and the uncertainty
   value from <uval>) is then up to the application processing the URI,

Mayrhofer & Spanring    Expires October 16, 2010               [Page 12]
Internet-Draft              'geo' URI Scheme                  April 2010

   and might depend on the context of the URI.

   An application may then use this location information for various
   purposes, for example:

   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.

   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

   Resolution of the URI returns the following information:

   o  The 'crs' parameter is not given in the URI, which means that the
      URI uses the default CRS of WGS-84.
   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.
   o  The <coord-a> value (latitude in WGS-84) is set to '48.2010'
      decimal degrees.
   o  The <coord-b> value (longitude in WGS-84) is set to '16.3695'
      decimal degrees.
   o  The <coord-c> value (altitude in WGS-84) is set to 183 meters.
   o  Uncertainty is undefined.

   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

Mayrhofer & Spanring    Expires October 16, 2010               [Page 13]
Internet-Draft              'geo' URI Scheme                  April 2010

      <a href='geo:48.198634,16.371648;crs=wgs84;u=40'>Karlskirche</a>.

   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
      WGS-84 explicitely.
   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.
   o  The <coord-a> value (latitude in WGS-84) is set to '48.198634'
      decimal degrees.
   o  The <coord-b> value (longitude in WGS-84) is set to '16.371648'
      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 'u' parameter is included in the URI, setting uncertainty to
      40 meters.

   A web browser could use this information 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.

   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.

Mayrhofer & Spanring    Expires October 16, 2010               [Page 14]
Internet-Draft              'geo' URI Scheme                  April 2010

   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.

6.4.  Comparison Examples

   This section provides examples of URI comparison.  Note that the
   unknown parameters 'foo' and 'bar' and unregistered 'crs' values in
   this section are used for illustrative purposes only, and their
   inclusion in the examples below does not constitute any formal
   parameter definition or registration request.

   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
      values are different, both reflect a location on the north pole
      (special "poles" rule for WGS-84 applies - longitude is to be
      ignored).  Note that the 'crs' parameter values are case
      insensitive.
   o  The URIs <geo:22.300;-118.44> and <geo:22.3;-118.4400> are equal,
      because their coordinate components are mathematically identical
   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
      the unknown parameter 'foo' is bitwise identical after percent-
      decoding, parameter names are case insensitive, and coordinates
      and uncertainty are mathematically identical.
   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
      undefined, because the normalization rules for 'foo' are not
      known, and hence the implementation cannot identify whether or not
      '1.00' is identical to '1' for the 'foo' parameter.
   o  Comparing <geo:47,11;foo=blue;bar=white> and <geo:
      47,11;bar=white;foo=blue> returns true, because parameter order is
      insignificant in comparison operations
   o  The comparison operation on <geo:22,0;bar=Blue> and <geo:
      22,0;BAR=blue> is undefined, because even though parameter names
      are case insensitive, this is not neccessarily the case for the
      values of the unknown 'bar' parameter.

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 transform 'geo' URIs from and to GML
   fragments.  The instructions in this section are not normative.

Mayrhofer & Spanring    Expires October 16, 2010               [Page 15]
Internet-Draft              'geo' URI Scheme                  April 2010

   For the following sections, "%lat%", "%lon%", "%alt%" and "%unc%" are
   placeholders for latitude, longitude, altitude and uncertainty
   values, respectively.  The mappings use WGS-84, and are defined in
   the following sections.

   Note: GML fragments 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 fixed point when placed into the 'geo' URI.

7.1.  2D GML 'Point'

   A 2D GML 'Point' [RFC5491] is constructed from a 'geo' URI that has
   two coordinates and an uncertainty ('u') parameter that is absent or
   zero.  A GML point is always converted to a 'geo' URI that has no
   uncertainty parameter.

   'geo' URI:

      geo:%lat%,%lon%

   GML fragment:

     <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%

Mayrhofer & Spanring    Expires October 16, 2010               [Page 16]
Internet-Draft              'geo' URI Scheme                  April 2010

   GML fragment:

     <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.

   'geo' URI:

      geo:%lat%,%lon%;u=%unc%

   GML fragment:

      <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%

Mayrhofer & Spanring    Expires October 16, 2010               [Page 17]
Internet-Draft              'geo' URI Scheme                  April 2010

   GML fragment:

      <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.

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.

   Unless specific instructions exists for a Parameter (like the
   definition of a Sub-registry), the following information MUST be
   provided when registering new values for existing "Predefined" 'geo'
   URI Parameters:

   o  Name of the Parameter.
   o  Reference to the RFC or other permanent and readily available
      public specification defining the new values.

Mayrhofer & Spanring    Expires October 16, 2010               [Page 18]
Internet-Draft              'geo' URI Scheme                  April 2010

   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" (which implies
   "Designated Expert"), as defined in [RFC5226].

8.3.  Sub-Registry for 'crs' Parameter

   This document creates a new IANA Sub-registry named "'geo' URI 'crs'
   Parameter Values", based on the Registry specified in Section 8.2 and
   the information in this section and Section 4.  The syntax of the
   'crs' parameter is constrained by the ABNF given in Section 3.3.

8.3.1.  Registry Contents

   When registering a new value for the 'crs' parameter, the following
   information MUST be provided:

   o  Value of the parameter.
   o  Reference to the RFC or other permanent and readily available
      public specification defining the use of the CRS in the scope of
      the 'geo' URI.  The specification should contain information that
      is similar to the WGS-84-specific text given in this document.
   o  Reference to the definition document of the CRS.  If a URN is
      assigned to the CRS, the use of such URN as reference is
      preferred.  Note that different URNs may exist for the
      2-dimensional and 3-dimensional case.

   The following table provides the initial values for this registry:

         crs Value     Reference(s)    CRS definition(s)
         -----------------------------------------------------------
         wgs84         [RFCxxxx]       urn:ogc:def:crs:EPSG::4326
                                       urn:ogc:def:crs:EPSG::4979

   [Note to RFC Editor: Replace RFCxxxx with reference to this document]

Mayrhofer & Spanring    Expires October 16, 2010               [Page 19]
Internet-Draft              'geo' URI Scheme                  April 2010

8.3.2.  Registration Policy

   The registration policy for the "'geo' URI 'crs' Parameter Values"
   Registry shall require both "Specification Required" and "IESG
   Approval" as defined in [RFC5226].

   Section 1 contains some text about the motivation when to introduce
   new 'crs' values.

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:

9.1.  Invalid Locations

   The URI syntax (Section 3.3) makes it possible to construct 'geo'
   URIs which don't identify a valid location.  Applications MUST NOT
   use URIs with such values, and SHOULD warn the user when such URIs
   are encountered.

   An example of such an URI referring 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 coordinates.  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"
   within the confines of a 'geo' URI, it also does not fit the
   specification of an "Location Object" (Section 5.2 of RFC 3693).

   However, if a 'geo' URI is used in a context where it identifies the
   location of a Target, it becomes part of a Location Object and is
   therefore subject to GEOPRIV rules.

   Therefore, when 'geo' URIs are put into such contexts, the privacy
   requirements of RFC 3693 MUST be met.

Mayrhofer & Spanring    Expires October 16, 2010               [Page 20]
Internet-Draft              'geo' URI Scheme                  April 2010

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, Cullen Jennings, Klaus Darilion, Bjorn
   Hoehrmann, Alissa Cooper and Ivan Shmakov.

   Alfred Hoenes has provided an extremely helpful in-depth review of
   the document.

11.  References

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 35,
              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",

Mayrhofer & Spanring    Expires October 16, 2010               [Page 21]
Internet-Draft              'geo' URI Scheme                  April 2010

              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-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

Mayrhofer & Spanring    Expires October 16, 2010               [Page 22]
Internet-Draft              'geo' URI Scheme                  April 2010

   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

   Alexander Mayrhofer
   IPCom GmbH
   Karlsplatz 1/2/9
   Wien  A-1010
   Austria

   Phone: +43 1 5056416 34
   Email: alexander.mayrhofer@ipcom.at
   URI:   http://www.ipcom.at/

Mayrhofer & Spanring    Expires October 16, 2010               [Page 23]
Internet-Draft              'geo' URI Scheme                  April 2010

   Christian   Spanring
   30 Hancock St
   Somerville  02144

   Phone: +1 617 863 0360
   Email: christian@spanring.eu
   URI:   http://www.spanring.eu/

Mayrhofer & Spanring    Expires October 16, 2010               [Page 24]