idnits 2.17.1 draft-ietf-geopriv-geo-uri-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 (March 06, 2010) is 5158 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 783, 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: 1 error (**), 0 flaws (~~), 4 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 Expires: September 7, 2010 March 06, 2010 7 A Uniform Resource Identifier for Geographic Locations ('geo' URI) 8 draft-ietf-geopriv-geo-uri-05 10 Abstract 12 This document specifies a Uniform Resource Identifier (URI) for 13 geographic locations using the 'geo' scheme name. A 'geo' URI 14 identifies a physical location in a two- or three-dimensional 15 coordinate reference system in a compact, simple, human-readable, and 16 protocol-independent way. The default coordinate reference system 17 used is WGS-84. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on September 7, 2010. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 3. IANA Registration of 'geo' URI Scheme . . . . . . . . . . . . 6 76 3.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . . 6 77 3.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 3.3. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 6 79 3.4. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 7 80 3.4.1. Coordinate Reference System Identification . . . . . . 7 81 3.4.2. Component Description for WGS-84 . . . . . . . . . . . 8 82 3.4.3. Location Uncertainty . . . . . . . . . . . . . . . . . 8 83 3.4.4. URI Comparison . . . . . . . . . . . . . . . . . . . . 9 84 3.4.5. Interpretation of Undefined Altitude . . . . . . . . . 9 85 3.5. Encoding Considerations . . . . . . . . . . . . . . . . . 9 86 3.6. Applications/Protocols that use this URI Scheme . . . . . 10 87 3.7. Interopability Considerations . . . . . . . . . . . . . . 10 88 3.8. Security Considerations . . . . . . . . . . . . . . . . . 10 89 3.9. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 11 90 3.10. Author/Change controller . . . . . . . . . . . . . . . . . 11 91 3.11. References . . . . . . . . . . . . . . . . . . . . . . . . 11 93 4. 'geo' URI Parameters Registry . . . . . . . . . . . . . . . . 11 95 5. URI Operations . . . . . . . . . . . . . . . . . . . . . . . . 12 97 6. Use Cases and Examples . . . . . . . . . . . . . . . . . . . . 12 98 6.1. Plain 'geo' URI Example . . . . . . . . . . . . . . . . . 12 99 6.2. Hyperlink . . . . . . . . . . . . . . . . . . . . . . . . 13 100 6.3. 'geo' URI in 2-dimensional barcode . . . . . . . . . . . . 13 102 7. GML Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 14 103 7.1. 2D GML 'Point' . . . . . . . . . . . . . . . . . . . . . . 14 104 7.2. 3D GML 'Point' . . . . . . . . . . . . . . . . . . . . . . 14 105 7.3. GML 'Circle' . . . . . . . . . . . . . . . . . . . . . . . 15 106 7.4. GML 'Sphere' . . . . . . . . . . . . . . . . . . . . . . . 15 108 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 109 8.1. 'geo' URI Scheme . . . . . . . . . . . . . . . . . . . . . 16 110 8.2. URI Parameter Registry . . . . . . . . . . . . . . . . . . 16 111 8.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 16 112 8.2.2. Registration Policy . . . . . . . . . . . . . . . . . 17 113 8.3. Sub-Registry for 'crs' Parameter . . . . . . . . . . . . . 17 114 8.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 17 115 8.3.2. Registration Policy . . . . . . . . . . . . . . . . . 18 117 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 118 9.1. Invalid Locations . . . . . . . . . . . . . . . . . . . . 18 119 9.2. Location Privacy . . . . . . . . . . . . . . . . . . . . . 18 121 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 123 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 124 11.1. Normative References . . . . . . . . . . . . . . . . . . . 19 125 11.2. Informative References . . . . . . . . . . . . . . . . . . 19 127 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 20 129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 131 1. Introduction 133 An increasing number of Internet protocols and data formats are 134 extended by specifications for adding spatial (geographic) location. 135 In most cases, latitude as well as longitude of simple points are 136 added as new attributes to existing data structures. However, all 137 those methods are very specific to a certain data format or protocol, 138 and don't provide a protocol-independent, compact and generic way to 139 refer to a physical geographic location. 141 Location-aware applications and location-based services are fast 142 emerging on the Internet. Most web search engines use geographic 143 information, and a vivid open source mapping community has brought an 144 enormous momentum into location aware technology. A wide range of 145 tools and data sets which formerly were accessible to professionals 146 only have became available to a wider audience. 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 a particular location or triggering further 152 services shouldn't be any harder than clicking on a 'mailto:' link 153 and writing 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 (physical resources) in a coordinate 159 reference system (CRS), per default the World Geodetic System 1984 160 (WGS-84) [WGS84]. The scheme provides the textual representation of 161 the location's spatial coordinates in either two or three dimensions 162 (latitude, longitude, and optionally altitude for the default CRS of 163 WGS-84). An example of such an 'geo' URI follows: 165 geo:13.4125,103.8667 167 Such URIs are independent from a specific protocol, application, or 168 data format, and can be used in any other protocol or data format 169 that supports inclusion of arbitrary URIs. 171 For the sake of usability, the definition of the URI scheme is 172 strictly focused on the simplest, but also most common representation 173 of a spatial location - a single point in a well known CRS. The 174 provision of more complex geometries or locations described by civic 175 addresses is out of scope of this document. 177 The optional 'crs' URI parameter described below may be used by 178 future specifications to define the use of CRSes other than WGS-84. 180 This is primarily intended to cope with the case of another CRS 181 replacing WGS-84 as the predominantly used one, rather than allowing 182 the arbitrary use of thousands of CRSes for the URI (which would 183 clearly affect interopability). The definition of 'crs' values 184 beyond the default of "wgs84" is therefore out of scope of this 185 document. 187 This spec discourages use of alternate CRSes in use cases where 188 comparison is an important function. 190 Note: The choice of WGS-84 as the default CRS is based on the 191 widespread availability of Global Positioning System (GPS) devices, 192 which use the WGS-84 reference system. It is anticipated that such 193 devices will serve as one of the primary data sources for authoring 194 'geo' URIs, hence the adoption of the native GPS reference system for 195 the URI scheme. Also, many other data formats for representing 196 geographic locations use the WGS-84 reference system, which makes 197 transposing from and to such data formats less error prone (no re- 198 projection involved). It is also believed that the burden of 199 potentially required spatial transformations should be put on the 200 author rather then the consumer of 'geo' URI instances. 202 2. Terminology 204 Geographic locations in this document are defined using WGS-84 (World 205 Geodetic System 1984), equivalent to the International Association of 206 Oil & Gas Producers (OGP) Surveying and Positioning Committee EPSG 207 (European Petroleum Survey Group) code 4326 (2 dimensions) and 4979 208 (3 dimensions). This document does not assign responsibilities for 209 coordinate transformations from and to other Spatial Reference 210 Systems. 212 A 2-dimensional WGS-84 coordinate value is represented here as a 213 comma-delimited latitude/longitude pair, measured in decimal degrees 214 (un-projected). A 3-dimensional WGS-84 coordinate value is 215 represented here by appending a comma-delimited altitude value in 216 meters to such pairs. 218 Latitudes range from -90 to 90 and longitudes range from -180 to 180. 219 Coordinates in the Southern and Western hemispheres as well as 220 altitudes below the WGS-84 reference geoid are signed negative with a 221 leading dash. 223 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 224 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 225 document are to be interpreted as described in RFC 2119 [RFC2119]. 227 3. IANA Registration of 'geo' URI Scheme 229 This section contains the fields required for the URI scheme 230 registration, following the guidelines in section 5.4 of [RFC4395]. 232 3.1. URI Scheme Name 234 geo 236 3.2. Status 238 permanent 240 3.3. URI Scheme Syntax 242 The syntax of the 'geo' URI scheme is specified below in Augmented 243 Backus-Naur Form (ABNF) [RFC5234]: 245 geo-URI = geo-scheme ":" geo-path 246 geo-scheme = "geo" 247 geo-path = coordinates p 248 coordinates = coord-a "," coord-b [ "," coord-c ] 250 coord-a = num 251 coord-b = num 252 coord-c = num 254 p = [ crsp ] [ uncp ] *parameter 255 crsp = ";crs=" crslabel 256 crslabel = "wgs84" / labeltext 257 uncp = ";u=" uval 258 uval = pnum 259 parameter = ";" pname [ "=" pvalue ] 260 pname = labeltext 261 pvalue = 1*paramchar 262 paramchar = p-unreserved / unreserved / pct-encoded 264 labeltext = 1*( alphanum / "-" ) 265 pnum = 1*DIGIT [ "." 1*DIGIT ] 266 num = [ "-" ] pnum 267 unreserved = alphanum / mark 268 mark = "-" / "_" / "." / "!" / "~" / "*" / 269 "'" / "(" / ")" 270 pct-encoded = "%" HEXDIG HEXDIG 271 p-unreserved = "[" / "]" / ":" / "&" / "+" / "$" 272 alphanum = ALPHA / DIGIT 274 Parameter names are case insensitive, use of the lowercase 275 representation is PREFERRED. Case sensitivity of non-numeric 276 parameter values MUST be described in the specification of the 277 respective parameter. For the 'crs' parameter, values are case 278 insensitive, and lowercase is PREFERRED. 280 Both 'crs' and 'u' parameters MUST NOT appear more than once each. 281 The 'crs' and 'u' parameters MUST be given before any other 282 parameters that may be defined in future extensions. The 'crs' 283 parameter MUST be given first if both 'crs' and 'u' are used. The 284 definition of other parameters, and values beyond the 285 default value of "wgs84" is out of scope of this document. 286 Section 8.2 discusses the IANA registration of such additional 287 parameters and values. 289 The value of "-0" for is allowed, and identical to "0". 291 In case the URI identifies a location in the default CRS of WGS-84, 292 the sub-components are further restricted as follows: 294 coord-a = latitude 295 coord-b = longitude 296 coord-c = altitude 298 latitude = [ "-" ] 1*2DIGIT [ "." 1*DIGIT ] 299 longitude = [ "-" ] 1*3DIGIT [ "." 1*DIGIT ] 300 altitude = [ "-" ] 1*DIGIT [ "." 1*DIGIT ] 302 3.4. URI Scheme Semantics 304 Data contained in a 'geo' URI identifies a physical resource: a 305 spatial location identified by the geographic coordinates and the CRS 306 encoded in the URI. 308 3.4.1. Coordinate Reference System Identification 310 The semantics of depends on the CRS of the URI. The 311 CRS itself is identified by the optional 'crs' parameter. A URI 312 instance uses the default WGS-84 CRS if the 'crs' parameter is either 313 missing or contains the value of 'wgs84'. Other values 314 are currently not defined, but may be specified by future documents. 316 Interpretation of coordinates in the wrong CRS produces invalid 317 location information. Consumers of 'geo' URIs therefore MUST NOT 318 ignore the 'crs' parameter if given, and MUST NOT interpret the 319 sub-components without considering and understanding 320 the 'crs' parameter value. 322 The following component description refers to the use of the default 323 CRS (WGS-84) only. Future documents specifying other 'crs' parameter 324 values MUST provide similar descriptions for the sub- 325 components in the described CRS. 327 3.4.2. Component Description for WGS-84 329 The , and components as specified in 330 the URI scheme syntax (Section 3.3) are to be used as follows: 332 o MUST contain the latitude of the identified location in 333 decimal degrees in the reference system WGS-84. 334 o MUST contain the longitude of the identified location 335 in decimal degrees in the reference system WGS-84. 336 o If present, the OPTIONAL MUST contain the altitude of 337 the identified location in meters in the reference system WGS-84. 339 If the altitude of the location is unknown, (and the comma 340 before) MUST NOT be present in the URI. Specifically, unknown 341 altitude MUST NOT be represented by setting to "0" (or any 342 other arbitrary value). 344 The of coordinate values reflecting the poles ( 345 set to -90 or 90 degrees) SHOULD be set to "0", although consumers of 346 'geo' URIs MUST accept such URIs with any longitude value from -180 347 to 180. 349 'geo' URIs with longitude values outside the range of -180 to 180 350 decimal degrees or with latitude values outside the range of -90 to 351 90 degrees MUST be considered invalid. 353 3.4.3. Location Uncertainty 355 The 'u' ("uncertainty") parameter indicates the amount of uncertainty 356 in the location as a value in meters. Where a 'geo' URI is used to 357 identify the location of a particular object, indicates the 358 uncertainty with which the identified location of the subject is 359 known. 361 The 'u' parameter is optional and it can appear only once. If it is 362 not specified, this indicates that uncertainty is unknown or 363 unspecified. If the intent is to indicate a specific point in space, 364 MAY be set to zero. Zero uncertainty and absent uncertainty 365 are never the same thing. 367 The single uncertainty value is applied to all dimensions given in 368 the URI. 370 Note: The number of digits of the values in MUST NOT be 371 interpreted as an indication to uncertainty. 373 3.4.4. URI Comparison 375 Two 'geo' URIs are equal when they use the same CRS, and , 376 , and 'u' value are mathematically identical 377 (including absent meaning undefined 'u' value). 379 If other parameters are contained in the URIs, the comparison 380 operation MUST be extended as described in the specification of the 381 respective parameter. Unknown parameters MUST NOT be ignored. 383 Two URIs use the same CRS if both have the 'crs' parameter omitted, 384 or both have the same , or one has the 'crs' parameter 385 omitted while the other URI specifies the default CRS explicitely 386 with a value of "wgs84". 388 For the default CRS of WGS-84, the following definitions apply in 389 addition: 390 o Where of a 'geo' URI is set to either 90 or -90 391 degrees, MUST be ignored in comparison operations 392 ("poles case"). 393 o A of 180 degrees MUST be considered equal to 394 of -180 degrees for the purpose of URI comparison 395 ("date line" case). 397 A URI with undefined (missing) (altitude) value MUST NOT be 398 considered equal to a URI containing a , even if the 399 remaining , , and their 'u' values are equivalent. 401 3.4.5. Interpretation of Undefined Altitude 403 A consumer of a 'geo' URI in the WGS-84 CRS with undefined 404 MAY assume that the URI refers to the respective location on Earth's 405 physical surface at the given latitude and longitude. 407 However, as defined above, altitudes are relative to the WGS-84 408 reference geoid rather than Earth's surface. Hence, an 409 value of 0 MUST NOT be mistaken to refer to "ground elevation". 411 3.5. Encoding Considerations 413 The path component of the 'geo' URI (see Section 3.3) 414 uses a comma (",") as the delimiter for subcomponents. This 415 delimiter MUST NOT be percent-encoded. 417 It is RECOMMENDED that for readability the contents of , 418 and as well as and are never 419 percent-encoded. 421 Regarding internationalization, the currently specified components do 422 allow for ASCII characters exclusively, and therefore don't require 423 internationalization. Future specifications of additional parameters 424 might allow the introduction of non-ASCII values. Such 425 specifications MUST describe internationalization considerations for 426 those parameters and their values, and MUST require percent-encoding 427 of non-ASCII values. 429 3.6. Applications/Protocols that use this URI Scheme 431 As many other URI scheme definitions, the 'geo' URI provides resource 432 identification independent of a specific application or protocol. 433 Examples of potential protocol mappings and use cases can be found in 434 Section 6. 436 3.7. Interopability Considerations 438 Like other new URI schemes, the 'geo' URI requires support in client 439 applications. Users of applications which are not aware of the 'geo' 440 scheme are likely not able to make direct use of the information in 441 the URI. However, a client can make indirect use by passing around 442 'geo' URIs even without understanding the format and semantics of the 443 scheme. Additionally, the simple structure of 'geo' URIs would allow 444 even manual dereference by humans. 446 Clients MUST NOT attempt to dereference 'geo' URIs given in an CRS 447 that is unknown to the client, because doing so would produce 448 entirely bogus results. 450 Authors of 'geo' URIs should carefully check that coordinate 451 components are set in the right CRS and in the specified order, since 452 wrong order of those components (or use of coordinates in a different 453 CRS without transformation) are commonly observed mistakes producing 454 completely bogus locations. 456 The number of digits in the values MUST NOT be 457 interpreted as an indication to a certain level of accuracy or 458 uncertainty. 460 3.8. Security Considerations 462 See Section 9 of [insert reference to this document] 464 3.9. Contact 466 Alexander Mayrhofer , 467 Christian Spanring 469 3.10. Author/Change controller 471 The 'geo' URI scheme is registered under the IETF part of the URI 472 tree. As such, change control is up to the IETF. 474 3.11. References 476 RFC XXXX [change to RFC number once assigned] 478 4. 'geo' URI Parameters Registry 480 This specification creates a new IANA Registry named "'geo' URI 481 Parameters Registry" for the component of the URI. 482 Parameters for the 'geo' URI and values for these parameters MUST be 483 registered with IANA to prevent namespace collisions, and provide 484 interopability. 486 Some parameters accept values that are constrained by a syntax 487 definition only, while others accept values from a predefined set 488 only. Some parameters might not accept any values at all ("flag" 489 type parameters). 491 The registration of values is REQUIRED for parameters that accept 492 values from a predefined set. 494 The specification of a parameter MUST fully explain the syntax, 495 intended usage and semantics of the parameter. This ensures 496 interopability between independent implementations. 498 For parameters that are neither restricted to a set of predefined 499 values nor of the "flag" type described above, the syntax of allowed 500 values MUST be described in the specification, for example by using 501 ABNF. 503 Documents defining new parameters (or new values for existing 504 parameters) MUST register them with IANA, as explained in 505 Section 8.2. 507 The 'geo' URI Parameter Registry contains a column named "Value 508 Restriction" that describes whether or not a parameter accepts a 509 value, and whether values are restricted to a predefined set. That 510 column accepts the following values: 512 o "No value": The parameter does not accept any values, and is to be 513 used as a "flag" only. 514 o "Predefined": The parameter does accept values from a predefined 515 set only, as specified in a RFC or other permanent and readily 516 available public specification. 517 o "Constrained": The parameter accepts arbitrary values that are 518 only constrained by a syntax as specified in a RFC or other 519 permanent and readily available public specification. 521 Section 8.2.1 contains the initial contents of the Registry. 523 5. URI Operations 525 Currently, just one operation on a 'geo' URI is defined - location 526 dereference: In that operation, a client dereferences the URI by 527 extracting the geographical coordinates from the URI path component 528 . Further use of those coordinates (and the uncertainty 529 value from ) is then up to the application processing the URI, 530 and might depend on the context of the URI. 532 An application may then use this location information for various 533 purposes, for example: 535 o A web browser could use that information to open a mapping service 536 of the user's choice, and display a map of the location. 538 o A navigational device such as a Global Positioning System (GPS) 539 receiver could offer the user to start navigation to the location. 541 Note that the examples and use cases aboves as well as in the next 542 section are non-normative, and provided for information only. 544 6. Use Cases and Examples 546 6.1. Plain 'geo' URI Example 548 The following 3-dimensional 'geo' URI example references to the 549 office location of one of the authors in Vienna, Austria: 551 geo:48.2010,16.3695,183 553 A user could type the data extracted from this URI into a electronic 554 navigation device, or even use it to locate the identified location 555 on a paper map. 557 6.2. Hyperlink 559 'geo' URIs (like any other URI scheme) could also be embedded as 560 hyperlinks in web pages. A Hyper Text Markup Language (HTML) snippet 561 with such a hyperlink could look like: 563

