One document matched: draft-ietf-geopriv-geo-uri-01.xml
<?xml version='1.0' ?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
<rfc ipr='pre5378Trust200902' docName='draft-ietf-geopriv-geo-uri-01' >
<?rfc toc='yes' ?>
<?rfc tocompact='no' ?>
<?rfc compact='yes' ?>
<?rfc subcompact='yes' ?>
<?rfc symrefs='yes' ?>
<front>
<title abbrev="'geo' URI scheme">
A Uniform Resource Identifier for Geographic Locations ('geo' URI)
</title>
<author initials='A.' surname='Mayrhofer' fullname='Alexander Mayrhofer'>
<organization abbrev='nic.at'>
nic.at GmbH
</organization>
<address>
<postal>
<street>Karlsplatz 1/9</street>
<city>Wien</city>
<code>A-1010</code>
<country>Austria</country>
</postal>
<phone>+43 1 5056416 34</phone>
<email>alexander.mayrhofer@nic.at</email>
<uri>http://www.nic.at/</uri>
</address>
</author>
<author initials='C.' surname='Spanring' fullname='Christian Spanring'>
<organization abbrev='OIR-ID'>
OIR-ID GmbH
</organization>
<address>
<postal>
<street>Franz-Josefs-Kai 27</street>
<city>Wien</city>
<code>A-1010</code>
</postal>
<phone>+43 1 5338747 36</phone>
<email>cspanring@gmail.com</email>
<uri>http://www.oir.at/</uri>
</address>
</author>
<date month='July' year='2009' day='03'/>
<area>RAI</area>
<workgroup>GEOPRIV -- Geographic Location/Privacy Working Group</workgroup>
<keyword>geography</keyword>
<keyword>geo</keyword>
<keyword>URI</keyword>
<keyword>scheme</keyword>
<abstract>
<t>This document specifies an 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.
</t>
</abstract>
</front>
<middle>
<section anchor='changelog' title='Change Log'>
<t>[Note to editors: This section is to be removed before publication - XML source available on request]
</t>
<t>draft-ietf-geopriv-geo-uri-01
<list style='symbols'>
<t>added parameters to ABNF</t>
<t>added optional 'crs' parameter to allow future use of other CRSes</t>
<t>Many other changes to not preclude the future specification of
other CRSes.</t>
<t>some typos fixes - credits Bill McQuillan</t>
</list>
</t>
<t>draft-ietf-geopriv-geo-uri-00
<list style='symbols'>
<t>submitted as WG item</t>
<t>changed IPR text because of text used from RFC 4395</t>
<t>added considerations for comparing +180/-180 longitude URIs</t>
<t>some editorial changes</t>
</list>
</t>
<t>draft-mayrhofer-geopriv-geo-uri-01
<list style='symbols'>
<t>added terminology text about WGS-84 (credits Carl Reed)</t>
<t>removed "resolution" / "uncertainty" text</t>
<t>added considerations regarding poles</t>
<t>added text about invalid URIs</t>
</list>
</t>
<t>draft-mayrhofer-geopriv-geo-uri-00
<list style='symbols'>
<t>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.
</t>
<t>Added GML mapping section</t>
</list>
</t>
<t>draft-mayrhofer-geo-uri-01
<list style='symbols'>
<t>removed parameters</t>
</list>
</t>
<t>draft-mayrhofer-geo-uri-00
<list style='symbols'>
<t>initial draft</t>
</list>
</t>
</section>
<section anchor='intro' title='Introduction'>
<t>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.
</t>
<t>Over the past few years, fast emerging location aware applications
and location based services were observable on the Internet.
Most web search engines use geographic information, and a vivid
open source mapping community brought an enormous momentum into
location aware
technology. A wide range and former to professionals exclusive
tools and data were provided free of charge for an everyday use
on the mass market.
</t>
<t>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
or trigger further services based on a particular place on earth
shouldn't be any harder for users than clicking on a 'mailto:' link
and write an email straight away.
</t>
<t>According to <xref target='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 (a physical resource) in a coordinate references system
(CRS), per default in <xref target='WGS84'>World Geodetic System 1984
(WGS-84)</xref>.
The optional "crs" URI parameter
described below may be used by future specifications to
define the use of other CRSes. However, such definitions are out of
scope of this document.
</t>
<t>
'Geo' URIs identify a geographic location using a
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). 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.
</t>
<t>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. The
provision of more complex geometries or locations described by
civic addresses is out of scope of this document.
</t>
<t>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 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).
</t>
</section>
<section anchor='terminology' title='Terminology'>
<t>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.</t>
<t>A 2-dimensional WGS-84 coordinate value is here represented as a comma-delimited latitude/longitude pair, measured in decimal degrees (un-projected). A 3-dimensional WGS-84 coordinate value is here represented by appending a comma-delimited altitude value in meters to such pairs.</t>
<t>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.</t>
<t>
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
<xref target='RFC2119'>RFC 2119</xref>.
</t>
</section>
<section anchor='registration' title="IANA Registration of 'geo' URI Scheme">
<t>This section contains the fields required for the URI scheme
registration, following the guidelines in section 5.4 of
<xref target='RFC4395'/>.
</t>
<section anchor='uriscname' title='URI Scheme Name'>
<t>geo</t>
</section>
<section anchor='uristatus' title='Status'>
<t>permanent</t>
</section>
<section anchor='urisyntax' title='URI Scheme Syntax'>
<t>The syntax of the 'geo' URI scheme is specified below in
<xref target='RFC4234'>Augmented Backus-Naur Form (ABNF)
</xref>:
</t>
<artwork>
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 / parameter
crsp = ";crs=" crslabel
crslabel = "wgs84"
parameter = ";" pname [ "=" pvalue ]
pname = 1*( alphanum / '-' )
pvalue = 1*paramchar
paramchar = p-unreserved / unreserved / pct-encoded
num = [ "-" ] 1*DIGIT [ "." 1*DIGIT ]
unreserved = alphanum / mark
mark = "-" / "_" / "." / "!" / "~" / "*" /
"'" / "(" / ")"
pct-encoded = "%" HEXDIG HEXDIG
p-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$"
alphanum = ALPHA / DIGIT
</artwork>
<t>The optional "crs" parameter MUST NOT appear more than once.
If other parameters are also given, the "crs" parameter MUST
be given first. The definition of other parameters besides "crs"
is out of scope for this document.
</t>
<t>Future documents proposing the use of other CRSes may update
the definition of the 'crslabel' component.</t>
<t>In case the URI identifies a location in
the default CRS of WGS-84, its sub-components are further
restricted as follows:</t>
<artwork>
coord-a = latitude
coord-b = longitude
coord-c = altitude
latitude = [ "-" ] 1*2DIGIT [ "." 1*DIGIT ]
longitude = [ "-" ] 1*3DIGIT [ "." 1*DIGIT ]
altitude = [ "-" ] 1*DIGIT [ "." 1*DIGIT ]
</artwork>
</section>
<section anchor='urisemantics' title='URI Scheme Semantics'>
<t>Data contained in a 'geo' URI identifies
a physical resource: A spatial location on earth in the
in a coordinate reference system, identified by
the geographic coordinates encoded in the URI.
</t>
<section anchor='crsidentification' title='Coordinate Reference System Identification'>
<t>The semantics of the 'coordinates' component depends on the
CRS of the URI. The CRS itself is identified by the optional
'crs' parameter the default. A URI instance uses the default
WGS-84 CRS if the 'crs' parameter is either missing,
or contains the value of 'wgs84'.
Other 'crs' values are not currently defined, but
may be specified by future documents.
</t>
<t>
Interpretation of coordinates in a wrong CRS produces invalid
location information. Consumers of 'geo' URIs
therefore MUST NOT ignore the 'crs' parameter if given, and
MUST NOT attempt to interpret the 'coordinates' component of
given in an unknown CRS.
</t>
<t>The following component description refers to the use of
the default CRS (WGS-84) only.
Future documents specifying
other 'crs' parameter values MUST provide similar
descriptions for the 'coordinates' sub-components in the
described CRS.
</t>
</section>
<section anchor='compdesc' title='Component Description for WGS-84'>
<t>The "latitude", "longitude" and "altitude"
components as specified in the URI scheme syntax (
<xref target='urisyntax'/>) are to be used as follows:
</t>
<vspace blankLine='1'/>
<list style='symbols'>
<t>The "latitude" component MUST contain the latitude of
the identified location in decimal degrees
in the reference system WGS-84.
</t>
<t>The "longitude" component MUST contain the longitude of
the identified location in decimal degrees
in the reference system WGS-84.
</t>
<t>If present, the OPTIONAL "altitude" component MUST contain
the WGS-84 altitude of the identified location
in meters.
</t>
</list>
<t>If the altitude of the location is unknown, the "altitude"
component MUST NOT be present in the URI. Specifically,
unknown altitude MUST NOT be represented by setting the 'altitude'
component to "0" (or any other arbitrary value).
</t>
<t>The "longitude" components 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 between -180 and 180.
</t>
<t>'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.
</t>
<!-- <t>The number of decimal places indicates the precision of
the value. One degree equals 111,319.45m at the equator
(40,075.004km / 360 degrees). Five decimal places
(0.00001 degree) seem to imply a for civil use
sufficient resolution.
</t> -->
</section>
<section anchor='comparison' title='URI Comparison'>
<t>Two 'geo' URIs are equal when they use the same CRS,
and their 'coord-a', 'coord-b' and 'coord-c' values are
mathematically identical.</t>
<t>Two 'geo' URIs use the same CRS if:
<list style='symbols'>
<t>their 'crslabel' components are identical</t>
<t>or if neither URIs contain a 'crs' parameter (in which case both URIs use WGS-84)</t>
<t>or if one URI contains a 'crslabel' value of 'wgs84',
while the other URI does not contain a 'crs' parameter
(which means that both URIs use the WGS-84 reference system
as well, with one of the URIs specifying the CRS explicitely)
</t>
</list>
</t>
<t>For the default CRS of WGS-84, the following definitions
apply additionally:
<list style='symbols'>
<t>
Where the 'latitude' component of a 'geo' URI is set to either
90 or -90 degrees, the 'longitude' component MUST be ignored
in comparison operations. </t>
<t>A 'longitude' component of 180 degrees
MUST be considered equal a 'longitude' component of -180 degrees
for the purpose of URI comparison.
</t>
</list>
</t>
<t>
An URI with undefined (missing) 'coord-c' (altitude) value
MUST NOT be considered equal to an URI containing an
'coord-c' value,
even if the remaining values 'coord-a'
and 'coord-b' are equivalent.
</t>
</section>
<section anchor='altinterpret' title='Interpretation of Undefined Altitude'>
<t>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'
coordinate.
</t>
<t>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 interpreted as "on earth's surface".
</t>
</section>
</section>
<section anchor='urienc' title='Encoding Considerations'>
<t>The 'coordinates' path component of the 'geo' URI
(see <xref target='urisyntax'/>) uses a comma (",") as a
delimiter for subcomponents. This delimiter MUST NOT be
percent encoded.
</t>
<t>It is RECOMMENDED that for readability the contents of
'coord-a', 'coord-b' and 'coord-c' subcomponents are
never percent encoded.
</t>
</section>
<section anchor='uriapps' title='Applications/protocols That Use This URI Scheme'>
<t>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
<xref target='examples'/>.
</t>
</section>
<section anchor='uriinterop' title='Interopability Considerations'>
<t>As with any other new URI scheme, the 'geo' URI requires
support in client applications. Users of applications which are
not aware of the 'geo' scheme are likely unable to make direct use
of the information in the URI. However, the simple structure of the
'geo' URI would even allow manual dereference by users.
</t>
<t>Poorly authored 'geo' URI instances could contain whitespace
and values with leading plus signs ("+"), which is not allowed
according to the ABNF.
Clients SHOULD, however, try to dereference such URIs after removing
such whitespace and plus signs.</t>
<t>This specification does not define
a query component. Future
revisions might define such components, using the
"?" character to delimit query components from
the path component specified above. Clients MUST be prepared to
encounter
such 'geo' URI instances, and MUST reduce the URI to the components
specified in <xref target='urisyntax'/> before they dereference
the URI.
</t>
<t>
Clients MUST NOT attempt to dereference URIs given in an
CRS that is unknown to the client, because doing so would
produce entirely bogus results.
</t>
<t>Authors of 'geo' URIs should carefully check that coordinate
components are set in
the specified order, since wrong order of those components is
a commonly observed mistake and produces completely bogus
locations.
</t>
</section>
<section anchor='uriseccons' title='Security Considerations'>
<t>See <xref target='seccons'/> of [insert reference to this document]
</t>
</section>
<section anchor='uricontact' title='Contact'>
<t>Christian Spanring (mailto:cspanring@gmail.at, http://spanring.eu/ ),
Alexander Mayrhofer (mailto:alexander.mayrhofer@nic.at, http://timatio.com/ )
</t>
</section>
<section anchor='urichange' title='Author/Change controller'>
<t>The 'geo' URI scheme is registered under the IETF part of the
URI tree. As such, change control is up to the IETF.
</t>
</section>
<section anchor='uriref' title='References'>
<t>RFC XXXX [change to RFC number once assigned]</t>
</section>
</section>
<section anchor='uriops' title="URI Operations">
<t>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' in the ABNF).
Further use of those coordinates is then up to the application
processing the URI, and might depend on the context of the URI.
</t>
<t>An application may then use this location information for various
purposes, for example:
<list style='symbols'>
<vspace blankLines='1'/>
<t>A web browser could use that information to open a
web mapping service of the user's choice, and display a map of
the location</t>
<vspace blankLines='1'/>
<t>A navigational device such as a Global Positioning System (GPS)
receiver could offer the user to start navigation to the location.
</t>
</list>
</t>
</section> <!-- end of URI Operations section -->
<section anchor='examples' title='Use Cases and Examples'>
<section anchor='plainex' title="Plain 'geo' URI Example">
<t>The following 3-dimensional 'geo' URI example references
to the office location of one of the authors in
Vienna, Austria:
</t>
<t>geo:48.2010,16.3695,183</t>
<t>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.
</t>
</section>
<section anchor='htmlembed' title='Hyperlink'>
<t>'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:
</t>
<t><p>one of Vienna's popular sights is the
<a href='geo:48.198634,16.371648;crs=wgs84'>Karlskirche</a>.
</t>
<t>A web brower could extract the coordinates from the HTML snippet, and offer the user various options (based on
configuration, context), for example:
</t>
<list style='symbols'>
<vspace blankLines='1'/>
<t>display a small map thumbnail when the mouse pointer hovers over the link</t>
<vspace blankLines='1'/>
<t>switch to a mapping service of the user's choice once the
link is selected</t>
<vspace blankLines='1'/>
<t>Locate nearby resources, for example by comparing the
'geo' URI with locations extracted from GeoRSS
feeds the user has subscribed to.</t>
<vspace blankLines='1'/>
<t>Convert the coordinates to a format suitable for uploading
to a navigation device</t>
</list>
<t>Note that the URI in this example also makes use of the
explicit specification of the CRS by using the 'crs' URI parameter.
</t>
</section>
<section anchor='barcode' title="'geo' URI in 2-dimensional barcode">
<t>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:
</t>
<list style='numbers'>
<vspace blankLines='1'/>
<t>User identifies such a barcode on a flyer, uses the camera
on his mobile phone to photograph and decode the barcode</t>
<vspace blankLines='1'/>
<t>The mobile phone dereferences the 'geo' URI, and offers
the user to calculate a navigation route to the identified
location.</t>
<vspace blankLines='1'/>
<t>Using the builtin GPS, the user follows the navgiation
instructions from his phone to reach the destination</t>
</list>
</section>
</section> <!-- end of Examples section -->
<section anchor='gmlconversion' title='GML Mappings'>
<t>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 transpose 'geo' URIs
from and to GML documents.
</t>
<t>A 'geo' URI can be mapped from a GML "point", and any 'geo' URI
can be mapped to a GML "point" (given that both support the CRS used).
For the following sections, "%lat%", "%lon%" and "%alt%" are
placeholders for latitude, longitude, and altitude
values. Mappings are defined as follows:
</t>
<section anchor='togml2d' title="'geo' URI without altitude to GML 'Point'">
<t>An instance of a WGS 84 'geo' URI without the altitude element is
mapped to a two-dimensional GML "Point" as follows:
</t>
<t>'geo' URI: <artwork>
geo:%lat%,%lon%
</artwork>
</t>
<t>GML document:
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8">
<Point srsDimension="2"
srsName="urn:ogc:def:crs:EPSG:6.6:4326"
xmlns="http://www.opengis.net/gml">
<pos>%lat% %lon%</pos>
</Point>
]]></artwork>
</t>
</section>
<section anchor='togml3d' title="'geo' URI with Altitude to GML 'Point'">
<t>A WGS 84 'geo' URI instance with the altitude element is mapped to
a three-dimensional GML "Point" as follows:
</t>
<t>'geo' URI: <artwork>
geo:%lat%,%lon%,%alt%
</artwork>
</t>
<t>GML document:
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8">
<Point srsDimension="3"
srsName="urn:ogc:def:crs:EPSG:6.6:4979"
xmlns="http://www.opengis.net/gml">
<pos>%lat% %lon% %alt%</pos>
</Point>
]]></artwork>
</t>
</section>
<section anchor='fromgml2d' title="GML 'Point' without Altitude to 'geo' URI">
<t>A GML 'Point' in the reference system identified as "urn:ogc:def:crs:EPSG:6.6:4326" is mapped to a 'geo' URI as follows:
</t>
<t>GML document:
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8">
<Point srsDimension="2"
srsName="urn:ogc:def:crs:EPSG:6.6:4326"
xmlns="http://www.opengis.net/gml">
<pos>%lat% %lon%</pos>
</Point>
]]></artwork>
</t>
<t>'geo' URI: <artwork>
geo:%lat%,%lon%
</artwork>
</t>
<t>Note: GML documents in other reference systems MAY be used
as well if a transformation into
"urn:ogc:def:crs:EPSG:6.6:4326" is defined and applied before
the mapping step.
</t>
</section>
<section anchor='fromgml3d' title="GML 'Point' with Altitude to 'geo' URI">
<t>A GML 'Point' in the reference system identified as "urn:ogc:def:crs:EPSG:6.6:4979" is mapped to a 'geo' URI as follows:
</t>
<t>GML document:
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8">
<Point srsDimension="3"
srsName="urn:ogc:def:crs:EPSG:6.6:4979"
xmlns="http://www.opengis.net/gml">
<pos>%lat% %lon% %alt%</pos>
</Point>
]]></artwork>
</t>
<t>'geo' URI: <artwork>
geo:%lat%,%lon%,%alt%
</artwork>
</t>
<t>Note: GML 'Point' instances in other reference systems could
be used as well if a transformation into
"urn:ogc:def:crs:EPSG:6.6:4979" is defined and applied before
the mapping step. It should be noted that such reprojections
are typically not lossless because of the limited accuracy of the
mathematical calculations involved.
</t>
</section>
</section> <!-- end of mapping section -->
<section anchor='ianacons' title='IANA Considerations'>
<t>This document requests assignment of the 'geo' URI scheme
in the IETF part of the URI scheme tree, according to the
guidelines in <xref target='RFC4395'>BCP 115 (RFC 4395)</xref>.
The definitions required
for the assignment are contained in <xref target='registration'/>.
</t>
</section>
<section anchor='seccons' title='Security Considerations'>
<t>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:
</t>
<section anchor='invalidloc' title='Invalid Locations'>
<t>The <xref target='urisyntax'>URI syntax</xref>
makes it possible to construct valid 'geo' URIs which don't
identify a valid location on earth. Applications MUST NOT use
URIs which such invalid values, and SHOULD warn the user when such
URIs are encountered.
</t>
<t>An example of such an invalid URI
would be <geo:94,0> (latitude "beyond" north pole).
</t>
</section>
<section anchor='locprivacy' title='Location Privacy'>
<t>Location information about individuals is an extremely
sensitive topic, especially when location is combined with
Personally Identifyable Information (PII). Authors of 'geo'
URIs MUST consider data protection and privacy before publishing
such URIs.
</t>
<t>However, it should be noted that a 'geo' URI by itself is
just opaque location information, and privacy considerations
typically arise only when such opaque location information
is put in context by combining it with other information (for
example, embedding it within a message to reflect the current
location of a person).
</t>
</section>
<!-- <t>FIXME: Only for public data, or willing to publish it. consent of
the user when publishing it.</t> -->
</section>
<section anchor='ack' title='Acknowledgements'>
<t>The authors wish to acknowledge the helpful contributions from
Carl Reed,
Bill McQuillan, Martin Kofal, Andrew Turner, Kim Sanders and
Ted Hardie.
</t>
</section>
</middle>
<back>
<references title='Normative References'>
<?rfc include="reference.RFC.3986" ?>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.4234" ?>
<?rfc include="reference.RFC.3261" ?>
</references>
<references title='Informative References'>
<?rfc include="reference.RFC.4395" ?>
<?rfc include="reference.WGS84" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:58:51 |