Geopriv                                                  J. Winterbottom
Internet-Draft                                                M. Thomson
Intended status: Informational                        Andrew Corporation
Expires: April 26, September 6, 2007                            Andrew Corporation
                                                           H. Tschofenig
                                           Siemens
                                                        October 23, 2006 Networks GmbH & Co KG
                                                           March 5, 2007

GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations
               draft-ietf-geopriv-pdif-lo-profile-05.txt
               draft-ietf-geopriv-pdif-lo-profile-06.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 April 26, September 6, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006). IETF Trust (2007).

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  . . . . . . . . . . . . . . . . . . .  4
     1.1.  05 changes . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  04 changes . . . . . . . . . . . . . . . . . . . . . . .  Introduction .  4
     1.3.  03 changes . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.4.  01 changes . . . . . . . . .
   2.  Terminology  . . . . . . . . . . . . . . .  4
   2.  To Do . . . . . . . . . .  5
   3.  Using Location Information . . . . . . . . . . . . . . . . . .  6
   3.  Introduction .
     3.1.  Single Civic Location Information  . . . . . . . . . . . .  8
     3.2.  Civic and Geospatial Location Information  . . . . . . . .  8
     3.3.  Manual/Automatic Configuration of Location Information . .  9
   4.  Geodetic Coordinate Representation . .  7
   4.  Terminology . . . . . . . . . . . . 10
   5.  Geodetic Shape Representation  . . . . . . . . . . . . .  8
   5.  Using Location Information . . . 11
     5.1.  Polygon Restrictions . . . . . . . . . . . . . . .  9
     5.1.  Single Civic Location Information . . . . 12
     5.2.  Complex Shape Examples . . . . . . . . 11
     5.2.  Civic and Geospatial Location Information . . . . . . . . 11
     5.3.  Manual/Automatic Configuration of Location Information . . 12
   6.  Geodetic Coordinate
       5.2.1.  Polygon Representation and Usage . . . . . . . . . . . . . . 14
   7.  Geodetic Shape 12
       5.2.2.  Prism Representation and Usage . . . . . . . . . . . . 14
       5.2.3.  Arc Band Respresentation and Usage . . . . 15
     7.1.  Polygon Restriction  . . . . . . . . . 16
       5.2.4.  Ellipsoid Representation and Usage . . . . . . . . . . 16
     7.2. 18
     5.3.  Emergency Shape Representations  . . . . . . . . . . . . . 16
   8. 20
   6.  Recommendations  . . . . . . . . . . . . . . . . . . . . . . . 17
   9. 22
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   10. 23
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   11. 24
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 20
   12. 25
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     12.1. 26
     10.1. Normative references . . . . . . . . . . . . . . . . . . . 21
     12.2. 26
     10.2. Informative References . . . . . . . . . . . . . . . . . . 21
   Appendix A.  Uncertainty in The RFC-3825 LCI Representation  . . . 22
     A.1.  Conversion From LCI Form . . . . . . . . . . . . . . . . . 22
     A.2.  Conversion To LCI Form . . 26
   Authors' Addresses . . . . . . . . . . . . . . . . 22
       A.2.1.  Example 1 . . . . . . . . 27
   Intellectual Property and Copyright Statements . . . . . . . . . . . . . . 23
       A.2.2.  Example 2  . . . . . . . . . . . . . . . . . . . . . . 24
     A.3.  Problem  . . . . . . . . . . . . . . . . . . . . . . . . . 24
     A.4.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 24
   Appendix B.  Creating a PIDF-LO from DHCP Geo Encoded Data . . . . 26
     B.1.  Latitude and Longitude . . . . . . . . . . . . . . . . . . 26
     B.2.  Altitude . . . . . . . . . . . . . . . . . . . . . . . . . 28
     B.3.  Generating the PIDF-LO . . . . . . . . . . . . . . . . . . 28
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
   Intellectual Property and Copyright Statements . . . . . . . . . . 34

1.  CHANGES SINCE LAST TIME

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

1.1.  05 changes

   Clarified definitions more.

   Clarified rules.

   Clarified examples, and removed confusion caused by the illustration
   of how not to represent location.

