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.

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
2.  Terminology
3.  Linking Derived Locations In the Same Document
4.  Linking to External Locations
5.  Schema
6.  Security Considerations
7.  IANA Considerations
    7.1.  XML Schema Namespace Registration
    7.2.  XML Schema Registration
    7.3.  derived Token Registration
8.  Acknowledgements
9.  Normative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

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] (Peterson, J., “A Presence-based GEOPRIV Location Object Format,” December 2005.) , 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] (Winterbottom, J., Thomson, M., and H. Tschofenig, “GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations,” November 2008.). 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.

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

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.

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] (Rosenberg, J., “A Data Model for Presence,” July 2006.). 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] (Winterbottom, J., Thomson, M., and H. Tschofenig, “GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations,” November 2008.) MUST be adhered to.

Using the attribute from the schema defined in Section 5 (Schema) a document showing a civic location that was reverse geocoded from a geodetic location would look similar to Figure 1 (Example Derived and Source Location). 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>
        </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>

The example shown in Figure 1 (Example Derived and Source Location) 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".

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 (Example Derived and Source Location), 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 (Example Derived and Source Location).

<?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>

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>

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.

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] (Mealling, M., “The IETF XML Registry,” January 2004.).

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] (Mealling, M., “The IETF XML Registry,” January 2004.).

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 (Schema) of this document.

7.3.  derived 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.

8.  Acknowledgements

Thanks to Brian Rosen for raising the issue of derived location

9. Normative References

Authors' Addresses

Full Copyright Statement

Copyright © 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.