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

Versions: 00 01 02

Network Working Group                                       A. Mayrhofer
Internet-Draft                                                   enum.at
Expires: December 31, 2007                                   C. Spanring
                                                                  OIR-ID
                                                           June 29, 2007


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

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 December 31, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document specifies an Uniform Resource Identifier (URI) for
   geographic locations using the 'geo' scheme name.  A 'geo' URI
   provides latitude, longitude and optionally altitude of a location in
   a simple, human-readable, and protocol independent way.






Mayrhofer & Spanring    Expires December 31, 2007               [Page 1]

Internet-Draft              'geo' URI scheme                   June 2007


Table of Contents

   1.  Change Log . . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4

   4.  IANA Registration of 'geo' URI Scheme  . . . . . . . . . . . .  4
     4.1.  URI Scheme Name  . . . . . . . . . . . . . . . . . . . . .  4
     4.2.  Status . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     4.3.  URI Scheme Syntax  . . . . . . . . . . . . . . . . . . . .  4
     4.4.  URI Scheme Semantics . . . . . . . . . . . . . . . . . . .  4
       4.4.1.  Component Description  . . . . . . . . . . . . . . . .  5
       4.4.2.  URI Comparison . . . . . . . . . . . . . . . . . . . .  5
       4.4.3.  Interpretation of Undefined Altitude . . . . . . . . .  5
     4.5.  Encoding Considerations  . . . . . . . . . . . . . . . . .  5
     4.6.  Applications/protocols That Use This URI Scheme  . . . . .  6
     4.7.  Interopability Considerations  . . . . . . . . . . . . . .  6
     4.8.  Security Considerations  . . . . . . . . . . . . . . . . .  6
     4.9.  Contact  . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.10. Author/Change controller . . . . . . . . . . . . . . . . .  6
     4.11. References . . . . . . . . . . . . . . . . . . . . . . . .  6

   5.  Use of 'geo' URIs  . . . . . . . . . . . . . . . . . . . . . .  6
     5.1.  Generation . . . . . . . . . . . . . . . . . . . . . . . .  6
     5.2.  Processing . . . . . . . . . . . . . . . . . . . . . . . .  6
     5.3.  URI Operations . . . . . . . . . . . . . . . . . . . . . .  6

   6.  Examples and Use Cases . . . . . . . . . . . . . . . . . . . .  7
     6.1.  Plain 'geo' URI  . . . . . . . . . . . . . . . . . . . . .  7
     6.2.  Hyperlink  . . . . . . . . . . . . . . . . . . . . . . . .  7
     6.3.  Header Field . . . . . . . . . . . . . . . . . . . . . . .  7

   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8

   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
     8.1.  Invalid Locations  . . . . . . . . . . . . . . . . . . . .  8
     8.2.  Location Privcay . . . . . . . . . . . . . . . . . . . . .  8

   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     9.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
     9.2.  Informative References . . . . . . . . . . . . . . . . . .  9

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9
   Intellectual Property and Copyright Statements . . . . . . . . . . 10





Mayrhofer & Spanring    Expires December 31, 2007               [Page 2]

Internet-Draft              'geo' URI scheme                   June 2007


1.  Change Log

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

   draft-mayrhofer-geo-uri-01
      removed parameters

   draft-mayrhofer-geo-uri-00
      initial draft


2.  Introduction

   An increasing number of Internet protocols and data formats are being
   enriched by specifications on how to add information about geographic
   location to them.  In most cases, latitude as well as longitude are
   added as attributes to existing data structures.  However, all those
   methods are specific to a certain data format or protocol, and don't
   provide a generic way to protocol independent location
   identification.

   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.

   A Uniform Resource Identifier (URI) [1] is a compact sequence of
   characters that identifies an abstract or physical resource.  The
   'geo' URI scheme defined in this document identifies geographic
   locations, independent from a specific protocol application or data
   format.

   This document specifies the 'geo' Uniform Resource Identifier (URI)
   scheme for identifying geographic locations in the WGS84 [6]
   reference system.  'Geo' URIs identify a geographic location by the
   textual representation of the location's spatial coordinates in
   either two or three dimensions (latitude, longitude, and optionally



Mayrhofer & Spanring    Expires December 31, 2007               [Page 3]

Internet-Draft              'geo' URI scheme                   June 2007


   altitude).

   The provision of civic addresses to identify locations is out of
   scope of this document.


3.  Terminology

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


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 [5].

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) [3]:

             geo-URI       = geo-scheme ":" geo-path
             geo-scheme    = "geo"
             geo-path      = geo-location

             geo-location   = latitude "," longitude [ "," altitude ]

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


4.4.  URI Scheme Semantics

   Generally, data contained in a 'geo' URI identifies the geographic
   coordinates of a spatial location.

   Note: In order to achieve high user acceptance it seems inevitable to



Mayrhofer & Spanring    Expires December 31, 2007               [Page 4]

Internet-Draft              'geo' URI scheme                   June 2007


   adopt commonly known GPS parameters (latitude, longitude, altitude)
   where possible.