1.2.  04 changes

   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.3.  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.4.  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 [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.  To Do

   Get Appendices moved into the RFC 3825 Biz document.

   Get an OGC reference for the GeoShapes specification

3.  Introduction

   The Presence Information Data Format Location Object (PIDF-LO) [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 [5].  A GML profile for expressing
   geodetic shapes in a PIDF-LO is described in [7].  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.

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

   The definition for "Target" is taken from [6].

   In this document a "discrete location" is defined as a place, point,
   area or volume in which a Target can be found.  It must be described
   with sufficient precision to address the requirements of an intended
   application.

   The term "location complex" is used to describe location information
   represented by a composite of both civic and geodetic information.
   An example of a location complex might be a geodetic polygon
   describing the perimeter of a building and a civic element
   representing the floor in the building.

5.  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 to a set of conventions being adopted.  These rules
   do not have any particular order, but should be followed by creators
   and users of location information conatined in a PIDF-LO to ensure
   that a consistent interpretation of the data can be achieved.

   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.  This may occur if a Target's location is determined
      using a series of different techniques.

   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> 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> element, the coarse location information MUST be provided
      first.  For example, a geodetic location describing an area, and a
      civic location indicating the floor should 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.

   Rule #9:  Where multiple PIDF documents can be sent of received
      together, say in a multi-part MIME body, and current location
      information is required by the recipient, then document selection
      SHOULD be based on document order, with the first document be
      considered first.

   The following examples illustrate the application of these rules.

5.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 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 consitently by receiving nodes if sent over the
   network.

5.2.  Civic and Geospatial Location Information

   Mike is visiting his Seattle office and connects his laptop into the
   Ethernet port in a spare cube.  In this case the location is a
   geodetic location, with the altitude represented as a building floor
   number.  The main location of user is inside the rectangle bounded by
   the geodetic coordinates specified.  Further that the user is on the
   second floor of the building located at these coordinates.  Applying
   rules #6 and #7 are applied, the 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>

5.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 is 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 this system cannot be sure that the
   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 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.

6.  Geodetic Coordinate Representation 28

1.  Introduction

   The geodetic examples provided in RFC 4119 Presence Information Data Format Location Object (PIDF-LO) [2] are illustrated using
   the 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 IETF recommended way of encoding location can be expressed information and
   associated privacy policies.  Location information in a variety of ways.  The PIDF-LO Geodetic Shapes specification [7] provides may
   be described in a specific geospatial manner based on a subset of GMLv3, or as
   civic location information [4].  A GML profile for expressing commonly used shapes using simple GML
   representations.  The
   geodetic shapes defined in [7] a PIDF-LO is described in [6].  Uses for PIDF-LO
   are envisioned in the recommended
   shapes to ensure interoperability between context of numerous location based
   applications.

7.  Geodetic Shape Representation

   The cellular mobile world today  This document makes extensive use of geodetic based
   location information recommendations for emergency formats and other location-based
   applications.  Generally these locations
   conventions to make interoperability less problematic.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are expressed to be interpreted as a point
   (either described in two or three dimensions) and an area or volume of
   uncertainty around the point. [1].

   The definition for "Target" is taken from [5].

   In theory, the this document a "discrete location" is defined as a place, point,
   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. Target can be found.  It is difficult to determine if systems have been
   implement in this manner for simplicity, and even more difficult must be described
   with sufficient precision to
   predict if uncertainty will play a more important role in address the future.
   An important decision is whether requirements of an uncertainty area should be
   specified. intended
   application.

   The PIDF-LO Geodetic Shapes specification [7] defines eight shape
   types most of which are easily translated in shapes definitions term "location complex" is used
   in other applications and protocol, such as Open Mobile Alliance
   (OMA) Mobile Location Protocol (MLP).  For completeness the shape
   defined in [7] 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)

   The GeoShape specification [7] also describes to describe location information
   represented by a standard set of
   coordinate reference systems (CRS), unit composite of measure and conventions
   relating to lines both civic and distances.  GeoShape mandates the use geodetic information.
   An example of a location complex might be a geodetic polygon
   describing the
   WGS-84 Coordinate reference system and restricts usage to EPSG-4326
   for two dimensional (2d) shape representations and EPSG-4979 for
   three dimensional (3d) volume representations.  Distance perimeter of a building and heights
   are expressed in meters using EPSG-9001.

7.1.  Polygon Restriction

   The Polygon shape type defined a civic element
   representing the floor in [7] intentionally does not place
   any constraints on the building.

3.  Using Location Information

   The PIDF format provides for an unbounded number of vertices that may be included to
   define tuples.  The
   geopriv element resides inside the bounds status component of the Polygon.  This allows arbitrarily complex
   shapes to be defined and conveyed in a PIDF-LO.  However where
   location information is to be used in real-time processing
   applications, such as location dependent routing, having arbitrarily
   complex shapes consisting tuple, hence
   a single PIDF document may contain an arbitrary number of tens location
   objects some or even hundreds all of points which may
   result in significant performance impacts.  To mitigate this risk it
   is recommended that Polygons be restricted to a maximum of 16 points
   when the contradictory or complementary.
   The actual location information is intended for use in real-time
   applications.  This limit of 16 points is chosen to allow moderately
   complex shape definitions while at the same time enabling
   interworking with other location transporting protocols such as those
   defined in 3GPP ([8]) contained inside a <location-info>
   element, and OMA where there may be one or more actual locations described
   inside the 16 point limit is already
   imposed.

   Polygons are defined with <location-info> element.

   Graphically, the minimum distance between two adjacent
   vertices (geodesic).  A connecting line SHALL NOT cross another
   connecting line structure of the PIDF-LO can be depicted as follows:

   PIDF document
      tuple 1
          status
               geopriv
                   location-info
                       civicAddress
                       geodetic
                       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 same Polygon.  Polygons SHOULD be defined with generators, conveyors and users of location
   information.  Practical experience within the upward normal pointing up, this is accomplished United States National
   Emergency Number Association (NENA) in trying to solve these
   ambiguities led to a set of conventions being adopted.  These rules
   do not have any particular order, but should be followed by defining the
   vertices creators
   and users of location information contained in counter-clockwise direction.

7.2.  Emergency Shape Representations

   In some parts a PIDF-LO to ensure
   that a consistent interpretation of the world cellular networks constraints are placed
   on the shape types that data can be used to represent achieved.

   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.  This may occur if a Target's location is determined
      using a series of an
   emergency caller.  These restrictions, while to some extend are
   artificial, may pose significant interoperability problems different techniques.

   Rule #4:  Providing more than one location in
   emergency networks were they to a single <location-
      info> element SHOULD be unilaterally lifted.  The largest
   impact likely being on Public Safety Answer Point (PSAP) avoided where
   multiple communication networks report emergency data.  Wholesale
   swap-out or upgrading of this equipment is deemed to be complex and
   costly and has resulted possible.

   Rule #5:  When providing more than one location in a number of countries, most notably single
      <location-info> element the
   United States, to adopt migratory standards towards emergency IP
   telephony support.  Where these migratory standards are implemented
   restrictions on acceptable geodetic shape types to represent locations MUST be provided by a common
      source at the
   location of an emergency caller may exist.  Conversion from same time and by the same method.

   Rule #6:  Providing more than one shape
   type to another should location in a single <location-
      info> element SHOULD only be avoided done if they form a complex to eliminate
      describe the introduction of
   errors in reported same location.

   In North America the migratory VoIP emergency services standard (i2)
   [11] reuses the NENA E2 interface [12] which restriction  For example, a geodetic
   shape representation to location
      describing a point, and a point with an uncertain circle, civic location indicating the floor in a
   point with
      building.

   Rule #7:  Where a location complex is provided in a single <location-
      info> element, the coarse location information MUST be provided
      first.  For example, a geodetic location describing an altitude area, and an uncertainty circle.  The NENA
   recommended shapes can a
      civic location indicating the floor should be represented in a PIDF-LO using with the GeoShape
   Point, GeoShape Circle, and GeoShape Sphere definitions respectively.

8.  Recommendations

   As
      area first followed by the civic location.

   Rule #8:  Where a summary, this PIDF document gives contains more than one tuple
      containing a few recommendations on status element with a geopriv location element , the usage
      priority of location information in PIDF-LO.  Nine rules specified in
   Section 5 give guidelines tuples SHOULD be based on avoiding ambiguity tuple position within the
      PIDF document.  That is to say, the tuple with the highest
      priority location occurs earliest in PIDF-LO
   interpretations when the PIDF document.

   Rule #9:  Where multiple locations may PIDF documents can be provided to a Target sent or received
      together, say in a multi-part MIME body, and current location recipient.

   It
      information is recommend that only required by the shape types and shape representations
   described in [7] recipient, then document selection
      SHOULD be used to express geodetic locations for exchange
   between general applications.  By standardizing geodetic data
   representation interoperability issues are mitigated.

   It is recommended that GML Polygons based on document order, with the first document be restricted to
      considered first.

   The following examples illustrate the application of these rules.

3.1.  Single Civic Location Information

   Jane is at a maximum coffee shop on the ground floor of 16
   points when used in location-dependent routing a large shopping
   mall.  Jane turns on her laptop and other real-time
   applications connects to mitigate possible performance issues.  This allows the coffee-shop's
   WiFi hotspot, Jane obtains a complete civic address for interoperability her current
   location, for example using the DHCP civic mechanism defined in [3].
   A Location Object is constructed consisting of a single PIDF
   document, with other location protocols where this
   restriction applies.

   Geodetic a single geopriv tuple, and a single location may require restricted shape definitions residing
   in regions
   where migratory emergency IP telephony implementations are deployed.
   Where the acceptable shape types are not understood restrictions to
   Point, Circle <location-info> element.  This document is unambiguous, and Sphere representations should be used to
   accommodate most existing deployments.

   Conversions from one geodetic shape type to another
   should be avoided
   where data interpreted consistently by receiving nodes if sent over
   the network.

3.2.  Civic and Geospatial Location Information

   Mike is considered critical visiting his Seattle office and connects his laptop into the introduction of errors
   considered unacceptable.

   If geodetic information
   Ethernet port in a spare cube.  In this case the location is to be provided via DHCP, then a minimum
   resolution of 20 bits SHOULD be specified for both
   geodetic location, with the Latitude and
   Longitude fields to achieve sub 100 meter precision.

9.  Security Considerations

   The primary security considerations relate to how altitude represented as a building floor
   number.  Mike's main location
   information is conveyed the point specified by the geodetic
   coordinates.  Further, Mike is on the second floor of the building
   located at these coordinates.  Applying rules #6 and used, which #7 are outside applied,
   the scope of this
   document.  This PIDF-LO document is intended to serve only as creates a set of
   guidelines complex as to which elements MUST or SHOULD be implemented by
   systems wishing to perform location dependent routing.  The
   ramification 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:gml="http://www.opengis.net/gml"
      entity="pres:mike@seattle.example.com">
     <tuple id="sg89ab">
       <status>
         <gp:geopriv>
           <gp:location-info>
             <gml:Point srsName="urn:ogc:def:crs:EPSG::4326"
                <gml:pos>-43.5723 153.21760</gml:pos>
             </gml:Point>
             <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>

3.3.  Manual/Automatic Configuration of such recommendations Location Information

   Loraine has a predefined civic location stored in her laptop, since
   she normally lives in Sydney, the address is that they extend for her Sydney-based
   apartment.  Loraine decides to devices visit sunny San Francisco, and clients that wish to make use of such services.

10.  IANA Considerations

   This document does not introduce any IANA considerations.

11.  Acknowledgments

   The authors would like to thank the GEOPRIV working group for their
   discussions when
   she gets there she plugs in her laptop and makes a call.  Loraine's
   laptop receives a new location from the context of PIDF-LO, visited network in particular Carl Reed, Ron
   Lake, James Polk San
   Francisco.  As this system cannot be sure that the pre-existing, and Henning Schulzrinne.  Furthermore, we would like
   to thank Jon Peterson as
   new location, describe the author of same place, Loraine's computer generates a
   new PIDF-LO and Nadine Abbott for
   her constructive comments in clarifying some aspects of the document.

12.  References

12.1.  Normative references

   [1]  Bradner, S., "Key words for will use in RFCs this 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 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 interpreted by location recipient providing Loraine's
   system applies rule #9.  In this case the resulting order of location
   information in
        progress), January 2006.

   [5]  Thomson, M. 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 J. Winterbottom, "Revised Civic Location Format
        for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-04 (work the information placed in
        progress), September 2006.

   [6]  Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
        Polk, "Geopriv Requirements", RFC 3693, February 2004.

   [7]  Thomson, M., "draft-thomson-geopriv-geo-shape, Geodetic Shapes
        for
   different tuples with the tuple containing the San Francisco location
   first.

