[Docs] [txt|pdf|xml] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-mayrhofer-geopriv-geo-uri) 00 01 02 03 04 05 06 07 RFC 5870

GEOPRIV -- Geographic                                       A. Mayrhofer
Location/Privacy Working Group                                    nic.at
Internet-Draft                                               C. Spanring
Expires: January 4, 2010                                          OIR-ID
                                                           July 03, 2009


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

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 January 4, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Mayrhofer & Spanring     Expires January 4, 2010                [Page 1]


Internet-Draft              'geo' URI scheme                   July 2009


   This document is subject to BCP 78 and the IETF Trust's Legal
   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 January 4, 2010                [Page 2]


Internet-Draft              'geo' URI scheme                   July 2009


Table of Contents

   1.  Change Log . . . . . . . . . . . . . . . . . . . . . . . . . .  5

   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5

   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  7

   4.  IANA Registration of 'geo' URI Scheme  . . . . . . . . . . . .  7
     4.1.  URI Scheme Name  . . . . . . . . . . . . . . . . . . . . .  7
     4.2.  Status . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.3.  URI Scheme Syntax  . . . . . . . . . . . . . . . . . . . .  7
     4.4.  URI Scheme Semantics . . . . . . . . . . . . . . . . . . .  9
       4.4.1.  Coordinate Reference System Identification . . . . . .  9
       4.4.2.  Component Description for WGS-84 . . . . . . . . . . .  9
       4.4.3.  URI Comparison . . . . . . . . . . . . . . . . . . . . 10
       4.4.4.  Interpretation of Undefined Altitude . . . . . . . . . 10
     4.5.  Encoding Considerations  . . . . . . . . . . . . . . . . . 10
     4.6.  Applications/protocols That Use This URI Scheme  . . . . . 11
     4.7.  Interopability Considerations  . . . . . . . . . . . . . . 11
     4.8.  Security Considerations  . . . . . . . . . . . . . . . . . 11
     4.9.  Contact  . . . . . . . . . . . . . . . . . . . . . . . . . 11
     4.10. Author/Change controller . . . . . . . . . . . . . . . . . 12
     4.11. References . . . . . . . . . . . . . . . . . . . . . . . . 12

   5.  URI Operations . . . . . . . . . . . . . . . . . . . . . . . . 12

   6.  Use Cases and Examples . . . . . . . . . . . . . . . . . . . . 12
     6.1.  Plain 'geo' URI Example  . . . . . . . . . . . . . . . . . 12
     6.2.  Hyperlink  . . . . . . . . . . . . . . . . . . . . . . . . 12
     6.3.  'geo' URI in 2-dimensional barcode . . . . . . . . . . . . 13

   7.  GML Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 13
     7.1.  'geo' URI without altitude to GML 'Point'  . . . . . . . . 14
     7.2.  'geo' URI with Altitude to GML 'Point' . . . . . . . . . . 14
     7.3.  GML 'Point' without Altitude to 'geo' URI  . . . . . . . . 14
     7.4.  GML 'Point' with Altitude to 'geo' URI . . . . . . . . . . 15

   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15

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

   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16

   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 16



Mayrhofer & Spanring     Expires January 4, 2010                [Page 3]


Internet-Draft              'geo' URI scheme                   July 2009


     11.2. Informative References . . . . . . . . . . . . . . . . . . 17

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
















































Mayrhofer & Spanring     Expires January 4, 2010                [Page 4]


Internet-Draft              'geo' URI scheme                   July 2009


1.  Change Log

   [Note to editors: This section is to be removed before publication -
   XML source available on request]

   draft-ietf-geopriv-geo-uri-01
   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


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



Mayrhofer & Spanring     Expires January 4, 2010                [Page 5]


Internet-Draft              'geo' URI scheme                   July 2009


   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 and former to professionals exclusive
   tools and data were provided free of charge for an everyday use on
   the mass market.

   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 or trigger further services based on a particular
   place on earth shouldn't be any harder for users 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 optional "crs" URI parameter described below
   may be used by future specifications to define the use of other
   CRSes.  However, such definitions are out of scope of this document.

   'Geo' URIs identify a geographic location using a textual
   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.  The provision of more
   complex geometries or locations described by civic addresses is 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).