4.4.1.  Component Description

   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 decimal latitude of the
      identified location in the reference system WGS 84.
   o  The "longitude" componont MUST contain the decimal longitude of
      the identified location in the reference system WGS 84.
   o  If present, the OPTIONAL "altitude" component MUST contain the
      WGS84 decimal altitude of the identified location in meters
      (elevation above mean seal level).

   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 number of decimal places indicates the precision of the value.
   One degree equals 111.319,45m at the equator (40.075,004km / 360
   degree).  Five decimal places (0.00001 degree) seem to imply a for
   civil use sufficient accuracy.

4.4.2.  URI Comparison

   Two 'geo' URIs MUST be considered equal when their 'longitude',
   'latitude' and 'altitude' values are mathematically identical.

   An URI with undefined (missing) 'altitude' value MUST NOT be
   considered identical to an URI with an 'altitude' value, even if the
   remaining components 'latitude', and 'longitude' match.

4.4.3.  Interpretation of Undefined Altitude

   A consumer of an 'geo' URI with undefined 'altitude' MAY assume that
   the URI refers to the location on earth's surface at the given
   'latitude' and 'longitude' coordinate.

4.5.  Encoding Considerations

   The 'geo-location' 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.

   It is RECOMMENDED that for readability the contents of 'latitude',
   'longitude' and 'altitude' subcomponents are never percent encoded.



Mayrhofer & Spanring    Expires December 31, 2007               [Page 5]

Internet-Draft              'geo' URI scheme                   June 2007


4.6.  Applications/protocols That Use This URI Scheme

   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

   FIXME

4.8.  Security Considerations

   See Section 8 of [insert reference to this document]

4.9.  Contact

   Christian Spanring (mailto:spanring@oir.at, http://spanring.eu/),
   Alexander Mayrhofer (mailto:alexander.mayrhofer@enum.at,
   http://nona.net/)

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

   FIXME


5.  Use of 'geo' URIs

5.1.  Generation

   FIXME

5.2.  Processing

   FIXME

5.3.  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.
   Further use of those coordinates is then up to the application
   processing the URI.




Mayrhofer & Spanring    Expires December 31, 2007               [Page 6]

Internet-Draft              'geo' URI scheme                   June 2007


   An application may then use this location information for various
   purposes, for example:
      A web browser could that information into the URI of a web mapping
      service of the user's choice, and display a map of the location
      A navigational device such as a Global Positioning System (GPS)
      receiver could offer the user to start navigation to the location.


6.  Examples and Use Cases

6.1.  Plain 'geo' URI

   The following 3-dimensional 'geo' URI example references to the
   platform on the southern tower of the St. Stephan's Cathedral,
   Vienna, Austria:

   geo:FIXME,FIXME,FIXME

   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 could (like any other URI scheme) also be embedded as
   hyperlinks in web pages.  A Hyper Text Markup Language (HTML) FIXME:
   ref snippet with such a hyperlink could look like:

   <p>one of Vienna's most popular sights is the <a href=' geo:
   FIXME,FIXME,FIXME'>St. Stephans Cathedral</a>

6.3.  Header Field

   Various protocols support the use of arbitrary URI schemes in their
   header Fields.  For example, a Session Initiation Protocol (SIP) [4]
   REGISTER request could contain a 'Contact' header with a 'geo' URI,
   to reflect the current geographic location to be used when the
   registering entity is to be contacted:

            REGISTER sip:geoaware.example.com SIP/2.0
            Via: SIP/2.0/UDP mypc.example.org:5060;branch=z9hG4bKnashds7
            Max-Forwards: 70
            To: Joe Geo <sip:joe@example.com>
            From: Joe Geo <sip:joe@example.com>;tag=456248
            Call-ID: aaafafff-84230@7afagggdd
            CSeq: 42 REGISTER
            Contact: <sip:joe@192.168.1.1>
            Contact: <geo:FIXME,FIXME>



Mayrhofer & Spanring    Expires December 31, 2007               [Page 7]

Internet-Draft              'geo' URI scheme                   June 2007


7.  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) [5].  The definitions required for the assignment are
   contained in Section 4.


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

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

8.2.  Location Privcay

   Location information about individuals is an extremely sensitive
   topic, especially when location is combined with Personally
   Identifyable Information (PII).

   FIXME: Only for public data, or willing to publish it. consent of the
   user when publishing it.


9.  References

9.1.  Normative References

   [1]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
        Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
        January 2005.

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [3]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax



Mayrhofer & Spanring    Expires December 31, 2007               [Page 8]

Internet-Draft              'geo' URI scheme                   June 2007


        Specifications: ABNF", RFC 4234, October 2005.

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

9.2.  Informative References

   [5]  Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
        Registration Procedures for New URI Schemes", BCP 115, RFC 4395,
        February 2006.

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


Authors' Addresses

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

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


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

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













Mayrhofer & Spanring    Expires December 31, 2007               [Page 9]

Internet-Draft              'geo' URI scheme                   June 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Mayrhofer & Spanring    Expires December 31, 2007              [Page 10]


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