4.  Geodetic Coordinate Representation of Uncertainty

   The geodetic examples provided in PIDF-LO", January 2006.

12.2.  Informative References

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

   [9]   Schulzrinne, H., "Common Policy: A Document Format for
         Expressing Privacy Preferences",
         draft-ietf-geopriv-common-policy-11 (work RFC 4119 [2] are illustrated using
   the 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 progress),
         August 2006.

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

   [11]  "abbrev"i2">NENA VoIP-Packet Technical Committee, Interim VoIP
         Architecture for Enhanced 9-1-1 Services (i2), NENA 08-001, Dec
         2005".

   [12]  "NENA Standard later versions of GML
   (3.1 and beyond) making it inadvisable to use for new applications.
   Secondly, the Implementation format of the Wireless Emergency
         Service Protocol E2 Interface, NENA 05-001, Dec 2003".

Appendix A.  Uncertainty 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 RFC-3825 LCI Representation

   RFC-3825 [3] defines
   PIDF-LO Geodetic Shapes specification [6] provides a binary geodetic representation referred specific GML
   profile for expressing commonly used shapes using simple GML
   representations.  The shapes defined in [6] are the recommended
   shapes to as
   Location Configuration Information LCI. ensure interoperability between location based
   applications.

5.  Geodetic Shape Representation

   The way that LCI represents
   uncertainty is through a resolution parameter that indicates how many
   binary digits cellular mobile world today makes extensive use of each axis geodetic based
   location information for emergency and other location-based
   applications.  Generally these locations are significant or accurate.  This is
   explained expressed as a point
   (either in detail two or three dimensions) and an area or volume of
   uncertainty around the point.  In theory, the area or volume
   represents a coverage in [3] with which the user has a series relatively high
   probability of examples, with being found, and the point is a further
   example provided in Appendix B convenient means of this document.
   defining the centroid for the area or volume.  In short LCI
   describes a rectangular prism that is aligned along practice, most
   systems use the north-south/
   east-west/up-down axes.

   This appendix should be regarded point as informative only an absolute value and provides
   guidance on aspects concerning ignore the interpretation of uncertainty as
   it applies
   uncertainty.  It is difficult to the binary geodetic LCI representation defined determine if systems have been
   implemented in RFC-
   3825 [3].