Mayrhofer & Spanring     Expires January 4, 2010                [Page 6]


Internet-Draft              'geo' URI scheme                   July 2009


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


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

4.1.  URI Scheme Name

   geo

4.2.  Status

   permanent

4.3.  URI Scheme Syntax

   The syntax of the 'geo' URI scheme is specified below in Augmented
   Backus-Naur Form (ABNF) [RFC4234]:








Mayrhofer & Spanring     Expires January 4, 2010                [Page 7]


Internet-Draft              'geo' URI scheme                   July 2009


             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 / parameter
             crsp          = ";crs=" crslabel
             crslabel      = "wgs84"
             parameter     = ";" pname [ "=" pvalue ]
             pname         = 1*( alphanum / '-' )
             pvalue        = 1*paramchar
             paramchar     = p-unreserved / unreserved / pct-encoded

             num           = [ "-" ] 1*DIGIT [ "." 1*DIGIT ]
             unreserved    = alphanum / mark
             mark          = "-" / "_" / "." / "!" / "~" / "*" /
                             "'" / "(" / ")"
             pct-encoded   = "%" HEXDIG HEXDIG
             p-unreserved  = "[" / "]" / "/" / ":" / "&" / "+" / "$"
             alphanum      = ALPHA / DIGIT

   The optional "crs" parameter MUST NOT appear more than once.  If
   other parameters are also given, the "crs" parameter MUST be given
   first.  The definition of other parameters besides "crs" is out of
   scope for this document.

   Future documents proposing the use of other CRSes may update the
   definition of the 'crslabel' component.

   In case the URI identifies a location in the default CRS of WGS-84,
   its sub-components are further restricted as follows:

             coord-a        = latitude
             coord-b        = longitude
             coord-c        = altitude

             latitude       = [ "-" ] 1*2DIGIT [ "." 1*DIGIT ]
             longitude      = [ "-" ] 1*3DIGIT [ "." 1*DIGIT ]
             altitude       = [ "-" ] 1*DIGIT [ "." 1*DIGIT ]








Mayrhofer & Spanring     Expires January 4, 2010                [Page 8]


Internet-Draft              'geo' URI scheme                   July 2009


4.4.  URI Scheme Semantics

   Data contained in a 'geo' URI identifies a physical resource: A
   spatial location on earth in the in a coordinate reference system,
   identified by the geographic coordinates encoded in the URI.

4.4.1.  Coordinate Reference System Identification

   The semantics of the 'coordinates' component depends on the CRS of
   the URI.  The CRS itself is identified by the optional 'crs'
   parameter the default.  A URI instance uses the default WGS-84 CRS if
   the 'crs' parameter is either missing, or contains the value of
   'wgs84'.  Other 'crs' values are not currently defined, but may be
   specified by future documents.

   Interpretation of coordinates in a wrong CRS produces invalid
   location information.  Consumers of 'geo' URIs therefore MUST NOT
   ignore the 'crs' parameter if given, and MUST NOT attempt to
   interpret the 'coordinates' component of given in an unknown CRS.

   The following component description refers to the use of the default
   CRS (WGS-84) only.  Future documents specifying other 'crs' parameter
   values MUST provide similar descriptions for the 'coordinates' sub-
   components in the described CRS.

4.4.2.  Component Description for WGS-84

   The "latitude", "longitude" and "altitude" components as specified in
   the URI scheme syntax ( Section 4.3) are to be used as follows:
   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
      WGS-84 altitude of the identified location in meters.

   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 between -180 and 180.




Mayrhofer & Spanring     Expires January 4, 2010                [Page 9]


Internet-Draft              'geo' URI scheme                   July 2009


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

4.4.3.  URI Comparison

   Two 'geo' URIs are equal when they use the same CRS, and their
   'coord-a', 'coord-b' and 'coord-c' values are mathematically
   identical.

   Two 'geo' URIs use the same CRS if:
   o  their 'crslabel' components are identical
   o  or if neither URIs contain a 'crs' parameter (in which case both
      URIs use WGS-84)
   o  or if one URI contains a 'crslabel' value of 'wgs84', while the
      other URI does not contain a 'crs' parameter (which means that
      both URIs use the WGS-84 reference system as well, with one of the
      URIs specifying the CRS explicitely)

   For the default CRS of WGS-84, the following definitions apply
   additionally:
   o  Where the 'latitude' component of a 'geo' URI is set to either 90
      or -90 degrees, the 'longitude' component MUST be ignored in
      comparison operations.
   o  A 'longitude' component of 180 degrees MUST be considered equal a
      'longitude' component of -180 degrees for the purpose of URI
      comparison.

   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' and 'coord-b' are equivalent.

