idnits 2.17.1 draft-mayrhofer-geo-uri-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 661. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 672. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 679. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 685. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Feb 15, 2008) is 5915 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 3548 (Obsoleted by RFC 4648) -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Mayrhofer 3 Internet-Draft enum.at 4 Intended status: Standards Track C. Spanring 5 Expires: August 18, 2008 OIR-ID 6 Feb 15, 2008 8 A Uniform Resource Identifier for Geographic Areas ('geo' URI) 9 draft-mayrhofer-geo-uri-02 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 18, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document specifies an Uniform Resource Identifier (URI) for 43 geographic areas using the 'geo' scheme name. A 'geo' URI provides a 44 compact, human-readable, and protocol independent way to identify an 45 area by means of a hierarchical tiling scheme. 47 Table of Contents 49 1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 5. IANA Registration of 'geo' URI Scheme . . . . . . . . . . . . 5 58 5.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . . 5 59 5.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 5.3. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 5 61 5.4. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 5 62 5.4.1. Component Description . . . . . . . . . . . . . . . . 6 63 5.4.2. URI Comparison . . . . . . . . . . . . . . . . . . . . 6 64 5.5. Properties of the URI scheme . . . . . . . . . . . . . . . 6 65 5.6. Applications/protocols That Use This URI Scheme . . . . . 7 66 5.7. Interopability Considerations . . . . . . . . . . . . . . 7 67 5.8. Security Considerations . . . . . . . . . . . . . . . . . 7 68 5.9. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 5.10. Author/Change controller . . . . . . . . . . . . . . . . . 7 70 5.11. References . . . . . . . . . . . . . . . . . . . . . . . . 7 72 6. The Tile Hierarchy . . . . . . . . . . . . . . . . . . . . . . 8 74 7. Encoding of Tile Identifiers . . . . . . . . . . . . . . . . . 11 75 7.1. Area Bitstring Padding . . . . . . . . . . . . . . . . . . 11 76 7.2. Appending Padding Counter and Parity Bits . . . . . . . . 11 77 7.3. Final Base32 Encoding . . . . . . . . . . . . . . . . . . 12 79 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 87 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 90 Intellectual Property and Copyright Statements . . . . . . . . . . 15 92 1. Change Log 94 [Note to editors: This section is to be removed before publication - 95 XML source available on request] 97 draft-mayrhofer-geo-uri-02 98 completely new way to create URI - tiling scheme, base32 encoding, 99 etc. 101 draft-mayrhofer-geo-uri-01 102 removed parameters 104 draft-mayrhofer-geo-uri-00 105 initial draft 107 2. Introduction 109 The use of spatial location in internet technology has gained 110 significant importance over the last few years. More and more 111 protocols and data formats are being extended to carry spatial 112 information, most prominently geographic location. 114 Most of those specifications are optimized for machine readability, 115 capable of carrying complex location information (and are therefore 116 complex by themselves), or are tied to a specific protocol or data 117 format. On the contrary, the success of domain names, URIs and 118 telephone numbers indicates that there is a demand for conveying 119 simple, concise identity information by a variety of "manual" means 120 between humans. 122 This document aims at specifying such a simple, concise identifier 123 for geographic location using a hierarchical tiling scheme. It is 124 intended to coexist with and support existing "machine-readable" 125 location information schemes. 127 According to [RFC3986], a Uniform Resource Identifier (URI) "is a 128 compact sequence of characters that identifies an abstract or 129 physical resource". The URI scheme specified in this document (using 130 the 'geo' scheme name) identifies such a physical resource (a 131 geographic area) in a compact, human-readable, and protocol 132 idependent way. 134 The URI scheme specified in this document uses only geographic 135 coordinates - the provision of civic addresses to identify locations 136 is out of scope of this document. 138 3. Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC 2119 [RFC2119]. 144 In addition this document uses the following terminology: 145 o area bitstring: A string of bits, describing a geographic tile 146 according to Section 6. 147 o tile identifier: A base32 encoded string containing an area 148 bitstring, padding and parity information, as described in 149 Section 7. 151 4. Requirements 153 (Note: Earlier versions of this document proposed URIs in the form of 154 "geo:,". Feedback from the GEOPRIV working 155 group indicated that this format does not seem to fulfill some of the 156 requirements mentioned during the presentation. Requirements are 157 therefore clarified in this section). 159 The IETF has already produced several specifications in the area of 160 encoding and conveying geographical location (RFC 4119, RFC 3825, RFC 161 4776). However, none of those schemes specifically focuses on 162 conveying geographic location identification among humans or between 163 humans and machines (for example, for user input into a device). 165 Identifiers handled by humans are considered to have the following 166 requirements: 167 o Interopability: Good identifiers are not limited to an 168 administrative domain, but are universally usable and recognized. 169 They have a clear public specification that allows anybody to 170 create, encode, decode and dereference identifier instances, and 171 they are easily distinguished from other identifier spaces. URI 172 schemes are an example of such an identifier scheme. 173 o Length: Good identifiers are as short as possible. Such 174 identifiers require less time to read, write and spell them. The 175 probability of "transmission errors" such as mistyped, missing, or 176 flipped characters is proportional to the length of an identifier. 177 o Character set: Good identifiers use a limited character set, which 178 reduces the risk of confusing two similar characters. A good 179 character set is also globally recognized. 180 o Ambigiuity: Good identifiers have little ambigiuity. 181 o Recognition: Good identifiers allow recognizing rough "similarity" 182 among a set of identifiers (for example, domain names below the 183 same top level domain, phone numbers within the same area or 184 network, email addresses within the same domain name). Such 185 identifiers allow a quick "categorization" even by humans. 186 o Error detection: Good identifiers provide basic error detection, 187 for example a mistyped identifier can at least be recognized as 188 invalid. 190 5. IANA Registration of 'geo' URI Scheme 192 This section contains the fields required for the URI scheme 193 registration, following the guidelines in section 5.4 of [RFC4395]. 195 5.1. URI Scheme Name 197 geo 199 5.2. Status 201 permanent 203 5.3. URI Scheme Syntax 205 The syntax of the 'geo' URI scheme is specified below in Augmented 206 Backus-Naur Form (ABNF) [RFC4234]: 208 geo-URI = geo-scheme ":" geo-tile-id \ 209 [ *("." geo-extension) ] 211 geo-scheme = "geo" 212 geo-tile-id = 2*32( ALPHA / base32-digits ) 213 base32-digits = "2" / "3" / "4" / "5" / "6" / "7" 215 geo-extension = *(ALPHA / DIGITS / "-" / "," ) 217 "geo-tile-id" and "geo-extension" are specified in section 218 Section 5.4.1. 220 (Note: The "geo-extension" component is under discussion, perspective 221 extensions are currently worked on. The authors seek feedback 222 whether an extension mechanism is considered useful) 224 5.4. URI Scheme Semantics 226 Data contained in a 'geo' URI identifies a physical resource, namely 227 the geographic coordinates of a spatial area on Earth in the World 228 Geodetic System 1984 [WGS84] datum / reference system. 230 5.4.1. Component Description 232 The "geo-tile-id" component of the URI contains a tile-identifier 233 (Base32 encoded), as specified in section Section 6. The 234 "geo-tile-id" component is case-insensitive. 236 The "geo-extension" component is currently not specified, but 237 applications should be prepared to receive URI instances with such 238 components. Applications should ignore the "geo-extension" for now. 239 The "geo-extension" components may be used in future revisions of the 240 specification to further narrow down the area identified. 242 Note: An application MAY attempt to recover a mistyped geo-tile-path 243 component by replacing the digit "0" (zero) with the character "o", 244 the digit "1" (one) with "i" and the digit "8" with "B" (even though 245 those character may not occur in that component). No replacement 246 SHOULD be attempted for the digit "9" or any character not listed. 247 An application SHOULD also strip any whitespace from the input string 248 before decoding a geo URI. 250 5.4.2. URI Comparison 252 Two 'geo' URIs are equal when their lowercased "geo-tile-id" 253 components are identical, and they contain identical lowercased "geo- 254 extension" components in identical order. 256 5.5. Properties of the URI scheme 258 The described URI scheme provides the following properties: 259 o URI instances are very short compared to other textual methods to 260 convey location - a 'geo' URI with a just 8 character long tile- 261 identifier (including padding and parity) already identifies an 262 area of approximately 150 x 150 meters (in the worst case, close 263 to the equator). An instance with 12 characters of tile- 264 identifier identifies an area of about 0.3 x 0.3 meters. 265 o By decoding 'geo' URIs while typing, applications can provide 266 rough results to the user even before the full URI has been 267 entered. Whenever the user types another character of the tile- 268 identifier, the application can "zoom in" further. 269 o It's easy to guess the approximate "scale" of a 'geo' URI by 270 looking at the length of the tile-identifier, much like numbers. 271 o The choice of Base32 encoding provides a character set that is 272 well known by almost all internet users, since it's a subset of 273 the characters used in Domain Names. 274 o The parity information provides a mechanism to recognize most 275 mistyped URIs without external information. 277 o 'geo' URIs can be visually compared. URIs with similar prefixes 278 reflect areas that are spatially nearby. 279 o Instances of 'geo' URIs are easy to read, spell and write, because 280 the use of special characters has been deliberately limited. 282 (Note: the current specification does not consider altitude - the 283 authors seek feedback whether that specification should be extended 284 to 3 dimensions) 286 5.6. Applications/protocols That Use This URI Scheme 288 The 'geo' URI provides resource identification independent of a 289 specific application or protocol. Examples of potential protocol 290 mappings and use cases can be found in Section 8. 292 5.7. Interopability Considerations 294 Applications MAY generate tile-identifiers using either lowercase or 295 uppercase characters during Base32 encoding, but SHOULD NOT mix 296 lowercase and uppercase characters in a single URI instance. 297 Applications MUST be able to decode URI instances with upper-, lower 298 as well as mixed case characters. 300 FIXME: accept geo URIs with "wrong" padding bits? 302 5.8. Security Considerations 304 See Section 10 of [insert reference to this document] 306 5.9. Contact 308 Christian Spanring (mailto:spanring@oir.at, http://spanring.eu/), 309 Alexander Mayrhofer (mailto:alexander.mayrhofer@enum.at, 310 http://nona.net/) 312 More information and sample applications can be found at 313 http://www.geouri.org/ 315 5.10. Author/Change controller 317 The 'geo' URI scheme is registered under the IETF part of the URI 318 tree. As such, change control is up to the IETF. 320 5.11. References 322 tbd. 324 6. The Tile Hierarchy 326 The "tile-identifier" of the 'geo' URI uses a hierarchical scheme to 327 tile an equirectangular projection of Earth's surface into 328 rectangular tiles. 330 Tiling starts with a global plate carree (longitude ranging from 180 331 degrees west to 180 degrees east, and latitude ranging from 90 332 degrees north to 90 degrees south). The WGS 84 reference system and 333 datum is used. Such a plate carree reflects an empty area bitstring, 334 and can be illustrated as follows: 336 -180 0 +180 337 +90 +-----------------------------------------------+ 338 | | 339 | | 340 | | 341 | | 342 | | 343 0 | | 344 | | 345 | | 346 | | 347 | | 348 | | 349 -90 +-----------------------------------------------+ 351 The first tiling step splits that area vertically, into two aras of 352 (-180 to 0 longitude / +90 to -90 latitude) and (0 to 180 longitude / 353 +90 to -90 latitude), respectively. The "left" area is assigned a 354 binary 0, and the "right" area is assigned a binary 1, as illustrated 355 below: 357 -180 0 +180 358 +90 +-----------------------+-----------------------+ 359 | | | 360 | | | 361 | | | 362 | | | 363 | | | 364 0 | 0 | 1 | 365 | | | 366 | | | 367 | | | 368 | | | 369 | | | 370 -90 +-----------------------+-----------------------+ 372 A subsequent tiling step involves splitting each of the areas 373 vertically, resulting in a total number of 4 tiles. To identify a 374 sub-tile in this step, a binary 0 is appended to the area bitstring 375 of each individual "upper" tile, and a binary 1 to the "lower" tile: 377 -180 0 +180 378 +90 +-----------------------+-----------------------+ 379 | | | 380 | | | 381 | 00 | 10 | 382 | | | 383 | | | 384 0 +-----------------------+-----------------------+ 385 | | | 386 | | | 387 | 01 | 11 | 388 | | | 389 | | | 390 -90 +-----------------------+-----------------------+ 392 From now on, vertical and horizontal splitting is continued until the 393 desired resolution is achieved, recursively tiling the whole range of 394 coordinates into smaller areas. Whenever a "sub-area" is split, the 395 new "left" (or "upper") area is identified by appending a binary 0 to 396 the area string , and the new "right" (or "lower") area is identified 397 by appending a binary 1 to the area bitstring. After another 398 repetition of a vertical split, the areas look like this: 400 -180 0 +180 401 +90 +-----------+-----------+-----------+-----------+ 402 | | | | | 403 | | | | | 404 | 000 | 001 | 100 | 101 | 405 | | | | | 406 | | | | | 407 0 +-----------+-----------+-----------+-----------+ 408 | | | | | 409 | | | | | 410 | 010 | 011 | 110 | 111 | 411 | | | | | 412 | | | | | 413 -90 +-----------+-----------+-----------+-----------+ 415 After another horizontal split, the following areas are identified: 417 -180 0 +180 418 +90 +-----------+-----------+-----------+-----------+ 419 | 0000 | 0010 | 1000 | 1010 | 420 | | | | | 421 +-----------+-----------+-----------+-----------+ 422 | 0001 | 0011 | 1001 | 1011 | 423 | | | | | 424 0 +-----------+-----------+-----------+-----------+ 425 | 0100 | 0110 | 1100 | 1110 | 426 | | | | | 427 +-----------+-----------+-----------+-----------+ 428 | 0101 | 0111 | 1101 | 1111 | 429 | | | | | 430 -90 +-----------+-----------+-----------+-----------+ 432 After another ("vertical" split), the following area bitstrings 433 exist: 435 -180 0 +180 436 +90 +-----+-----+-----+-----+-----+-----+-----+-----+ 437 |00000|00001|00100|00101|10000|10001|10100|10101| 438 | | | | | | | | | 439 +-----+-----+-----+-----+-----+-----+-----+-----+ 440 |00010|00011|00110|00111|10010|10011|10110|10111| 441 | | | | | | | | | 442 0 +-----+-----+-----+-----+-----+-----+-----+-----+ 443 |01001|01101|01100|01101|11000|11001|11100|11101| 444 | | | | | | | | | 445 +-----+-----+-----+-----+-----+-----+-----+-----+ 446 |01010|01011|01110|01111|11010|11011|11110|11111| 447 | | | | | | | | | 448 -90 +-----+-----+-----+-----+-----+-----+-----+-----+ 450 Those splitting steps can be repeated as long until the desired size 451 of the area to be identified is reached. Tiling MUST always be 452 initiated with a vertical split. After a vertical split, the next 453 split MUST be a horizontal split. After a horizontal split, the next 454 split MUST be a vertical split, etc.. 456 The resulting area bitstring is used in encoding tile identifiers 457 (see Section 7). 459 Note that area bitstrings can be obviously calculated directly as 460 well - the above "splitting" procedure is considered to have 461 illustrative value. 463 7. Encoding of Tile Identifiers 465 A "geo" URI contains base32 encoded tile identifiers. This section 466 describes how to transform area bitstrings into their Base32 467 representation. 469 7.1. Area Bitstring Padding 471 Since tiling as outlined above may be stopped at any "resolution", 472 area bitstrings may have arbitrary numbers of binary digits, and 473 therefore not fit into the 5-bit boundaries of Base32. The following 474 process MUST be followed to pad area bitstrings to multiples of 5 bit 475 (the example uses an area bitstring of 12 bits): 476 1. Identify number of significant bits in area bitstrings (void bits 477 are illustrated as dots below): 479 01011 10100 11... (12 significant bits) 480 area id: -------------- 482 2. Pad area bitstring to the next 5-bit border with "0" bits, and 483 record the number of padding bits used in "padding-counter": 485 01011 10100 11000 (total lenght: 15 bit) 486 area id: -------------- 487 padding: --- (padding-counter: 3) 489 (Note that after padding, the number of significant bit cannot be 490 recovered from the padded area bitstring without the padding- 491 counter). 493 7.2. Appending Padding Counter and Parity Bits 495 To recover the number of significant bits in the resulting URI 496 string, the binary representation of padding-counter is appended to 497 the padded area bitstring. Since the padding size is between 0 and 4 498 bits, 3 bits are required to encode padding-counter. 500 01011 10100 11000 011 (padding-counter: 3) 501 area id: -------------- 502 padding: --- 503 padding-counter: --- 505 The encoded padding-counter of 3 bits always leaves 2 bits of "free 506 space" in the last 5 bit group. Those 2 bits are used for parity 507 bits, which are calculated as follows: 508 o The first parity bit (A) is used to convey even parity over the 509 "longitude" bits 511 o The second parity bit (B) is used to convey even parity for the 512 "latitude" bits 514 01011 10100 11000 01100 515 area id: ----- ----- -- 516 parity bits: -- 517 longitude bit: 0 0 1 0 0 1 0 (parity bit A - longitude) 518 latitude bit: 1 1 1 1 0 0 0 (parity bit B - latitude) 520 Note that padding bits MUST NOT be included in parity calculation 521 (the use of '0' bits for padding does not affect parity anyways, 522 however, mangled URI instances could contain '1's in padding). 524 7.3. Final Base32 Encoding 526 The bitstream resulting from the operations above (including the 527 significance / parity bits) is Base32 encoded according to section 5 528 of [RFC3548]. 530 Bitstream: 01011 10100 11000 01100 531 Decimal: 11 20 24 12 532 Base32: L U Y M 534 Therefore, the final base32 encoded tile identifier is "LUYM". That 535 string is to be used in the "geo-tile-id" component of the URI (see 536 Section 5.3). 538 8. Example 540 The following 'geo' URI identifies a geographic area that resembles 541 the square in front of one of the author's office: 542 o Center coordinates (approx.): 48.200179 latitude, 16.367957 543 longitude. 544 o Number of tiling steps: 34 545 o Area bitstring: 1000010111001111100111010000111011 546 o Geographic coordinates of respective area: 48.1997680664 to 547 48.2011413574 degrees north, 16.3668823242 to 16.3696289062 548 degrees east ( approximately 150 x 300 meters). 549 o Area bitstring padded: 551 10000 10111 00111 11001 11010 00011 10110 552 = 554 o Area bitstring with padding-counter (1 bit padding): 556 10000 10111 00111 11001 11010 00011 10110 001 557 === 559 o Adding parity bits: 561 10000 10111 00111 11001 11010 00011 10110 00110 562 == 563 lon: 1 0 0 0 1 0 1 1 1 0 1 0 0 0 1 1 1 0 -> 1 564 lat: 0 0 1 1 1 0 1 1 0 1 1 1 0 0 1 0 1 --> 0 566 o Base32 encoding: 568 10000 10111 00111 11001 11010 00011 10110 00110 569 Q X H Z 2 D W G 571 o Resulting 'geo' URI: 573 geo:QXHZ2DWG 575 9. IANA Considerations 577 This document requests assignment of the 'geo' URI scheme in the IETF 578 part of the URI scheme tree, according to the guidelines in BCP 115 579 (RFC 4395) [RFC4395]. The definitions required for the assignment 580 are contained in Section 5. 582 10. Security Considerations 584 Because the 'geo' URI is not tied to any specific protocol, and 585 identifies a physical area rather than an abstract resource, most of 586 the general security considerations on URIs (Section 7 of RFC 3986) 587 do not apply. 589 Instances of 'geo' URIs convey location information. Such location 590 information may be publicly known, and therefore not be very 591 sensitive (for example, 'geo' URIs conveying the location of public 592 sights, hotels, etc.). However, 'geo' URIs might be used in 593 situations that have considerable privacy implications (for example, 594 the current location of a person combined with Personally 595 Identifieable Information). 597 Therefore, security and privacy must be considered for individual use 598 cases. 600 11. References 601 11.1. Normative References 603 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 604 Resource Identifier (URI): Generic Syntax", STD 66, 605 RFC 3986, January 2005. 607 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 608 Requirement Levels", BCP 14, RFC 2119, March 1997. 610 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 611 Specifications: ABNF", RFC 4234, October 2005. 613 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 614 Encodings", RFC 3548, July 2003. 616 11.2. Informative References 618 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 619 Registration Procedures for New URI Schemes", BCP 115, 620 RFC 4395, February 2006. 622 [WGS84] National Imagery and Mapping Agency, "Department of 623 Defense World Geodetic System 1984, Third Edition", 624 NIMA TR8350.2, January 2000. 626 Authors' Addresses 628 Alexander Mayrhofer 629 enum.at GmbH 630 Karlsplatz 1/9 631 Wien A-1010 632 Austria 634 Phone: +43 1 5056416 34 635 Email: alexander.mayrhofer@enum.at 636 URI: http://www.enum.at/ 638 Christian Spanring 639 OIR-ID GmbH 640 Franz-Josefs-Kai 27 641 Wien A-1010 643 Phone: +43 1 5338747 36 644 Email: spanring@oir.at 645 URI: http://www.oir.at/ 647 Full Copyright Statement 649 Copyright (C) The IETF Trust (2008). 651 This document is subject to the rights, licenses and restrictions 652 contained in BCP 78, and except as set forth therein, the authors 653 retain all their rights. 655 This document and the information contained herein are provided on an 656 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 657 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 658 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 659 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 660 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 661 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 663 Intellectual Property 665 The IETF takes no position regarding the validity or scope of any 666 Intellectual Property Rights or other rights that might be claimed to 667 pertain to the implementation or use of the technology described in 668 this document or the extent to which any license under such rights 669 might or might not be available; nor does it represent that it has 670 made any independent effort to identify any such rights. Information 671 on the procedures with respect to rights in RFC documents can be 672 found in BCP 78 and BCP 79. 674 Copies of IPR disclosures made to the IETF Secretariat and any 675 assurances of licenses to be made available, or the result of an 676 attempt made to obtain a general license or permission for the use of 677 such proprietary rights by implementers or users of this 678 specification can be obtained from the IETF on-line IPR repository at 679 http://www.ietf.org/ipr. 681 The IETF invites any interested party to bring to its attention any 682 copyrights, patents or patent applications, or other proprietary 683 rights that may cover technology that may be required to implement 684 this standard. Please address the information to the IETF at 685 ietf-ipr@ietf.org. 687 Acknowledgment 689 Funding for the RFC Editor function is provided by the IETF 690 Administrative Support Activity (IASA).