Geopriv J. Winterbottom
Internet-Draft M. Thomson
Intended status: Standards Track Andrew Corporation
Expires: January 29, 2009 July 28, 2008
Specifying Derived Location in a PIDF-LO
draft-winterbottom-geopriv-derived-loc-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 January 29, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Winterbottom & Thomson Expires January 29, 2009 [Page 1]
Internet-Draft Derived Locations July 2008
Abstract
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Linking Derived Locations In the Same Document . . . . . . . . 5
4. Linking to External Locations . . . . . . . . . . . . . . . . 7
5. Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7.1. XML Schema Namespace Registration . . . . . . . . . . . . 10
7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 10
7.3. derived <method> Token Registration . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
9. Normative References . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Winterbottom & Thomson Expires January 29, 2009 [Page 2]
Internet-Draft Derived Locations July 2008
1. Introduction
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.
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 [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.
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.
This memo requires the PIDF-LO be constructed using the rules laid
out in [I-D.ietf-geopriv-pdif-lo-profile]. Specifically rule #2 MUST
be adhered to to avoid amibuities in identifiying the correct source
location.
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.
Winterbottom & Thomson Expires January 29, 2009 [Page 3]
Internet-Draft Derived Locations July 2008
2. Terminology
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 [RFC2119].
The term "geocoding" refers to the act of converting a civic location
into a corresponding geodetic location.
The term "reverse geocoding" refers to the act of converting a
geodetic location into a corresponding civic address.
Winterbottom & Thomson Expires January 29, 2009 [Page 4]
Internet-Draft Derived Locations July 2008
3. Linking Derived Locations In the Same Document
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.
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 [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
[I-D.ietf-geopriv-pdif-lo-profile] MUST be adhered to.
Using the attribute from the schema defined in Section 5 a document
showing a civic location that was reverse geocoded from a geodetic
location would look similar to Figure 1. 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".
<?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>
Winterbottom & Thomson Expires January 29, 2009 [Page 5]
Internet-Draft Derived Locations July 2008
</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>
Figure 1: Example Derived and Source Location
The example shown in Figure 1 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".
Winterbottom & Thomson Expires January 29, 2009 [Page 6]
Internet-Draft Derived Locations July 2008
4. Linking to External Locations
The derivedFrom attribute is a URI, so while it can point a position
within the same PIDF-LO as shown in Figure 1, 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 Figure 2.
<?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>
Figure 2: Example Derived and Source Location
Winterbottom & Thomson Expires January 29, 2009 [Page 7]
Internet-Draft Derived Locations July 2008
5. Schema
This section defined the XML schema used to support derived location
linking.
<?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>
Derived Location Schema
Winterbottom & Thomson Expires January 29, 2009 [Page 8]
Internet-Draft Derived Locations July 2008
6. Security Considerations
Any location that has a <method> value of _derived_ 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 _Manual_ in that the
dependability of the location information cannot be assured.
This document does not introduce any security issues beyond those
already identified by PIDF-LO and the use of location URIs.
Winterbottom & Thomson Expires January 29, 2009 [Page 9]
Internet-Draft Derived Locations July 2008
7. IANA Considerations
7.1. XML Schema Namespace Registration
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:derived", as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:derived
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), James Winterbottom
(james.winterbottom@andrew.com).
XML:
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
7.2. XML Schema Registration
This section registers an XML schema as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:schema:geopriv:derived
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
James Winterbottom (james.winterbottom@andrew.com).
Schema: The XML for this schema can be found as the entirety of
Section 5 of this document.
Winterbottom & Thomson Expires January 29, 2009 [Page 10]
Internet-Draft Derived Locations July 2008
7.3. derived <method> Token Registration
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.
Winterbottom & Thomson Expires January 29, 2009 [Page 11]
Internet-Draft Derived Locations July 2008
8. Acknowledgements
Thanks to Brian Rosen for raising the issue of derived location
Winterbottom & Thomson Expires January 29, 2009 [Page 12]
Internet-Draft Derived Locations July 2008
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[I-D.ietf-geopriv-pdif-lo-profile]
Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
PIDF-LO Usage Clarification, Considerations and
Recommendations", draft-ietf-geopriv-pdif-lo-profile-11
(work in progress), February 2008.
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479,
July 2006.
Winterbottom & Thomson Expires January 29, 2009 [Page 13]
Internet-Draft Derived Locations July 2008
Authors' Addresses
James Winterbottom
Andrew Corporation
PO Box U40
University of Wollongong, NSW 2500
AU
Email: james.winterbottom@andrew.com
Martin Thomson
Andrew Corporation
PO Box U40
University of Wollongong, NSW 2500
AU
Email: martin.thomson@andrew.com
Winterbottom & Thomson Expires January 29, 2009 [Page 14]
Internet-Draft Derived Locations July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Winterbottom & Thomson Expires January 29, 2009 [Page 15]