4.4.4.  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 interpreted as "on earth's surface".

4.5.  Encoding Considerations

   The 'coordinates' path component of the 'geo' URI (see Section 4.3)
   uses a comma (",") as a delimiter for subcomponents.  This delimiter
   MUST NOT be percent encoded.




Mayrhofer & Spanring     Expires January 4, 2010               [Page 10]


Internet-Draft              'geo' URI scheme                   July 2009


   It is RECOMMENDED that for readability the contents of 'coord-a',
   'coord-b' and 'coord-c' subcomponents are never percent encoded.

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

4.7.  Interopability Considerations

   As with any other new URI scheme, the 'geo' URI requires support in
   client applications.  Users of applications which are not aware of
   the 'geo' scheme are likely unable to make direct use of the
   information in the URI.  However, the simple structure of the 'geo'
   URI would even allow manual dereference by users.

   Poorly authored 'geo' URI instances could contain whitespace and
   values with leading plus signs ("+"), which is not allowed according
   to the ABNF.  Clients SHOULD, however, try to dereference such URIs
   after removing such whitespace and plus signs.

   This specification does not define a query component.  Future
   revisions might define such components, using the "?" character to
   delimit query components from the path component specified above.
   Clients MUST be prepared to encounter such 'geo' URI instances, and
   MUST reduce the URI to the components specified in Section 4.3 before
   they dereference the URI.

   Clients MUST NOT attempt to dereference URIs given in an CRS that is
   unknown to the client, because doing so would produce entirely bogus
   results.

   Authors of 'geo' URIs should carefully check that coordinate
   components are set in the specified order, since wrong order of those
   components is a commonly observed mistake and produces completely
   bogus locations.

4.8.  Security Considerations

   See Section 9 of [insert reference to this document]

