idnits 2.17.1 draft-mayrhofer-geopriv-geo-uri-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (February 12, 2009) is 5550 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) == Unused Reference: 'RFC3261' is defined on line 559, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV -- Geographic A. Mayrhofer 3 Location/Privacy Working Group nic.at 4 Internet-Draft C. Spanring 5 Expires: August 16, 2009 OIR-ID 6 February 12, 2009 8 A Uniform Resource Identifier for Geographic Locations ('geo' URI) 9 draft-mayrhofer-geopriv-geo-uri-01 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 16, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 Abstract 48 This document specifies an Uniform Resource Identifier (URI) for 49 geographic locations using the 'geo' scheme name. A 'geo' URI 50 identifies a physical location by latitude, longitude and optionally 51 altitude in a compact, simple, human-readable, and protocol 52 independent way. 54 Table of Contents 56 1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. IANA Registration of 'geo' URI Scheme . . . . . . . . . . . . 6 63 4.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . . 6 64 4.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.3. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 6 66 4.4. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 6 67 4.4.1. Component Description . . . . . . . . . . . . . . . . 6 68 4.4.2. URI Comparison . . . . . . . . . . . . . . . . . . . . 7 69 4.4.3. Interpretation of Undefined Altitude . . . . . . . . . 7 70 4.5. Encoding Considerations . . . . . . . . . . . . . . . . . 7 71 4.6. Applications/protocols That Use This URI Scheme . . . . . 8 72 4.7. Interopability Considerations . . . . . . . . . . . . . . 8 73 4.8. Security Considerations . . . . . . . . . . . . . . . . . 8 74 4.9. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 4.10. Author/Change controller . . . . . . . . . . . . . . . . . 8 76 4.11. References . . . . . . . . . . . . . . . . . . . . . . . . 9 78 5. URI Operations . . . . . . . . . . . . . . . . . . . . . . . . 9 80 6. Use Cases and Examples . . . . . . . . . . . . . . . . . . . . 9 81 6.1. Plain 'geo' URI Example . . . . . . . . . . . . . . . . . 9 82 6.2. Hyperlink . . . . . . . . . . . . . . . . . . . . . . . . 9 83 6.3. 'geo' URI in 2-dimensional barcode . . . . . . . . . . . . 10 85 7. GML Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 10 86 7.1. 'geo' URI without altitude to GML 'Point' . . . . . . . . 10 87 7.2. 'geo' URI with Altitude to GML 'Point' . . . . . . . . . . 11 88 7.3. GML 'Point' without Altitude to 'geo' URI . . . . . . . . 11 89 7.4. GML 'Point' with Altitude to 'geo' URI . . . . . . . . . . 12 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 93 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 94 9.1. Invalid Locations . . . . . . . . . . . . . . . . . . . . 12 95 9.2. Location Privacy . . . . . . . . . . . . . . . . . . . . . 13 97 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 99 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 100 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 101 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 105 1. Change Log 107 [Note to editors: This section is to be removed before publication - 108 XML source available on request] 110 draft-mayrhofer-geopriv-geo-uri-01 111 o added terminology text about WGS-84 (credits Carl Reed) 112 o removed "resolution" / "uncertainty" text 113 o added considerations regarding poles 114 o added text about invalid URIs 116 draft-mayrhofer-geopriv-geo-uri-00 117 o Initial version under new name, reverting to "plain" lat/lon 118 scheme, with the "tiling" scheme moved to seperate draft 119 (potentially published as "draft-mayrhofer-geopriv-geotile-uri"). 120 refer to draft-mayrhofer-geo-uri-01 for the history of this 121 document. 122 o Added GML mapping section 124 draft-mayrhofer-geo-uri-01 125 o removed parameters 127 draft-mayrhofer-geo-uri-00 128 o initial draft 130 2. Introduction 132 An increasing number of Internet protocols and data formats are 133 extended by specifications for adding spatial (geographic) location. 134 In most cases, latitude as well as longitude of simple points are 135 added as new attributes to existing data structures. However, all 136 those methods are very specific to a certain data format or protocol, 137 and don't provide a protocol independent, compact and generic way to 138 refer to a physical geographic location. 140 Over the past few years, fast emerging location aware applications 141 and location based services were observable on the Internet. Most 142 web search engines use geographic information, and a vivid open 143 source mapping community brought an enormous momentum into location 144 aware technology. A wide range and former to professionals exclusive 145 tools and data were provided free of charge for an everyday use on 146 the mass market. 148 The 'geo' URI scheme is another step into that direction and aims to 149 facilitate, support and standardize the problem of location 150 identification in geospatial services and applications. Accessing 151 information about or trigger further services based on a particular 152 place on earth shouldn't be any harder for users than clicking on a 153 'mailto:' link and write an email straight away. 155 According to [RFC3986], a Uniform Resource Identifier (URI) is "a 156 compact sequence of characters that identifies an abstract or 157 physical resource". The 'geo' URI scheme defined in this document 158 identifies geographic locations (a physical resource) in the World 159 Geodetic System 1984 (WGS-84) [WGS84] reference system. 161 'Geo' URIs identify a geographic location using a textual 162 representation of the location's spatial coordinates in either two or 163 three dimensions (latitude, longitude, and optionally altitude). 164 Such URIs are independent from a specific protocol, application, or 165 data format, and can be used in any other protocol or data format 166 that supports inclusion of arbitrary URIs. 168 The definition of the URI scheme is strictly focused on the most 169 simplest representation of a spatial location - a single point. The 170 provision of more complex geometries or locations described by civic 171 addresses is out of scope of this document. 173 Note: The choice of WGS-84 is based on the widespread availability of 174 Global Positioning System (GPS) devices, which use the WGS-84 175 reference system. It is anticipated that such devices serve as one 176 of the primary data sources for authoring 'geo' URIs, hence the 177 adoption of the native GPS reference system for the URI scheme. 178 Also, many other data formats for representing geographic locations 179 use the WGS-84 reference system, which makes transposing from and to 180 such data formats less error prone (no re-projection involved). 182 3. Terminology 184 Geographic locations in this document are defined using WGS 84 (World 185 Geodetic System 1984), equivalent to the OGP Surveying and 186 Positioning Committee EPSG code 4326 (2 dimensions) and 4979 (3 187 dimensions). This document does not assign responsibilities for 188 coordinate transformations from and to other Spatial Reference 189 Systems. 191 A 2-dimensional WGS-84 coordinate value is here represented as a 192 comma-delimited latitude/longitude pair, measured in decimal degrees 193 (un-projected). A 3-dimensional WGS-84 coordinate value is here 194 represented by appending a comma-delimited altitude value in meters 195 to such pairs. 197 Latitudes range from -90 to 90 and longitudes range from -180 to 180. 198 Coordinates in the Southern and Western hemispheres as well as 199 altitudes below the WGS-84 reference geoid are signed negative with a 200 leading dash. 202 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 203 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 204 document are to be interpreted as described in RFC 2119 [RFC2119]. 206 4. IANA Registration of 'geo' URI Scheme 208 This section contains the fields required for the URI scheme 209 registration, following the guidelines in section 5.4 of [RFC4395]. 211 4.1. URI Scheme Name 213 geo 215 4.2. Status 217 permanent 219 4.3. URI Scheme Syntax 221 The syntax of the 'geo' URI scheme is specified below in Augmented 222 Backus-Naur Form (ABNF) [RFC4234]: 224 geo-URI = geo-scheme ":" geo-path 225 geo-scheme = "geo" 226 geo-path = geo-location 228 geo-location = latitude "," longitude [ "," altitude ] 230 latitude = [ "-" ] 1*2DIGIT [ "." *DIGIT ] 231 longitude = [ "-" ] 1*3DIGIT [ "." *DIGIT ] 232 altitude = [ "-" ] *DIGIT [ "." *DIGIT ] 234 4.4. URI Scheme Semantics 236 Data contained in a 'geo' URI identifies a physical resource: A 237 spatial location on earth in the WGS-84 references system, identified 238 by the geographic coordinates encoded in the URI. 240 4.4.1. Component Description 242 The "latitude", "longitude" and "altitude" components as specified in 243 the URI scheme syntax ( Section 4.3) are to be used as follows: 245 o The "latitude" component MUST contain the latitude of the 246 identified location in decimal degrees in the reference system 247 WGS-84. 248 o The "latitude" component MUST contain the latitude of the 249 identified location in decimal degrees in the reference system 250 WGS-84. 251 o If present, the OPTIONAL "altitude" component MUST contain the 252 WGS-84 altitude of the identified location in meters. 254 If the altitude of the location is unknown, the "altitude" component 255 MUST NOT be present in the URI. Specifically, unknown altitude MUST 256 NOT be represented by setting the 'altitude' component to "0" (or any 257 other arbitrary value). 259 The "longitude" components of coordinate values reflecting the poles 260 (latitude set to -90 or 90 degrees) SHOULD be set to "0", although 261 consumers of "geo" URIs MUST accept such URIs with any longitude 262 value between -180 and 180. 264 'geo' URIs with longitude values outside the range of -180 to 180 265 decimal degrees or with latitude values outside the range of -90 to 266 90 degrees MUST be considered invalid. 268 4.4.2. URI Comparison 270 Two 'geo' URIs are equal when their 'longitude', 'latitude' and 271 'altitude' values are mathematically identical. Where the 'latitude' 272 component of a 'geo' URI is set to either 90 or -90 degrees, the 273 'longitude' component MUST be ignored in comparison operations. 275 An URI with undefined (missing) 'altitude' value MUST NOT be 276 considered equal to an URI containing an 'altitude' value, even if 277 the remaining values 'latitude' and 'longitude' are equivalent. 279 4.4.3. Interpretation of Undefined Altitude 281 A consumer of a 'geo' URI with undefined 'altitude' MAY assume that 282 the URI refers to the respective location on earth's physical surface 283 at the given 'latitude' and 'longitude' coordinate. 285 However, as defined above, altitudes are relative to the WGS-84 286 reference geoid rather than earth's surface. Hence, an altitude 287 value of 0 MUST NOT be interpreted as "on earth's surface". 289 4.5. Encoding Considerations 291 The 'geo-location' path component of the 'geo' URI (see Section 4.3) 292 uses a comma (",") as a delimiter for subcomponents. This delimiter 293 MUST NOT be percent encoded. 295 It is RECOMMENDED that for readability the contents of 'latitude', 296 'longitude' and 'altitude' subcomponents are never percent encoded. 298 4.6. Applications/protocols That Use This URI Scheme 300 As many other URI scheme definitions, the 'geo' URI provides resource 301 identification independent of a specific application or protocol. 302 Examples of potential protocol mappings and use cases can be found in 303 Section 6. 305 4.7. Interopability Considerations 307 As with any other new URI scheme, the 'geo' URI requires support in 308 client applications. Users of applications which are not aware of 309 the 'geo' scheme are likely unable to make use of the information in 310 the URI. However, the simple structure of the 'geo' URI would even 311 allow manual dereference by users. 313 Poorly authored 'geo' URI instances could contain whitespace and 314 numbers with leading plus signs ("+"). Clients SHOULD try to 315 dereference such URIs after removing such whitespace and plus signs. 317 This specification does not define any URI parameters nor a query 318 component. Future revisions might define such parameters, using the 319 ";" and "?" characters to delimit parameter and query components from 320 the path component specified above. Clients MUST be prepared to 321 encounter such 'geo' URI instances, and MUST reduce the URI to the 322 components specified in Section 4.3 before they dereference the URI. 324 4.8. Security Considerations 326 See Section 9 of [insert reference to this document] 328 4.9. Contact 330 Christian Spanring (mailto:spanring@oir.at, http://spanring.eu/ ), 331 Alexander Mayrhofer (mailto:alexander.mayrhofer@nic.at, 332 http://timatio.com/ ) 334 4.10. Author/Change controller 336 The 'geo' URI scheme is registered under the IETF part of the URI 337 tree. As such, change control is up to the IETF. 339 4.11. References 341 RFC XXXX [change to RFC number once assigned] 343 5. URI Operations 345 Currently, just one operation on a 'geo' URI is defined - location 346 dereference: In that operation, a client dereferences the URI by 347 extracting the geographical coordinates from the URI path component. 348 Further use of those coordinates is then up to the application 349 processing the URI. 351 An application may then use this location information for various 352 purposes, for example: 354 o A web browser could use that information to open a web mapping 355 service of the user's choice, and display a map of the location 357 o A navigational device such as a Global Positioning System (GPS) 358 receiver could offer the user to start navigation to the location. 360 6. Use Cases and Examples 362 6.1. Plain 'geo' URI Example 364 The following 3-dimensional 'geo' URI example references to the 365 office location of one of the authors in Vienna, Austria: 367 geo:48.2010,16.3695,183 369 A user could type the data extracted from this URI into a electronic 370 navigation device, or even use it to locate the identified location 371 on a paper map. 373 6.2. Hyperlink 375 'geo' URIs (like any other URI scheme) could also be embedded as 376 hyperlinks in web pages. A Hyper Text Markup Language (HTML) snippet 377 with such a hyperlink could look like: 379

