idnits 2.17.1 draft-ietf-geopriv-geo-uri-01.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 (July 03, 2009) is 5411 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3261' is defined on line 683, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV -- Geographic A. Mayrhofer 3 Location/Privacy Working Group nic.at 4 Internet-Draft C. Spanring 5 Expires: January 4, 2010 OIR-ID 6 July 03, 2009 8 A Uniform Resource Identifier for Geographic Locations ('geo' URI) 9 draft-ietf-geopriv-geo-uri-01 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on January 4, 2010. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 This document specifies an Uniform Resource Identifier (URI) for 58 geographic locations using the 'geo' scheme name. A 'geo' URI 59 identifies a physical location in a two- or three-dimensional 60 coordinate reference system in a compact, simple, human-readable, and 61 protocol independent way. The default coordinate reference system 62 used is WGS-84. 64 Table of Contents 66 1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 4. IANA Registration of 'geo' URI Scheme . . . . . . . . . . . . 7 73 4.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . . 7 74 4.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 4.3. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 7 76 4.4. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 9 77 4.4.1. Coordinate Reference System Identification . . . . . . 9 78 4.4.2. Component Description for WGS-84 . . . . . . . . . . . 9 79 4.4.3. URI Comparison . . . . . . . . . . . . . . . . . . . . 10 80 4.4.4. Interpretation of Undefined Altitude . . . . . . . . . 10 81 4.5. Encoding Considerations . . . . . . . . . . . . . . . . . 10 82 4.6. Applications/protocols That Use This URI Scheme . . . . . 11 83 4.7. Interopability Considerations . . . . . . . . . . . . . . 11 84 4.8. Security Considerations . . . . . . . . . . . . . . . . . 11 85 4.9. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 4.10. Author/Change controller . . . . . . . . . . . . . . . . . 12 87 4.11. References . . . . . . . . . . . . . . . . . . . . . . . . 12 89 5. URI Operations . . . . . . . . . . . . . . . . . . . . . . . . 12 91 6. Use Cases and Examples . . . . . . . . . . . . . . . . . . . . 12 92 6.1. Plain 'geo' URI Example . . . . . . . . . . . . . . . . . 12 93 6.2. Hyperlink . . . . . . . . . . . . . . . . . . . . . . . . 12 94 6.3. 'geo' URI in 2-dimensional barcode . . . . . . . . . . . . 13 96 7. GML Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 13 97 7.1. 'geo' URI without altitude to GML 'Point' . . . . . . . . 14 98 7.2. 'geo' URI with Altitude to GML 'Point' . . . . . . . . . . 14 99 7.3. GML 'Point' without Altitude to 'geo' URI . . . . . . . . 14 100 7.4. GML 'Point' with Altitude to 'geo' URI . . . . . . . . . . 15 102 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 104 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 105 9.1. Invalid Locations . . . . . . . . . . . . . . . . . . . . 16 106 9.2. Location Privacy . . . . . . . . . . . . . . . . . . . . . 16 108 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 110 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 111 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 112 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 116 1. Change Log 118 [Note to editors: This section is to be removed before publication - 119 XML source available on request] 121 draft-ietf-geopriv-geo-uri-01 122 o added parameters to ABNF 123 o added optional 'crs' parameter to allow future use of other CRSes 124 o Many other changes to not preclude the future specification of 125 other CRSes. 126 o some typos fixes - credits Bill McQuillan 128 draft-ietf-geopriv-geo-uri-00 129 o submitted as WG item 130 o changed IPR text because of text used from RFC 4395 131 o added considerations for comparing +180/-180 longitude URIs 132 o some editorial changes 134 draft-mayrhofer-geopriv-geo-uri-01 135 o added terminology text about WGS-84 (credits Carl Reed) 136 o removed "resolution" / "uncertainty" text 137 o added considerations regarding poles 138 o added text about invalid URIs 140 draft-mayrhofer-geopriv-geo-uri-00 141 o Initial version under new name, reverting to "plain" lat/lon 142 scheme, with the "tiling" scheme moved to seperate draft 143 (potentially published as "draft-mayrhofer-geopriv-geotile-uri"). 144 refer to draft-mayrhofer-geo-uri-01 for the history of this 145 document. 146 o Added GML mapping section 148 draft-mayrhofer-geo-uri-01 149 o removed parameters 151 draft-mayrhofer-geo-uri-00 152 o initial draft 154 2. Introduction 156 An increasing number of Internet protocols and data formats are 157 extended by specifications for adding spatial (geographic) location. 158 In most cases, latitude as well as longitude of simple points are 159 added as new attributes to existing data structures. However, all 160 those methods are very specific to a certain data format or protocol, 161 and don't provide a protocol independent, compact and generic way to 162 refer to a physical geographic location. 164 Over the past few years, fast emerging location aware applications 165 and location based services were observable on the Internet. Most 166 web search engines use geographic information, and a vivid open 167 source mapping community brought an enormous momentum into location 168 aware technology. A wide range and former to professionals exclusive 169 tools and data were provided free of charge for an everyday use on 170 the mass market. 172 The 'geo' URI scheme is another step into that direction and aims to 173 facilitate, support and standardize the problem of location 174 identification in geospatial services and applications. Accessing 175 information about or trigger further services based on a particular 176 place on earth shouldn't be any harder for users than clicking on a 177 'mailto:' link and write an email straight away. 179 According to [RFC3986], a Uniform Resource Identifier (URI) is "a 180 compact sequence of characters that identifies an abstract or 181 physical resource". The 'geo' URI scheme defined in this document 182 identifies geographic locations (a physical resource) in a coordinate 183 references system (CRS), per default in World Geodetic System 1984 184 (WGS-84) [WGS84]. The optional "crs" URI parameter described below 185 may be used by future specifications to define the use of other 186 CRSes. However, such definitions are out of scope of this document. 188 'Geo' URIs identify a geographic location using a textual 189 representation of the location's spatial coordinates in either two or 190 three dimensions (latitude, longitude, and optionally altitude for 191 the default CRS of WGS-84). Such URIs are independent from a 192 specific protocol, application, or data format, and can be used in 193 any other protocol or data format that supports inclusion of 194 arbitrary URIs. 196 For the sake of usability, the definition of the URI scheme is 197 strictly focused on the simplest, but also most common representation 198 of a spatial location - a single point. The provision of more 199 complex geometries or locations described by civic addresses is out 200 of scope of this document. 202 Note: The choice of WGS-84 as the default CRS is based on the 203 widespread availability of Global Positioning System (GPS) devices, 204 which use the WGS-84 reference system. It is anticipated that such 205 devices serve as one of the primary data sources for authoring 'geo' 206 URIs, hence the adoption of the native GPS reference system for the 207 URI scheme. Also, many other data formats for representing 208 geographic locations use the WGS-84 reference system, which makes 209 transposing from and to such data formats less error prone (no re- 210 projection involved). 212 3. Terminology 214 Geographic locations in this document are defined using WGS 84 (World 215 Geodetic System 1984), equivalent to the International Association of 216 Oil & Gas Producers (OGP) Surveying and Positioning Committee EPSG 217 (European Petroleum Survey Group) code 4326 (2 dimensions) and 4979 218 (3 dimensions). This document does not assign responsibilities for 219 coordinate transformations from and to other Spatial Reference 220 Systems. 222 A 2-dimensional WGS-84 coordinate value is here represented as a 223 comma-delimited latitude/longitude pair, measured in decimal degrees 224 (un-projected). A 3-dimensional WGS-84 coordinate value is here 225 represented by appending a comma-delimited altitude value in meters 226 to such pairs. 228 Latitudes range from -90 to 90 and longitudes range from -180 to 180. 229 Coordinates in the Southern and Western hemispheres as well as 230 altitudes below the WGS-84 reference geoid are signed negative with a 231 leading dash. 233 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 234 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 235 document are to be interpreted as described in RFC 2119 [RFC2119]. 237 4. IANA Registration of 'geo' URI Scheme 239 This section contains the fields required for the URI scheme 240 registration, following the guidelines in section 5.4 of [RFC4395]. 242 4.1. URI Scheme Name 244 geo 246 4.2. Status 248 permanent 250 4.3. URI Scheme Syntax 252 The syntax of the 'geo' URI scheme is specified below in Augmented 253 Backus-Naur Form (ABNF) [RFC4234]: 255 geo-URI = geo-scheme ":" geo-path 256 geo-scheme = "geo" 257 geo-path = coordinates *p 258 coordinates = coord-a "," coord-b [ "," coord-c ] 260 coord-a = num 261 coord-b = num 262 coord-c = num 264 p = crsp / parameter 265 crsp = ";crs=" crslabel 266 crslabel = "wgs84" 267 parameter = ";" pname [ "=" pvalue ] 268 pname = 1*( alphanum / '-' ) 269 pvalue = 1*paramchar 270 paramchar = p-unreserved / unreserved / pct-encoded 272 num = [ "-" ] 1*DIGIT [ "." 1*DIGIT ] 273 unreserved = alphanum / mark 274 mark = "-" / "_" / "." / "!" / "~" / "*" / 275 "'" / "(" / ")" 276 pct-encoded = "%" HEXDIG HEXDIG 277 p-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$" 278 alphanum = ALPHA / DIGIT 280 The optional "crs" parameter MUST NOT appear more than once. If 281 other parameters are also given, the "crs" parameter MUST be given 282 first. The definition of other parameters besides "crs" is out of 283 scope for this document. 285 Future documents proposing the use of other CRSes may update the 286 definition of the 'crslabel' component. 288 In case the URI identifies a location in the default CRS of WGS-84, 289 its sub-components are further restricted as follows: 291 coord-a = latitude 292 coord-b = longitude 293 coord-c = altitude 295 latitude = [ "-" ] 1*2DIGIT [ "." 1*DIGIT ] 296 longitude = [ "-" ] 1*3DIGIT [ "." 1*DIGIT ] 297 altitude = [ "-" ] 1*DIGIT [ "." 1*DIGIT ] 299 4.4. URI Scheme Semantics 301 Data contained in a 'geo' URI identifies a physical resource: A 302 spatial location on earth in the in a coordinate reference system, 303 identified by the geographic coordinates encoded in the URI. 305 4.4.1. Coordinate Reference System Identification 307 The semantics of the 'coordinates' component depends on the CRS of 308 the URI. The CRS itself is identified by the optional 'crs' 309 parameter the default. A URI instance uses the default WGS-84 CRS if 310 the 'crs' parameter is either missing, or contains the value of 311 'wgs84'. Other 'crs' values are not currently defined, but may be 312 specified by future documents. 314 Interpretation of coordinates in a wrong CRS produces invalid 315 location information. Consumers of 'geo' URIs therefore MUST NOT 316 ignore the 'crs' parameter if given, and MUST NOT attempt to 317 interpret the 'coordinates' component of given in an unknown CRS. 319 The following component description refers to the use of the default 320 CRS (WGS-84) only. Future documents specifying other 'crs' parameter 321 values MUST provide similar descriptions for the 'coordinates' sub- 322 components in the described CRS. 324 4.4.2. Component Description for WGS-84 326 The "latitude", "longitude" and "altitude" components as specified in 327 the URI scheme syntax ( Section 4.3) are to be used as follows: 328 o The "latitude" component MUST contain the latitude of the 329 identified location in decimal degrees in the reference system 330 WGS-84. 331 o The "longitude" component MUST contain the longitude of the 332 identified location in decimal degrees in the reference system 333 WGS-84. 334 o If present, the OPTIONAL "altitude" component MUST contain the 335 WGS-84 altitude of the identified location in meters. 337 If the altitude of the location is unknown, the "altitude" component 338 MUST NOT be present in the URI. Specifically, unknown altitude MUST 339 NOT be represented by setting the 'altitude' component to "0" (or any 340 other arbitrary value). 342 The "longitude" components of coordinate values reflecting the poles 343 (latitude set to -90 or 90 degrees) SHOULD be set to "0", although 344 consumers of "geo" URIs MUST accept such URIs with any longitude 345 value between -180 and 180. 347 'geo' URIs with longitude values outside the range of -180 to 180 348 decimal degrees or with latitude values outside the range of -90 to 349 90 degrees MUST be considered invalid. 351 4.4.3. URI Comparison 353 Two 'geo' URIs are equal when they use the same CRS, and their 354 'coord-a', 'coord-b' and 'coord-c' values are mathematically 355 identical. 357 Two 'geo' URIs use the same CRS if: 358 o their 'crslabel' components are identical 359 o or if neither URIs contain a 'crs' parameter (in which case both 360 URIs use WGS-84) 361 o or if one URI contains a 'crslabel' value of 'wgs84', while the 362 other URI does not contain a 'crs' parameter (which means that 363 both URIs use the WGS-84 reference system as well, with one of the 364 URIs specifying the CRS explicitely) 366 For the default CRS of WGS-84, the following definitions apply 367 additionally: 368 o Where the 'latitude' component of a 'geo' URI is set to either 90 369 or -90 degrees, the 'longitude' component MUST be ignored in 370 comparison operations. 371 o A 'longitude' component of 180 degrees MUST be considered equal a 372 'longitude' component of -180 degrees for the purpose of URI 373 comparison. 375 An URI with undefined (missing) 'coord-c' (altitude) value MUST NOT 376 be considered equal to an URI containing an 'coord-c' value, even if 377 the remaining values 'coord-a' and 'coord-b' are equivalent. 379 4.4.4. Interpretation of Undefined Altitude 381 A consumer of a 'geo' URI in the WGS-84 CRS with undefined 'altitude' 382 MAY assume that the URI refers to the respective location on earth's 383 physical surface at the given 'latitude' and 'longitude' coordinate. 385 However, as defined above, altitudes are relative to the WGS-84 386 reference geoid rather than earth's surface. Hence, an altitude 387 value of 0 MUST NOT be interpreted as "on earth's surface". 389 4.5. Encoding Considerations 391 The 'coordinates' path component of the 'geo' URI (see Section 4.3) 392 uses a comma (",") as a delimiter for subcomponents. This delimiter 393 MUST NOT be percent encoded. 395 It is RECOMMENDED that for readability the contents of 'coord-a', 396 'coord-b' and 'coord-c' subcomponents are never percent encoded. 398 4.6. Applications/protocols That Use This URI Scheme 400 As many other URI scheme definitions, the 'geo' URI provides resource 401 identification independent of a specific application or protocol. 402 Examples of potential protocol mappings and use cases can be found in 403 Section 6. 405 4.7. Interopability Considerations 407 As with any other new URI scheme, the 'geo' URI requires support in 408 client applications. Users of applications which are not aware of 409 the 'geo' scheme are likely unable to make direct use of the 410 information in the URI. However, the simple structure of the 'geo' 411 URI would even allow manual dereference by users. 413 Poorly authored 'geo' URI instances could contain whitespace and 414 values with leading plus signs ("+"), which is not allowed according 415 to the ABNF. Clients SHOULD, however, try to dereference such URIs 416 after removing such whitespace and plus signs. 418 This specification does not define a query component. Future 419 revisions might define such components, using the "?" character to 420 delimit query components from the path component specified above. 421 Clients MUST be prepared to encounter such 'geo' URI instances, and 422 MUST reduce the URI to the components specified in Section 4.3 before 423 they dereference the URI. 425 Clients MUST NOT attempt to dereference URIs given in an CRS that is 426 unknown to the client, because doing so would produce entirely bogus 427 results. 429 Authors of 'geo' URIs should carefully check that coordinate 430 components are set in the specified order, since wrong order of those 431 components is a commonly observed mistake and produces completely 432 bogus locations. 434 4.8. Security Considerations 436 See Section 9 of [insert reference to this document] 438 4.9. Contact 440 Christian Spanring (mailto:cspanring@gmail.at, http://spanring.eu/ ), 441 Alexander Mayrhofer (mailto:alexander.mayrhofer@nic.at, 442 http://timatio.com/ ) 444 4.10. Author/Change controller 446 The 'geo' URI scheme is registered under the IETF part of the URI 447 tree. As such, change control is up to the IETF. 449 4.11. References 451 RFC XXXX [change to RFC number once assigned] 453 5. URI Operations 455 Currently, just one operation on a 'geo' URI is defined - location 456 dereference: In that operation, a client dereferences the URI by 457 extracting the geographical coordinates from the URI path component 458 ('geo-path' in the ABNF). Further use of those coordinates is then 459 up to the application processing the URI, and might depend on the 460 context of the URI. 462 An application may then use this location information for various 463 purposes, for example: 465 o A web browser could use that information to open a web mapping 466 service of the user's choice, and display a map of the location 468 o A navigational device such as a Global Positioning System (GPS) 469 receiver could offer the user to start navigation to the location. 471 6. Use Cases and Examples 473 6.1. Plain 'geo' URI Example 475 The following 3-dimensional 'geo' URI example references to the 476 office location of one of the authors in Vienna, Austria: 478 geo:48.2010,16.3695,183 480 A user could type the data extracted from this URI into a electronic 481 navigation device, or even use it to locate the identified location 482 on a paper map. 484 6.2. Hyperlink 486 'geo' URIs (like any other URI scheme) could also be embedded as 487 hyperlinks in web pages. A Hyper Text Markup Language (HTML) snippet 488 with such a hyperlink could look like: 490

