Network Working Group A. Mayrhofer Internet-Draft enum.at Intended status: Standards Track C. Spanring Expires: August 18, 2008 OIR-ID Feb 15, 2008 A Uniform Resource Identifier for Geographic Areas ('geo' URI) draft-mayrhofer-geo-uri-02 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 August 18, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document specifies an Uniform Resource Identifier (URI) for geographic areas using the 'geo' scheme name. A 'geo' URI provides a compact, human-readable, and protocol independent way to identify an area by means of a hierarchical tiling scheme. Mayrhofer & Spanring Expires August 18, 2008 [Page 1] Internet-Draft 'geo' URI scheme Feb 2008 Table of Contents 1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. IANA Registration of 'geo' URI Scheme . . . . . . . . . . . . 5 5.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . . 5 5.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.3. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 5 5.4. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 5 5.4.1. Component Description . . . . . . . . . . . . . . . . 6 5.4.2. URI Comparison . . . . . . . . . . . . . . . . . . . . 6 5.5. Properties of the URI scheme . . . . . . . . . . . . . . . 6 5.6. Applications/protocols That Use This URI Scheme . . . . . 7 5.7. Interopability Considerations . . . . . . . . . . . . . . 7 5.8. Security Considerations . . . . . . . . . . . . . . . . . 7 5.9. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.10. Author/Change controller . . . . . . . . . . . . . . . . . 7 5.11. References . . . . . . . . . . . . . . . . . . . . . . . . 7 6. The Tile Hierarchy . . . . . . . . . . . . . . . . . . . . . . 8 7. Encoding of Tile Identifiers . . . . . . . . . . . . . . . . . 11 7.1. Area Bitstring Padding . . . . . . . . . . . . . . . . . . 11 7.2. Appending Padding Counter and Parity Bits . . . . . . . . 11 7.3. Final Base32 Encoding . . . . . . . . . . . . . . . . . . 12 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Mayrhofer & Spanring Expires August 18, 2008 [Page 2] Internet-Draft 'geo' URI scheme Feb 2008 1. Change Log [Note to editors: This section is to be removed before publication - XML source available on request] draft-mayrhofer-geo-uri-02 completely new way to create URI - tiling scheme, base32 encoding, etc. draft-mayrhofer-geo-uri-01 removed parameters draft-mayrhofer-geo-uri-00 initial draft 2. Introduction The use of spatial location in internet technology has gained significant importance over the last few years. More and more protocols and data formats are being extended to carry spatial information, most prominently geographic location. Most of those specifications are optimized for machine readability, capable of carrying complex location information (and are therefore complex by themselves), or are tied to a specific protocol or data format. On the contrary, the success of domain names, URIs and telephone numbers indicates that there is a demand for conveying simple, concise identity information by a variety of "manual" means between humans. This document aims at specifying such a simple, concise identifier for geographic location using a hierarchical tiling scheme. It is intended to coexist with and support existing "machine-readable" location information schemes. According to [RFC3986], a Uniform Resource Identifier (URI) "is a compact sequence of characters that identifies an abstract or physical resource". The URI scheme specified in this document (using the 'geo' scheme name) identifies such a physical resource (a geographic area) in a compact, human-readable, and protocol idependent way. The URI scheme specified in this document uses only geographic coordinates - the provision of civic addresses to identify locations is out of scope of this document. Mayrhofer & Spanring Expires August 18, 2008 [Page 3] Internet-Draft 'geo' URI scheme Feb 2008 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]. In addition this document uses the following terminology: o area bitstring: A string of bits, describing a geographic tile according to Section 6. o tile identifier: A base32 encoded string containing an area bitstring, padding and parity information, as described in Section 7. 4. Requirements (Note: Earlier versions of this document proposed URIs in the form of "geo:,". Feedback from the GEOPRIV working group indicated that this format does not seem to fulfill some of the requirements mentioned during the presentation. Requirements are therefore clarified in this section). The IETF has already produced several specifications in the area of encoding and conveying geographical location (RFC 4119, RFC 3825, RFC 4776). However, none of those schemes specifically focuses on conveying geographic location identification among humans or between humans and machines (for example, for user input into a device). Identifiers handled by humans are considered to have the following requirements: o Interopability: Good identifiers are not limited to an administrative domain, but are universally usable and recognized. They have a clear public specification that allows anybody to create, encode, decode and dereference identifier instances, and they are easily distinguished from other identifier spaces. URI schemes are an example of such an identifier scheme. o Length: Good identifiers are as short as possible. Such identifiers require less time to read, write and spell them. The probability of "transmission errors" such as mistyped, missing, or flipped characters is proportional to the length of an identifier. o Character set: Good identifiers use a limited character set, which reduces the risk of confusing two similar characters. A good character set is also globally recognized. o Ambigiuity: Good identifiers have little ambigiuity. o Recognition: Good identifiers allow recognizing rough "similarity" among a set of identifiers (for example, domain names below the same top level domain, phone numbers within the same area or network, email addresses within the same domain name). Such Mayrhofer & Spanring Expires August 18, 2008 [Page 4] Internet-Draft 'geo' URI scheme Feb 2008 identifiers allow a quick "categorization" even by humans. o Error detection: Good identifiers provide basic error detection, for example a mistyped identifier can at least be recognized as invalid. 5. 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]. 5.1. URI Scheme Name geo 5.2. Status permanent 5.3. URI Scheme Syntax The syntax of the 'geo' URI scheme is specified below in Augmented Backus-Naur Form (ABNF) [RFC4234]: geo-URI = geo-scheme ":" geo-tile-id \ [ *("." geo-extension) ] geo-scheme = "geo" geo-tile-id = 2*32( ALPHA / base32-digits ) base32-digits = "2" / "3" / "4" / "5" / "6" / "7" geo-extension = *(ALPHA / DIGITS / "-" / "," ) "geo-tile-id" and "geo-extension" are specified in section Section 5.4.1. (Note: The "geo-extension" component is under discussion, perspective extensions are currently worked on. The authors seek feedback whether an extension mechanism is considered useful) 5.4. URI Scheme Semantics Data contained in a 'geo' URI identifies a physical resource, namely the geographic coordinates of a spatial area on Earth in the World Geodetic System 1984 [WGS84] datum / reference system. Mayrhofer & Spanring Expires August 18, 2008 [Page 5] Internet-Draft 'geo' URI scheme Feb 2008 5.4.1. Component Description The "geo-tile-id" component of the URI contains a tile-identifier (Base32 encoded), as specified in section Section 6. The "geo-tile-id" component is case-insensitive. The "geo-extension" component is currently not specified, but applications should be prepared to receive URI instances with such components. Applications should ignore the "geo-extension" for now. The "geo-extension" components may be used in future revisions of the specification to further narrow down the area identified. Note: An application MAY attempt to recover a mistyped geo-tile-path component by replacing the digit "0" (zero) with the character "o", the digit "1" (one) with "i" and the digit "8" with "B" (even though those character may not occur in that component). No replacement SHOULD be attempted for the digit "9" or any character not listed. An application SHOULD also strip any whitespace from the input string before decoding a geo URI. 5.4.2. URI Comparison Two 'geo' URIs are equal when their lowercased "geo-tile-id" components are identical, and they contain identical lowercased "geo- extension" components in identical order. 5.5. Properties of the URI scheme The described URI scheme provides the following properties: o URI instances are very short compared to other textual methods to convey location - a 'geo' URI with a just 8 character long tile- identifier (including padding and parity) already identifies an area of approximately 150 x 150 meters (in the worst case, close to the equator). An instance with 12 characters of tile- identifier identifies an area of about 0.3 x 0.3 meters. o By decoding 'geo' URIs while typing, applications can provide rough results to the user even before the full URI has been entered. Whenever the user types another character of the tile- identifier, the application can "zoom in" further. o It's easy to guess the approximate "scale" of a 'geo' URI by looking at the length of the tile-identifier, much like numbers. o The choice of Base32 encoding provides a character set that is well known by almost all internet users, since it's a subset of the characters used in Domain Names. o The parity information provides a mechanism to recognize most mistyped URIs without external information. Mayrhofer & Spanring Expires August 18, 2008 [Page 6] Internet-Draft 'geo' URI scheme Feb 2008 o 'geo' URIs can be visually compared. URIs with similar prefixes reflect areas that are spatially nearby. o Instances of 'geo' URIs are easy to read, spell and write, because the use of special characters has been deliberately limited. (Note: the current specification does not consider altitude - the authors seek feedback whether that specification should be extended to 3 dimensions) 5.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 8. 5.7. Interopability Considerations Applications MAY generate tile-identifiers using either lowercase or uppercase characters during Base32 encoding, but SHOULD NOT mix lowercase and uppercase characters in a single URI instance. Applications MUST be able to decode URI instances with upper-, lower as well as mixed case characters. FIXME: accept geo URIs with "wrong" padding bits? 5.8. Security Considerations See Section 10 of [insert reference to this document] 5.9. Contact Christian Spanring (mailto:spanring@oir.at, http://spanring.eu/), Alexander Mayrhofer (mailto:alexander.mayrhofer@enum.at, http://nona.net/) More information and sample applications can be found at http://www.geouri.org/ 5.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. 5.11. References tbd. Mayrhofer & Spanring Expires August 18, 2008 [Page 7] Internet-Draft 'geo' URI scheme Feb 2008 6. The Tile Hierarchy The "tile-identifier" of the 'geo' URI uses a hierarchical scheme to tile an equirectangular projection of Earth's surface into rectangular tiles. Tiling starts with a global plate carree (longitude ranging from 180 degrees west to 180 degrees east, and latitude ranging from 90 degrees north to 90 degrees south). The WGS 84 reference system and datum is used. Such a plate carree reflects an empty area bitstring, and can be illustrated as follows: -180 0 +180 +90 +-----------------------------------------------+ | | | | | | | | | | 0 | | | | | | | | | | | | -90 +-----------------------------------------------+ The first tiling step splits that area vertically, into two aras of (-180 to 0 longitude / +90 to -90 latitude) and (0 to 180 longitude / +90 to -90 latitude), respectively. The "left" area is assigned a binary 0, and the "right" area is assigned a binary 1, as illustrated below: -180 0 +180 +90 +-----------------------+-----------------------+ | | | | | | | | | | | | | | | 0 | 0 | 1 | | | | | | | | | | | | | | | | -90 +-----------------------+-----------------------+ Mayrhofer & Spanring Expires August 18, 2008 [Page 8] Internet-Draft 'geo' URI scheme Feb 2008 A subsequent tiling step involves splitting each of the areas vertically, resulting in a total number of 4 tiles. To identify a sub-tile in this step, a binary 0 is appended to the area bitstring of each individual "upper" tile, and a binary 1 to the "lower" tile: -180 0 +180 +90 +-----------------------+-----------------------+ | | | | | | | 00 | 10 | | | | | | | 0 +-----------------------+-----------------------+ | | | | | | | 01 | 11 | | | | | | | -90 +-----------------------+-----------------------+ From now on, vertical and horizontal splitting is continued until the desired resolution is achieved, recursively tiling the whole range of coordinates into smaller areas. Whenever a "sub-area" is split, the new "left" (or "upper") area is identified by appending a binary 0 to the area string , and the new "right" (or "lower") area is identified by appending a binary 1 to the area bitstring. After another repetition of a vertical split, the areas look like this: -180 0 +180 +90 +-----------+-----------+-----------+-----------+ | | | | | | | | | | | 000 | 001 | 100 | 101 | | | | | | | | | | | 0 +-----------+-----------+-----------+-----------+ | | | | | | | | | | | 010 | 011 | 110 | 111 | | | | | | | | | | | -90 +-----------+-----------+-----------+-----------+ After another horizontal split, the following areas are identified: Mayrhofer & Spanring Expires August 18, 2008 [Page 9] Internet-Draft 'geo' URI scheme Feb 2008 -180 0 +180 +90 +-----------+-----------+-----------+-----------+ | 0000 | 0010 | 1000 | 1010 | | | | | | +-----------+-----------+-----------+-----------+ | 0001 | 0011 | 1001 | 1011 | | | | | | 0 +-----------+-----------+-----------+-----------+ | 0100 | 0110 | 1100 | 1110 | | | | | | +-----------+-----------+-----------+-----------+ | 0101 | 0111 | 1101 | 1111 | | | | | | -90 +-----------+-----------+-----------+-----------+ After another ("vertical" split), the following area bitstrings exist: -180 0 +180 +90 +-----+-----+-----+-----+-----+-----+-----+-----+ |00000|00001|00100|00101|10000|10001|10100|10101| | | | | | | | | | +-----+-----+-----+-----+-----+-----+-----+-----+ |00010|00011|00110|00111|10010|10011|10110|10111| | | | | | | | | | 0 +-----+-----+-----+-----+-----+-----+-----+-----+ |01001|01101|01100|01101|11000|11001|11100|11101| | | | | | | | | | +-----+-----+-----+-----+-----+-----+-----+-----+ |01010|01011|01110|01111|11010|11011|11110|11111| | | | | | | | | | -90 +-----+-----+-----+-----+-----+-----+-----+-----+ Those splitting steps can be repeated as long until the desired size of the area to be identified is reached. Tiling MUST always be initiated with a vertical split. After a vertical split, the next split MUST be a horizontal split. After a horizontal split, the next split MUST be a vertical split, etc.. The resulting area bitstring is used in encoding tile identifiers (see Section 7). Note that area bitstrings can be obviously calculated directly as well - the above "splitting" procedure is considered to have illustrative value. Mayrhofer & Spanring Expires August 18, 2008 [Page 10] Internet-Draft 'geo' URI scheme Feb 2008 7. Encoding of Tile Identifiers A "geo" URI contains base32 encoded tile identifiers. This section describes how to transform area bitstrings into their Base32 representation. 7.1. Area Bitstring Padding Since tiling as outlined above may be stopped at any "resolution", area bitstrings may have arbitrary numbers of binary digits, and therefore not fit into the 5-bit boundaries of Base32. The following process MUST be followed to pad area bitstrings to multiples of 5 bit (the example uses an area bitstring of 12 bits): 1. Identify number of significant bits in area bitstrings (void bits are illustrated as dots below): 01011 10100 11... (12 significant bits) area id: -------------- 2. Pad area bitstring to the next 5-bit border with "0" bits, and record the number of padding bits used in "padding-counter": 01011 10100 11000 (total lenght: 15 bit) area id: -------------- padding: --- (padding-counter: 3) (Note that after padding, the number of significant bit cannot be recovered from the padded area bitstring without the padding- counter). 7.2. Appending Padding Counter and Parity Bits To recover the number of significant bits in the resulting URI string, the binary representation of padding-counter is appended to the padded area bitstring. Since the padding size is between 0 and 4 bits, 3 bits are required to encode padding-counter. 01011 10100 11000 011 (padding-counter: 3) area id: -------------- padding: --- padding-counter: --- The encoded padding-counter of 3 bits always leaves 2 bits of "free space" in the last 5 bit group. Those 2 bits are used for parity bits, which are calculated as follows: o The first parity bit (A) is used to convey even parity over the "longitude" bits Mayrhofer & Spanring Expires August 18, 2008 [Page 11] Internet-Draft 'geo' URI scheme Feb 2008 o The second parity bit (B) is used to convey even parity for the "latitude" bits 01011 10100 11000 01100 area id: ----- ----- -- parity bits: -- longitude bit: 0 0 1 0 0 1 0 (parity bit A - longitude) latitude bit: 1 1 1 1 0 0 0 (parity bit B - latitude) Note that padding bits MUST NOT be included in parity calculation (the use of '0' bits for padding does not affect parity anyways, however, mangled URI instances could contain '1's in padding). 7.3. Final Base32 Encoding The bitstream resulting from the operations above (including the significance / parity bits) is Base32 encoded according to section 5 of [RFC3548]. Bitstream: 01011 10100 11000 01100 Decimal: 11 20 24 12 Base32: L U Y M Therefore, the final base32 encoded tile identifier is "LUYM". That string is to be used in the "geo-tile-id" component of the URI (see Section 5.3). 8. Example The following 'geo' URI identifies a geographic area that resembles the square in front of one of the author's office: o Center coordinates (approx.): 48.200179 latitude, 16.367957 longitude. o Number of tiling steps: 34 o Area bitstring: 1000010111001111100111010000111011 o Geographic coordinates of respective area: 48.1997680664 to 48.2011413574 degrees north, 16.3668823242 to 16.3696289062 degrees east ( approximately 150 x 300 meters). o Area bitstring padded: 10000 10111 00111 11001 11010 00011 10110 = o Area bitstring with padding-counter (1 bit padding): 10000 10111 00111 11001 11010 00011 10110 001 === Mayrhofer & Spanring Expires August 18, 2008 [Page 12] Internet-Draft 'geo' URI scheme Feb 2008 o Adding parity bits: 10000 10111 00111 11001 11010 00011 10110 00110 == lon: 1 0 0 0 1 0 1 1 1 0 1 0 0 0 1 1 1 0 -> 1 lat: 0 0 1 1 1 0 1 1 0 1 1 1 0 0 1 0 1 --> 0 o Base32 encoding: 10000 10111 00111 11001 11010 00011 10110 00110 Q X H Z 2 D W G o Resulting 'geo' URI: geo:QXHZ2DWG 9. 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 5. 10. Security Considerations Because the 'geo' URI is not tied to any specific protocol, and identifies a physical area rather than an abstract resource, most of the general security considerations on URIs (Section 7 of RFC 3986) do not apply. Instances of 'geo' URIs convey location information. Such location information may be publicly known, and therefore not be very sensitive (for example, 'geo' URIs conveying the location of public sights, hotels, etc.). However, 'geo' URIs might be used in situations that have considerable privacy implications (for example, the current location of a person combined with Personally Identifieable Information). Therefore, security and privacy must be considered for individual use cases. 11. References Mayrhofer & Spanring Expires August 18, 2008 [Page 13] Internet-Draft 'geo' URI scheme Feb 2008 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 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. [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003. 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 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 August 18, 2008 [Page 14] Internet-Draft 'geo' URI scheme Feb 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Mayrhofer & Spanring Expires August 18, 2008 [Page 15]