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:
one of Vienna's most popular sights is the St. Stephans Cathedral
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