GEOPRIV -- Geographic A. Mayrhofer Location/Privacy Working Group enum.at Internet-Draft C. Spanring Expires: November 22, 2008 OIR-ID May 21, 2008 A Uniform Resource Identifier for Geographic Locations ('geo' URI) draft-mayrhofer-geopriv-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 November 22, 2008. 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 physical location in a compact, simple, human-readable, and protocol independent way. Mayrhofer & Spanring Expires November 22, 2008 [Page 1] Internet-Draft 'geo' URI scheme May 2008 Table of Contents 1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Registration of 'geo' URI Scheme . . . . . . . . . . . . 5 4.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . . 5 4.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.3. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 5 4.4. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 6 4.4.1. Component Description . . . . . . . . . . . . . . . . 6 4.4.2. URI Comparison . . . . . . . . . . . . . . . . . . . . 6 4.4.3. Interpretation of Undefined Altitude . . . . . . . . . 7 4.5. Encoding Considerations . . . . . . . . . . . . . . . . . 7 4.6. Applications/protocols That Use This URI Scheme . . . . . 7 4.7. Interopability Considerations . . . . . . . . . . . . . . 7 4.8. Security Considerations . . . . . . . . . . . . . . . . . 7 4.9. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.10. Author/Change controller . . . . . . . . . . . . . . . . . 8 4.11. References . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Use of 'geo' URIs . . . . . . . . . . . . . . . . . . . . . . 8 5.1. URI Operations . . . . . . . . . . . . . . . . . . . . . . 8 6. GML Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. 'geo' URI without altitude to GML 'Point' . . . . . . . . 8 6.2. 'geo' URI with Altitude to GML 'Point' . . . . . . . . . . 9 6.3. GML 'Point' without Altitude to 'geo' URI . . . . . . . . 9 6.4. GML 'Point' with Altitude to 'geo' URI . . . . . . . . . . 10 7. Examples and Use Cases . . . . . . . . . . . . . . . . . . . . 10 7.1. Plain 'geo' URI . . . . . . . . . . . . . . . . . . . . . 10 7.2. Hyperlink . . . . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9.1. Invalid Locations . . . . . . . . . . . . . . . . . . . . 11 9.2. Location Privcay . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Mayrhofer & Spanring Expires November 22, 2008 [Page 2] Internet-Draft 'geo' URI scheme May 2008 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Mayrhofer & Spanring Expires November 22, 2008 [Page 3] Internet-Draft 'geo' URI scheme May 2008 1. Change Log [Note to editors: This section is to be removed before publication - XML source available on request] 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 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. 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 Mayrhofer & Spanring Expires November 22, 2008 [Page 4] Internet-Draft 'geo' URI scheme May 2008 identifies geographic locations (a physical resource) in the WGS84 [WGS84] reference system. '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). Such URIs are independent from a specific protocol, application, or data format in which they might be contained. The provision of civic addresses to identify locations is out of scope of this document. Note: The choice of WGS84 is based on the widespread availability of Global Positioning System (GPS) devices, which use the WGS84 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. 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 [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 November 22, 2008 [Page 5] Internet-Draft 'geo' URI scheme May 2008 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 a physical resource: A spatial location on earth identified by the geographic coordinates contained in the URI. 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 sea 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. Mayrhofer & Spanring Expires November 22, 2008 [Page 6] Internet-Draft 'geo' URI scheme May 2008 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. 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 7. 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 use of the information in the URI (unless they dereference the URI components manually). Poorly authored 'geo' URI instances could contain whitespace. Clients SHOULD try to dereference such URIs after removing whitespace. This specification does not define any URI parameters nor a query component. Future revisions might define such parameters, potentially using the ";" and "?" characters to delimit parameter and query components from the path component. Clients SHOULD be prepared to encounter such 'geo' instances, and SHOULD reduce the URI to the components specified in Section 4.3 before they dereference the URI. 4.8. Security Considerations See Section 9 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/) Mayrhofer & Spanring Expires November 22, 2008 [Page 7] Internet-Draft 'geo' URI scheme May 2008 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. Use of 'geo' URIs 5.1. 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. 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. GML Mappings A 'geo' URI can be authored from a GML "point", and any 'geo' URI can be mapped to a GML "point". For the following sections, For the following sections, "%lat%", "%lon%" and "%alt%" are to be considered placeholders for latitude, longitude, and altitude values. Mappings are defined as follows: 6.1. 'geo' URI without altitude to GML 'Point' An instance of the 'geo' URI without the altitude element is mapped to a two-dimensional GML "Point" as follows: 'geo' URI: geo:%lat%,%lon% GML document: Mayrhofer & Spanring Expires November 22, 2008 [Page 8] Internet-Draft 'geo' URI scheme May 2008 %lat% %lon% 6.2. 'geo' URI with Altitude to GML 'Point' A '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: %lat% %lon% %alt% 6.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: %lat% %lon% '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. Mayrhofer & Spanring Expires November 22, 2008 [Page 9] Internet-Draft 'geo' URI scheme May 2008 6.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: %lat% %lon% 'geo' URI: geo:%lat%,%lon% Note: GML 'Point' instances 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. Examples and Use Cases 7.1. Plain 'geo' URI 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. 7.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 popular sights is the Karlskirche A web brower could extract the coordinates from the HTML snippet, and offer the user various options (based on configuration, context), for example: Mayrhofer & Spanring Expires November 22, 2008 [Page 10] Internet-Draft 'geo' URI scheme May 2008 o display a small map 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 making use of GeoRSS feeds the user has subscribed to o Convert the coordinates to a format suitable for uploading to a navigation device 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. 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 (latitude "beyond" north pole). 9.2. Location Privcay 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. 10. References Mayrhofer & Spanring Expires November 22, 2008 [Page 11] Internet-Draft 'geo' URI scheme May 2008 10.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. [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. 10.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 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/ Mayrhofer & Spanring Expires November 22, 2008 [Page 12] Internet-Draft 'geo' URI scheme May 2008 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 November 22, 2008 [Page 13] Internet-Draft 'geo' URI scheme May 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. Mayrhofer & Spanring Expires November 22, 2008 [Page 14]