Geopriv                                                  J. Winterbottom
Internet-Draft                                                M. Thomson
Expires: September 4, November 3, 2006                             Andrew Corporation
                                                           H. Tschofenig
                                                                 Siemens
                                                           March 3,
                                                             May 2, 2006

GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations
               draft-ietf-geopriv-pdif-lo-profile-03.txt
               draft-ietf-geopriv-pdif-lo-profile-04.txt

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 September 4, November 3, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   The Presence Information Data Format Location Object (PIDF-LO)
   specification provides a flexible and versatile means to represent
   location information.  There are, however, circumstances that arise
   when information needs to be constrained in how it is represented so
   that the number of options that need to be implemented in order to
   make use of it are reduced.  There is growing interest in being able
   to use location information contained in a PIDF-LO for routing
   applications.  To allow successfully interoperability between
   applications, location information needs to be normative and more
   tightly constrained than is currently specified in the PIDF-LO.  This
   document makes recommendations on how to constrain, represent and
   interpret locations in a PIDF-LO.  It further recommends a subset of
   GML that MUST be implemented by applications involved in location
   based routing.

Table of Contents

   1.  CHANGES SINCE LAST TIME  . . . . . . . . . . . . . . . . . . .  3
     1.1.  03  04 changes . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  03 changes . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.3.  01 changes . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4  5
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5  6
   4.  Using Location Information . . . . . . . . . . . . . . . . . .  6  7
     4.1.  Single Civic Location Information  . . . . . . . . . . . .  7  8
     4.2.  Civic and Geospatial Location Information  . . . . . . . .  8  9
     4.3.  Manual/Automatic Configuration of Location Information . . 11 12
   5.  Geodetic Coordinate Representation . . . . . . . . . . . . . . 12 13
   6.  Geodetic Shape Representation  . . . . . . . . . . . . . . . . 13 14
     6.1.  Polygon Restriction  . . . . . . . . . . . . . . . . . . . 15
     6.2.  Emergency Shape Representations  . . . . . . . . . . . . . 15
   7.  Recommendations  . . . . . . . . . . . . . . . . . . . . . . . 14 16
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15 17
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16 18
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17 19
   11. Open Issues References . . . . . . . . . . . . . . . . . . . . . . . . . 18
   12. . 20
     11.1. Normative references . . . . . . . . . . . . . . . . . . . 20
     11.2. Informative References . . . . . . . . . . . . . . . . . . 20
   Appendix A.  Uncertainty in The RFC-3825 LCI Representation  . . . 21
     A.1.  Conversion From LCI Form . . . . . . . . . . . . 19
     12.1. Normative references . . . . . 21
     A.2.  Conversion To LCI Form . . . . . . . . . . . . . . 19
     12.2. Informative References . . . . 22
       A.2.1.  Example 1  . . . . . . . . . . . . . . 19 . . . . . . . . 22
       A.2.2.  Example 2  . . . . . . . . . . . . . . . . . . . . . . 23
     A.3.  Problem  . . . . . . . . . . . . . . . . . . . . . . . . . 23
     A.4.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 23
   Appendix A. B.  Creating a PIDF-LO from DHCP Geo Encoded Data . . . . 20
     A.1. 25
     B.1.  Latitude and Longitude . . . . . . . . . . . . . . . . . . 20
     A.2. 25
     B.2.  Altitude . . . . . . . . . . . . . . . . . . . . . . . . . 22
     A.3. 27
     B.3.  Generating the PIDF-LO . . . . . . . . . . . . . . . . . . 22 27
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 32
   Intellectual Property and Copyright Statements . . . . . . . . . . 28 33

1.  CHANGES SINCE LAST TIME

   [[This section is informational only and will be removed before the
   final version.]]

1.1.  03  04 changes

   Removed some shape defintions, ellipses, arcbands.

   Removed OMA shape definition comparisons.

   Modified

   Added a section to recommend restricting Polygon to 16 points for
   routing and other real-time applications.

   Added section detailing caution when selecting shapes for emergency
   routing.

   Modified the recommendations section to include the two above
   additions.

   Added a second appendix detailing problems with expressing
   uncertainty using LCI.

1.2.  03 changes

   Removed some shape definitions, ellipses, arcbands.

   Removed OMA shape definition comparisons.

   Modified examples to use new civicAddr draft data.

   Made extensive references to the GeoShape Draft.

1.2.

1.3.  01 changes

   minor changes to the abstract.

   Minor changes to the introduction.

   Added and appendix to take implementers through how to create a
   PIDF-LO from data received using DHCP option 123 as defined in [2]. [3].

   Rectified examples to use position and pos rather than location and
   point.

   Corrected example 3 so that it does not violate SIP rules.

   Added addition geopriv elements to the status component of the figure
   in "Using Location Information" to more accurately reflect the
   cardinality issues.

   Revised text in section Geodetic Coordinate Representation.  Removed
   last example as this was addressed with the change to position and
   pos in previous examples.

