GEOPRIV -- Geographic A. Mayrhofer Location/Privacy Working Group IPCom Internet-Draft C. Spanring Expires: September 7, 2010 March 06, 2010 A Uniform Resource Identifier for Geographic Locations ('geo' URI) draft-ietf-geopriv-geo-uri-05 Abstract This document specifies a Uniform Resource Identifier (URI) for geographic locations using the 'geo' scheme name. A 'geo' URI identifies a physical location in a two- or three-dimensional coordinate reference system in a compact, simple, human-readable, and protocol-independent way. The default coordinate reference system used is WGS-84. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 7, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Mayrhofer & Spanring Expires September 7, 2010 [Page 1]
Internet-Draft 'geo' URI Scheme March 2010 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Mayrhofer & Spanring Expires September 7, 2010 [Page 2]
Internet-Draft 'geo' URI Scheme March 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. IANA Registration of 'geo' URI Scheme . . . . . . . . . . . . 6 3.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . . 6 3.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 6 3.4. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 7 3.4.1. Coordinate Reference System Identification . . . . . . 7 3.4.2. Component Description for WGS-84 . . . . . . . . . . . 8 3.4.3. Location Uncertainty . . . . . . . . . . . . . . . . . 8 3.4.4. URI Comparison . . . . . . . . . . . . . . . . . . . . 9 3.4.5. Interpretation of Undefined Altitude . . . . . . . . . 9 3.5. Encoding Considerations . . . . . . . . . . . . . . . . . 9 3.6. Applications/Protocols that use this URI Scheme . . . . . 10 3.7. Interopability Considerations . . . . . . . . . . . . . . 10 3.8. Security Considerations . . . . . . . . . . . . . . . . . 10 3.9. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.10. Author/Change controller . . . . . . . . . . . . . . . . . 11 3.11. References . . . . . . . . . . . . . . . . . . . . . . . . 11 4. 'geo' URI Parameters Registry . . . . . . . . . . . . . . . . 11 5. URI Operations . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Use Cases and Examples . . . . . . . . . . . . . . . . . . . . 12 6.1. Plain 'geo' URI Example . . . . . . . . . . . . . . . . . 12 6.2. Hyperlink . . . . . . . . . . . . . . . . . . . . . . . . 13 6.3. 'geo' URI in 2-dimensional barcode . . . . . . . . . . . . 13 7. GML Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. 2D GML 'Point' . . . . . . . . . . . . . . . . . . . . . . 14 7.2. 3D GML 'Point' . . . . . . . . . . . . . . . . . . . . . . 14 7.3. GML 'Circle' . . . . . . . . . . . . . . . . . . . . . . . 15 7.4. GML 'Sphere' . . . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8.1. 'geo' URI Scheme . . . . . . . . . . . . . . . . . . . . . 16 8.2. URI Parameter Registry . . . . . . . . . . . . . . . . . . 16 8.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 16 8.2.2. Registration Policy . . . . . . . . . . . . . . . . . 17 8.3. Sub-Registry for 'crs' Parameter . . . . . . . . . . . . . 17 8.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 17 8.3.2. Registration Policy . . . . . . . . . . . . . . . . . 18 Mayrhofer & Spanring Expires September 7, 2010 [Page 3]
Internet-Draft 'geo' URI Scheme March 2010 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9.1. Invalid Locations . . . . . . . . . . . . . . . . . . . . 18 9.2. Location Privacy . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . . 19 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Mayrhofer & Spanring Expires September 7, 2010 [Page 4]
Internet-Draft 'geo' URI Scheme March 2010 1. Introduction An increasing number of Internet protocols and data formats are extended by specifications for adding spatial (geographic) location. In most cases, latitude as well as longitude of simple points are added as new attributes to existing data structures. However, all those methods are very specific to a certain data format or protocol, and don't provide a protocol-independent, compact and generic way to refer to a physical geographic location. Location-aware applications and location-based services are fast emerging on the Internet. Most web search engines use geographic information, and a vivid open source mapping community has brought an enormous momentum into location aware technology. A wide range of tools and data sets which formerly were accessible to professionals only have became available to a wider audience. The 'geo' URI scheme is another step into that direction and aims to facilitate, support and standardize the problem of location identification in geospatial services and applications. Accessing information about a particular location or triggering further services shouldn't be any harder than clicking on a 'mailto:' link and writing an email straight away. According to [RFC3986], a Uniform Resource Identifier (URI) is "a compact sequence of characters that identifies an abstract or physical resource". The 'geo' URI scheme defined in this document identifies geographic locations (physical resources) in a coordinate reference system (CRS), per default the World Geodetic System 1984 (WGS-84) [WGS84]. The scheme provides the textual representation of the location's spatial coordinates in either two or three dimensions (latitude, longitude, and optionally altitude for the default CRS of WGS-84). An example of such an 'geo' URI follows: geo:13.4125,103.8667 Such URIs are independent from a specific protocol, application, or data format, and can be used in any other protocol or data format that supports inclusion of arbitrary URIs. For the sake of usability, the definition of the URI scheme is strictly focused on the simplest, but also most common representation of a spatial location - a single point in a well known CRS. The provision of more complex geometries or locations described by civic addresses is out of scope of this document. The optional 'crs' URI parameter described below may be used by future specifications to define the use of CRSes other than WGS-84. Mayrhofer & Spanring Expires September 7, 2010 [Page 5]
Internet-Draft 'geo' URI Scheme March 2010 This is primarily intended to cope with the case of another CRS replacing WGS-84 as the predominantly used one, rather than allowing the arbitrary use of thousands of CRSes for the URI (which would clearly affect interopability). The definition of 'crs' values beyond the default of "wgs84" is therefore out of scope of this document. This spec discourages use of alternate CRSes in use cases where comparison is an important function. Note: The choice of WGS-84 as the default CRS is based on the widespread availability of Global Positioning System (GPS) devices, which use the WGS-84 reference system. It is anticipated that such devices will serve as one of the primary data sources for authoring 'geo' URIs, hence the adoption of the native GPS reference system for the URI scheme. Also, many other data formats for representing geographic locations use the WGS-84 reference system, which makes transposing from and to such data formats less error prone (no re- projection involved). It is also believed that the burden of potentially required spatial transformations should be put on the author rather then the consumer of 'geo' URI instances. 2. Terminology Geographic locations in this document are defined using WGS-84 (World Geodetic System 1984), equivalent to the International Association of Oil & Gas Producers (OGP) Surveying and Positioning Committee EPSG (European Petroleum Survey Group) code 4326 (2 dimensions) and 4979 (3 dimensions). This document does not assign responsibilities for coordinate transformations from and to other Spatial Reference Systems. A 2-dimensional WGS-84 coordinate value is represented here as a comma-delimited latitude/longitude pair, measured in decimal degrees (un-projected). A 3-dimensional WGS-84 coordinate value is represented here by appending a comma-delimited altitude value in meters to such pairs. Latitudes range from -90 to 90 and longitudes range from -180 to 180. Coordinates in the Southern and Western hemispheres as well as altitudes below the WGS-84 reference geoid are signed negative with a leading dash. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Mayrhofer & Spanring Expires September 7, 2010 [Page 6]
Internet-Draft 'geo' URI Scheme March 2010 3. IANA Registration of 'geo' URI Scheme This section contains the fields required for the URI scheme registration, following the guidelines in section 5.4 of [RFC4395]. 3.1. URI Scheme Name geo 3.2. Status permanent 3.3. URI Scheme Syntax The syntax of the 'geo' URI scheme is specified below in Augmented Backus-Naur Form (ABNF) [RFC5234]: geo-URI = geo-scheme ":" geo-path geo-scheme = "geo" geo-path = coordinates p coordinates = coord-a "," coord-b [ "," coord-c ] coord-a = num coord-b = num coord-c = num p = [ crsp ] [ uncp ] *parameter crsp = ";crs=" crslabel crslabel = "wgs84" / labeltext uncp = ";u=" uval uval = pnum parameter = ";" pname [ "=" pvalue ] pname = labeltext pvalue = 1*paramchar paramchar = p-unreserved / unreserved / pct-encoded labeltext = 1*( alphanum / "-" ) pnum = 1*DIGIT [ "." 1*DIGIT ] num = [ "-" ] pnum unreserved = alphanum / mark mark = "-" / "_" / "." / "!" / "~" / "*" / "'" / "(" / ")" pct-encoded = "%" HEXDIG HEXDIG p-unreserved = "[" / "]" / ":" / "&" / "+" / "$" alphanum = ALPHA / DIGIT Parameter names are case insensitive, use of the lowercase Mayrhofer & Spanring Expires September 7, 2010 [Page 7]
Internet-Draft 'geo' URI Scheme March 2010 representation is PREFERRED. Case sensitivity of non-numeric parameter values MUST be described in the specification of the respective parameter. For the 'crs' parameter, values are case insensitive, and lowercase is PREFERRED. Both 'crs' and 'u' parameters MUST NOT appear more than once each. The 'crs' and 'u' parameters MUST be given before any other parameters that may be defined in future extensions. The 'crs' parameter MUST be given first if both 'crs' and 'u' are used. The definition of other parameters, and <crslabel> values beyond the default value of "wgs84" is out of scope of this document. Section 8.2 discusses the IANA registration of such additional parameters and values. The value of "-0" for <num> is allowed, and identical to "0". In case the URI identifies a location in the default CRS of WGS-84, the <coordinates> sub-components are further restricted as follows: coord-a = latitude coord-b = longitude coord-c = altitude latitude = [ "-" ] 1*2DIGIT [ "." 1*DIGIT ] longitude = [ "-" ] 1*3DIGIT [ "." 1*DIGIT ] altitude = [ "-" ] 1*DIGIT [ "." 1*DIGIT ] 3.4. URI Scheme Semantics Data contained in a 'geo' URI identifies a physical resource: a spatial location identified by the geographic coordinates and the CRS encoded in the URI. 3.4.1. Coordinate Reference System Identification The semantics of <coordinates> depends on the CRS of the URI. The CRS itself is identified by the optional 'crs' parameter. A URI instance uses the default WGS-84 CRS if the 'crs' parameter is either missing or contains the value of 'wgs84'. Other <crslabel> values are currently not defined, but may be specified by future documents. Interpretation of coordinates in the wrong CRS produces invalid location information. Consumers of 'geo' URIs therefore MUST NOT ignore the 'crs' parameter if given, and MUST NOT interpret the <coordinates> sub-components without considering and understanding the 'crs' parameter value. The following component description refers to the use of the default Mayrhofer & Spanring Expires September 7, 2010 [Page 8]
Internet-Draft 'geo' URI Scheme March 2010 CRS (WGS-84) only. Future documents specifying other 'crs' parameter values MUST provide similar descriptions for the <coordinates> sub- components in the described CRS. 3.4.2. Component Description for WGS-84 The <latitude>, <longitude> and <altitude> components as specified in the URI scheme syntax (Section 3.3) are to be used as follows: o <latitude> MUST contain the latitude of the identified location in decimal degrees in the reference system WGS-84. o <longitude> MUST contain the longitude of the identified location in decimal degrees in the reference system WGS-84. o If present, the OPTIONAL <altitude> MUST contain the altitude of the identified location in meters in the reference system WGS-84. If the altitude of the location is unknown, <altitude> (and the comma before) MUST NOT be present in the URI. Specifically, unknown altitude MUST NOT be represented by setting <altitude> to "0" (or any other arbitrary value). The <longitude> of coordinate values reflecting the poles (<latitude> set to -90 or 90 degrees) SHOULD be set to "0", although consumers of 'geo' URIs MUST accept such URIs with any longitude value from -180 to 180. 'geo' URIs with longitude values outside the range of -180 to 180 decimal degrees or with latitude values outside the range of -90 to 90 degrees MUST be considered invalid. 3.4.3. Location Uncertainty The 'u' ("uncertainty") parameter indicates the amount of uncertainty in the location as a value in meters. Where a 'geo' URI is used to identify the location of a particular object, <uval> indicates the uncertainty with which the identified location of the subject is known. The 'u' parameter is optional and it can appear only once. If it is not specified, this indicates that uncertainty is unknown or unspecified. If the intent is to indicate a specific point in space, <uval> MAY be set to zero. Zero uncertainty and absent uncertainty are never the same thing. The single uncertainty value is applied to all dimensions given in the URI. Note: The number of digits of the values in <coordinates> MUST NOT be Mayrhofer & Spanring Expires September 7, 2010 [Page 9]
Internet-Draft 'geo' URI Scheme March 2010 interpreted as an indication to uncertainty. 3.4.4. URI Comparison Two 'geo' URIs are equal when they use the same CRS, and <coord-a>, <coord-b>, <coord-c> and 'u' value are mathematically identical (including absent <uval> meaning undefined 'u' value). If other parameters are contained in the URIs, the comparison operation MUST be extended as described in the specification of the respective parameter. Unknown parameters MUST NOT be ignored. Two URIs use the same CRS if both have the 'crs' parameter omitted, or both have the same <crslabel>, or one has the 'crs' parameter omitted while the other URI specifies the default CRS explicitely with a <crslabel> value of "wgs84". For the default CRS of WGS-84, the following definitions apply in addition: o Where <latitude> of a 'geo' URI is set to either 90 or -90 degrees, <longitude> MUST be ignored in comparison operations ("poles case"). o A <longitude> of 180 degrees MUST be considered equal to <longitude> of -180 degrees for the purpose of URI comparison ("date line" case). A URI with undefined (missing) <coord-c> (altitude) value MUST NOT be considered equal to a URI containing a <coord-c>, even if the remaining <coord-a>, <coord-b>, and their 'u' values are equivalent. 3.4.5. Interpretation of Undefined Altitude A consumer of a 'geo' URI in the WGS-84 CRS with undefined <altitude> MAY assume that the URI refers to the respective location on Earth's physical surface at the given latitude and longitude. However, as defined above, altitudes are relative to the WGS-84 reference geoid rather than Earth's surface. Hence, an <altitude> value of 0 MUST NOT be mistaken to refer to "ground elevation". 3.5. Encoding Considerations The <coordinates> path component of the 'geo' URI (see Section 3.3) uses a comma (",") as the delimiter for subcomponents. This delimiter MUST NOT be percent-encoded. It is RECOMMENDED that for readability the contents of <coord-a>, <coord-b> and <coord-c> as well as <crslabel> and <uval> are never Mayrhofer & Spanring Expires September 7, 2010 [Page 10]
Internet-Draft 'geo' URI Scheme March 2010 percent-encoded. Regarding internationalization, the currently specified components do allow for ASCII characters exclusively, and therefore don't require internationalization. Future specifications of additional parameters might allow the introduction of non-ASCII values. Such specifications MUST describe internationalization considerations for those parameters and their values, and MUST require percent-encoding of non-ASCII values. 3.6. Applications/Protocols that use this URI Scheme As many other URI scheme definitions, the 'geo' URI provides resource identification independent of a specific application or protocol. Examples of potential protocol mappings and use cases can be found in Section 6. 3.7. Interopability Considerations Like other new URI schemes, the 'geo' URI requires support in client applications. Users of applications which are not aware of the 'geo' scheme are likely not able to make direct use of the information in the URI. However, a client can make indirect use by passing around 'geo' URIs even without understanding the format and semantics of the scheme. Additionally, the simple structure of 'geo' URIs would allow even manual dereference by humans. Clients MUST NOT attempt to dereference 'geo' URIs given in an CRS that is unknown to the client, because doing so would produce entirely bogus results. Authors of 'geo' URIs should carefully check that coordinate components are set in the right CRS and in the specified order, since wrong order of those components (or use of coordinates in a different CRS without transformation) are commonly observed mistakes producing completely bogus locations. The number of digits in the <coordinates> values MUST NOT be interpreted as an indication to a certain level of accuracy or uncertainty. 3.8. Security Considerations See Section 9 of [insert reference to this document] Mayrhofer & Spanring Expires September 7, 2010 [Page 11]
Internet-Draft 'geo' URI Scheme March 2010 3.9. Contact Alexander Mayrhofer <axelm@ipcom.at>, <http://geouri.org/> Christian Spanring <christian@spanring.eu> 3.10. Author/Change controller The 'geo' URI scheme is registered under the IETF part of the URI tree. As such, change control is up to the IETF. 3.11. References RFC XXXX [change to RFC number once assigned] 4. 'geo' URI Parameters Registry This specification creates a new IANA Registry named "'geo' URI Parameters Registry" for the <parameter> component of the URI. Parameters for the 'geo' URI and values for these parameters MUST be registered with IANA to prevent namespace collisions, and provide interopability. Some parameters accept values that are constrained by a syntax definition only, while others accept values from a predefined set only. Some parameters might not accept any values at all ("flag" type parameters). The registration of values is REQUIRED for parameters that accept values from a predefined set. The specification of a parameter MUST fully explain the syntax, intended usage and semantics of the parameter. This ensures interopability between independent implementations. For parameters that are neither restricted to a set of predefined values nor of the "flag" type described above, the syntax of allowed values MUST be described in the specification, for example by using ABNF. Documents defining new parameters (or new values for existing parameters) MUST register them with IANA, as explained in Section 8.2. The 'geo' URI Parameter Registry contains a column named "Value Restriction" that describes whether or not a parameter accepts a value, and whether values are restricted to a predefined set. That column accepts the following values: Mayrhofer & Spanring Expires September 7, 2010 [Page 12]
Internet-Draft 'geo' URI Scheme March 2010 o "No value": The parameter does not accept any values, and is to be used as a "flag" only. o "Predefined": The parameter does accept values from a predefined set only, as specified in a RFC or other permanent and readily available public specification. o "Constrained": The parameter accepts arbitrary values that are only constrained by a syntax as specified in a RFC or other permanent and readily available public specification. Section 8.2.1 contains the initial contents of the Registry. 5. URI Operations Currently, just one operation on a 'geo' URI is defined - location dereference: In that operation, a client dereferences the URI by extracting the geographical coordinates from the URI path component <geo-path>. Further use of those coordinates (and the uncertainty value from <uval>) is then up to the application processing the URI, and might depend on the context of the URI. An application may then use this location information for various purposes, for example: o A web browser could use that information to open a mapping service of the user's choice, and display a map of the location. o A navigational device such as a Global Positioning System (GPS) receiver could offer the user to start navigation to the location. Note that the examples and use cases aboves as well as in the next section are non-normative, and provided for information only. 6. Use Cases and Examples 6.1. Plain 'geo' URI Example The following 3-dimensional 'geo' URI example references to the office location of one of the authors in Vienna, Austria: geo:48.2010,16.3695,183 A user could type the data extracted from this URI into a electronic navigation device, or even use it to locate the identified location on a paper map. Mayrhofer & Spanring Expires September 7, 2010 [Page 13]
Internet-Draft 'geo' URI Scheme March 2010 6.2. Hyperlink 'geo' URIs (like any other URI scheme) could also be embedded as hyperlinks in web pages. A Hyper Text Markup Language (HTML) snippet with such a hyperlink could look like: <p>one of Vienna's popular sights is the <a href='geo:48.198634,16.371648;crs=wgs84'>Karlskirche</a>. A web browser could extract the coordinates from the HTML snippet and offer the user various options (based on configuration, context), for example: o Display a small map thumbnail when the mouse pointer hovers over the link. o Switch to a mapping service of the user's choice once the link is selected. o Locate nearby resources, for example by comparing the 'geo' URI with locations extracted from GeoRSS feeds the user has subscribed to. o Convert the coordinates to a format suitable for uploading to a navigation device. Note that the URI in this example also makes use of the explicit specification of the CRS by using the 'crs' parameter. 6.3. 'geo' URI in 2-dimensional barcode Due to it's short length, a 'geo' URI could easily be encoded in 2-dimensional barcodes. Such barcodes could be printed on business cards, flyers, paper maps and subsequently used by mobile devices, for example as follows: 1. User identifies such a barcode on a flyer and uses the camera on his mobile phone to photograph and decode the barcode. 2. The mobile phone dereferences the 'geo' URI, and offers the user to calculate a navigation route to the identified location. 3. Using the builtin GPS receiver, the user follows the navgiation instructions to reach the location. Mayrhofer & Spanring Expires September 7, 2010 [Page 14]
Internet-Draft 'geo' URI Scheme March 2010 7. GML Mappings The Geographic Markup Language (GML) by the Open Geospatial Consortium (OGC) is a set of XML schemas to represent geographical features. Since GML is widely accepted, this document includes instructions on how to transform 'geo' URIs from and to GML fragments. The instructions in this section are not normative. For the following sections, "%lat%", "%lon%", "%alt%" and "%unc%" are placeholders for latitude, longitude, altitude and uncertainty values, respectively. The mappings use WGS-84, and are defined in the following sections. Note: GML fragments in other reference systems could be used as well if a transformation into "urn:ogc:def:crs:EPSG::4979" or "urn:ogc:def:crs:EPSG::4326" is defined and applied before the mapping step. Such transformations are typically not lossless. GML uses the 'double' type from XML schema, and the mapping examples assume that numbers in the form of "3.32435e2" in GML are properly converted to fixed point when placed into the 'geo' URI. 7.1. 2D GML 'Point' A 2D GML 'Point' [RFC5491] is constructed from a 'geo' URI that has two coordinates and an uncertainty ('u') parameter that is absent or zero. A GML point is always converted to a 'geo' URI that has no uncertainty parameter. 'geo' URI: geo:%lat%,%lon% GML fragment: <Point srsName="urn:ogc:def:crs:EPSG::4326" xmlns="http://www.opengis.net/gml"> <pos>%lat% %lon%</pos> </Point> Note that a 'geo' URI with an uncertainty value of zero is converted to a GML 'Point', but a GML 'Point' cannot be translated to a 'geo' URI with zero uncertainty. 7.2. 3D GML 'Point' A 3D GML 'Point' [RFC5491] is constructed from a 'geo' URI that has three coordinates and an uncertainty parameter that is absent or Mayrhofer & Spanring Expires September 7, 2010 [Page 15]
Internet-Draft 'geo' URI Scheme March 2010 zero. A GML point is always converted to a 'geo' URI that has no uncertainty parameter. 'geo' URI: geo:%lat%,%lon%,%alt% GML fragment: <Point srsName="urn:ogc:def:crs:EPSG::4979" xmlns="http://www.opengis.net/gml"> <pos>%lat% %lon% %alt%</pos> </Point> 7.3. GML 'Circle' A GML 'Circle' [RFC5491] is constructed from a 'geo' URI that has two coordinates and an uncertainty parameter that is present and non- zero. 'geo' URI: geo:%lat%,%lon%;u=%unc% GML fragment: <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326" xmlns:gml="http://www.opengis.net/gml" xmlns:gs="http://www.opengis.net/pidflo/1.0"> <gml:pos>%lat% %lon%</gml:pos> <gs:radius uom="urn:ogc:def:uom:EPSG::9001"> %unc% </gs:radius> </gs:Circle> 7.4. GML 'Sphere' A GML 'sphere' [RFC5491] is constructed from a 'geo' URI that has three coordinates and an uncertainty parameter that is present and non-zero. 'geo' URI: geo:%lat%,%lon%,%alt%;u=%unc% Mayrhofer & Spanring Expires September 7, 2010 [Page 16]
Internet-Draft 'geo' URI Scheme March 2010 GML fragment: <gs:Sphere srsName="urn:ogc:def:crs:EPSG::4979" xmlns:gml="http://www.opengis.net/gml" xmlns:gs="http://www.opengis.net/pidflo/1.0"> <gml:pos>%lat% %lon% %alt%</gml:pos> <gs:radius uom="urn:ogc:def:uom:EPSG::9001"> %unc% </gs:radius> </gs:Sphere> 8. IANA Considerations 8.1. 'geo' URI Scheme This document requests assignment of the 'geo' URI scheme in the IETF part of the URI scheme tree, according to the guidelines in BCP 115 (RFC 4395) [RFC4395]. The definitions required for the assignment are contained in Section 3. 8.2. URI Parameter Registry This document creates a new IANA Registry named "'geo' URI Parameters", according to the information in Section 4 and the definition in this section. 8.2.1. Registry Contents When registering a new 'geo' URI Parameter, the following information MUST be provided: o Name of the Parameter. o Whether the Parameter accepts no value ("No value"), values from a predefined set ("Predefined"), or values constrained by a syntax only ("Constrained"). o Reference to the RFC or other permanent and readily available public specification defining the parameters and the new values. Unless specific instructions exists for a Parameter (like the definition of a Sub-registry), the following information MUST be provided when registering new values for existing "Predefined" 'geo' URI Parameters: o Name of the Parameter. o Reference to the RFC or other permanent and readily available public specification defining the new values. Mayrhofer & Spanring Expires September 7, 2010 [Page 17]
Internet-Draft 'geo' URI Scheme March 2010 The following table provides the initial values for this registry: Parameter Name Value Restriction Reference(s) ---------------------------------------------------------- crs Predefined [RFCxxxx] u Constrained [RFCxxxx] [Note to RFC Editor: Replace RFCxxxx with reference to this document] 8.2.2. Registration Policy The Registration Policy for 'geo' URI Parameters and their value definitions shall be "Specification Required" (which implies "Designated Expert"), as defined in [RFC5226]. 8.3. Sub-Registry for 'crs' Parameter This document creates a new IANA Sub-registry named "'geo' URI 'crs' Parameter Values", based on the Registry specified in Section 8.2 and the information in this section and Section 4. The syntax of the 'crs' parameter is constrained by the ABNF given in Section 3.3. 8.3.1. Registry Contents When registering a new value for the 'crs' parameter, the following information MUST be provided: o Value of the parameter. o Reference to the RFC or other permanent and readily available public specification defining the use of the CRS in the scope of the 'geo' URI. The specification should contain information that is similar to the WGS-84-specific text given in this document. o Reference to the definition document of the CRS. If a URN is assigned to the CRS, the use of such URN as reference is preferred. Note that different URNs may exist for the 2-dimensional and 3-dimensional case. The following table provides the initial values for this registry: crs Value Reference(s) CRS definition(s) ----------------------------------------------------------- wgs84 [RFCxxxx] urn:ogc:def:crs:EPSG::4326 urn:ogc:def:crs:EPSG::4979 [Note to RFC Editor: Replace RFCxxxx with reference to this document] Mayrhofer & Spanring Expires September 7, 2010 [Page 18]
Internet-Draft 'geo' URI Scheme March 2010 8.3.2. Registration Policy The registration policy for the "'geo' URI 'crs' Parameter Values" Registry shall require both "Specification Required" and "IESG Approval" as defined in [RFC5226]. Section 1 contains some text about the motivation when to introduce new 'crs' values. 9. Security Considerations Because the 'geo' URI is not tied to any specific protocol and identifies a physical location rather than a network resource, most of the general security considerations on URIs (Section 7 of RFC 3986) do not apply. However, the following (additional) issues apply: 9.1. Invalid Locations The URI syntax (Section 3.3) makes it possible to construct 'geo' URIs which don't identify a valid location. Applications MUST NOT use URIs with such values, and SHOULD warn the user when such URIs are encountered. An example of such an URI referring to an invalid location would be <geo:94,0> (latitude "beyond" north pole). 9.2. Location Privacy A 'geo' URI by itself is just an opaque reference to a physical location, expressed by a set of spatial coordinates. This does not fit the "Location Information" definition according to Section 5.2 of GEOPRIV Requirements [RFC3693], because there is not necessarily a "Device" involved. Because there is also no way to specify the identity of a "Target" within the confines of a 'geo' URI, it also does not fit the specification of an "Location Object" (Section 5.2 of RFC 3693). However, if a 'geo' URI is used in a context where it identifies the location of a Target, it becomes part of a Location Object and is therefore subject to GEOPRIV rules. Therefore, when 'geo' URIs are put into such contexts, the privacy requirements of RFC 3693 MUST be met. Mayrhofer & Spanring Expires September 7, 2010 [Page 19]
Internet-Draft 'geo' URI Scheme March 2010 10. Acknowledgements Martin Thomson has provided significant text around the definition of the "uncertainty" parameter and the GML mappings. The authors further wish to acknowledge the helpful contributions from Carl Reed, Bill McQuillan, Martin Kofal, Andrew Turner, Kim Sanders, Ted Hardie, Cullen Jennings, Klaus Darilion, Bjorn Hoehrmann, Alissa Cooper and Ivan Shmakov. Alfred Hoenes has provided an extremely helpful in-depth review of the document. 11. References 11.1. Normative References [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, March 2009. 11.2. Informative References [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. [WGS84] National Imagery and Mapping Agency, "Department of Defense World Geodetic System 1984, Third Edition", Mayrhofer & Spanring Expires September 7, 2010 [Page 20]
Internet-Draft 'geo' URI Scheme March 2010 NIMA TR8350.2, January 2000. Appendix A. Change Log [Note to editors: This section is to be removed before publication - XML source available on request] draft-ietf-geopriv-geo-uri-04 o Added "crs" URI parameter registry o Added example URI to Introduction o Changed quoting of parameters according to Alfred Hoenes' comments draft-ietf-geopriv-geo-uri-03 o Updated privacy considerations section as per Alissa's comments o Added text on uncertainty applied to all given dimensions o various editorial changes o Changed ABNF to reflect order of parameters (CRS first, then U, then others draft-ietf-geopriv-geo-uri-02 o Added IANA registry for 'geo' URI Parameters and values o Moved change log to appendix o Added "u" parameter to ABNF, restructred ABNF slightly o Added new section describing uncertainty o Changed mapping examples, added some for uncertainty o Added text that number of digits shouldn't be confused with uncertainty or accuracy o marked GML mappings as non-normative based on URI expert review advice o added internationalization consideration section o various other changes based on Expert Review draft-ietf-geopriv-geo-uri-01 o added parameters to ABNF o added optional 'crs' parameter to allow future use of other CRSes o Many other changes to not preclude the future specification of other CRSes. o some typos fixes - credits Bill McQuillan draft-ietf-geopriv-geo-uri-00 o submitted as WG item o changed IPR text because of text used from RFC 4395 o added considerations for comparing +180/-180 longitude URIs o some editorial changes draft-mayrhofer-geopriv-geo-uri-01 Mayrhofer & Spanring Expires September 7, 2010 [Page 21]
Internet-Draft 'geo' URI Scheme March 2010 o added terminology text about WGS-84 (credits Carl Reed) o removed "resolution" / "uncertainty" text o added considerations regarding poles o added text about invalid URIs draft-mayrhofer-geopriv-geo-uri-00 o Initial version under new name, reverting to "plain" lat/lon scheme, with the "tiling" scheme moved to seperate draft (potentially published as "draft-mayrhofer-geopriv-geotile-uri"). refer to draft-mayrhofer-geo-uri-01 for the history of this document. o Added GML mapping section draft-mayrhofer-geo-uri-01 o removed parameters draft-mayrhofer-geo-uri-00 o initial draft Authors' Addresses Alexander Mayrhofer IPCom GmbH Karlsplatz 1/2/9 Wien A-1010 Austria Phone: +43 1 5056416 34 Email: alexander.mayrhofer@nic.at URI: http://www.ipcom.at/ Christian Spanring 30 Hancock St Somerville 02144 Phone: +1 617 863 0360 Email: christian@spanring.eu URI: http://www.spanring.eu/ Mayrhofer & Spanring Expires September 7, 2010 [Page 22]