A.1.  Conversion From LCI Form

   From the example this manner for simplicity, and even more difficult to
   predict if uncertainty will play a more important role in RFC 3825, 38.89868 degrees the future.
   An important decision is encoded into a
   34bit twos-complement number:

   000100110.1110011000001111111001000 whether an uncertainty area should be
   specified.

   The resolution value for this axis indicates how many PIDF-LO Geodetic Shapes specification [6] defines eight shape
   types most of thess bits which are actually significant.  A resolution of 18 indicates that easily translated into shapes definitions
   used in other applications and protocols, such as Open Mobile
   Alliance (OMA) Mobile Location Protocol (MLP).  For completeness the last
   16 bits
   shapes defined in [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)

   o  Ellipsoid (3d)

   o  Prism (3d)

   The GeoShape specification [6] also describes a standard set of
   coordinate reference systems (CRS), unit of measure (UoM) and
   conventions relating to lines and distances.  GeoShape mandates the number could be either 1 or zero:

   000100110.111001100xxxxxxxxxxxxxxxx

   To determine
   use the WGS-84 Coordinate reference system and restricts usage to
   EPSG-4326 for two dimensional (2d) shape representations and EPSG-
   4979 for three dimensional (3d) volume representations.  Distance and
   heights are expressed in meters using EPSG-9001.

   It is RECOMMENDED that where uncertainty assume is included, a range from the minimum possible
   value (all zeros confidence of
   68% (or one standard deviation) is used.  Specifying a convention for
   confidence enables better use of uncertainty values.

5.1.  Polygon Restrictions

   The Polygon shape type defined in [6] intentionally does not place
   any constraints on the last 16 bits) to the maximum (all ones):

   000100110.1110011000000000000000000 number of vertices that may be included to
   000100110.1110011001111111111111111

   This yields
   define the range in bounds of the example Polygon.  This allows arbitrarily complex
   shapes to be between 38.8984375 degrees defined and 38.9003906 degrees (rounded to 7 decimal places).