2.  Introduction

   The Presence Information Data Format Location Object (PIDF-LO) [3] [2] is
   the IETF recommended way of encoding location information and
   associated privacy policies.  Location information in a PIDF-LO may
   be described in a geospatial manner based on a subset of GMLv3, or as
   civic location information [4]. [5].  A GML profile for expressing
   geodetic shapes in a PIDF-LO is described in [5].Uses [6].Uses for PIDF-LO are
   envisioned in the context of numerous location based applications.
   This document makes recommendations for formats and conventions to
   make interoperability less problematic.

3.  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 [1].

   In this document a "discrete location" is defined as a location that
   can be found based on the information used to describe it.  It is not
   necessarily a single point in space, but may be an area or volume
   depending on what is being defined and the required precision.

4.  Using Location Information

   The PIDF format provides for an unbounded number of tuples.  The
   geopriv element resides inside the status component of a tuple, hence
   a single PIDF document may contain an arbitrary number of location
   objects some or all of which may be contradictory or complementary.
   The actual location information is contained inside a <location-info>
   element, and there may be one or more actual locations described
   inside the <location-info> element.

   Graphically, the structure of the PIDF/PIDF-LO can be depicted as
   follows:

   PIDF document
      tuple 1
          status
               geopriv
                   location-info
                       civicAddress
                        location
                    usage-rules
               geopriv 2
               geopriv 3
               .
               .
               .

      tuple 2
      tuple 3

   All of these potential sources and storage places for location lead
   to confusion for the generators, conveyors and users of location
   information.  Practical experience within the United States National
   Emergency Number Association (NENA) in trying to solve these
   ambiguities led the following conventions being adopted:

   Rule #1: A geopriv element MUST describe a discrete location.

   Rule #2: Where a discrete location can be uniquely described in more
      than one way, each location description SHOULD reside in a
      separate tuple.

   Rule #3: Providing more than one location in a single presence
      document (PIDF) MUST only be done if all objects describe the same
      location.

   Rule #4: Providing more than one location in a single <location-info>
      element SHOULD be avoided where possible.

   Rule #5: When providing more than one location in a single
      <location-info> <location-
      info> element the locations MUST be provided by a common source.

   Rule #6: Providing more than one location in a single <location-info>
      element SHOULD only be done if they form a complex to describe the
      same location.  For example, a geodetic location describing a
      point, and a civic location indicating the floor in a building.

   Rule #7: Where a location complex is provided in a single
      <location-info> <location-
      info> element, the macro locations MUST be provided first.  For
      example, a geodetic location describing an area, and a civic
      location indicating the floor MUST be represented with the area
      first followed by the civic location.

   Rule #8: Where a PIDF document contains more than one tuple
      containing a status element with a geopriv location element , the
      priority of tuples SHOULD be based on tuple position within the
      PIDF document.  That is to say, the tuple with the highest
      priority location occurs earliest in the PIDF document.  Initial
      priority SHOULD be determined by the originating UA, the final
      priority MAY be determined by a proxy along the way, or the UAS.

   Rule #9: Where multiple PIDF documents are contained within a single
      request, document selection SHOULD be based on document order.

   The following examples illustrate the application of these rules.

4.1.  Single Civic Location Information

   Jane is at a coffee shop on the ground floor of a large shopping
   mall.  Jane turns on her laptop and connects to the coffee-shop's
   WiFi hotspot, Jane obtains a complete civic address for her current
   location, for example using [6]. the DHCP Civic mechanism defined in [4].
   A Location Object is constructed consisting of a single PIDF
   document, with a single geopriv tuple, and a single location residing
   in the <location-info> element.  This document is unambiguous, and
   should be interpreted correctly consitently by receiving nodes if sent
   of over the
   network.