one of Vienna's popular sights is the Karlskirche. 493 A web brower could extract the coordinates from the HTML snippet, and 494 offer the user various options (based on configuration, context), for 495 example: 497 o display a small map thumbnail when the mouse pointer hovers over 498 the link 500 o switch to a mapping service of the user's choice once the link is 501 selected 503 o Locate nearby resources, for example by comparing the 'geo' URI 504 with locations extracted from GeoRSS feeds the user has subscribed 505 to. 507 o Convert the coordinates to a format suitable for uploading to a 508 navigation device 510 Note that the URI in this example also makes use of the explicit 511 specification of the CRS by using the 'crs' URI parameter. 513 6.3. 'geo' URI in 2-dimensional barcode 515 Due to it's short length, a 'geo' URI could easily be encoded in 516 2-dimensional barcodes. Such barcodes could be printed on business 517 cards, flyers, paper maps and subsequently used by mobile devices, 518 for example as follows: 520 1. User identifies such a barcode on a flyer, uses the camera on his 521 mobile phone to photograph and decode the barcode 523 2. The mobile phone dereferences the 'geo' URI, and offers the user 524 to calculate a navigation route to the identified location. 526 3. Using the builtin GPS, the user follows the navgiation 527 instructions from his phone to reach the destination 529 7. GML Mappings 531 The Geographic Markup Language (GML) by the Open Geospatial 532 Consortium (OGC) is a set of XML schemas to represent geographical 533 features. Since GML is widely accepted, this document includes 534 instructions on how to transpose 'geo' URIs from and to GML 535 documents. 537 A 'geo' URI can be mapped from a GML "point", and any 'geo' URI can 538 be mapped to a GML "point" (given that both support the CRS used). 539 For the following sections, "%lat%", "%lon%" and "%alt%" are 540 placeholders for latitude, longitude, and altitude values. Mappings 541 are defined as follows: 543 7.1. 'geo' URI without altitude to GML 'Point' 545 An instance of a WGS 84 'geo' URI without the altitude element is 546 mapped to a two-dimensional GML "Point" as follows: 548 'geo' URI: 550 geo:%lat%,%lon% 552 GML document: 554 555 558 %lat% %lon% 559 561 7.2. 'geo' URI with Altitude to GML 'Point' 563 A WGS 84 'geo' URI instance with the altitude element is mapped to a 564 three-dimensional GML "Point" as follows: 566 'geo' URI: 568 geo:%lat%,%lon%,%alt% 570 GML document: 572 573 576 %lat% %lon% %alt% 577 579 7.3. GML 'Point' without Altitude to 'geo' URI 581 A GML 'Point' in the reference system identified as 582 "urn:ogc:def:crs:EPSG:6.6:4326" is mapped to a 'geo' URI as follows: 584 GML document: 586 587 590 %lat% %lon% 591 593 'geo' URI: 595 geo:%lat%,%lon% 597 Note: GML documents in other reference systems MAY be used as well if 598 a transformation into "urn:ogc:def:crs:EPSG:6.6:4326" is defined and 599 applied before the mapping step. 601 7.4. GML 'Point' with Altitude to 'geo' URI 603 A GML 'Point' in the reference system identified as 604 "urn:ogc:def:crs:EPSG:6.6:4979" is mapped to a 'geo' URI as follows: 606 GML document: 608 609 612 %lat% %lon% %alt% 613 615 'geo' URI: 617 geo:%lat%,%lon%,%alt% 619 Note: GML 'Point' instances in other reference systems could be used 620 as well if a transformation into "urn:ogc:def:crs:EPSG:6.6:4979" is 621 defined and applied before the mapping step. It should be noted that 622 such reprojections are typically not lossless because of the limited 623 accuracy of the mathematical calculations involved. 625 8. IANA Considerations 627 This document requests assignment of the 'geo' URI scheme in the IETF 628 part of the URI scheme tree, according to the guidelines in BCP 115 629 (RFC 4395) [RFC4395]. The definitions required for the assignment 630 are contained in Section 4. 632 9. Security Considerations 634 Because the 'geo' URI is not tied to any specific protocol, and 635 identifies a physical location rather than a network resource, most 636 of the general security considerations on URIs (Section 7 of RFC 637 3986) do not apply. However, the following (additional) issues 638 apply: 640 9.1. Invalid Locations 642 The URI syntax (Section 4.3) makes it possible to construct valid 643 'geo' URIs which don't identify a valid location on earth. 644 Applications MUST NOT use URIs which such invalid values, and SHOULD 645 warn the user when such URIs are encountered. 647 An example of such an invalid URI would be (latitude 648 "beyond" north pole). 650 9.2. Location Privacy 652 Location information about individuals is an extremely sensitive 653 topic, especially when location is combined with Personally 654 Identifyable Information (PII). Authors of 'geo' URIs MUST consider 655 data protection and privacy before publishing such URIs. 657 However, it should be noted that a 'geo' URI by itself is just opaque 658 location information, and privacy considerations typically arise only 659 when such opaque location information is put in context by combining 660 it with other information (for example, embedding it within a message 661 to reflect the current location of a person). 663 10. Acknowledgements 665 The authors wish to acknowledge the helpful contributions from Carl 666 Reed, Bill McQuillan, Martin Kofal, Andrew Turner, Kim Sanders and 667 Ted Hardie. 669 11. References 671 11.1. Normative References 673 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 674 Resource Identifier (URI): Generic Syntax", STD 66, 675 RFC 3986, January 2005. 677 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 678 Requirement Levels", BCP 14, RFC 2119, March 1997. 680 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 681 Specifications: ABNF", RFC 4234, October 2005. 683 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 684 A., Peterson, J., Sparks, R., Handley, M., and E. 685 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 686 June 2002. 688 11.2. Informative References 690 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 691 Registration Procedures for New URI Schemes", BCP 115, 692 RFC 4395, February 2006. 694 [WGS84] National Imagery and Mapping Agency, "Department of 695 Defense World Geodetic System 1984, Third Edition", 696 NIMA TR8350.2, January 2000. 698 Authors' Addresses 700 Alexander Mayrhofer 701 nic.at GmbH 702 Karlsplatz 1/9 703 Wien A-1010 704 Austria 706 Phone: +43 1 5056416 34 707 Email: alexander.mayrhofer@nic.at 708 URI: http://www.nic.at/ 710 Christian Spanring 711 OIR-ID GmbH 712 Franz-Josefs-Kai 27 713 Wien A-1010 715 Phone: +43 1 5338747 36 716 Email: cspanring@gmail.com 717 URI: http://www.oir.at/