A.2.  Conversion To LCI Form

   Converting conveyed in a PIDF-LO.  However where
   location information into the LCI format involves
   converting the original shape is to a rectangular prism. be used in real-time processing
   applications, such as location dependent routing, having arbitrarily
   complex shapes consisting of tens or even hundreds of points could
   result in significant performance impacts.  To do mitigate this
   determine the minimum and risk it
   is recommended that Polygons be restricted to a maximum values for each of 15
   discrete points (16 including the axes:
   latitude, longitude and altitude.  This results in a slightly
   increased area, but repeated point) when the overall effect location
   information 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. intended for use in real-time applications.  This is because the starting area represents a set
   limit of 15 points and the Target may reside is chosen to allow moderately complex shape
   definitions while at anyone of these points the same time enabling interoperation with equal
   probability.  If other
   location transporting protocols such as those defined in 3GPP ([7])
   and OMA where the area is cropped there 15 point limit is a risk that already imposed.

   Polygons are defined with the
   Target's position will be one minimum distance between two adjacent
   vertices (geodesic).  A connecting line SHALL NOT cross another
   connecting line of the discarded points yielding an
   incorrect result.  In general same Polygon.  Polygons SHOULD be defined with
   the upward normal pointing up, this is accomplished by defining the increases
   vertices in counter-clockwise direction.

   Points specified in area are minimal, for a circular area, as shown, the increase ratio polygon must be coplanar, and it is 4:pi; a square
   building will at most double recommended
   that where points are specified in 3 dimensions that all points
   maintain the size same altitude.

5.2.  Complex Shape Examples

   This section provides some examples of where some 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 meters.  Converting each value
   into more complex
   shapes are used, how they are determined, and how they are
   represented in a 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 PIDF-LO.  Complete details on all of the common stem as marked this above.
   There Geoshape
   types are 16 common bits between low provided in [6].

5.2.1.  Polygon Representation 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 Usage

   The polygon shape may be used to 32.9843745
   degrees, which is approximately 870 meters represent a significant increase
   over building outline or
   coverage area.  The first and last points of the original 56 meters.

A.2.2.  Example 2

   Take polygon must be the range from 31.9999985 degrees
   same to 32.00000274 degrees, which
   is about 0.5 meters in distances ranging around 32 degrees.  This
   results in form a closed shape.  For example looking at the following binary values:

   000011111.1111111111111111111001110 to
   000100000.0000000000000000001011100
   ^^^

   Only 3 bits are common to octagon
   below with vertices, A,H,G,F,E,D,C,B,A. The resulting polygon will be
   defined with 9 points, with the first and last points both values which yields an encoded range
   from 0 having the
   coordinates of point A.

        B-------------C
      /                \
     /                  \
    /                    \
   A                      D
   |                      |
   |                      |
   |                      |
   |                      |
   H                      E
    \                    /
     \                  /
      \                /
       G--------------F
   <?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="http://www.opengis.net/pidflo/1.0"
    xmlns:gml="http://www.opengis.net/gml"
      entity="pres:octagon@example.com">
     <tuple id="sg89ab">
       <status>
         <gp:geopriv>
           <gp:location-info>
             <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
               <gml:exterior>
                 <gml:LinearRing>
                   <gml:pos>43.311 -73.422</gml:pos> <!--A-->
                   <gml:pos>43.211 -73.422</gml:pos> <!--H-->
                   <gml:pos>43.111 -73.322</gml:pos> <!--G-->
                   <gml:pos>43.111 -73.222</gml:pos> <!--F-->
                   <gml:pos>43.211 -73.122</gml:pos> <!--E-->
                   <gml:pos>43.311 -73.122</gml:pos> <!--D-->
                   <gml:pos>43.411 -73.222</gml:pos> <!--C-->
                   <gml:pos>43.411 -73.322</gml:pos> <!--B-->
                   <gml:pos>43.311 -73.422</gml:pos> <!--A-->
                 </gml:LinearRing>
              </gml:exterior>
             </gml:Polygon>
           </gp:location-info>
           <gp:usage-rules/>
         </gp:geopriv>
       </status>
       <timestamp>2007-06-22T20:57:29Z</timestamp>
     </tuple>
   </presence>

5.2.2.  Prism Representation and Usage

   A prsim may be used to 64 degrees, or represent a distance section of a building or range of 3,500 kilometers.

A.3.  Problem
   floors of building.  The LCI encoding breaks when the uncertainty that is being
   represented causes prism extrudes a change in polygon by providing a relatively significant binary digit.
   This results
   height element.  It consists of a base made up of coplanar 3 points
   defined in 3 dimensions all at the same altitude.  The prism is then
   an expanded uncertainty, possibly very large,
   depending on which binary digit changes.  In many cases extrusion from this base to the change
   will be in lower-order digits, which will result in a relatively
   small increase value specified in uncertainty, but certain values will yield an
   almost useless location see Appendix A.2.2.

   This problem the height
   element.  If the height is exacerbated at negative, then the three zero points - prism is extruded from
   the Greenwich
   Meridian, Equator and at top down, while a positive height extrudes from the surface bottom up.
   The first and last points of the geoid (altitude).  In
   these cases, if polygon must be the input uncertainty spans same to form a
   closed shape.

   For example looking at the zero point, cube below.  If the
   resolution value ends up as zero; that is, it indicates that there prism is
   no useful information for that parameter.

   The original uncertainty has very little bearing on this problem - a
   small value can be increased to any value.  More precise location
   determination technologies only reduce extruded from
   the probability of large
   problems occurring, although bottom up, then the polygon forming the nature base of the encoding is such that
   any uncertainty can be greatly increased.