4.2.  Civic and Geospatial Location Information

   Mike is visiting his Seattle office and connects his laptop into the
   Ethernet port in a spare cube.  Mike's computer receives a location
   over DHCP as defined in [2]. RFC-3825 [3].  In this case the location is a
   geodetic location, with the altitude represented as a building floor
   number.  This is constructed by Mike's computer into the following
   PIDF document:

   <?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:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape"
      entity="pres:mike@seattle.example.com">
     <tuple id="sg89ab">
       <status>
         <gp:geopriv>
           <gp:location-info>
             <cl:civicAddress>
                <cl:FLR>2</cl:FLR>
             </cl:civicAddress>
           </gp:location-info>
           <gp:usage-rules/>
         </gp:geopriv>
       </status>
       <timestamp>2006-01-30T20:57:29Z</timestamp>
     </tuple>
     <tuple id="sg89ae">
       <status>
         <gp:geopriv>
           <gp:location-info>
             <Polygon srsName="urn:ogc:def::crs:EPSG::4326"
                      xmlns="http://www.opengis.net/gml">
               <exterior>
                 <LinearRing>
                   <pos>37.775 -122.4194</pos>
                   <pos>37.555 -122.4194</pos>
                   <pos>37.555 -122.4264</pos>
                   <pos>37.775 -122.4264</pos>
                   <pos>37.775 -122.4194</pos>
                 </LinearRing>
               </exterior>
             </Polygon>
           </gp:location-info>
           <gp:usage-rules/>
         </gp:geopriv>
       </status>
       <timestamp>2006-01-30T20:57:29Z</timestamp>
     </tuple>
   </presence>

   The constructed PIDF document contains two geopriv elements each in a
   separate PIDF tuple, the first being a civic address made up of only
   floor, the second containing the provided geodetic information.  If
   the location is required for routing purposes, which information is
   used?  Applying rule #8, we will likely fail, or at a minimum need to
   fall back to the second tuple describing the geodetic location, a
   route described by floor only is not precise enough in the normal
   case to permit route selection.  If rule #6 and #7 are applied, then
   the revised PIDF-LO document creates a complex as shown below.

   <?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:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape"
      entity="pres:mike@seattle.example.com">
     <tuple id="sg89ab">
       <status>
         <gp:geopriv>
           <gp:location-info>
             <Polygon srsName="urn:ogc:def:crs:EPSG::4326"
                      xmlns="http://www.opengis.net/gml">
               <exterior>
                 <LinearRing>
                   <pos>37.775 -122.4194</pos>
                   <pos>37.555 -122.4194</pos>
                   <pos>37.555 -122.4264</pos>
                   <pos>37.775 -122.4264</pos>
                   <pos>37.775 -122.4194</pos>
                 </LinearRing>
               </exterior>
             </Polygon>
             <cl:civicAddress>
               <cl:FLR>2</cl:FLR>
             </cl:civicAddress>
           </gp:location-info>
           <gp:usage-rules/>
         </gp:geopriv>
       </status>
       <timestamp>2003-06-22T20:57:29Z</timestamp>
     </tuple>
   </presence>

   It is now clear that the main location of user is inside the
   rectangle bounded by the geodetic coordinates specfied. specified.  Further
   that the user is on the second floor of the building located at these
   coordinates.