4.9.  Contact

   Christian Spanring (mailto:cspanring@gmail.at, http://spanring.eu/ ),
   Alexander Mayrhofer (mailto:alexander.mayrhofer@nic.at,
   http://timatio.com/ )



Mayrhofer & Spanring     Expires January 4, 2010               [Page 11]


Internet-Draft              'geo' URI scheme                   July 2009


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

4.11.  References

   RFC XXXX [change to RFC number once assigned]


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

   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.


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:




Mayrhofer & Spanring     Expires January 4, 2010               [Page 12]


Internet-Draft              'geo' URI scheme                   July 2009


   <p>one of Vienna's popular sights is the <a href='geo:
   48.198634,16.371648;crs=wgs84'>Karlskirche</a>.

   A web brower 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.

   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' URI 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, 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, the user follows the navgiation
       instructions from his phone to reach the destination


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.




Mayrhofer & Spanring     Expires January 4, 2010               [Page 13]


Internet-Draft              'geo' URI scheme                   July 2009


   A 'geo' URI can be mapped from a GML "point", and any 'geo' URI can
   be mapped to a GML "point" (given that both support the CRS used).
   For the following sections, "%lat%", "%lon%" and "%alt%" are
   placeholders for latitude, longitude, and altitude values.  Mappings
   are defined as follows:

7.1.  'geo' URI without altitude to GML 'Point'

   An instance of a WGS 84 'geo' URI without the altitude element is
   mapped to a two-dimensional GML "Point" as follows:

   'geo' URI:

       geo:%lat%,%lon%

   GML document:

       <?xml version="1.0" encoding="UTF-8">
       <Point srsDimension="2"
              srsName="urn:ogc:def:crs:EPSG:6.6:4326"
              xmlns="http://www.opengis.net/gml">
         <pos>%lat% %lon%</pos>
       </Point>

7.2.  'geo' URI with Altitude to GML 'Point'

   A WGS 84 'geo' URI instance with the altitude element is mapped to a
   three-dimensional GML "Point" as follows:

   'geo' URI:

       geo:%lat%,%lon%,%alt%

   GML document:

       <?xml version="1.0" encoding="UTF-8">
       <Point srsDimension="3"
              srsName="urn:ogc:def:crs:EPSG:6.6:4979"
              xmlns="http://www.opengis.net/gml">
         <pos>%lat% %lon% %alt%</pos>
       </Point>

7.3.  GML 'Point' without Altitude to 'geo' URI

   A GML 'Point' in the reference system identified as
   "urn:ogc:def:crs:EPSG:6.6:4326" is mapped to a 'geo' URI as follows:

   GML document:



Mayrhofer & Spanring     Expires January 4, 2010               [Page 14]


Internet-Draft              'geo' URI scheme                   July 2009


       <?xml version="1.0" encoding="UTF-8">
       <Point srsDimension="2"
              srsName="urn:ogc:def:crs:EPSG:6.6:4326"
              xmlns="http://www.opengis.net/gml">
         <pos>%lat% %lon%</pos>
       </Point>

   'geo' URI:

       geo:%lat%,%lon%

   Note: GML documents in other reference systems MAY be used as well if
   a transformation into "urn:ogc:def:crs:EPSG:6.6:4326" is defined and
   applied before the mapping step.

7.4.  GML 'Point' with Altitude to 'geo' URI

   A GML 'Point' in the reference system identified as
   "urn:ogc:def:crs:EPSG:6.6:4979" is mapped to a 'geo' URI as follows:

   GML document:

       <?xml version="1.0" encoding="UTF-8">
       <Point srsDimension="3"
              srsName="urn:ogc:def:crs:EPSG:6.6:4979"
              xmlns="http://www.opengis.net/gml">
         <pos>%lat% %lon% %alt%</pos>
       </Point>

   'geo' URI:

       geo:%lat%,%lon%,%alt%

   Note: GML 'Point' instances in other reference systems could be used
   as well if a transformation into "urn:ogc:def:crs:EPSG:6.6:4979" is
   defined and applied before the mapping step.  It should be noted that
   such reprojections are typically not lossless because of the limited
   accuracy of the mathematical calculations involved.


8.  IANA Considerations

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





Mayrhofer & Spanring     Expires January 4, 2010               [Page 15]


Internet-Draft              'geo' URI scheme                   July 2009


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 4.3) makes it possible to construct valid
   'geo' URIs which don't identify a valid location on earth.
   Applications MUST NOT use URIs which such invalid values, and SHOULD
   warn the user when such URIs are encountered.

   An example of such an invalid URI would be <geo:94,0> (latitude
   "beyond" north pole).

9.2.  Location Privacy

   Location information about individuals is an extremely sensitive
   topic, especially when location is combined with Personally
   Identifyable Information (PII).  Authors of 'geo' URIs MUST consider
   data protection and privacy before publishing such URIs.

   However, it should be noted that a 'geo' URI by itself is just opaque
   location information, and privacy considerations typically arise only
   when such opaque location information is put in context by combining
   it with other information (for example, embedding it within a message
   to reflect the current location of a person).


10.  Acknowledgements

   The authors wish to acknowledge the helpful contributions from Carl
   Reed, Bill McQuillan, Martin Kofal, Andrew Turner, Kim Sanders and
   Ted Hardie.


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



Mayrhofer & Spanring     Expires January 4, 2010               [Page 16]


Internet-Draft              'geo' URI scheme                   July 2009


              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 4234, October 2005.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

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.

   [WGS84]    National Imagery and Mapping Agency, "Department of
              Defense World Geodetic System 1984, Third Edition",
              NIMA TR8350.2, January 2000.


Authors' Addresses

   Alexander Mayrhofer
   nic.at GmbH
   Karlsplatz 1/9
   Wien  A-1010
   Austria

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


   Christian Spanring
   OIR-ID GmbH
   Franz-Josefs-Kai 27
   Wien  A-1010

   Phone: +43 1 5338747 36
   Email: cspanring@gmail.com
   URI:   http://www.oir.at/









Mayrhofer & Spanring     Expires January 4, 2010               [Page 17]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/