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

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