4.3.  Manual/Automatic Configuration of Location Information

   Loraine has a predefined civic location stored in her laptop, since
   she normally lives in Sydney, the address in her address is for her
   Sydney-based apartment.  Loraine decides to visit sunny San
   Francisco, and when she gets there she plugs in her laptop and makes
   a call.  Loraine's laptop receives a new location from the visited
   network in San Francisco.  As ths this system cannot be sure that the pre-
   existing
   pre-existing and new location describe the same place, Loraine's
   computer generates a new PIDF-LO and will use this to represent
   Loraine's location.  If Loraine's computer were to add the new
   location to her existing PIDF location document (breaking rule #3),
   then the correct information may still be interpretted interpreted by location
   recipient providing Loraine's system applies rule #9.  In this case
   the resulting order of location information in the PIDF document
   should be San Francisco first, followed by Sydney.  Since the
   information is provided by different sources, rule #8 should also be
   applied and the information placed in different tuples with San
   Francisco first.

5.  Geodetic Coordinate Representation

   The geodetic examples provided in [3] RFC-4119 [2] are illustrated using
   the gml:
   location gml:location element which uses the gml:coordinates elements
   (inside the gml:Point element) and this representation has several
   drawbacks.  Firstly, it has been deprecated in later versions of GML
   (3.1 and beyond) making it inadvisable to use for new applications.
   Secondly, the format of the coordinates type is opaque and so can be
   difficult to parse and interpret to ensure consistent results, as the
   same geodetic location can be expressed in a variety of ways.  The
   PIDF-LO Geodetic Shapes specification [5] [6] provides a specific GML
   profile for expressing commonly used shapes using simple GML
   representations.  The shapes defined in [5] [6] are the recommended
   shapes to ensure interoperability between location based
   applications.

6.  Geodetic Shape Representation

   The cellular mobile world today makes extensive use of geodetic based
   location information for emergency and other location-based
   applications.  Generally these locations are expressed as a point
   (either in two or three dimensions) and an area or volume of
   uncertainty around the point.  In theory, the area or volume
   represents a coverage in which the user has a relatively high
   probability of being found, and the point is a convenient means of
   defining the centroid for the area or volume.  In practice, most
   systems use the point as an absolute value and ignore the
   uncertainty.  It is difficult to determine if systems have been
   implement in this manner for simplicity, and even more difficult to
   predict if uncertainty will play a more important role in the future.
   An important decision is whether an uncertainty area should be
   specified.

   [5]

   The PIDF-LO Geodetic Shapes specification [6] defines eight shape
   types most of which are easily translated in shapes definitions used
   in other applications and protocol, such as Open Mobile Alliance
   (OMA) Mobile Location Protocol (MLP).  For completeness the shape
   defined in [5] [6] are listed below:

   o  Point (2d or 3d)

   o  Polygon (2d)

   o  Circle (2d)

   o  Ellipse (2d)

   o  Arc band (2d)

   o  Sphere (3d circle)

   o  Ellipsoid (3d)

   o  Prism (3d polygon)

   [5]

   The GeoShape specification [6] also describes a standard set of
   coordinate reference systems (CRS), unit of measure and conventions
   relating to lines and
   distances that will be repeated here.

7.  Recommendations

   As a summary this document gives a few recommendations on distances.  GeoShape mandates the use the
   WGS-84 Coordinate reference system and restricts usage
   of location information to EPSG-4326
   for two dimensional (2d) shape representations and EPSG-4979 for
   three dimensional (3d) volume representations.  Distance and heights
   are expressed in PIDF-LO.  Nine rules specified metres using EPSG-9001.

6.1.  Polygon Restriction

   The Polygon shape type defined in
   Section 4 give guidelines [6] intentionally does not place
   any constraints on the ambiguity number of PIDF-LO with regard points that may be included to
   define the occurrence bounds of multiple location information.  It is recommend
   that only the shape types Polygon.  This allows arbitrarily complex
   shapes to be defined and shape representations described conveyed in [5]
   be used to express geodetic locations for exchange between general
   applications.  By standardizing geodetic data representation
   interoperability issues are mitigated.

   If Geodetic a PIDF-LO.  However where
   location information is to be provided via DHCP, then a minimum
   resolution used in real-time processing
   applications, such as location dependent routing, having arbitrarily
   complex shapes consisting of 20 bits SHOULD tens or even hundreds of points may
   result in significant performance impacts.  To mitigate this risk it
   is recommended that Polygons be specified for both the Latitude and
   Longitude fields to achieve sub 100 metre precision.  Where only two
   dimensional objects are required polygons SHOULD be used restricted to express
   the enclosed area.  Where 3 dimensions are required a rectangular
   prism SHOULD be used.

8.  Security Considerations

   The primary security considerations relate to how maximum of 16 points
   when the location information is conveyed and used, which are outside the scope of this
   document. intended for use in real-time
   applications.  This document limit of 16 points is intended chosen to serve only allow moderately
   complex shape definitions while at the same time enabling
   interworking with other location transporting protocols such as a set those
   defined in 3GPP ([7]) and OMA where the 16 point limit is already
   imposed.

6.2.  Emergency Shape Representations

   In some parts of
   guidelines as to which elements MUST or SHOULD the world cellular networks constraints are placed
   on the shape types that can be implemented by
   systems wishing used to perform represent the location dependent routing.  The
   ramification of such recommendations is that they extend an
   emergency caller.  These restrictions, while to devices
   and clients that wish some extend are
   artificial, may pose significant interoperability problems in
   emergency networks were they to make use of such services.

9.  IANA Considerations

   This document does not introduce any IANA considerations.

10.  Acknowledgments be unilaterally lifted.  The authors would like to thank the GEOPRIV working group for their
   discussions in the context largest
   impact likely being on PSAP CPE where multiple communication networks
   report emergency data.  Wholesale swap-out or upgrading of PIDF-LO, in particular Carl Reed, Ron
   Lake, James Polk and Henning Schulzrinne.  Furthermore, we would like this
   equipment is deemed to thank Jon Peterson as the author of PIDF-LO be complex and Nadine Abbott for
   her constructive comments costly and has resulted in clarifying some aspects a
   number of countries, most notably the document.

11.  Open Issues

   Do we need United States, to indicate which shapes adopt
   migratory standards towards emergency IP telephony support.  Where
   these migratory standards are implemented restrictions on acceptable for
   geodetic shape types to represent the location of an emergency
   calling?  Ceratinly not all caller
   may exist and MUST be adhered to.  Conversion from one shape type to
   another should be avoided to eliminate the introduction of errors in
   reported location.

   In North America the migratory VoIP emergency services standard (i2)
   implicitly imposes the restriction ([10]) that the geodetic shape be
   constrained to a point, point and uncertain circle, point with
   altitude and uncertainty circle.  These shapes can be easily
   represented using the GeoShape specification and map to Point, Circle
   and Sphere respectively.

7.  Recommendations

   As a summary this document gives a few recommendations on the usage
   of location information in PIDF-LO.  Nine rules specified in
   Section 4 give guidelines on the ambiguity of PIDF-LO with regard to
   the occurrence of multiple locations.

   It is recommend that only the shape types and shape representations
   described in [6] be used today, to express geodetic locations for example exchange
   between general applications.  By standardizing geodetic data
   representation interoperability issues are mitigated.

   It is recommended that Polygons be restricted to a maximum of 16
   points when used in location-dependent routing and other real-time
   applications to mitigate possible performance issues.  This allows
   for interoperability with other location protocols where this
   restriction applies.

   Geodetic location may require restricted shape definitions in regions
   where migratory emergency IP telephony implementations are deployed.
   Where the acceptable shape types are not understood restrictions to
   Point, Circle and Sphere representations should be used to
   accommodate most existing deployments.

   Conversions from one geodetic shape type to another should be avoided
   where data is considered critical and the introduction of errors
   considered unacceptable.

   If Geodetic information is to be provided via DHCP, then a minimum
   resolution of 20 bits SHOULD be specified for both the Latitude and
   Longitude fields to achieve sub 100 metre precision.  Where only two
   dimensional objects are required polygons SHOULD be used to express
   the enclosed area.  Where 3 dimensions are required a rectangular
   prism SHOULD be used.

8.  Security Considerations

   The primary security considerations relate to how location
   information is conveyed and used, which are outside the scope of this
   document.  This document is intended to serve only as a set of
   guidelines as to which elements MUST or SHOULD be implemented by
   systems wishing to perform location dependent routing.  The
   ramification of such recommendations is that they extend to devices
   and clients that wish to make use of such services.

9.  IANA Considerations

   This document does not introduce any IANA considerations.

10.  Acknowledgments

   The authors would like to thank the GEOPRIV working group for their
   discussions in the context of PIDF-LO, in particular Carl Reed, Ron
   Lake, James Polk and Henning Schulzrinne.  Furthermore, we would like
   to thank Jon Peterson as the author of PIDF-LO and Nadine Abbott for
   her constructive comments in clarifying some aspects of the document.

11.  References

11.1.  Normative references

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", March 1997.

   [2]  Peterson, J., "A Presence-based GEOPRIV Location Object Format",
        RFC 4119, December 2005.

   [3]  Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
        Configuration Protocol Option for Coordinate-based Location
        Configuration Information", RFC 3825, July 2004.

   [4]  Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4
        and DHCPv6) Option for Civic  Addresses Configuration
        Information", draft-ietf-geopriv-dhcp-civil-09 (work in
        progress), January 2006.

   [5]  Thomson, M. and J. Winterbottom, "Revised Civic Location Format
        for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-02 (work in
        progress), April 2006.

   [6]  Thomson, M., "draft-thomson-geopriv-geo-shape, Geodetic Shapes
        for the Representation of Uncertainty in PIDF-LO", January 2006.