A.4.  Conclusion

   Uncertainty prism is a reality of location and important for a number of
   applications.  LCI's limited form means that adapting existing
   uncertainty information, for example a circle as in Appendix A.2.2,
   results in a small error.
   defined with the points A, B, C, D, A. The introduction height of this small encoding
   error is, however, 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 prism is informative only.

   RFC 3825 [3] describes a means by which an end the
   distance between point may learn it
   location from information encoded into DHCP option 123.  The
   following section describes how A and end point can take this
   information E in meters.  The resulting
   PIDF-LO is provided below.

              G-----F
             /|    /|
            / |   / |
           H--+--E  |
           |  C--|--B
           | /   | /
           |/    |/
           D-----A
   <?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="http://www.opengis.net/pidflo/1.0"
    xmlns:gml="http://www.opengis.net/gml"
      entity="pres:mike@someprism.example.com">
     <tuple id="sg89ab">
       <status>
         <gp:geopriv>
           <gp:location-info>
             <gs:Prism srsName="urn:ogc:def:crs:EPSG::4979">
               <gs:base>
                  <gml:Polygon>
                     <gml:exterior>
                       <gml:LinearRing>
                          <gml:posList>
                              42.556844 -73.248157 36.6 <!--A-->
                              42.656844 -73.248157 36.6 <!--B-->
                              42.656844 -73.348157 36.6 <!--C-->
                              42.556844 -73.348157 36.6 <!--D-->
                              42.556844 -73.248157 36.6 <!--A-->
                           </gml:posList>
                        </gml:LinearRing>
                     </gml:exterior>
                  </gml:Polygon>
               </gs:base>
               <gs:height uom="urn:ogc:def:uom:EPSG::9001">
                  2.4
               </gs:height>
            </gs:Prism>
           </gp:location-info>
           <gp:usage-rules/>
         </gp:geopriv>
       </status>
       <timestamp>2007-06-22T20:57:29Z</timestamp>
     </tuple>
   </presence>

5.2.3.  Arc Band Respresentation and represent it in a well formed PIDF-LO describing this
   geodetic location. Usage

   The location information described arc band shape type is commonly generated in RFC 3825 consists of a
   latitude, longitude, altitude and datum.

