idnits 2.17.1 draft-ietf-geopriv-geo-uri-07.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 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 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 (April 14, 2010) is 5119 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) == Missing Reference: 'RFCxxxx' is mentioned on line 872, but not defined -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 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 IPCom 4 Internet-Draft C. Spanring 5 Intended status: Standards Track April 14, 2010 6 Expires: October 16, 2010 8 A Uniform Resource Identifier for Geographic Locations ('geo' URI) 9 draft-ietf-geopriv-geo-uri-07 11 Abstract 13 This document specifies a Uniform Resource Identifier (URI) for 14 geographic locations using the 'geo' scheme name. A 'geo' URI 15 identifies a physical location in a two- or three-dimensional 16 coordinate reference system in a compact, simple, human-readable, and 17 protocol-independent way. The default coordinate reference system 18 used is WGS-84. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on October 16, 2010. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. IANA Registration of 'geo' URI Scheme . . . . . . . . . . . . 6 71 3.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . . 6 72 3.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.3. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 6 74 3.4. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 7 75 3.4.1. Coordinate Reference System Identification . . . . . . 7 76 3.4.2. Component Description for WGS-84 . . . . . . . . . . . 8 77 3.4.3. Location Uncertainty . . . . . . . . . . . . . . . . . 8 78 3.4.4. URI Comparison . . . . . . . . . . . . . . . . . . . . 9 79 3.4.5. Interpretation of Undefined Altitude . . . . . . . . . 10 80 3.5. Encoding Considerations . . . . . . . . . . . . . . . . . 10 81 3.6. Applications/Protocols that use this URI Scheme . . . . . 10 82 3.7. Interopability Considerations . . . . . . . . . . . . . . 11 83 3.8. Security Considerations . . . . . . . . . . . . . . . . . 11 84 3.9. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 3.10. Author/Change controller . . . . . . . . . . . . . . . . . 11 86 3.11. References . . . . . . . . . . . . . . . . . . . . . . . . 11 88 4. 'geo' URI Parameters Registry . . . . . . . . . . . . . . . . 11 90 5. URI Operations . . . . . . . . . . . . . . . . . . . . . . . . 12 92 6. Use Cases and Examples . . . . . . . . . . . . . . . . . . . . 13 93 6.1. Plain 'geo' URI Example . . . . . . . . . . . . . . . . . 13 94 6.2. Hyperlink . . . . . . . . . . . . . . . . . . . . . . . . 13 95 6.3. 'geo' URI in 2-dimensional barcode . . . . . . . . . . . . 14 96 6.4. Comparison Examples . . . . . . . . . . . . . . . . . . . 15 98 7. GML Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 15 99 7.1. 2D GML 'Point' . . . . . . . . . . . . . . . . . . . . . . 16 100 7.2. 3D GML 'Point' . . . . . . . . . . . . . . . . . . . . . . 16 101 7.3. GML 'Circle' . . . . . . . . . . . . . . . . . . . . . . . 17 102 7.4. GML 'Sphere' . . . . . . . . . . . . . . . . . . . . . . . 17 104 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 105 8.1. 'geo' URI Scheme . . . . . . . . . . . . . . . . . . . . . 18 106 8.2. URI Parameter Registry . . . . . . . . . . . . . . . . . . 18 107 8.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 18 108 8.2.2. Registration Policy . . . . . . . . . . . . . . . . . 19 109 8.3. Sub-Registry for 'crs' Parameter . . . . . . . . . . . . . 19 110 8.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 19 111 8.3.2. Registration Policy . . . . . . . . . . . . . . . . . 20 113 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 114 9.1. Invalid Locations . . . . . . . . . . . . . . . . . . . . 20 115 9.2. Location Privacy . . . . . . . . . . . . . . . . . . . . . 20 117 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 119 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 120 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 121 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 123 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 22 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 127 1. Introduction 129 An increasing number of Internet protocols and data formats are 130 extended by specifications for adding spatial (geographic) location. 131 In most cases, latitude as well as longitude of simple points are 132 added as new attributes to existing data structures. However, all 133 those methods are very specific to a certain data format or protocol, 134 and don't provide a protocol-independent, compact and generic way to 135 refer to a physical geographic location. 137 Location-aware applications and location-based services are fast 138 emerging on the Internet. Most web search engines use geographic 139 information, and a vivid open source mapping community has brought an 140 enormous momentum into location aware technology. A wide range of 141 tools and data sets which formerly were accessible to professionals 142 only have became available to a wider audience. 144 The 'geo' URI scheme is another step into that direction and aims to 145 facilitate, support and standardize the problem of location 146 identification in geospatial services and applications. Accessing 147 information about a particular location or triggering further 148 services shouldn't be any harder than clicking on a 'mailto:' link 149 and writing an email straight away. 151 According to [RFC3986], a Uniform Resource Identifier (URI) is "a 152 compact sequence of characters that identifies an abstract or 153 physical resource". The 'geo' URI scheme defined in this document 154 identifies geographic locations (physical resources) in a coordinate 155 reference system (CRS), per default the World Geodetic System 1984 156 (WGS-84) [WGS84]. The scheme provides the textual representation of 157 the location's spatial coordinates in either two or three dimensions 158 (latitude, longitude, and optionally altitude for the default CRS of 159 WGS-84). An example of such an 'geo' URI follows: 161 geo:13.4125,103.8667 163 Such URIs are independent from a specific protocol, application, or 164 data format, and can be used in any other protocol or data format 165 that supports inclusion of arbitrary URIs. 167 For the sake of usability, the definition of the URI scheme is 168 strictly focused on the simplest, but also most common representation 169 of a spatial location - a single point in a well known CRS. The 170 provision of more complex geometries or locations described by civic 171 addresses is out of scope of this document. 173 The optional 'crs' URI parameter described below may be used by 174 future specifications to define the use of CRSes other than WGS-84. 176 This is primarily intended to cope with the case of another CRS 177 replacing WGS-84 as the predominantly used one, rather than allowing 178 the arbitrary use of thousands of CRSes for the URI (which would 179 clearly affect interopability). The definition of 'crs' values 180 beyond the default of "wgs84" is therefore out of scope of this 181 document. 183 This spec discourages use of alternate CRSes in use cases where 184 comparison is an important function. 186 Note: The choice of WGS-84 as the default CRS is based on the 187 widespread availability of Global Positioning System (GPS) devices, 188 which use the WGS-84 reference system. It is anticipated that such 189 devices will serve as one of the primary data sources for authoring 190 'geo' URIs, hence the adoption of the native GPS reference system for 191 the URI scheme. Also, many other data formats for representing 192 geographic locations use the WGS-84 reference system, which makes 193 transposing from and to such data formats less error prone (no re- 194 projection involved). It is also believed that the burden of 195 potentially required spatial transformations should be put on the 196 author rather then the consumer of 'geo' URI instances. 198 2. Terminology 200 Geographic locations in this document are defined using WGS-84 (World 201 Geodetic System 1984), equivalent to the International Association of 202 Oil & Gas Producers (OGP) Surveying and Positioning Committee EPSG 203 (European Petroleum Survey Group) code 4326 (2 dimensions) and 4979 204 (3 dimensions). This document does not assign responsibilities for 205 coordinate transformations from and to other Spatial Reference 206 Systems. 208 A 2-dimensional WGS-84 coordinate value is represented here as a 209 comma-delimited latitude/longitude pair, measured in decimal degrees 210 (un-projected). A 3-dimensional WGS-84 coordinate value is 211 represented here by appending a comma-delimited altitude value in 212 meters to such pairs. 214 Latitudes range from -90 to 90 and longitudes range from -180 to 180. 215 Coordinates in the Southern and Western hemispheres as well as 216 altitudes below the WGS-84 reference geoid are signed negative with a 217 leading dash. 219 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 220 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 221 document are to be interpreted as described in RFC 2119 [RFC2119]. 223 3. IANA Registration of 'geo' URI Scheme 225 This section contains the fields required for the URI scheme 226 registration, following the guidelines in section 5.4 of [RFC4395]. 228 3.1. URI Scheme Name 230 geo 232 3.2. Status 234 permanent 236 3.3. URI Scheme Syntax 238 The syntax of the 'geo' URI scheme is specified below in Augmented 239 Backus-Naur Form (ABNF) [RFC5234]: 241 geo-URI = geo-scheme ":" geo-path 242 geo-scheme = "geo" 243 geo-path = coordinates p 244 coordinates = coord-a "," coord-b [ "," coord-c ] 246 coord-a = num 247 coord-b = num 248 coord-c = num 250 p = [ crsp ] [ uncp ] *parameter 251 crsp = ";crs=" crslabel 252 crslabel = "wgs84" / labeltext 253 uncp = ";u=" uval 254 uval = pnum 255 parameter = ";" pname [ "=" pvalue ] 256 pname = labeltext 257 pvalue = 1*paramchar 258 paramchar = p-unreserved / unreserved / pct-encoded 260 labeltext = 1*( alphanum / "-" ) 261 pnum = 1*DIGIT [ "." 1*DIGIT ] 262 num = [ "-" ] pnum 263 unreserved = alphanum / mark 264 mark = "-" / "_" / "." / "!" / "~" / "*" / 265 "'" / "(" / ")" 266 pct-encoded = "%" HEXDIG HEXDIG 267 p-unreserved = "[" / "]" / ":" / "&" / "+" / "$" 268 alphanum = ALPHA / DIGIT 270 Parameter names are case insensitive, use of the lowercase 271 representation is PREFERRED. Case sensitivity of non-numeric 272 parameter values MUST be described in the specification of the 273 respective parameter. For the 'crs' parameter, values are case 274 insensitive, and lowercase is PREFERRED. 276 Both 'crs' and 'u' parameters MUST NOT appear more than once each. 277 The 'crs' and 'u' parameters MUST be given before any other 278 parameters that may be defined in future extensions. The 'crs' 279 parameter MUST be given first if both 'crs' and 'u' are used. The 280 definition of other parameters, and values beyond the 281 default value of "wgs84" is out of scope of this document. 282 Section 8.2 discusses the IANA registration of such additional 283 parameters and values. 285 The value of "-0" for is allowed, and identical to "0". 287 In case the URI identifies a location in the default CRS of WGS-84, 288 the sub-components are further restricted as follows: 290 coord-a = latitude 291 coord-b = longitude 292 coord-c = altitude 294 latitude = [ "-" ] 1*2DIGIT [ "." 1*DIGIT ] 295 longitude = [ "-" ] 1*3DIGIT [ "." 1*DIGIT ] 296 altitude = [ "-" ] 1*DIGIT [ "." 1*DIGIT ] 298 3.4. URI Scheme Semantics 300 Data contained in a 'geo' URI identifies a physical resource: a 301 spatial location identified by the geographic coordinates and the CRS 302 encoded in the URI. 304 3.4.1. Coordinate Reference System Identification 306 The semantics of depends on the CRS of the URI. The 307 CRS itself is identified by the optional 'crs' parameter. A URI 308 instance uses the default WGS-84 CRS if the 'crs' parameter is either 309 missing or contains the value of 'wgs84'. Other values 310 are currently not defined, but may be specified by future documents. 312 Interpretation of coordinates in the wrong CRS produces invalid 313 location information. Consumers of 'geo' URIs therefore MUST NOT 314 ignore the 'crs' parameter if given, and MUST NOT interpret the 315 sub-components without considering and understanding 316 the 'crs' parameter value. 318 The following component description refers to the use of the default 319 CRS (WGS-84) only. Future documents specifying other 'crs' parameter 320 values MUST provide similar descriptions for the sub- 321 components in the described CRS. 323 3.4.2. Component Description for WGS-84 325 The , and components as specified in 326 the URI scheme syntax (Section 3.3) are to be used as follows: 328 o MUST contain the latitude of the identified location in 329 decimal degrees in the reference system WGS-84. 330 o MUST contain the longitude of the identified location 331 in decimal degrees in the reference system WGS-84. 332 o If present, the OPTIONAL MUST contain the altitude of 333 the identified location in meters in the reference system WGS-84. 335 If the altitude of the location is unknown, (and the comma 336 before) MUST NOT be present in the URI. Specifically, unknown 337 altitude MUST NOT be represented by setting to "0" (or any 338 other arbitrary value). 340 The of coordinate values reflecting the poles ( 341 set to -90 or 90 degrees) SHOULD be set to "0", although consumers of 342 'geo' URIs MUST accept such URIs with any longitude value from -180 343 to 180. 345 'geo' URIs with longitude values outside the range of -180 to 180 346 decimal degrees or with latitude values outside the range of -90 to 347 90 degrees MUST be considered invalid. 349 3.4.3. Location Uncertainty 351 The 'u' ("uncertainty") parameter indicates the amount of uncertainty 352 in the location as a value in meters. Where a 'geo' URI is used to 353 identify the location of a particular object, indicates the 354 uncertainty with which the identified location of the subject is 355 known. 357 The 'u' parameter is optional and it can appear only once. If it is 358 not specified, this indicates that uncertainty is unknown or 359 unspecified. If the intent is to indicate a specific point in space, 360 MAY be set to zero. Zero uncertainty and absent uncertainty 361 are never the same thing. 363 The single uncertainty value is applied to all dimensions given in 364 the URI. 366 Note: The number of digits of the values in MUST NOT be 367 interpreted as an indication to uncertainty. 369 3.4.4. URI Comparison 371 Comparison of URIs intends to determine whether two URI strings are 372 equivalent and identify the same resource (rather than comparing the 373 resources themselves). Therefore, a comparison of two 'geo' URIs 374 does not compare spatial objects, but only the strings (URIs) 375 identifying those objects. 377 The term "mathematically identical" used below specifies that some 378 components of the URI MUST be compared as normalized numbers rather 379 than strings to account for the variety in string representations of 380 identical numbers (for example, the strings "43.10" and "43.1" are 381 different, but represent the same number). 383 Two 'geo' URIs are equal only if they fulfill all of the following 384 general comparison rules: 386 o Both URIs use the same CRS, which means that either both have the 387 'crs' parameter omitted, or both have the same value, 388 or one has the 'crs' parameter omitted while the other URI 389 specifies the default CRS explicitely with a value of 390 "wgs84". 391 o Their , , and 'u' values are 392 mathematically identical (including absent meaning 393 undefined 'u' value). 394 o Their sets of other parameters are equal, with comparison 395 operations applied on each parameter as described in its 396 respective specification. 398 Parameter order is not significant for URI comparison. 400 Since new parameters may be registered over time, legacy 401 implementations of the 'geo' URI might encounter unknown parameters. 402 In such cases, the following rules apply: 404 o Two 'geo' URIs with unknown parameters are equivalent only if the 405 same set of unknown parameter names appears in each URI, and their 406 values are bitwise identical after percent-decoding. 407 o Otherwise, the comparison operation for the respective URIs is 408 undefined (since the legacy implementation is not be aware of the 409 comparison rules for those parameters). 411 Designers of future extension parameters should take this into 412 account when choosing the comparison rules for new parameters. 414 A URI with undefined (missing) (altitude) value MUST NOT be 415 considered equal to a URI containing a , even if the 416 remaining , , and their 'u' values are equivalent. 418 For the default CRS of WGS-84, the following comparison rules apply 419 additionally: 421 o Where of a 'geo' URI is set to either 90 or -90 422 degrees, MUST be ignored in comparison operations 423 ("poles case"). 424 o A of 180 degrees MUST be considered equal to 425 of -180 degrees for the purpose of URI comparison 426 ("date line" case). 428 3.4.5. Interpretation of Undefined Altitude 430 A consumer of a 'geo' URI in the WGS-84 CRS with undefined 431 MAY assume that the URI refers to the respective location on Earth's 432 physical surface at the given latitude and longitude. 434 However, as defined above, altitudes are relative to the WGS-84 435 reference geoid rather than Earth's surface. Hence, an 436 value of 0 MUST NOT be mistaken to refer to "ground elevation". 438 3.5. Encoding Considerations 440 The path component of the 'geo' URI (see Section 3.3) 441 uses a comma (",") as the delimiter for subcomponents. This 442 delimiter MUST NOT be percent-encoded. 444 It is RECOMMENDED that for readability the contents of , 445 and as well as and are never 446 percent-encoded. 448 Regarding internationalization, the currently specified components do 449 allow for ASCII characters exclusively, and therefore don't require 450 internationalization. Future specifications of additional parameters 451 might allow the introduction of non-ASCII values. Such 452 specifications MUST describe internationalization considerations for 453 those parameters and their values, and MUST require percent-encoding 454 of non-ASCII values. 456 3.6. Applications/Protocols that use this URI Scheme 458 As many other URI scheme definitions, the 'geo' URI provides resource 459 identification independent of a specific application or protocol. 460 Examples of potential protocol mappings and use cases can be found in 461 Section 6. 463 3.7. Interopability Considerations 465 Like other new URI schemes, the 'geo' URI requires support in client 466 applications. Users of applications which are not aware of the 'geo' 467 scheme are likely not able to make direct use of the information in 468 the URI. However, a client can make indirect use by passing around 469 'geo' URIs even without understanding the format and semantics of the 470 scheme. Additionally, the simple structure of 'geo' URIs would allow 471 even manual dereference by humans. 473 Clients MUST NOT attempt to dereference 'geo' URIs given in an CRS 474 that is unknown to the client, because doing so would produce 475 entirely bogus results. 477 Authors of 'geo' URIs should carefully check that coordinate 478 components are set in the right CRS and in the specified order, since 479 wrong order of those components (or use of coordinates in a different 480 CRS without transformation) are commonly observed mistakes producing 481 completely bogus locations. 483 The number of digits in the values MUST NOT be 484 interpreted as an indication to a certain level of accuracy or 485 uncertainty. 487 3.8. Security Considerations 489 See Section 9 of [insert reference to this document] 491 3.9. Contact 493 Alexander Mayrhofer , 494 Christian Spanring 496 3.10. Author/Change controller 498 The 'geo' URI scheme is registered under the IETF part of the URI 499 tree. As such, change control is up to the IETF. 501 3.11. References 503 RFC XXXX [change to RFC number once assigned] 505 4. 'geo' URI Parameters Registry 507 This specification creates a new IANA Registry named "'geo' URI 508 Parameters Registry" for the component of the URI. 509 Parameters for the 'geo' URI and values for these parameters MUST be 510 registered with IANA to prevent namespace collisions, and provide 511 interopability. 513 Some parameters accept values that are constrained by a syntax 514 definition only, while others accept values from a predefined set 515 only. Some parameters might not accept any values at all ("flag" 516 type parameters). 518 The registration of values is REQUIRED for parameters that accept 519 values from a predefined set. 521 The specification of a parameter MUST fully explain the syntax, 522 intended usage and semantics of the parameter. This ensures 523 interopability between independent implementations. 525 For parameters that are neither restricted to a set of predefined 526 values nor of the "flag" type described above, the syntax of allowed 527 values MUST be described in the specification, for example by using 528 ABNF. 530 Documents defining new parameters (or new values for existing 531 parameters) MUST register them with IANA, as explained in 532 Section 8.2. 534 The 'geo' URI Parameter Registry contains a column named "Value 535 Restriction" that describes whether or not a parameter accepts a 536 value, and whether values are restricted to a predefined set. That 537 column accepts the following values: 539 o "No value": The parameter does not accept any values, and is to be 540 used as a "flag" only. 541 o "Predefined": The parameter does accept values from a predefined 542 set only, as specified in a RFC or other permanent and readily 543 available public specification. 544 o "Constrained": The parameter accepts arbitrary values that are 545 only constrained by a syntax as specified in a RFC or other 546 permanent and readily available public specification. 548 Section 8.2.1 contains the initial contents of the Registry. 550 5. URI Operations 552 Currently, just one operation on a 'geo' URI is defined - location 553 dereference: In that operation, a client dereferences the URI by 554 extracting the geographical coordinates from the URI path component 555 . Further use of those coordinates (and the uncertainty 556 value from ) is then up to the application processing the URI, 557 and might depend on the context of the URI. 559 An application may then use this location information for various 560 purposes, for example: 562 o A web browser could use that information to open a mapping service 563 of the user's choice, and display a map of the location. 565 o A navigational device such as a Global Positioning System (GPS) 566 receiver could offer the user to start navigation to the location. 568 Note that the examples and use cases aboves as well as in the next 569 section are non-normative, and provided for information only. 571 6. Use Cases and Examples 573 6.1. Plain 'geo' URI Example 575 The following 3-dimensional 'geo' URI example references to the 576 office location of one of the authors in Vienna, Austria: 578 geo:48.2010,16.3695,183 580 Resolution of the URI returns the following information: 582 o The 'crs' parameter is not given in the URI, which means that the 583 URI uses the default CRS of WGS-84. 584 o The URI includes , is hence 3-dimensional, and therefore 585 uses 'urn:ogc:def:crs:EPSG::4979' as the WGS-84 CRS identifier. 586 o The value (latitude in WGS-84) is set to '48.2010' 587 decimal degrees. 588 o The value (longitude in WGS-84) is set to '16.3695' 589 decimal degrees. 590 o The value (altitude in WGS-84) is set to 183 meters. 591 o Uncertainty is undefined. 593 A user could type the data extracted from this URI into a electronic 594 navigation device, or even use it to locate the identified location 595 on a paper map. 597 6.2. Hyperlink 599 'geo' URIs (like any other URI scheme) could also be embedded as 600 hyperlinks in web pages. A Hyper Text Markup Language (HTML) snippet 601 with such a hyperlink could look like: 603

