idnits 2.17.1 draft-ietf-geopriv-geo-uri-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2, 2009) is 5442 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 578, 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: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 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: December 4, 2009 OIR-ID 6 June 2, 2009 8 A Uniform Resource Identifier for Geographic Locations ('geo' URI) 9 draft-ietf-geopriv-geo-uri-00 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. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on December 4, 2009. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 This document specifies an Uniform Resource Identifier (URI) for 58 geographic locations using the 'geo' scheme name. A 'geo' URI 59 identifies a physical location by latitude, longitude and optionally 60 altitude in a compact, simple, human-readable, and protocol 61 independent way. 63 Table of Contents 65 1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 4. IANA Registration of 'geo' URI Scheme . . . . . . . . . . . . 7 72 4.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . . 7 73 4.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 4.3. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 7 75 4.4. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 7 76 4.4.1. Component Description . . . . . . . . . . . . . . . . 8 77 4.4.2. URI Comparison . . . . . . . . . . . . . . . . . . . . 8 78 4.4.3. Interpretation of Undefined Altitude . . . . . . . . . 8 79 4.5. Encoding Considerations . . . . . . . . . . . . . . . . . 9 80 4.6. Applications/protocols That Use This URI Scheme . . . . . 9 81 4.7. Interopability Considerations . . . . . . . . . . . . . . 9 82 4.8. Security Considerations . . . . . . . . . . . . . . . . . 9 83 4.9. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 4.10. Author/Change controller . . . . . . . . . . . . . . . . . 10 85 4.11. References . . . . . . . . . . . . . . . . . . . . . . . . 10 87 5. URI Operations . . . . . . . . . . . . . . . . . . . . . . . . 10 89 6. Use Cases and Examples . . . . . . . . . . . . . . . . . . . . 10 90 6.1. Plain 'geo' URI Example . . . . . . . . . . . . . . . . . 10 91 6.2. Hyperlink . . . . . . . . . . . . . . . . . . . . . . . . 10 92 6.3. 'geo' URI in 2-dimensional barcode . . . . . . . . . . . . 11 94 7. GML Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 11 95 7.1. 'geo' URI without altitude to GML 'Point' . . . . . . . . 12 96 7.2. 'geo' URI with Altitude to GML 'Point' . . . . . . . . . . 12 97 7.3. GML 'Point' without Altitude to 'geo' URI . . . . . . . . 12 98 7.4. GML 'Point' with Altitude to 'geo' URI . . . . . . . . . . 13 100 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 102 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 103 9.1. Invalid Locations . . . . . . . . . . . . . . . . . . . . 14 104 9.2. Location Privacy . . . . . . . . . . . . . . . . . . . . . 14 106 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 108 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 109 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 110 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 114 1. Change Log 116 [Note to editors: This section is to be removed before publication - 117 XML source available on request] 119 draft-ietf-geopriv-geo-uri-00 120 o submitted as WG item 121 o changed IPR text because of text used from RFC 4395 122 o added considerations for comparing +180/-180 longitude URIs 123 o some editorial changes 125 draft-mayrhofer-geopriv-geo-uri-01 126 o added terminology text about WGS-84 (credits Carl Reed) 127 o removed "resolution" / "uncertainty" text 128 o added considerations regarding poles 129 o added text about invalid URIs 131 draft-mayrhofer-geopriv-geo-uri-00 132 o Initial version under new name, reverting to "plain" lat/lon 133 scheme, with the "tiling" scheme moved to seperate draft 134 (potentially published as "draft-mayrhofer-geopriv-geotile-uri"). 135 refer to draft-mayrhofer-geo-uri-01 for the history of this 136 document. 137 o Added GML mapping section 139 draft-mayrhofer-geo-uri-01 140 o removed parameters 142 draft-mayrhofer-geo-uri-00 143 o initial draft 145 2. Introduction 147 An increasing number of Internet protocols and data formats are 148 extended by specifications for adding spatial (geographic) location. 149 In most cases, latitude as well as longitude of simple points are 150 added as new attributes to existing data structures. However, all 151 those methods are very specific to a certain data format or protocol, 152 and don't provide a protocol independent, compact and generic way to 153 refer to a physical geographic location. 155 Over the past few years, fast emerging location aware applications 156 and location based services were observable on the Internet. Most 157 web search engines use geographic information, and a vivid open 158 source mapping community brought an enormous momentum into location 159 aware technology. A wide range and former to professionals exclusive 160 tools and data were provided free of charge for an everyday use on 161 the mass market. 163 The 'geo' URI scheme is another step into that direction and aims to 164 facilitate, support and standardize the problem of location 165 identification in geospatial services and applications. Accessing 166 information about or trigger further services based on a particular 167 place on earth shouldn't be any harder for users than clicking on a 168 'mailto:' link and write an email straight away. 170 According to [RFC3986], a Uniform Resource Identifier (URI) is "a 171 compact sequence of characters that identifies an abstract or 172 physical resource". The 'geo' URI scheme defined in this document 173 identifies geographic locations (a physical resource) in the World 174 Geodetic System 1984 (WGS-84) [WGS84] reference system. 176 'Geo' URIs identify a geographic location using a textual 177 representation of the location's spatial coordinates in either two or 178 three dimensions (latitude, longitude, and optionally altitude). 179 Such URIs are independent from a specific protocol, application, or 180 data format, and can be used in any other protocol or data format 181 that supports inclusion of arbitrary URIs. 183 The definition of the URI scheme is strictly focused on the most 184 simplest representation of a spatial location - a single point. The 185 provision of more complex geometries or locations described by civic 186 addresses is out of scope of this document. 188 Note: The choice of WGS-84 is based on the widespread availability of 189 Global Positioning System (GPS) devices, which use the WGS-84 190 reference system. It is anticipated that such devices serve as one 191 of the primary data sources for authoring 'geo' URIs, hence the 192 adoption of the native GPS reference system for the URI scheme. 193 Also, many other data formats for representing geographic locations 194 use the WGS-84 reference system, which makes transposing from and to 195 such data formats less error prone (no re-projection involved). 197 3. Terminology 199 Geographic locations in this document are defined using WGS 84 (World 200 Geodetic System 1984), equivalent to the OGP Surveying and 201 Positioning Committee EPSG code 4326 (2 dimensions) and 4979 (3 202 dimensions). This document does not assign responsibilities for 203 coordinate transformations from and to other Spatial Reference 204 Systems. 206 A 2-dimensional WGS-84 coordinate value is here represented as a 207 comma-delimited latitude/longitude pair, measured in decimal degrees 208 (un-projected). A 3-dimensional WGS-84 coordinate value is here 209 represented by appending a comma-delimited altitude value in meters 210 to such pairs. 212 Latitudes range from -90 to 90 and longitudes range from -180 to 180. 213 Coordinates in the Southern and Western hemispheres as well as 214 altitudes below the WGS-84 reference geoid are signed negative with a 215 leading dash. 217 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 218 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 219 document are to be interpreted as described in RFC 2119 [RFC2119]. 221 4. IANA Registration of 'geo' URI Scheme 223 This section contains the fields required for the URI scheme 224 registration, following the guidelines in section 5.4 of [RFC4395]. 226 4.1. URI Scheme Name 228 geo 230 4.2. Status 232 permanent 234 4.3. URI Scheme Syntax 236 The syntax of the 'geo' URI scheme is specified below in Augmented 237 Backus-Naur Form (ABNF) [RFC4234]: 239 geo-URI = geo-scheme ":" geo-path 240 geo-scheme = "geo" 241 geo-path = geo-location 243 geo-location = latitude "," longitude [ "," altitude ] 245 latitude = [ "-" ] 1*2DIGIT [ "." *DIGIT ] 246 longitude = [ "-" ] 1*3DIGIT [ "." *DIGIT ] 247 altitude = [ "-" ] *DIGIT [ "." *DIGIT ] 249 4.4. URI Scheme Semantics 251 Data contained in a 'geo' URI identifies a physical resource: A 252 spatial location on earth in the WGS-84 references system, identified 253 by the geographic coordinates encoded in the URI. 255 4.4.1. Component Description 257 The "latitude", "longitude" and "altitude" components as specified in 258 the URI scheme syntax ( Section 4.3) are to be used as follows: 259 o The "latitude" component MUST contain the latitude of the 260 identified location in decimal degrees in the reference system 261 WGS-84. 262 o The "latitude" component MUST contain the latitude of the 263 identified location in decimal degrees in the reference system 264 WGS-84. 265 o If present, the OPTIONAL "altitude" component MUST contain the 266 WGS-84 altitude of the identified location in meters. 268 If the altitude of the location is unknown, the "altitude" component 269 MUST NOT be present in the URI. Specifically, unknown altitude MUST 270 NOT be represented by setting the 'altitude' component to "0" (or any 271 other arbitrary value). 273 The "longitude" components of coordinate values reflecting the poles 274 (latitude set to -90 or 90 degrees) SHOULD be set to "0", although 275 consumers of "geo" URIs MUST accept such URIs with any longitude 276 value between -180 and 180. 278 'geo' URIs with longitude values outside the range of -180 to 180 279 decimal degrees or with latitude values outside the range of -90 to 280 90 degrees MUST be considered invalid. 282 4.4.2. URI Comparison 284 Two 'geo' URIs are equal when their 'longitude', 'latitude' and 285 'altitude' values are mathematically identical. Where the 'latitude' 286 component of a 'geo' URI is set to either 90 or -90 degrees, the 287 'longitude' component MUST be ignored in comparison operations. A 288 'longitude' component of 180 degrees MUST be considered equal a 289 'longitude' component of -180 degrees for the purpose of URI 290 comparison. 292 An URI with undefined (missing) 'altitude' value MUST NOT be 293 considered equal to an URI containing an 'altitude' value, even if 294 the remaining values 'latitude' and 'longitude' are equivalent. 296 4.4.3. Interpretation of Undefined Altitude 298 A consumer of a 'geo' URI with undefined 'altitude' MAY assume that 299 the URI refers to the respective location on earth's physical surface 300 at the given 'latitude' and 'longitude' coordinate. 302 However, as defined above, altitudes are relative to the WGS-84 303 reference geoid rather than earth's surface. Hence, an altitude 304 value of 0 MUST NOT be interpreted as "on earth's surface". 306 4.5. Encoding Considerations 308 The 'geo-location' path component of the 'geo' URI (see Section 4.3) 309 uses a comma (",") as a delimiter for subcomponents. This delimiter 310 MUST NOT be percent encoded. 312 It is RECOMMENDED that for readability the contents of 'latitude', 313 'longitude' and 'altitude' subcomponents are never percent encoded. 315 4.6. Applications/protocols That Use This URI Scheme 317 As many other URI scheme definitions, the 'geo' URI provides resource 318 identification independent of a specific application or protocol. 319 Examples of potential protocol mappings and use cases can be found in 320 Section 6. 322 4.7. Interopability Considerations 324 As with any other new URI scheme, the 'geo' URI requires support in 325 client applications. Users of applications which are not aware of 326 the 'geo' scheme are likely unable to make direct use of the 327 information in the URI. However, the simple structure of the 'geo' 328 URI would even allow manual dereference by users. 330 Poorly authored 'geo' URI instances could contain whitespace and 331 values with leading plus signs ("+"), which is not allowed according 332 to the ABNF. Clients SHOULD, however, try to dereference such URIs 333 after removing such whitespace and plus signs. 335 This specification does not define any URI parameters nor a query 336 component. Future revisions might define such parameters, using the 337 ";" and "?" characters to delimit parameter and query components from 338 the path component specified above. Clients MUST be prepared to 339 encounter such 'geo' URI instances, and MUST reduce the URI to the 340 components specified in Section 4.3 before they dereference the URI. 342 4.8. Security Considerations 344 See Section 9 of [insert reference to this document] 346 4.9. Contact 348 Christian Spanring (mailto:cspanring@gmail.at, http://spanring.eu/ ), 349 Alexander Mayrhofer (mailto:alexander.mayrhofer@nic.at, 350 http://timatio.com/ ) 352 4.10. Author/Change controller 354 The 'geo' URI scheme is registered under the IETF part of the URI 355 tree. As such, change control is up to the IETF. 357 4.11. References 359 RFC XXXX [change to RFC number once assigned] 361 5. URI Operations 363 Currently, just one operation on a 'geo' URI is defined - location 364 dereference: In that operation, a client dereferences the URI by 365 extracting the geographical coordinates from the URI path component 366 ('geo-path' in the ABNF). Further use of those coordinates is then 367 up to the application processing the URI, and might depend on the 368 context of the URI. 370 An application may then use this location information for various 371 purposes, for example: 373 o A web browser could use that information to open a web mapping 374 service of the user's choice, and display a map of the location 376 o A navigational device such as a Global Positioning System (GPS) 377 receiver could offer the user to start navigation to the location. 379 6. Use Cases and Examples 381 6.1. Plain 'geo' URI Example 383 The following 3-dimensional 'geo' URI example references to the 384 office location of one of the authors in Vienna, Austria: 386 geo:48.2010,16.3695,183 388 A user could type the data extracted from this URI into a electronic 389 navigation device, or even use it to locate the identified location 390 on a paper map. 392 6.2. Hyperlink 394 'geo' URIs (like any other URI scheme) could also be embedded as 395 hyperlinks in web pages. A Hyper Text Markup Language (HTML) snippet 396 with such a hyperlink could look like: 398
one of Vienna's popular sights is the Karlskirche.
401 A web brower could extract the coordinates from the HTML snippet, and
402 offer the user various options (based on configuration, context), for
403 example:
405 o display a small map thumbnail when the mouse pointer hovers over
406 the link
408 o switch to a mapping service of the user's choice once the link is
409 selected
411 o Locate nearby resources, for example by comparing the 'geo' URI
412 with locations extracted from GeoRSS feeds the user has subscribed
413 to.
415 o Convert the coordinates to a format suitable for uploading to a
416 navigation device
418 6.3. 'geo' URI in 2-dimensional barcode
420 Due to it's short length, a 'geo' URI could easily be encoded in
421 2-dimensional barcodes. Such barcodes could be printed on business
422 cards, flyers, paper maps and subsequently used by mobile devices,
423 for example as follows:
425 1. User identifies such a barcode on a flyer, uses the camera on his
426 mobile phone to photograph and decode the barcode
428 2. The mobile phone dereferences the 'geo' URI, and offers the user
429 to calculate a navigation route to the identified location.
431 3. Using the builtin GPS, the user follows the navgiation
432 instructions from his phone to reach the destination
434 7. GML Mappings
436 The Geographic Markup Language (GML) by the Open Geospatial
437 Consortium (OGC) is a set of XML schemas to represent geographical
438 features. Since GML is widely accepted, this document includes
439 instructions on how to transpose 'geo' URIs from and to GML
440 documents.
442 A 'geo' URI can be authored from a GML "point", and any 'geo' URI can
443 be mapped to a GML "point". For the following sections, "%lat%",
444 "%lon%" and "%alt%" are placeholders for latitude, longitude, and
445 altitude values. Mappings are defined as follows:
447 7.1. 'geo' URI without altitude to GML 'Point'
449 An instance of the 'geo' URI without the altitude element is mapped
450 to a two-dimensional GML "Point" as follows:
452 'geo' URI:
454 geo:%lat%,%lon%
456 GML document:
458
459