B.1.  Latitude wireless systems
   where timing advance or code offsets sequences are used to compensate
   for distances between handsets and Longitude the access point.  The latitude and longitude values are arc band is
   represented in degrees as two radii emanating from a central point, and
   decimal degrees.  Latitude values are positive if north of two
   angles which represent the
   equator, starting angle and negative if south the opening angle of
   the equator.  Similarly
   longitudinal values are positive if east arc.  In a cellular environment the central point is nominally
   the location of the Greenwich meridian,
   and negative if west cell tower, the two radii are determined by the
   extent of the Greenwich meridian.

   The latitude timing advance, and longitude values the two angles are each 34 bit long fields
   consisting of generally
   provisioned information.

   For example, Paul is using a 9 bit integer component cellular wireless device and is 7 timing
   advance symbols away from the cell tower.  For a 25 bit fraction
   component, with negative numbers being represented in 2s complement
   notation.  The latitude GSM-based network
   this would place Paul roughly between 3,594 meters and longitude fields are each proceeded by a
   6 bit resolution field, 4,148 meters
   from the LaRes for latitude, cell tower, providing the inner and outer radius values.  If
   the LoRes for
   longitude.  The value in start angle is 20 degrees from north, and the LaRes field indicates opening angle is
   120 degrees, an arc band representing Paul's location would look
   similar to the number of
   significant bits figure below.

         N ^        ,.__
           | a(s)  /     `-.
           | 20   /         `-.
           |--.  /             `.
           |   `/                \
           |   /__                \
           |  .   `-.              \
           | .       `.             \
           |. \        \             .
        ---c-- a(o) -- |             | -->
           |.  / 120   '             |   E
           |  .       /              '
           |    .    /              ;
                  .,'              /
               r(i)`.             /
            (3594m)  `.          /
                       `.      ,'
                         `.  ,'
                       r(o)`'
                     (4148m)

   The resulting PIDF-LO is reflected 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="http://www.opengis.net/pidflo/1.0"
    xmlns:gml="http://www.opengis.net/gml"
      entity="pres:paul@somecell.example.com">
     <tuple id="sg89ab">
       <status>
         <gp:geopriv>
           <gp:location-info>
             <gs:ArcBand srsName="urn:ogc:def:crs:EPSG::4326">
                <gml:pos>
                  -43.5723 153.21760
                </gml:pos>
                <gs:innerRadius uom="urn:ogc:def:uom:EPSG::9001">
                  3594
                </gs:innerRadius>
                <gs:outerRadius uom="urn:ogc:def:uom:EPSG::9001">
                  4148
                </gs:outerRadius>
                <gs:startAngle uom="urn:ogc:def:uom:EPSG::9102">
                  20
                </gs:startAngle>
                <gs:openingAngle uom="urn:ogc:def:uom:EPSG::9102">
                  20
                </gs:openingAngle>
             </gs:ArcBand>
           </gp:location-info>
           <gp:usage-rules/>
         </gp:geopriv>
       </status>
       <timestamp>2003-06-22T20:57:29Z</timestamp>
     </tuple>
   </presence>

   An important note to interpret in make on the Latitude field, while arc band is that the value center point
   used in the LoRes field indicates the number definition of significant bits to
   interpret the shape is not included in resulting
   enclosed area, and that Target may be anywhere in the defined area of
   the arc band.

5.2.4.  Ellipsoid Representation and Usage

   The ellipsoid is the Longitude field.

   For example, if you are volume most commonly produced by GPS systems.
   It is used extensively in Wollongong Australia which navigation systems and wireless location
   networks.  The ellipsoid is located at
   34 Degrees 25 minutes South constructed around a central point
   specified in three dimensions, and 150 degrees 32 minutes East, this
   would translate three axies perpendicular to -34.41667, 150.53333 in decimal degrees.  If these
   numbers one
   another are translated to their full 34 bit representations, then we
   arrive extended outwards from this point.  These axies are
   defined as the following:

   Latitude = 111011101.1001010101010101000111010

   Longitude = 0100101101000100010001000010100001

   RFC 3825, uses semi-major (M) axis, the LaRes and LoRes values to specify a lower semi-minor (m) axis, and
   upper boundary for location thereby specifying an area.  The size of the area specified
   vertical (v) axis respectively.  An angle is directly related used to express the value specified in
   orientation of the
   LaRes ellipsoid.  The orientation angle is measured in
   degrees from north, and LoRes fields.

   Using represents the previous example, if LaRes is set 7, then lower latitude
   boundary direction of the semi-major
   axis from the center point.

                  \
                _.-\""""^"""""-._
              .'    \   |        `.
             /       v  m          \
            |         \ |           |
            |          -c ----M---->|
            |                       |
             \                     /
              `._               _.'
                 `-...........-'

   A PIDF-LO containing an ellipsoid would like something like the
   sample 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="http://www.opengis.net/pidflo/1.0"
    xmlns:gml="http://www.opengis.net/gml"
      entity="pres:somone@gpsreceiver.example.com">
     <tuple id="sg89ab">
       <status>
         <gp:geopriv>
           <gp:location-info>
             <gs:Ellipsoid srsName="urn:ogc:def:crs:EPSG::4979">
               <gml:pos>
                 42.5463 -73.2512 26.3
               </gml:pos>
               <gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001">
                 7.7156
               </gs:semiMajorAxis>
               <gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001">
                 3.31
               </gs:semiMinorAxis>
              <gs:verticalAxis uom="urn:ogc:def:uom:EPSG::9001">
                28.7
              </gs:verticalAxis>
              <gs:orientation uom="urn:ogc:def:uom:EPSG::9102">
                90
              </gs:orientation>
             </gs:Ellipsoid>
           </gp:location-info>
           <gp:usage-rules/>
         </gp:geopriv>
       </status>
       <timestamp>2003-06-22T20:57:29Z</timestamp>
     </tuple>
   </presence>

5.3.  Emergency Shape Representations

   In some parts of the world cellular networks constraints are placed
   on the shape types that can be calculated as -256+128+64+16+8+4, which is -36
   degrees, used to represent the upper boundary then becomes -256+128+64+16+8+4+2+1 which
   is -35 degrees.  LoRes location of an
   emergency caller.  These restrictions, while to some extend are
   artificial, may pose significant interoperability problems in
   emergency networks were they to be used similarly for Longitude.

   So what level unilaterally lifted.  The largest
   impact likely being on Public Safety Answer Point (PSAP) where
   multiple communication networks report emergency data.  Wholesale
   swap-out or upgrading of precision this equipment is useful?  Well, certain types of
   applications deemed to be complex and regulations call for different levels of precision,
   costly and the required precision may vary depending on how the location was
   determined.  For cellular 911 calls has resulted in a number of countries, most notably the
   United States, for
   example, if the network measures to adopt migratory standards towards emergency IP
   telephony support.  Where these migratory standards are implemented
   restrictions on acceptable geodetic shape types to represent the
   location then the of an emergency caller may exist.  Conversion from one shape
   type to another should be within 100 meters, while if avoided to eliminate the handset does introduction of
   errors in reported location.

   In North America the measurement then migratory VoIP emergency services standard (i2)
   [8] reuses the location should be within 50 meters.  Since DHCP is a network
   based mechanism we will benchmark off 100 meters (approximately 330
   ft) NENA E2 interface [9] which is still restriction geodetic shape
   representation to a large area.

   For simplicity we shall assume that we are defining point, 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
   meters.

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

   The distance between the top and the bottom and the left and the
   right is the same, the area being point with an uncertain circle, a square, point
   with an altitude and this works out to an uncertainty circle.  The NENA recommended
   shapes can be
   70.7 meters.  When expressed in decimal degrees, the third point
   after the decimal place represents about 100 meter precision, this
   equates to 10 binary places of fractional part.  A 70 meter distance
   is required, so 11 fractional binary digits are necessary resulting represented in a total of 20 bits of precision.

   With -34.4167, 150.5333 encoded with 20 bits of precision for PIDF-LO using the
   LaRes GeoShape Point,
   GeoShape Circle, and LoRes, GeoShape Sphere definitions respectively.