11.2.  Informative References

   [7]   "3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project;
         Technical Specification Group Code Network; Universal
         Geographic Area Description (GAD)".

   [8]   Schulzrinne, H., "A Document Format for Expressing Privacy
         Preferences", draft-ietf-geopriv-common-policy-09 (work in
         progress), April 2006.

   [9]   "TR-45 J-STD-036-AD-2 Enhanced Wireless 9-1-1 Phase 2".

   [10]  "NENA Standard for the Implementation of the Wireless Emergency
         Service Protocol E2 Interface".

Appendix A.  Uncertainty in The RFC-3825 LCI Representation

   This Appendix should be regarded as informative only and provides
   guidance on aspects concerning the interpretation of uncertainty as
   it applies to the binary geodetic LCI representation defined in RFC-
   3825 [3].  No recommendation on the use or otherwise of LCI in
   applications is made.  However the risks of introducing large errors
   into reported location when LCI is used to represent uncertainty are
   clearly explained.

   RFC-3825 [3] defines a binary geodetic representation referred to as
   LCI.  The way that LCI represents uncertainty is through a resolution
   parameter that indicates how many binary digits of each axis are
   significant or accurate.  This is explained in detail in [3] with a
   series of examples with a further example provided in Appendix B of
   this document.  In short LCI describes a rectangular prism that is
   aligned along the north-south/east-west/up-down axes.

A.1.  Conversion From LCI Form

   From the example in RFC-3825, 38.89868 degrees is encoded into a
   34bit twos-complement number:

   000100110.1110011000001111111001000

   The resolution value for this axis indicates how many of this bits
   are actually significant.  A resolution of 18 indicates that the last
   16 bits of the number could be either 1 or zero:

   000100110.111001100xxxxxxxxxxxxxxxx

   To determine the uncertainty assume a range from the minimum possible
   value (all zeros for the last 16 bits) to the maximum (all ones):

   000100110.1110011000000000000000000 to
   000100110.1110011001111111111111111

   This yields the range in the example to be between 38.8984375 degrees
   and 38.9003906 degrees (rounded to 7 decimal places).