one of Vienna's popular sights is the 564 Karlskirche. 566 A web browser could extract the coordinates from the HTML snippet and 567 offer the user various options (based on configuration, context), for 568 example: 570 o Display a small map thumbnail when the mouse pointer hovers over 571 the link. 573 o Switch to a mapping service of the user's choice once the link is 574 selected. 576 o Locate nearby resources, for example by comparing the 'geo' URI 577 with locations extracted from GeoRSS feeds the user has subscribed 578 to. 580 o Convert the coordinates to a format suitable for uploading to a 581 navigation device. 583 Note that the URI in this example also makes use of the explicit 584 specification of the CRS by using the 'crs' parameter. 586 6.3. 'geo' URI in 2-dimensional barcode 588 Due to it's short length, a 'geo' URI could easily be encoded in 589 2-dimensional barcodes. Such barcodes could be printed on business 590 cards, flyers, paper maps and subsequently used by mobile devices, 591 for example as follows: 593 1. User identifies such a barcode on a flyer and uses the camera on 594 his mobile phone to photograph and decode the barcode. 596 2. The mobile phone dereferences the 'geo' URI, and offers the user 597 to calculate a navigation route to the identified location. 599 3. Using the builtin GPS receiver, the user follows the navgiation 600 instructions to reach the location. 602 7. GML Mappings 604 The Geographic Markup Language (GML) by the Open Geospatial 605 Consortium (OGC) is a set of XML schemas to represent geographical 606 features. Since GML is widely accepted, this document includes 607 instructions on how to transform 'geo' URIs from and to GML 608 fragments. The instructions in this section are not normative. 610 For the following sections, "%lat%", "%lon%", "%alt%" and "%unc%" are 611 placeholders for latitude, longitude, altitude and uncertainty 612 values, respectively. The mappings use WGS-84, and are defined in 613 the following sections. 615 Note: GML fragments in other reference systems could be used as well 616 if a transformation into "urn:ogc:def:crs:EPSG::4979" or 617 "urn:ogc:def:crs:EPSG::4326" is defined and applied before the 618 mapping step. Such transformations are typically not lossless. 620 GML uses the 'double' type from XML schema, and the mapping examples 621 assume that numbers in the form of "3.32435e2" in GML are properly 622 converted to fixed point when placed into the 'geo' URI. 624 7.1. 2D GML 'Point' 626 A 2D GML 'Point' [RFC5491] is constructed from a 'geo' URI that has 627 two coordinates and an uncertainty ('u') parameter that is absent or 628 zero. A GML point is always converted to a 'geo' URI that has no 629 uncertainty parameter. 631 'geo' URI: 633 geo:%lat%,%lon% 635 GML fragment: 637 639 %lat% %lon% 640 642 Note that a 'geo' URI with an uncertainty value of zero is converted 643 to a GML 'Point', but a GML 'Point' cannot be translated to a 'geo' 644 URI with zero uncertainty. 646 7.2. 3D GML 'Point' 648 A 3D GML 'Point' [RFC5491] is constructed from a 'geo' URI that has 649 three coordinates and an uncertainty parameter that is absent or 650 zero. A GML point is always converted to a 'geo' URI that has no 651 uncertainty parameter. 653 'geo' URI: 655 geo:%lat%,%lon%,%alt% 657 GML fragment: 659 661 %lat% %lon% %alt% 662 664 7.3. GML 'Circle' 666 A GML 'Circle' [RFC5491] is constructed from a 'geo' URI that has two 667 coordinates and an uncertainty parameter that is present and non- 668 zero. 670 'geo' URI: 672 geo:%lat%,%lon%;u=%unc% 674 GML fragment: 676 679 %lat% %lon% 680 681 %unc% 682 683 685 7.4. GML 'Sphere' 687 A GML 'sphere' [RFC5491] is constructed from a 'geo' URI that has 688 three coordinates and an uncertainty parameter that is present and 689 non-zero. 691 'geo' URI: 693 geo:%lat%,%lon%,%alt%;u=%unc% 695 GML fragment: 697 700 %lat% %lon% %alt% 701 702 %unc% 703 704 706 8. IANA Considerations 708 8.1. 'geo' URI Scheme 710 This document requests assignment of the 'geo' URI scheme in the IETF 711 part of the URI scheme tree, according to the guidelines in BCP 115 712 (RFC 4395) [RFC4395]. The definitions required for the assignment 713 are contained in Section 3. 715 8.2. URI Parameter Registry 717 This document creates a new IANA Registry named "'geo' URI 718 Parameters", according to the information in Section 4 and the 719 definition in this section. 721 8.2.1. Registry Contents 723 When registering a new 'geo' URI Parameter, the following information 724 MUST be provided: 726 o Name of the Parameter. 727 o Whether the Parameter accepts no value ("No value"), values from a 728 predefined set ("Predefined"), or values constrained by a syntax 729 only ("Constrained"). 730 o Reference to the RFC or other permanent and readily available 731 public specification defining the parameters and the new values. 733 Unless specific instructions exists for a Parameter (like the 734 definition of a Sub-registry), the following information MUST be 735 provided when registering new values for existing "Predefined" 'geo' 736 URI Parameters: 738 o Name of the Parameter. 739 o Reference to the RFC or other permanent and readily available 740 public specification defining the new values. 742 The following table provides the initial values for this registry: 744 Parameter Name Value Restriction Reference(s) 745 ---------------------------------------------------------- 746 crs Predefined [RFCxxxx] 747 u Constrained [RFCxxxx] 749 [Note to RFC Editor: Replace RFCxxxx with reference to this document] 751 8.2.2. Registration Policy 753 The Registration Policy for 'geo' URI Parameters and their value 754 definitions shall be "Specification Required" (which implies 755 "Designated Expert"), as defined in [RFC5226]. 757 8.3. Sub-Registry for 'crs' Parameter 759 This document creates a new IANA Sub-registry named "'geo' URI 'crs' 760 Parameter Values", based on the Registry specified in Section 8.2 and 761 the information in this section and Section 4. The syntax of the 762 'crs' parameter is constrained by the ABNF given in Section 3.3. 764 8.3.1. Registry Contents 766 When registering a new value for the 'crs' parameter, the following 767 information MUST be provided: 769 o Value of the parameter. 770 o Reference to the RFC or other permanent and readily available 771 public specification defining the use of the CRS in the scope of 772 the 'geo' URI. The specification should contain information that 773 is similar to the WGS-84-specific text given in this document. 774 o Reference to the definition document of the CRS. If a URN is 775 assigned to the CRS, the use of such URN as reference is 776 preferred. Note that different URNs may exist for the 777 2-dimensional and 3-dimensional case. 779 The following table provides the initial values for this registry: 781 crs Value Reference(s) CRS definition(s) 782 ----------------------------------------------------------- 783 wgs84 [RFCxxxx] urn:ogc:def:crs:EPSG::4326 784 urn:ogc:def:crs:EPSG::4979 786 [Note to RFC Editor: Replace RFCxxxx with reference to this document] 788 8.3.2. Registration Policy 790 The registration policy for the "'geo' URI 'crs' Parameter Values" 791 Registry shall require both "Specification Required" and "IESG 792 Approval" as defined in [RFC5226]. 794 Section 1 contains some text about the motivation when to introduce 795 new 'crs' values. 797 9. Security Considerations 799 Because the 'geo' URI is not tied to any specific protocol and 800 identifies a physical location rather than a network resource, most 801 of the general security considerations on URIs (Section 7 of RFC 802 3986) do not apply. However, the following (additional) issues 803 apply: 805 9.1. Invalid Locations 807 The URI syntax (Section 3.3) makes it possible to construct 'geo' 808 URIs which don't identify a valid location. Applications MUST NOT 809 use URIs with such values, and SHOULD warn the user when such URIs 810 are encountered. 812 An example of such an URI referring to an invalid location would be 813 (latitude "beyond" north pole). 815 9.2. Location Privacy 817 A 'geo' URI by itself is just an opaque reference to a physical 818 location, expressed by a set of spatial coordinates. This does not 819 fit the "Location Information" definition according to Section 5.2 of 820 GEOPRIV Requirements [RFC3693], because there is not necessarily a 821 "Device" involved. 823 Because there is also no way to specify the identity of a "Target" 824 within the confines of a 'geo' URI, it also does not fit the 825 specification of an "Location Object" (Section 5.2 of RFC 3693). 827 However, if a 'geo' URI is used in a context where it identifies the 828 location of a Target, it becomes part of a Location Object and is 829 therefore subject to GEOPRIV rules. 831 Therefore, when 'geo' URIs are put into such contexts, the privacy 832 requirements of RFC 3693 MUST be met. 834 10. Acknowledgements 836 Martin Thomson has provided significant text around the definition of 837 the "uncertainty" parameter and the GML mappings. 839 The authors further wish to acknowledge the helpful contributions 840 from Carl Reed, Bill McQuillan, Martin Kofal, Andrew Turner, Kim 841 Sanders, Ted Hardie, Cullen Jennings, Klaus Darilion, Bjorn 842 Hoehrmann, Alissa Cooper and Ivan Shmakov. 844 Alfred Hoenes has provided an extremely helpful in-depth review of 845 the document. 847 11. References 849 11.1. Normative References 851 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 852 Resource Identifier (URI): Generic Syntax", STD 66, 853 RFC 3986, January 2005. 855 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 856 Requirement Levels", BCP 14, RFC 2119, March 1997. 858 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 859 Specifications: ABNF", STD 68, RFC 5234, January 2008. 861 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 862 Presence Information Data Format Location Object (PIDF-LO) 863 Usage Clarification, Considerations, and Recommendations", 864 RFC 5491, March 2009. 866 11.2. Informative References 868 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 869 Registration Procedures for New URI Schemes", BCP 35, 870 RFC 4395, February 2006. 872 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 873 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 874 May 2008. 876 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 877 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 879 [WGS84] National Imagery and Mapping Agency, "Department of 880 Defense World Geodetic System 1984, Third Edition", 881 NIMA TR8350.2, January 2000. 883 Appendix A. Change Log 885 [Note to editors: This section is to be removed before publication - 886 XML source available on request] 888 draft-ietf-geopriv-geo-uri-04 889 o Added "crs" URI parameter registry 890 o Added example URI to Introduction 891 o Changed quoting of parameters according to Alfred Hoenes' comments 893 draft-ietf-geopriv-geo-uri-03 894 o Updated privacy considerations section as per Alissa's comments 895 o Added text on uncertainty applied to all given dimensions 896 o various editorial changes 897 o Changed ABNF to reflect order of parameters (CRS first, then U, 898 then others 900 draft-ietf-geopriv-geo-uri-02 901 o Added IANA registry for 'geo' URI Parameters and values 902 o Moved change log to appendix 903 o Added "u" parameter to ABNF, restructred ABNF slightly 904 o Added new section describing uncertainty 905 o Changed mapping examples, added some for uncertainty 906 o Added text that number of digits shouldn't be confused with 907 uncertainty or accuracy 908 o marked GML mappings as non-normative based on URI expert review 909 advice 910 o added internationalization consideration section 911 o various other changes based on Expert Review 913 draft-ietf-geopriv-geo-uri-01 914 o added parameters to ABNF 915 o added optional 'crs' parameter to allow future use of other CRSes 916 o Many other changes to not preclude the future specification of 917 other CRSes. 918 o some typos fixes - credits Bill McQuillan 920 draft-ietf-geopriv-geo-uri-00 921 o submitted as WG item 922 o changed IPR text because of text used from RFC 4395 923 o added considerations for comparing +180/-180 longitude URIs 924 o some editorial changes 926 draft-mayrhofer-geopriv-geo-uri-01 927 o added terminology text about WGS-84 (credits Carl Reed) 928 o removed "resolution" / "uncertainty" text 929 o added considerations regarding poles 930 o added text about invalid URIs 932 draft-mayrhofer-geopriv-geo-uri-00 933 o Initial version under new name, reverting to "plain" lat/lon 934 scheme, with the "tiling" scheme moved to seperate draft 935 (potentially published as "draft-mayrhofer-geopriv-geotile-uri"). 936 refer to draft-mayrhofer-geo-uri-01 for the history of this 937 document. 938 o Added GML mapping section 940 draft-mayrhofer-geo-uri-01 941 o removed parameters 943 draft-mayrhofer-geo-uri-00 944 o initial draft 946 Authors' Addresses 948 Alexander Mayrhofer 949 IPCom GmbH 950 Karlsplatz 1/2/9 951 Wien A-1010 952 Austria 954 Phone: +43 1 5056416 34 955 Email: alexander.mayrhofer@nic.at 956 URI: http://www.ipcom.at/ 958 Christian Spanring 959 30 Hancock St 960 Somerville 02144 962 Phone: +1 617 863 0360 963 Email: christian@spanring.eu 964 URI: http://www.spanring.eu/