one of Vienna's popular sights is the Karlskirche. 382 A web brower could extract the coordinates from the HTML snippet, and 383 offer the user various options (based on configuration, context), for 384 example: 386 o display a small map thumbnail when the mouse pointer hovers over 387 the link 389 o switch to a mapping service of the user's choice once the link is 390 selected 392 o Locate nearby resources, for example by comparing the 'geo' URI 393 with locations extracted from GeoRSS feeds the user has subscribed 394 to. 396 o Convert the coordinates to a format suitable for uploading to a 397 navigation device 399 6.3. 'geo' URI in 2-dimensional barcode 401 Due to it's short length, a 'geo' URI could easily be encoded in 402 2-dimensional barcodes. Such barcodes could be printed on business 403 cards, flyers, paper maps and subsequently used by mobile devices, 404 for example as follows: 406 1. User identifies such a barcode on a flyer, uses the camera on his 407 mobile phone to photograph and decode the barcode 409 2. The mobile phone dereferences the 'geo' URI, and offers the user 410 to calculate a navigation route to the identified location. 412 3. Using the builtin GPS, the user follows the navgiation 413 instructions from his phone to reach the destination 415 7. GML Mappings 417 The Geographic Markup Language (GML) by the Open Geospatial 418 Consortium (OGC) is a set of XML schemas to represent geographical 419 features. Since GML is widely accepted, this document includes 420 instructions on how to transpose 'geo' URIs from and to GML 421 documents. 423 A 'geo' URI can be authored from a GML "point", and any 'geo' URI can 424 be mapped to a GML "point". For the following sections, "%lat%", 425 "%lon%" and "%alt%" are placeholders for latitude, longitude, and 426 altitude values. Mappings are defined as follows: 428 7.1. 'geo' URI without altitude to GML 'Point' 430 An instance of the 'geo' URI without the altitude element is mapped 431 to a two-dimensional GML "Point" as follows: 433 'geo' URI: 435 geo:%lat%,%lon% 437 GML document: 439 440 443 %lat% %lon% 444 446 7.2. 'geo' URI with Altitude to GML 'Point' 448 A 'geo' URI instance with the altitude element is mapped to a three- 449 dimensional GML "Point" as follows: 451 'geo' URI: 453 geo:%lat%,%lon%,%alt% 455 GML document: 457 458 461 %lat% %lon% %alt% 462 464 7.3. GML 'Point' without Altitude to 'geo' URI 466 A GML 'Point' in the reference system identified as 467 "urn:ogc:def:crs:EPSG:6.6:4326" is mapped to a 'geo' URI as follows: 469 GML document: 471 472 475 %lat% %lon% 476 478 'geo' URI: 480 geo:%lat%,%lon% 482 Note: GML documents in other reference systems MAY be used as well if 483 a transformation into "urn:ogc:def:crs:EPSG:6.6:4326" is defined and 484 applied before the mapping step. 486 7.4. GML 'Point' with Altitude to 'geo' URI 488 A GML 'Point' in the reference system identified as 489 "urn:ogc:def:crs:EPSG:6.6:4979" is mapped to a 'geo' URI as follows: 491 GML document: 493 494 497 %lat% %lon% 498 500 'geo' URI: 502 geo:%lat%,%lon% 504 Note: GML 'Point' instances in other reference systems MAY be used as 505 well if a transformation into "urn:ogc:def:crs:EPSG:6.6:4326" is 506 defined and applied before the mapping step. 508 8. IANA Considerations 510 This document requests assignment of the 'geo' URI scheme in the IETF 511 part of the URI scheme tree, according to the guidelines in BCP 115 512 (RFC 4395) [RFC4395]. The definitions required for the assignment 513 are contained in Section 4. 515 9. Security Considerations 517 Because the 'geo' URI is not tied to any specific protocol, and 518 identifies a physical location rather than a network resource, most 519 of the general security considerations on URIs (Section 7 of RFC 520 3986) do not apply. However, the following (additional) issues 521 apply: 523 9.1. Invalid Locations 525 The URI syntax (Section 4.3) makes it possible to construct valid 526 'geo' URIs which don't identify a valid location on earth. 527 Applications MUST NOT use URIs which such invalid values, and SHOULD 528 warn the user when such URIs are encountered. 530 An example of such an invalid URI would be (latitude 531 "beyond" north pole). 533 9.2. Location Privacy 535 Location information about individuals is an extremely sensitive 536 topic, especially when location is combined with Personally 537 Identifyable Information (PII). Authors of 'geo' URIs MUST consider 538 data protection and privacy before publishing such URIs. 540 10. Acknowledgements 542 The authors wish to acknowledge the helpful contributions from Carl 543 Reed, Bill McQuillan, Martin Kofal, Andrew Turner and Kim Sanders. 545 11. References 547 11.1. Normative References 549 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 550 Resource Identifier (URI): Generic Syntax", STD 66, 551 RFC 3986, January 2005. 553 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 554 Requirement Levels", BCP 14, RFC 2119, March 1997. 556 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 557 Specifications: ABNF", RFC 4234, October 2005. 559 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 560 A., Peterson, J., Sparks, R., Handley, M., and E. 561 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 562 June 2002. 564 11.2. Informative References 566 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 567 Registration Procedures for New URI Schemes", BCP 115, 568 RFC 4395, February 2006. 570 [WGS84] National Imagery and Mapping Agency, "Department of 571 Defense World Geodetic System 1984, Third Edition", 572 NIMA TR8350.2, January 2000. 574 Authors' Addresses 576 Alexander Mayrhofer 577 nic.at GmbH 578 Karlsplatz 1/9 579 Wien A-1010 580 Austria 582 Phone: +43 1 5056416 34 583 Email: alexander.mayrhofer@nic.at 584 URI: http://www.nic.at/ 586 Christian Spanring 587 OIR-ID GmbH 588 Franz-Josefs-Kai 27 589 Wien A-1010 591 Phone: +43 1 5338747 36 592 Email: spanring@oir.at 593 URI: http://www.oir.at/