6.  Recommendations

   As a summary, this document gives a few recommendations on the corners usage
   of the enclosing square are:

   Point 1 (-34.4170, 150.5332)
   Point 2 (-34.4170, 150.5337)
   Point location information in PIDF-LO.  Nine rules specified in
   Section 3 (-34.4165, 150.5332)
   Point 4 (-34.4165, 150.5337)

B.2.  Altitude

   The altitude elements define how the altitude is encoded and give guidelines on avoiding ambiguity in PIDF-LO
   interpretations when multiple locations may be provided to what
   level of precision.  The units for altitude are either meters, a Target
   or
   floors, with location recipient.

   It is recommended that only the actual measurement being encoded shape types and shape representations
   described in a similar manner [6] be used to those express geodetic locations for latitude and longitude, but with 22 bit integer, and 8
   bit fractional components.

B.3.  Generating the PIDF-LO

   If altitude is not required, or is expressed in floors then a exchange
   between general applications.  By standardizing 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 data
   representation interoperability issues are mitigated.

   It is required, the altitude SHOULD be expressed
   as a civic floor number as part of the same <location-info> element.
   In the example above the recommended that GML for the location would Polygons 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>

                                No Altitude

   If restricted to a floor number maximum of say 3 were included, then the 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>

                              Civic Altitude

   When altitude is expressed as an integer 16
   points when used in location-dependent routing and fractional component, as 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 latitude and longitude, it expresses a range which requires
   the prism form acceptable shape types are not understood restrictions to
   Point, Circle and Sphere representations should be used.  Care must be taken to ensure that the
   points are defined in a counter-clockwise direction used to ensure that
   the upward normal points up.

   Extending the previous example
   accommodate most existing deployments.

   Conversions from one geodetic shape type to include an altitude expressed in
   metres rather than floors.  AltRes another should be avoided
   where data is set considered critical and the introduction of errors
   considered unacceptable.

   In the absence of any application specific knowledge shapes and
   volumes should assumed to have a corresponding confidence value of 19,
   68% when associated representing a Target's location.

7.  Security Considerations

   The primary security considerations relate to how location
   information is conveyed and used, which are outside the
   Altitude value scope of this
   document.  This document is set intended to 34.  Using similar techniques serve only as shown in
   the latitude and longitude section, a range set of altitudes between 32
   meters and 40 meters is described.  The prism would therefore be
   defined
   guidelines 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 Wiremap.

   The timestamp value which elements MUST or SHOULD be set implemented by
   systems wishing to the time that perform location was
   retrieved from the DHCP server. dependent routing.  The client application MAY insert any usage rules
   ramification of such recommendations is that are pertinent they extend to devices
   and clients that wish to make use of such services.

8.  IANA Considerations

   This document does not introduce any IANA considerations.

9.  Acknowledgments

   The authors would like to thank the user 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 device author of PIDF-LO and Nadine Abbott for
   her constructive comments in clarifying some aspects of the document.

10.  References

10.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]   Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4
         and DHCPv6) Option for Civic Addresses Configuration
         Information", RFC 4676, October 2006.

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

   [5]   Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and that comply with [9].  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 J.
         Polk, "Geopriv Requirements", RFC 3693, February 2004.

   [6]   Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape Application
         Schema for use by the source Internet Engineering Task Force (IETF)",
         Candidate OpenGIS Implementation Specification 06-142, Version:
         0.0.9, December 2006.

10.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]   "abbrev"i2">NENA VoIP-Packet Technical Committee, Interim VoIP
         Architecture for Enhanced 9-1-1 Services (i2), NENA 08-001, Dec
         2005".

   [9]   "NENA Standard for the Implementation 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, Wireless Emergency
         Service Protocol E2 Interface, NENA 05-001, Dec 2003".

   [10]  Polk, J., Schnizlein, J., 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>Wiremap</gp:method>
         </gp:geopriv>
       </status>
       <timestamp>2005-07-05T14:49:53+10:00</timestamp>
     </tuple>
   </presence>

                      Geodetic Location Only PIDF-LO
   <?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>Wiremap</gp:method>
         </gp:geopriv>
       </status>
       <timestamp>2005-07-05T14:49:53+10:00</timestamp>
     </tuple>
   </presence>

                Geodetic M. Linsner, "Dynamic Host
         Configuration Protocol Option for Coordinate-based Location with Civic Floor PIDF-LO
   <?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>Wiremap</gp:method>
         </gp:geopriv>
       </status>
       <timestamp>2005-07-05T14:49:53+10:00</timestamp>
     </tuple>
   </presence>

                         Rectangular Prism PIDF-LO
         Configuration Information", RFC 3825, July 2004.

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 Networks GmbH & Co KG
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   Email: Hannes.Tschofenig@siemens.com

Full Copyright Statement

   Copyright (C) The Internet Society (2006). IETF Trust (2007).

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