Network Working Group A. Mayrhofer Internet-Draft enum.at Expires: July 6, 2007 C. Spanring OIR-ID January 02, 2007 A Uniform Resource Identifier for Geographic Locations ('geo' URI) draft-mayrhofer-geo-uri-00 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 July 6, 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 form. The 'geo' URI is not tied to a specific application or protocol. Mayrhofer & Spanring Expires July 6, 2007 [Page 1] Internet-Draft 'geo' URI scheme January 2007 Table of Contents 1. Changes & Supplemental Information . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. IANA Registration of the '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. URI Construction . . . . . . . . . . . . . . . . . . . . . 6 5.2. URI Dereference . . . . . . . . . . . . . . . . . . . . . 8 5.3. URI Operations . . . . . . . . . . . . . . . . . . . . . . 8 6. Examples and Use Cases . . . . . . . . . . . . . . . . . . . . 9 6.1. Plain 'geo' URI . . . . . . . . . . . . . . . . . . . . . 9 6.2. Hyperlink . . . . . . . . . . . . . . . . . . . . . . . . 9 6.3. Header Field . . . . . . . . . . . . . . . . . . . . . . . 9 6.4. Web Mapping Services . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8.1. Invalid Locations . . . . . . . . . . . . . . . . . . . . 11 8.2. Location Privacy . . . . . . . . . . . . . . . . . . . . . 11 8.3. Malicious Locations . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Mayrhofer & Spanring Expires July 6, 2007 [Page 2] Internet-Draft 'geo' URI scheme January 2007 1. Changes & Supplemental Information [Note to editors: This section is to be removed before publication - XML source available on request] o draft-mayrhofer-geo-uri-00 * initial draft A supplemental web site for the development of this draft and the 'geo' URI in general has been set up at 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 application, data format or protocol, and don't provide a generic way to protocol independent location identification. Over the past few years, emerging location aware applications and location based services were observable on the Internet. Most Internet search engines and a vivid open source mapping community brought an enormous momentum into location aware technology. A wide range of tools and data formerly available to professionals only were provided free of charge for everyday use on the mass market. The 'geo' Uniform Resorce Identifier (URI) [1] scheme is another step into that direction and aims to facilitate, support and standardize part of the interaction with geospatial services and applications. Accessing information about or trigger further services based on a particular place on earth shouldn't be any harder than writing an email by clicking on a 'mailto:' link. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This document specifies the 'geo' URI scheme for identifying geographic locations in the WGS84 [5] reference system, independent of any specific application, data format or protocol. 'Geo' URIs identify a geographic location by the textual representation of the location's spatial coordinates in either two or 3 dimensions (latitude, longitude, and optionally altitude). An optional query string contains additional parameters. The provision of civic addresses (street, city, country, etc.) to identify locations is out of scope for the 'geo' URI scheme. Mayrhofer & Spanring Expires July 6, 2007 [Page 3] Internet-Draft 'geo' URI scheme January 2007 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 the 'geo' URI Scheme This section contains information required for the URI scheme registration, following the guidelines in section 5.4 of RFC 4395 [4]. 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-query ] geo-scheme = "geo" geo-path = geo-location geo-query = query geo-location = latitude "," longitude [ "," altitude ] latitude = [ "-" ] 1*2DIGIT [ "." *DIGIT ] longitude = [ "-" ] 1*3DIGIT [ "." *DIGIT ] altitude = [ "-" ] *DIGIT [ "." *DIGIT ] The 'query' component is specified in secion 3.4 of RFC 3986. 4.4. URI Scheme Semantics Generally, data contained in a 'geo' URI describes the geographic coordinates of the identified location, and contains an optional query string. Note: In order to achieve high user acceptance it seems inevitable to adopt commonly known GPS parameters (latitude, longitude, altitude) where possible. Mayrhofer & Spanring Expires July 6, 2007 [Page 4] Internet-Draft 'geo' URI scheme January 2007 4.4.1. Component Description The "latitude", "longitude", "altitude" and "query" 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 WGS84. o The "longitude" componont MUST contain the decimal longitude of the identified location in the reference system WGS84. 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. As one degree equals 111319.45m at the equator (40075.004km / 360 degrees), five decimal places (0.00001 degree) correspond to roughly one meter, which seem to provide sufficient accuracy for civil use. 4.4.2. URI Comparison Two 'geo' URIs MUST be considered equal when their 'longitude', 'latitude' and 'altitude' values are mathematically identical, and their decoded 'query' strings match. 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', 'longitude' and 'query' 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 July 6, 2007 [Page 5] Internet-Draft 'geo' URI scheme January 2007 Contents of the 'query' component is to be encoded according to RFC 3986. 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 While the interpretation of 'latitude', 'longitude' and 'altitude' is quite clear, the interpretation of the 'query' component may vary by application or protocol to which a 'geo' URI is being mapped. Consumers MUST ignore unknown query parameters they encounter while authors of 'geo' URIs SHOULD only use well known parameters in the 'query' component. To reduce interopability issues, it might be neccessary to create a registry of query parameters. 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 The 'geo' URI is specified in [insert reference to this document]. 5. Use of 'geo' URIs 5.1. URI Construction The production of a 'geo' URI involves the following steps: Mayrhofer & Spanring Expires July 6, 2007 [Page 6] Internet-Draft 'geo' URI scheme January 2007 1. Aquire coordinates of the location to be identified: latitude, longitude, and optionally altitude. 2. If coordinates are given in degrees/minutes/seconds, transform them to their respective decimal representation. 3. Ensure that coordinates are represented in the correct reference system / units as described in Section 4.4.1. Transform coordinates if neccessary. 4. Round coordinate values to a sensible number of decimal places, according to the presumed accuracy of the data source used. 5. Remove abundant leading zero's from values, keeping at least one digit in the integer part. Make sure that negative values have a minus sign, while positive values don't have a sign. 6. concatenate prepared latitude, longitude, optionally altitude strings with the subcomponent delimiter ",", not adding any whitespace or other characters. 7. prepend the result with the string 'geo:' (the URI scheme and delimiter) 8. if the final URI is to include a 'query' component, add the component delimiter "?" to the end of the result, followed by the encoded query string. The following example constructs a 'geo' URI from the location message of a Global Positioning System (GPS) receiver: 1. Aquire coordinates (data split in two lines): $GPGGA,124951.000,4812.0556,N,01622.1729,E,1, 05,3.3,192.4,M,43.4,M,,0000*5D latitude = 48 degrees, 12.0556 minutes north. longitude = 16 degrees, 22.1729 minutes east. altitude = 192.4 meters (using a geoid height of 43.4 meters) Horizontal Dilution of Precision (HDOP) = 3.3 (corresponds to about 10 meters) 2. Transform into decimal values: latitude = +48.2009266666 degrees longitude = +16.3695483333 degrees altitude = 192.4 meters 3. Reference system: longitude and latitude values are already given in WGS84, altitude already refers to mean sea level (according to the geoid correction value of 43.4 meters) 4. Round values: latitude = +48.20093 degrees longitude = +016.36955 degrees altitude = 192 meters Mayrhofer & Spanring Expires July 6, 2007 [Page 7] Internet-Draft 'geo' URI scheme January 2007 (five decimal rougly correlate to about one meter on the equator. This is more precise than the indicated HDOP of about 10 meters). 5. Remove abundant stuff: latitude = 48.200927 longitude = 16.369548 altitude = 192 6. Concatenate: 48.200927,16.369548,192 7. Prepend with URI scheme name and delimiter: geo:48.200927,16.369548,192 8. In this example, no query component is to be added. 5.2. URI Dereference A consumer of a 'geo' URI has to perform the following operation for dereference: 1. Validate the 'geo' URI against the syntax specification (Section 4.3). URIs which do not match the syntax SHOULD NOT be used (see note below). 2. Remove the URI scheme and the URI delimiter ("geo:") from the beginning of the string. 3. If the string contains a query delimiter ("?"), split off the 'query' component and the query delimiter 4. Split the remaining string into subcomponents, using the comma (",") as the delimiter 5. Use the first subcomponent as latitude, the second one as longitude. If a thrid subcomponent is present, use it as altitude. Note: An application MAY use URIs which contain whitespace in the 'geo-location' component by stripping it off before the dereference process. 5.3. URI Operations Currently, just one operation on a 'geo' URI is defined - location retrieval: In that operation, a client uses the data from the URI to retrieve the geographical location to which the URI refers to. A client may then, though, use this location information for various Mayrhofer & Spanring Expires July 6, 2007 [Page 8] Internet-Draft 'geo' URI scheme January 2007 purposes: A web browser may rewrite 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 may offer the user to start navigation to the location. Examples of such uses can be found in Section 6. 6. Examples and Use Cases 6.1. Plain 'geo' URI The following 3-dimensional 'geo' URI example references to the bottom of the stairs leading to the Karlskirche in Vienna, Austria: 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) snippet with such a hyperlink could look like:

one of Vienna's most popular sights is the Karlskirche 6.3. Header Field Many protocols support the use of arbitrary URI schemes, for example in their header Fields. A Session Initiation Protocol (SIP) [7] REGISTER request could contain a 'Contact' header with a 'geo' URI, to reflect the geographic location to be used to contact the registering entity physically: 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 From: Joe Geo ;tag=456248 Call-ID: aaafafff-84230@7afagggdd CSeq: 42 REGISTER Contact: Mayrhofer & Spanring Expires July 6, 2007 [Page 9] Internet-Draft 'geo' URI scheme January 2007 Contact: 6.4. Web Mapping Services A rather common method for accessing geographic information on the Internet are web mapping services (WMS) [6]. An image containing a map is delivered by a mapserver as response to a WMS request. WMS requests usually contain a bounding box (enclosing rectangle), the spatial reference system (e.g. 'EPSG:4326' for WGS84), displayed layers (e.g. roads, borders), image dimensions and image format (e.g. 'image/png'): http://map.example.org/maps/wms.cgi?BBOX=16,48,18,50&SRS=EPSG:4326 \ &LAYERS=roads,borders&WIDTH=400&HEIGHT=400&FORMAT=image/png A location identified by a 'geo' URI could be used to support input parameters in terms of a center point of a WMS request. Query parameters could be used to reflect the requested type of service, eg. a 'geo' URI could be mapped to a WMS request as follows: geo:48.20833,16.37278,171?service=wms&scale=5000&layers=roads,borders \ &height=400&width=400&format=image/png A bounding box can be calculated by given scale, height and width. In our case, based on an output scale of 1:5000 and 400px image height and width the bounding box width and height is 0.00634 degrees. A 'geo' URI is limited to one spatial reference system, thus 'SRS=EPSG:4326' is a constant parameter in WMS transformations. The resulting WMS request could look like: http://map.example.org/maps/wms.cgi?BBOX=16.05690,47.89167, \ 16.69142,48.52619&SRS= EPSG:4326&LAYERS=roads,borders&WIDTH=400 \ &HEIGHT=400&FORMAT=image/png 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) [4]. 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 Mayrhofer & Spanring Expires July 6, 2007 [Page 10] Internet-Draft 'geo' URI scheme January 2007 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 (latitude "beyond" north pole). 8.2. Location Privacy Location information about individuals is an extremely sensitive topic, especially when location is combined with Personally Identifyable Information (PII). In cases where location information about individuals is used in a publicly available 'geo' URI, the explicit consent of the individual is REQUIRED. 8.3. Malicious Locations As with other URI schemes, the information provisioned in 'geo' URIs cannot be trusted unless some kind of trust relation with the author of a URI is in place. Applications of the 'geo' URI SHOULD consider methods of validating and protecting URIs. 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 Specifications: ABNF", RFC 4234, October 2005. Mayrhofer & Spanring Expires July 6, 2007 [Page 11] Internet-Draft 'geo' URI scheme January 2007 9.2. Informative References [4] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 115, RFC 4395, February 2006. [5] National Imagery and Mapping Agency, "Department of Defense World Geodetic System 1984, Third Edition", NIMA TR8350.2, January 2000. [6] Open GIS Consortium Inc., "Web Map Service Implementations Specification, Version 1.1.1", OGC 01-068r3, January 2002. [7] 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. 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-Informationsdienste 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 July 6, 2007 [Page 12] Internet-Draft 'geo' URI scheme January 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 July 6, 2007 [Page 13]