one of Vienna's popular sights is the 604 Karlskirche. 606 Resolution of the URI returns the following information: 608 o The 'crs' is given in the URI, and sets the CRS used in the URI to 609 WGS-84 explicitely. 610 o The URI does omit , is hence 2-dimensional, and therefore 611 uses 'urn:ogc:def:crs:EPSG::4326' as the WGS-84 CRS identifier. 612 o The value (latitude in WGS-84) is set to '48.198634' 613 decimal degrees. 614 o The value (longitude in WGS-84) is set to '16.371648' 615 decimal degrees. 616 o The (altitude) value is undefined, hence the client MAY 617 assume the identified location to be on Earth's physical surface. 618 o The 'u' parameter is included in the URI, setting uncertainty to 619 40 meters. 621 A web browser could use this information from the HTML snippet, and 622 offer the user various options (based on configuration, context), for 623 example: 625 o Display a small map thumbnail when the mouse pointer hovers over 626 the link. 628 o Switch to a mapping service of the user's choice once the link is 629 selected. 631 o Locate nearby resources, for example by comparing the 'geo' URI 632 with locations extracted from GeoRSS feeds the user has subscribed 633 to. 635 o Convert the coordinates to a format suitable for uploading to a 636 navigation device. 638 Note that the URI in this example also makes use of the explicit 639 specification of the CRS by using the 'crs' parameter. 641 6.3. 'geo' URI in 2-dimensional barcode 643 Due to it's short length, a 'geo' URI could easily be encoded in 644 2-dimensional barcodes. Such barcodes could be printed on business 645 cards, flyers, paper maps and subsequently used by mobile devices, 646 for example as follows: 648 1. User identifies such a barcode on a flyer and uses the camera on 649 his mobile phone to photograph and decode the barcode. 651 2. The mobile phone dereferences the 'geo' URI, and offers the user 652 to calculate a navigation route to the identified location. 654 3. Using the builtin GPS receiver, the user follows the navgiation 655 instructions to reach the location. 657 6.4. Comparison Examples 659 This section provides examples of URI comparison. Note that the 660 unknown parameters 'foo' and 'bar' and unregistered 'crs' values in 661 this section are used for illustrative purposes only, and their 662 inclusion in the examples below does not constitute any formal 663 parameter definition or registration request. 665 o The two URIs and are equal, 666 because both use the same CRS, and even though the longitude 667 values are different, both reflect a location on the north pole 668 (special "poles" rule for WGS-84 applies - longitude is to be 669 ignored). Note that the 'crs' parameter values are case 670 insensitive. 671 o The URIs and are equal, 672 because their coordinate components are mathematically identical 673 o The set of and are identical, because the value of 675 the unknown parameter 'foo' is bitwise identical after percent- 676 decoding, parameter names are case insensitive, and coordinates 677 and uncertainty are mathematically identical. 678 o The comparison operation on and 679 in a legacy implementation is 680 undefined, because the normalization rules for 'foo' are not 681 known, and hence the implementation cannot identify whether or not 682 '1.00' is identical to '1' for the 'foo' parameter. 683 o Comparing and returns true, because parameter order is 685 insignificant in comparison operations 686 o The comparison operation on and is undefined, because even though parameter names 688 are case insensitive, this is not neccessarily the case for the 689 values of the unknown 'bar' parameter. 691 7. GML Mappings 693 The Geographic Markup Language (GML) by the Open Geospatial 694 Consortium (OGC) is a set of XML schemas to represent geographical 695 features. Since GML is widely accepted, this document includes 696 instructions on how to transform 'geo' URIs from and to GML 697 fragments. The instructions in this section are not normative. 699 For the following sections, "%lat%", "%lon%", "%alt%" and "%unc%" are 700 placeholders for latitude, longitude, altitude and uncertainty 701 values, respectively. The mappings use WGS-84, and are defined in 702 the following sections. 704 Note: GML fragments in other reference systems could be used as well 705 if a transformation into "urn:ogc:def:crs:EPSG::4979" or 706 "urn:ogc:def:crs:EPSG::4326" is defined and applied before the 707 mapping step. Such transformations are typically not lossless. 709 GML uses the 'double' type from XML schema, and the mapping examples 710 assume that numbers in the form of "3.32435e2" in GML are properly 711 converted to fixed point when placed into the 'geo' URI. 713 7.1. 2D GML 'Point' 715 A 2D GML 'Point' [RFC5491] is constructed from a 'geo' URI that has 716 two coordinates and an uncertainty ('u') parameter that is absent or 717 zero. A GML point is always converted to a 'geo' URI that has no 718 uncertainty parameter. 720 'geo' URI: 722 geo:%lat%,%lon% 724 GML fragment: 726 728 %lat% %lon% 729 731 Note that a 'geo' URI with an uncertainty value of zero is converted 732 to a GML 'Point', but a GML 'Point' cannot be translated to a 'geo' 733 URI with zero uncertainty. 735 7.2. 3D GML 'Point' 737 A 3D GML 'Point' [RFC5491] is constructed from a 'geo' URI that has 738 three coordinates and an uncertainty parameter that is absent or 739 zero. A GML point is always converted to a 'geo' URI that has no 740 uncertainty parameter. 742 'geo' URI: 744 geo:%lat%,%lon%,%alt% 746 GML fragment: 748 750 %lat% %lon% %alt% 751 753 7.3. GML 'Circle' 755 A GML 'Circle' [RFC5491] is constructed from a 'geo' URI that has two 756 coordinates and an uncertainty parameter that is present and non- 757 zero. 759 'geo' URI: 761 geo:%lat%,%lon%;u=%unc% 763 GML fragment: 765 768 %lat% %lon% 769 770 %unc% 771 772 774 7.4. GML 'Sphere' 776 A GML 'sphere' [RFC5491] is constructed from a 'geo' URI that has 777 three coordinates and an uncertainty parameter that is present and 778 non-zero. 780 'geo' URI: 782 geo:%lat%,%lon%,%alt%;u=%unc% 784 GML fragment: 786 789 %lat% %lon% %alt% 790 791 %unc% 792 793 795 8. IANA Considerations 797 8.1. 'geo' URI Scheme 799 This document requests assignment of the 'geo' URI scheme in the IETF 800 part of the URI scheme tree, according to the guidelines in BCP 115 801 (RFC 4395) [RFC4395]. The definitions required for the assignment 802 are contained in Section 3. 804 8.2. URI Parameter Registry 806 This document creates a new IANA Registry named "'geo' URI 807 Parameters", according to the information in Section 4 and the 808 definition in this section. 810 8.2.1. Registry Contents 812 When registering a new 'geo' URI Parameter, the following information 813 MUST be provided: 815 o Name of the Parameter. 816 o Whether the Parameter accepts no value ("No value"), values from a 817 predefined set ("Predefined"), or values constrained by a syntax 818 only ("Constrained"). 819 o Reference to the RFC or other permanent and readily available 820 public specification defining the parameters and the new values. 822 Unless specific instructions exists for a Parameter (like the 823 definition of a Sub-registry), the following information MUST be 824 provided when registering new values for existing "Predefined" 'geo' 825 URI Parameters: 827 o Name of the Parameter. 828 o Reference to the RFC or other permanent and readily available 829 public specification defining the new values. 831 The following table provides the initial values for this registry: 833 Parameter Name Value Restriction Reference(s) 834 ---------------------------------------------------------- 835 crs Predefined [RFCxxxx] 836 u Constrained [RFCxxxx] 838 [Note to RFC Editor: Replace RFCxxxx with reference to this document] 840 8.2.2. Registration Policy 842 The Registration Policy for 'geo' URI Parameters and their value 843 definitions shall be "Specification Required" (which implies 844 "Designated Expert"), as defined in [RFC5226]. 846 8.3. Sub-Registry for 'crs' Parameter 848 This document creates a new IANA Sub-registry named "'geo' URI 'crs' 849 Parameter Values", based on the Registry specified in Section 8.2 and 850 the information in this section and Section 4. The syntax of the 851 'crs' parameter is constrained by the ABNF given in Section 3.3. 853 8.3.1. Registry Contents 855 When registering a new value for the 'crs' parameter, the following 856 information MUST be provided: 858 o Value of the parameter. 859 o Reference to the RFC or other permanent and readily available 860 public specification defining the use of the CRS in the scope of 861 the 'geo' URI. The specification should contain information that 862 is similar to the WGS-84-specific text given in this document. 863 o Reference to the definition document of the CRS. If a URN is 864 assigned to the CRS, the use of such URN as reference is 865 preferred. Note that different URNs may exist for the 866 2-dimensional and 3-dimensional case. 868 The following table provides the initial values for this registry: 870 crs Value Reference(s) CRS definition(s) 871 ----------------------------------------------------------- 872 wgs84 [RFCxxxx] urn:ogc:def:crs:EPSG::4326 873 urn:ogc:def:crs:EPSG::4979 875 [Note to RFC Editor: Replace RFCxxxx with reference to this document] 877 8.3.2. Registration Policy 879 The registration policy for the "'geo' URI 'crs' Parameter Values" 880 Registry shall require both "Specification Required" and "IESG 881 Approval" as defined in [RFC5226]. 883 Section 1 contains some text about the motivation when to introduce 884 new 'crs' values. 886 9. Security Considerations 888 Because the 'geo' URI is not tied to any specific protocol and 889 identifies a physical location rather than a network resource, most 890 of the general security considerations on URIs (Section 7 of RFC 891 3986) do not apply. However, the following (additional) issues 892 apply: 894 9.1. Invalid Locations 896 The URI syntax (Section 3.3) makes it possible to construct 'geo' 897 URIs which don't identify a valid location. Applications MUST NOT 898 use URIs with such values, and SHOULD warn the user when such URIs 899 are encountered. 901 An example of such an URI referring to an invalid location would be 902 (latitude "beyond" north pole). 904 9.2. Location Privacy 906 A 'geo' URI by itself is just an opaque reference to a physical 907 location, expressed by a set of spatial coordinates. This does not 908 fit the "Location Information" definition according to Section 5.2 of 909 GEOPRIV Requirements [RFC3693], because there is not necessarily a 910 "Device" involved. 912 Because there is also no way to specify the identity of a "Target" 913 within the confines of a 'geo' URI, it also does not fit the 914 specification of an "Location Object" (Section 5.2 of RFC 3693). 916 However, if a 'geo' URI is used in a context where it identifies the 917 location of a Target, it becomes part of a Location Object and is 918 therefore subject to GEOPRIV rules. 920 Therefore, when 'geo' URIs are put into such contexts, the privacy 921 requirements of RFC 3693 MUST be met. 923 10. Acknowledgements 925 Martin Thomson has provided significant text around the definition of 926 the "uncertainty" parameter and the GML mappings. 928 The authors further wish to acknowledge the helpful contributions 929 from Carl Reed, Bill McQuillan, Martin Kofal, Andrew Turner, Kim 930 Sanders, Ted Hardie, Cullen Jennings, Klaus Darilion, Bjorn 931 Hoehrmann, Alissa Cooper and Ivan Shmakov. 933 Alfred Hoenes has provided an extremely helpful in-depth review of 934 the document. 936 11. References 938 11.1. Normative References 940 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 941 Resource Identifier (URI): Generic Syntax", STD 66, 942 RFC 3986, January 2005. 944 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 945 Requirement Levels", BCP 14, RFC 2119, March 1997. 947 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 948 Specifications: ABNF", STD 68, RFC 5234, January 2008. 950 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 951 Presence Information Data Format Location Object (PIDF-LO) 952 Usage Clarification, Considerations, and Recommendations", 953 RFC 5491, March 2009. 955 11.2. Informative References 957 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 958 Registration Procedures for New URI Schemes", BCP 35, 959 RFC 4395, February 2006. 961 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 962 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 963 May 2008. 965 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 966 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 968 [WGS84] National Imagery and Mapping Agency, "Department of 969 Defense World Geodetic System 1984, Third Edition", 970 NIMA TR8350.2, January 2000. 972 Appendix A. Change Log 974 [Note to editors: This section is to be removed before publication - 975 XML source available on request] 977 draft-ietf-geopriv-geo-uri-07 978 o Additonal text in URI comparison explaining what is being compared 979 o fixed typo in comparison example 981 draft-ietf-geopriv-geo-uri-06 982 o Addressed remaining IESG evaluation comments: 983 o comparison rules for unknown parameters 984 o extended examples 986 draft-ietf-geopriv-geo-uri-05 987 o Addressed IESG evaluation comments (some) 989 draft-ietf-geopriv-geo-uri-04 990 o Added "crs" URI parameter registry 991 o Added example URI to Introduction 992 o Changed quoting of parameters according to Alfred Hoenes' comments 994 draft-ietf-geopriv-geo-uri-03 995 o Updated privacy considerations section as per Alissa's comments 996 o Added text on uncertainty applied to all given dimensions 997 o various editorial changes 998 o Changed ABNF to reflect order of parameters (CRS first, then U, 999 then others 1001 draft-ietf-geopriv-geo-uri-02 1002 o Added IANA registry for 'geo' URI Parameters and values 1003 o Moved change log to appendix 1004 o Added "u" parameter to ABNF, restructred ABNF slightly 1005 o Added new section describing uncertainty 1006 o Changed mapping examples, added some for uncertainty 1007 o Added text that number of digits shouldn't be confused with 1008 uncertainty or accuracy 1009 o marked GML mappings as non-normative based on URI expert review 1010 advice 1011 o added internationalization consideration section 1012 o various other changes based on Expert Review 1014 draft-ietf-geopriv-geo-uri-01 1015 o added parameters to ABNF 1016 o added optional 'crs' parameter to allow future use of other CRSes 1017 o Many other changes to not preclude the future specification of 1018 other CRSes. 1019 o some typos fixes - credits Bill McQuillan 1021 draft-ietf-geopriv-geo-uri-00 1022 o submitted as WG item 1023 o changed IPR text because of text used from RFC 4395 1024 o added considerations for comparing +180/-180 longitude URIs 1025 o some editorial changes 1027 draft-mayrhofer-geopriv-geo-uri-01 1028 o added terminology text about WGS-84 (credits Carl Reed) 1029 o removed "resolution" / "uncertainty" text 1030 o added considerations regarding poles 1031 o added text about invalid URIs 1033 draft-mayrhofer-geopriv-geo-uri-00 1034 o Initial version under new name, reverting to "plain" lat/lon 1035 scheme, with the "tiling" scheme moved to seperate draft 1036 (potentially published as "draft-mayrhofer-geopriv-geotile-uri"). 1037 refer to draft-mayrhofer-geo-uri-01 for the history of this 1038 document. 1039 o Added GML mapping section 1041 draft-mayrhofer-geo-uri-01 1042 o removed parameters 1044 draft-mayrhofer-geo-uri-00 1045 o initial draft 1047 Authors' Addresses 1049 Alexander Mayrhofer 1050 IPCom GmbH 1051 Karlsplatz 1/2/9 1052 Wien A-1010 1053 Austria 1055 Phone: +43 1 5056416 34 1056 Email: alexander.mayrhofer@ipcom.at 1057 URI: http://www.ipcom.at/ 1058 Christian Spanring 1059 30 Hancock St 1060 Somerville 02144 1062 Phone: +1 617 863 0360 1063 Email: christian@spanring.eu 1064 URI: http://www.spanring.eu/