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]