One document matched: draft-winterbottom-geopriv-derived-loc-00.xml
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4119.xml">
<!ENTITY RFC3688 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml">
<!ENTITY I-D.ietf-geopriv-pdif-lo-profile PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-pdif-lo-profile.xml">
<!ENTITY RFC4479 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4479.xml">
]>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc toc="yes" ?>
<rfc category="std" ipr="full3978">
<front>
<title abbrev="Derived Locations">Specifying Derived Location in a PIDF-LO</title>
<author initials="J." surname="Winterbottom" fullname="James Winterbottom">
<organization>Andrew Corporation</organization>
<address>
<postal>
<street>PO Box U40</street>
<city>University of Wollongong</city>
<region>NSW</region>
<code>2500</code>
<country>AU</country>
</postal>
<email>james.winterbottom@andrew.com</email>
</address>
</author>
<author initials="M." surname="Thomson" fullname="Martin Thomson">
<organization>Andrew Corporation</organization>
<address>
<postal>
<street>PO Box U40</street>
<city>University of Wollongong</city>
<region>NSW</region>
<code>2500</code>
<country>AU</country>
</postal>
<email>martin.thomson@andrew.com</email>
</address>
</author>
<date month="July" year="2008"/>
<area>Application</area>
<workgroup>Geopriv</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document describes how specify that a location in a PIDF-LO has been derived or converted from a different location. The
source location may reside in the same PIDF-LO or be a remote document referenced by a location URI and associated id fragement.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>Some systems generate or determine location in one format, but the application needing to comsume location requires it to be
expressed in a different form. A common example of this is a location generator that uses wireless measurements to determine the
location of a device in geodetic coordinates, but this information needs to be relayed to a delivery person that requires a street
address. In this case it is advantangeous to reverse geocode the location from geodetic form to civic form.
</t>
<t>The intended use of the location will not always be known ahead of time, and it may be important to the ultimate consumer of location
to know not only that the location information being provided was derived from a different location, but also what the original location was.
This can be done using ordering techniques with in the PIDF-LO <xref target="RFC4119"/> , but this leads to issues if more that derived location is provided,
or if space is a constraint and the only one location can comfortably be conveyed.
</t>
<t>This specification provides a convenient and standard way to indicate and link derived locations to their sources in a way that
scales to support multiple derived locations delievered, either in the same document, or out of band through location URIs.
</t>
<t>This memo requires the PIDF-LO be constructed using the rules laid out in <xref target="I-D.ietf-geopriv-pdif-lo-profile"/>.
Specifically rule #2 MUST be adhered to to avoid amibuities in identifiying the correct source location.
</t>
<t>A small XML schema is created to provide a linking attribute. Guidance on how to use the linking attribute is provided, and a new
PIDF-LO <method> is registered is IANA to support the derived location type.
</t>
</section>
<section anchor="terminology" title="Terminology">
<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"/>.
</t>
<t>The term "geocoding" refers to the act of converting a civic location into a corresponding geodetic location.
</t>
<t>The term "reverse geocoding" refers to the act of converting a geodetic location into a corresponding civic address.
</t>
</section>
<section title="Linking Derived Locations In the Same Document">
<t>A derived location is obtained by performing an operation on data acquired from a source location. Consequently in a single document
two tags are required for derived location; a tag indicating which is the source location, and a second tag indicating which
location is the derived location.
</t>
<t>The source location is identified by an 'id' attribute associated with a <tuple>, <device>, or <person>
element in a PIDF-LO. The value of this 'id' MUST be unique in the scope of the entire document as defined in
<xref target="RFC4479"/>. Providing only one location is attributed to this 'id' the source location can be unambiguously
identified, and it is for this reason that rule #2 from <xref target="I-D.ietf-geopriv-pdif-lo-profile"/> MUST be adhered to.
</t>
<t>Using the attribute from the schema defined in <xref target="schema"/> a document showing a civic location that was reverse geocoded
from a geodetic location would look similar to <xref target="ex1"/>. In this example the source location is a circle, and is
identified by the tuple id "nesspc-1". The derived location, the civic location, is marked with the dl:derivedFrom
attribute that's value is a URI, in this case linking to the location contained in the tuple with an 'id' attribute value of
"nesspc-1".
</t>
<t>
<figure anchor="ex1" title="Example Derived and Source Location">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:dl="urn:ietf:params:xml:ns:geopriv:derived"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:ness@example.com">
<tuple id="nesspc-1">
<status>
<gp:geopriv>
<gp:location-info>
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-34.410649 150.87651</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
30
</gs:radius>
</gs:Circle>
</gp:location-info>
<gp:usage-rules/>
<method>GPS</method>
</gp:geopriv>
</status>
<timestamp>2007-06-22T20:57:29Z</timestamp>
</tuple>
<tuple id="ness">
<status>
<gp:geopriv>
<gp:location-info>
<civicAddress xml:lang="en-AU"
dl:derivedFrom="#nesspc-1">
<country>AU</country>
<A1>NSW</A1>
<A3> Wollongong
</A3><A4>North Wollongong
</A4>
<RD>Flinders</RD><STS>Street</STS>
<RDBR>Campbell Street</RDBR>
<LMK>
Gilligan's Island
</LMK> <LOC>Corner</LOC>
<NAM> Main Bank </NAM>
<PC>2500</PC>
<ROOM> 398 </ROOM>
<PLC>store</PLC>
<POBOX>Private Box 15</POBOX>
</civicAddress>
</gp:location-info>
<gp:usage-rules/>
<method>Derived</method>
</gp:geopriv>
</status>
<timestamp>2007-06-24T12:28:04Z</timestamp>
</tuple>
</presence>
]]>
</artwork>
</figure>
</t>
<t>The example shown in <xref target="ex1"/> can scale to any number of derived locations. For example if a third location were subsequently derived
from the civic location then it would have a derivedFrom attribute with a value of "#ness".
</t>
</section>
<section title="Linking to External Locations">
<t>The derivedFrom attribute is a URI, so while it can point a position within the same PIDF-LO as shown in <xref target="ex1"/>, it can point to an
external source using a held, pres, sip or http URI. A location derived from an external source is shown in <xref target="ex2"/>.
</t>
<t>
<figure anchor="ex2" title="Example Derived and Source Location">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:dl="urn:ietf:params:xml:ns:geopriv:derived"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:ness@example.com">
<tuple id="ness">
<status>
<gp:geopriv>
<gp:location-info>
<civicAddress xml:lang="en-AU"
dl:derivedFrom="held://lis.example.com:9128/xyz#freddy">
<country>AU</country>
<A1>NSW</A1>
<A3> Wollongong
</A3><A4>North Wollongong
</A4>
<RD>Flinders</RD><STS>Street</STS>
<RDBR>Campbell Street</RDBR>
<PC>2500</PC>
<POBOX>Private Box 15</POBOX>
</civicAddress>
</gp:location-info>
<gp:usage-rules/>
<method>Derived</method>
</gp:geopriv>
</status>
<timestamp>2008-07-24T12:28:04Z</timestamp>
</tuple>
</presence>
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="schema" title="Schema">
<t>This section defined the XML schema used to support derived location linking.
</t>
<t>
<figure title="Derived Location Schema">
<artwork><![CDATA[
<?xml version="1.0"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:geopriv:derived"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:attribute type="xs:anyURI" name="derivedFrom"/>
</xs:schema>
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>Any location that has a <method> value of <spanx style="emph">derived</spanx> that does provide a corresponding derivedFrom attribute link,
or provides an invalid derivedFrom link should be treated with the same degree of caution as a location with a <method> value of <spanx style="emph">Manual</spanx>
in that the dependability of the location information cannot be assured.
</t>
<t>This document does not introduce any security issues beyond those already identified
by PIDF-LO and the use of location URIs.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<section title="XML Schema Namespace Registration">
<t>This section registers a new XML namespace, <spanx style="verb">urn:ietf:params:xml:ns:geopriv:derived</spanx>,
as per the guidelines in <xref target="RFC3688"/>.
<list style="empty">
<t>URI: urn:ietf:params:xml:ns:geopriv:derived</t>
<t>Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), James Winterbottom (james.winterbottom@andrew.com).</t>
<t>XML:
<figure>
<artwork><![CDATA[
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>PIDF-LO Derived Location Link Schema</title>
</head>
<body>
<h1>Namespace for derived location linking attributes</h1>
<h2>urn:ietf:params:xml:ns:geopriv:derived</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]]
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body>
</html>
END
]]></artwork>
</figure>
</t>
</list>
</t>
</section>
<section title="XML Schema Registration">
<t>This section registers an XML schema as per the guidelines in <xref target="RFC3688"/>.
<list style="hanging">
<t hangText="URI:">urn:ietf:params:xml:schema:geopriv:derived</t>
<t hangText="Registrant Contact:">IETF, GEOPRIV working group, (geopriv@ietf.org), James Winterbottom (james.winterbottom@andrew.com).</t>
<t hangText="Schema:">The XML for this schema can be found as the entirety of <xref target="schema"/> of this document.
</t>
</list>
</t>
</section>
<section title="derived <method> Token Registration">
<t>This section registers a new 'method' token in the IANA geopriv 'method' token registry.
This new token is called 'derived' and is used then the location being represented has been derived from a different location.
</t>
</section>
</section>
<section title="Acknowledgements">
<t>Thanks to Brian Rosen for raising the issue of derived location
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC4119;
&RFC3688;
&I-D.ietf-geopriv-pdif-lo-profile;
&RFC4479;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 09:01:18 |