A.2.  Conversion To LCI Form

   This involves converting the original shape to a rectangular prism.
   To do this determine the minimum and maximum values for each of the
   axes: latitude, longitude and altitude.  This results in a slightly
   increased area, but the overall effect is minimal.

   +----------.....----------+
   |      _d^^^^^^^^^b_      |
   |   .d''yyyyyyyyyyy``b.   |
   | .p'yyyyyyyyyyyyyyyyy`q. |
   |.d'yyyyyyyyyyyyyyyyyyy`b.|
   .d'yyyyyyyyyyyyyyyyyyyyy`b.
   ::yyyyyyyyyyyyyyyyyyyyyyy::
   ::  ...................  ::
   ::vvvvvvvvvvvvvvvvvvvvvvv::
   `p.vvvvvvvvvvvvvvvvvvvvv.q'
   |`p.vvvvvvvvvvvvvvvvvvv.q'|
   | `b.vvvvvvvvvvvvvvvvv.d' |
   |   `q..vvvvvvvvvv..p'  <-+----Area Increase
   |     ^q........p^        |
   +---------''''------------+

   It's important to note the resulting area cannot be less that the
   starting area.  This is because the starting area represents a set of
   points and the Target may reside at anyone of these points with equal
   probability.  If the area is cropped there is a risk that the
   Target's position will be one of the discarded points yielding an
   incorrect result.  In general the increases in area are minimal, for
   a circular area, as shown, the increase ratio is 4:pi; a square
   building will at most double the size of the area.

A.2.1.  Example 1

   Looking at a random example from 32.98004 degrees to 32.98054397
   degrees the approximate distance is 56 metres.  Converting each value
   into a The 34-bit twos-complement number yields the following:

   000100000.1111101011100011111001110 to
   000100000.1111101100000100111011100
   ^^^^^^^^^^^^^^^^^

   To ensure that the encoded value represents the full range from the
   lowest to highest value, take the common stem as marked this above.

   There are 16 common bits between low and high.  To check, convert the
   value back by making the last 18 bits either 0 or 1 as described
   earlier.  This leads to a range from 32.9765625 degrees to 32.9843745
   degrees, which is approximately 870 metres a significant increase
   over the original 56 metres.

A.2.2.  Example 2

   Take the range from 31.9999985 degrees to 32.00000274 degrees, which
   is about 0.5 metres in distances ranging around 32 degrees.  This
   results in the following binary values:

   000011111.1111111111111111111001110 to
   000100000.0000000000000000001011100
   ^^^

   Only 3 bits are common to both values which yields an encoded range
   from 0 to 64 degrees, or a distance of 3,500 kilometres.

A.3.  Problem

   The LCI encoding breaks when the uncertainty that is being
   represented causes a change in a relatively significant binary digit.
   This results in an expanded uncertainty, possibly very large,
   depending on which binary digit changes.  In many cases the change
   will be in lower-order digits, which will result in a relatively
   small increase in uncertainty, but certain values will yield an
   almost useless location see Appendix A.2.2.

   This problem is exacerbated at the three zero points - the Greenwich
   Meridian, Equator and at the surface of the geoid (altitude).  In
   these cases, if the input uncertainty spans the
   polygon and prism types will not work with NENA i2 zero point, the
   resolution value ends up as zero; that is, it indicates that there is defined
   today due to restrictions over the VE2 interface [7].

12.  References

12.1.  Normative references

   [1]  Bradner, S., "Key words
   no useful information for use in RFCs that parameter.

   The original uncertainty has very little bearing on this problem - a
   small value can be increased to Indicate Requirement
        Levels", March 1997.

12.2.  Informative References

   [2]   Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
         Configuration Protocol Option for Coordinate-based Location
         Configuration Information", RFC 3825, July 2004.

   [3]   Peterson, J., "A Presence-based GEOPRIV Location Object
         Format", RFC 4119, December 2005.

   [4]   Thomson, M. and J. Winterbottom, "Revised Civic Location Format
         for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-01 (work in
         progress), January 2006.

   [5]   Thomson, M., "draft-thomson-geopriv-geo-shape, Geodetic Shapes
         for any value.  More precise location
   determination technologies only reduce the Representation probability of large
   problems occurring, although the nature of the encoding is such that
   any uncertainty can be greatly increased.

A.4.  Conclusion

   Uncertainty in PIDF-LO",
         January 2006.

   [6]   Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 is a reality of location and DHCPv6) Option for Civic  Addresses Configuration
         Information", draft-ietf-geopriv-dhcp-civil-09 (work in
         progress), January 2006.

   [7]   "NENA Standard important for the Implementation a number of the Wireless Emergency
         Service Protocol E2 Interface".

   [8]   Schulzrinne, H., "A Document Format
   applications.  LCI's limited form means that adapting existing
   uncertainty information, for Expressing Privacy
         Preferences", draft-ietf-geopriv-common-policy-07 (work example a circle as in
         progress), February 2006.

   [9]   "3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project;
         Technical Specification Group Code Network; Universal
         Geographic Area Description (GAD)".

   [10]  "TR-45 J-STD-036-AD-2 Enhanced Wireless 9-1-1 Phase 2". Appendix A. A.2.2,
   results in a small error.  The introduction of this small encoding
   error however is insignificant when compared to the error that can be
   introduced by the way that the resolution parameter is interpreted.

Appendix B.  Creating a PIDF-LO from DHCP Geo Encoded Data

   This appendix is informative only.

   RFC-3825 [2] [3] describes a means by which an end-point may learns learn it
   location from information encoded into DHCP option 123.  The
   following section describes how and end-point can take this
   information and represent it in a well formed PIDF-LO describing this
   geodetic location.

   The location information described in RFC-3825 consists of a
   latitude, longitude, altitude and datum.

A.1.

B.1.  Latitude and Longitude

   The latitude and longitude values are represented in degrees and
   decimal degrees.  Latitude values are positive if north of the
   equator, and negative if south of the equator.  Similarly
   longitudinal values are positive if east of the Greenwich meridian,
   and negative if west of the Greenwich meridian.

   The latitude and longitude values are each 34 bit long fields
   consisting of a 9 bit integer component and a 25 bit fraction
   component, with negative numbers being represented in 2s complement
   notation.  The latitude and longitude fields are each proceeded by a
   6 bit resolution field, the LaRes for latitude, and the LoRes for
   longitude.  The value in the LaRes field indicates the number of
   significant bits to interpret in the Latitude field, while the value
   in the LoRes field indicates the number of significant bits to
   interpret in the Longitude field.

   For example, if you are in Wollongong Australia which is located at
   34 Degrees 25 minutes South and 150 degrees 32 minutes East this
   would translate to -34.41667, 150.53333 in decimal degrees.  If these
   numbers are translated to their full 34 bit representations, then we
   arrive the following:

   Latitude = 111011101.1001010101010101000111010

   Longitude = 0100101101000100010001000010100001

   RFC-3825, uses the LaRes and LoRes values to specify a lower and
   upper boundary for location thereby specifying an area.  The size of
   the area specified is directly related to the value specified in the
   LaRes and LoRes fields.

   Using the previous example, if LaRes is set 7, then lower latitude
   boundary can be calculated as -256+128+64+16+8+4, which is -36
   degrees, the upper boundary then becomes -256+128+64+16+8+4+2+1 which
   is -35 degrees.  LoRes may be used similarly for Longitude.

   So what level of precision is useful?  Well, certain types of
   applications and regulations call for different levels of precision,
   and the required precision may vary depending on how the location was
   determined.  For Cellular 911 calls in the United States, for
   example, if the network measures the location then the caller should
   be within 100 metres, while if the handset does the measurement then
   the location should be within 50 metres.  Since DHCP is a network
   based mechanism we will benchmark off 100 metres (approximately 330
   ft) which is still a large area.

   For simplicity we shall assume that we are defining a square, in
   which we are equally to appear anywhere.  The greatest distance
   through this square is across the diagonal, so we make this 100
   metres.

   +----------------------+
   |                    _/|
   |                  _/  |
   |                _/    |
   |              _/      |
   |            _/        |
   |       100_/ metres   |
   |        _/            |
   |      _/              |
   |    _/                |
   |  _/                  |
   |_/                    |
   +----------------------+

   The distance between the top and the bottom and the left and the
   right is the same, the area being a square, and this works out to be
   70.7 metres.  When expressed in decimal degrees, the third point
   after the decimal place represents about 100 metre precision, this
   equates to 10 binary places of fractional part.  A 70 metre distance
   is required, so 11 fractional binary digits are necessary resulting
   in a total of 20 bits of precision.

   With -34.4167, 150.5333 encoded with 20 bits of precision for the
   LaRes and LoRes, the corners of the enclosing square are:

   Point 1 (-34.4170, 150.5332)
   Point 2 (-34.4170, 150.5337)
   Point 3 (-34.4165, 150.5332)
   Point 4 (-34.4165, 150.5337)

A.2.

B.2.  Altitude

   The altitude elements define how the altitude is encoded and to what
   level of precision.  The units for altitude are either metres, or
   floors, with the actual measurement being encoded in a similar manner
   to those for latitude and longitude, but with 22 bit integer, and 8
   bit fractional components.

A.3.

B.3.  Generating the PIDF-LO

   If altitude is not required, or is expressed in floors then a
   geodetic location expressed by a polygon SHOULD be used, with points
   expressed in a counter-clockwise direction.  If the altitude is
   expressed in floors and is required, the altitude SHOULD be expressed
   as a civic floor number as part of the same location-info <location-info> element.
   In the example above the GML for the location would be expressed as
   follows:

     <Polygon srsName="urn:ogc:def:crs:EPSG::4326"
              xmlns="http://www.opengis.net/gml">
       <exterior>
         <LinearRing>
            <pos>-34.4165 150.5332</pos>
            <pos>-34.4170 150.5532</pos>
            <pos>-34.4170 150.5537</pos>
            <pos>-34.4165 150.5337</pos>
            <pos>-34.4165 150.5332</pos>
         </LinearRing>
        </exterior>
      </Polygon>

   If a floor number of say 3 were included, then the location-info location-;info
   element would contain the above information and the following:

   <civicAddress
      xlmns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
      <FLR>2</FLR>
   </civicAddress>
   When altitude is expressed as an integer and fractional component, as
   with the latitude and longitude, it expresses a range which requires
   the prism form to be used.  Care must be taken to ensure that the
   points are defined in a counter-clowise counter-clockwise direction to ensure that
   the upward normal points up.

   Extending the previous example to include an altitude expressed in
   metres rather than floors.  AltRes is set to a value of 19, and the
   Altitude value is set to 34.  Using similar techniques as shown in
   the latitude and longitude section, a range of altitudes between 32
   metres and 40 metres is described.  The prism would therefore be
   defined as follows:

   <Prism  srsName="urn:ogc:def:crs:EPSG::4976"
           xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape"
           xmlns:gml="http://www.opengis.net/gml">
      <base>
         <gml:Polygon>
            <gml:exterior>
               <gml:LinearRing>
                  <gml:pos>-34.4165 150.5332 32</gml:pos>
                  <gml:pos>-34.4170 150.5532 32</gml:pos>
                  <gml:pos>-34.4170 150.5537 32</gml:pos>
                  <gml:pos>-34.4165 150.5337 32</gml:pos>
                  <gml:pos>-34.4165 150.5332 32</gml:pos>
               </gml:LinearRing>
            </gml:exterior>
         </gml:Polygon>
      </base>
      <height uom="urn:ogc:def:uom:EPSG::9001">
         8
      </height>
   </Prism>

   The Method value SHOULD be set to DHCP.  Note that this case, the
   DHCP is referring to the way in which location information was
   delivered to the IP-device, and not necessarily how the location was
   determined.

   The timestamp value SHOULD be set to the time that location was
   retrieved from the DHCP server.

   The client application MAY insert any usage rules that are pertinent
   to the user of the device and that comply with [8].  A guideline is
   that the any retention-expiry value SHOULD NOT exceed the current
   lease time.

   The Provided-By element SHOULD NOT be populated as this is not
   provided by the source of the location information.

   The 3 completed PIDF-LO representations are provided below, and
   represent a location without altitude, a location with a civic
   altitude, and a location represented as a 3 dimensional rectangular
   prism.

   <?xml version="1.0"?>
   <presence xmlns="urn:ietf:params:xml:ns:pidf"
             xmlns:pidf="urn:ietf:params:xml:ns:pidf"
             xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
             xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape"
             xmlns:gml="http://www.opengis.net/gml"
             entity="pres:user@example.com">
     <tuple id="a6fea09">
       <status>
         <gp:geopriv>
           <gp:location-info>
               <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
                  <gml:exterior>
                     <gml:LinearRing>
                        <gml:pos>-34.4165 150.5332</gml:pos>
                        <gml:pos>-34.4170 150.5532</gml:pos>
                        <gml:pos>-34.4170 150.5537</gml:pos>
                        <gml:pos>-34.4165 150.5337</gml:pos>
                        <gml:pos>-34.4165 150.5332</gml:pos>
                     </gml:LinearRing>
                  </gml:exterior>
               </gml:Polygon>
           </gp:location-info>
           <gp:usage-rules/>
                <gp:method>DHCP</gp:method>
         </gp:geopriv>
       </status>
       <timestamp>2005-07-05T14:49:53+10:00</timestamp>
     </tuple>
   </presence>
   <?xml version="1.0"?>
   <presence xmlns="urn:ietf:params:xml:ns:pidf"
             xmlns:pidf="urn:ietf:params:xml:ns:pidf"
             xmlns:cl=" urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
             xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape"
             xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
             xmlns:gml="http://www.opengis.net/gml"
             entity="pres:user@example.com">
     <tuple id="a6fea09">
       <status>
         <gp:geopriv>
           <gp:location-info>
              <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
                  <gml:exterior>
                     <gml:LinearRing>
                        <gml:pos>-34.4165 150.5332</gml:pos>
                        <gml:pos>-34.4170 150.5532</gml:pos>
                        <gml:pos>-34.4170 150.5537</gml:pos>
                        <gml:pos>-34.4165 150.5337</gml:pos>
                        <gml:pos>-34.4165 150.5332</gml:pos>
                     </gml:LinearRing>
                  </gml:exterior>
               </gml:Polygon>
             <cl:civilAddress>
               <cl:FLR>2</cl:FLR>
             </cl:civilAddress>
           </gp:location-info>
           <gp:usage-rules/>
                <gp:method>DHCP</gp:method>
         </gp:geopriv>
       </status>
       <timestamp>2005-07-05T14:49:53+10:00</timestamp>
     </tuple>
   </presence>
   <?xml version="1.0"?>
   <presence xmlns="urn:ietf:params:xml:ns:pidf"
             xmlns:pidf="urn:ietf:params:xml:ns:pidf"
             xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
             xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape"
             xmlns:gml="http://www.opengis.net/gml"
             entity="pres:user@example.com">
     <tuple id="a6fea09">
       <status>
         <gp:geopriv>
           <gp:location-info>
               <gs:Prism  srsName="urn:ogc:def:crs:EPSG::4976">
                  <gs:base>
                     <gml:Polygon>
                        <gml:exterior>
                           <gml:LinearRing>
                              <gml:pos>-34.4165 150.5332 32</gml:pos>
                              <gml:pos>-34.4170 150.5532 32</gml:pos>
                              <gml:pos>-34.4170 150.5537 32</gml:pos>
                              <gml:pos>-34.4165 150.5337 32</gml:pos>
                              <gml:pos>-34.4165 150.5332 32</gml:pos>
                           </gml:LinearRing>
                        </gml:exterior>
                     </gml:Polygon>
                  </gs:base>
                  <gs:height uom="urn:ogc:def:uom:EPSG::9001">
                     8
                  </gs:height>
               </gs:Prism>
           </gp:location-info>
           <gp:usage-rules/>
           <gp:method>DHCP</gp:method>
         </gp:geopriv>
       </status>
       <timestamp>2005-07-05T14:49:53+10:00</timestamp>
     </tuple>
   </presence>

Authors' Addresses

   James Winterbottom
   Andrew Corporation
   Wollongong
   NSW Australia

   Email: james.winterbottom@andrew.com

   Martin Thomson
   Andrew Corporation
   Wollongong
   NSW Australia

   Email: martin.thomson@andrew.com

   Hannes Tschofenig
   Siemens
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   Email: Hannes.Tschofenig@siemens.com

Intellectual Property Statement

   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.

Disclaimer of Validity

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

Copyright Statement

   Copyright (C) The Internet Society (2006).  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.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.