draft-ietf-geopriv-pdif-lo-profile-03.txt   draft-ietf-geopriv-pdif-lo-profile-04.txt 
Geopriv J. Winterbottom Geopriv J. Winterbottom
Internet-Draft M. Thomson Internet-Draft M. Thomson
Expires: September 4, 2006 Andrew Corporation Expires: November 3, 2006 Andrew Corporation
H. Tschofenig H. Tschofenig
Siemens Siemens
March 3, 2006 May 2, 2006
GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations 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 Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 4, 2006. This Internet-Draft will expire on November 3, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
The Presence Information Data Format Location Object (PIDF-LO) The Presence Information Data Format Location Object (PIDF-LO)
specification provides a flexible and versatile means to represent specification provides a flexible and versatile means to represent
location information. There are, however, circumstances that arise location information. There are, however, circumstances that arise
skipping to change at page 2, line 16 skipping to change at page 2, line 16
applications, location information needs to be normative and more applications, location information needs to be normative and more
tightly constrained than is currently specified in the PIDF-LO. This tightly constrained than is currently specified in the PIDF-LO. This
document makes recommendations on how to constrain, represent and document makes recommendations on how to constrain, represent and
interpret locations in a PIDF-LO. It further recommends a subset of interpret locations in a PIDF-LO. It further recommends a subset of
GML that MUST be implemented by applications involved in location GML that MUST be implemented by applications involved in location
based routing. based routing.
Table of Contents Table of Contents
1. CHANGES SINCE LAST TIME . . . . . . . . . . . . . . . . . . . 3 1. CHANGES SINCE LAST TIME . . . . . . . . . . . . . . . . . . . 3
1.1. 03 changes . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. 04 changes . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. 01 changes . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. 03 changes . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. 01 changes . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Using Location Information . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Single Civic Location Information . . . . . . . . . . . . 7 4. Using Location Information . . . . . . . . . . . . . . . . . . 7
4.2. Civic and Geospatial Location Information . . . . . . . . 8 4.1. Single Civic Location Information . . . . . . . . . . . . 8
4.3. Manual/Automatic Configuration of Location Information . . 11 4.2. Civic and Geospatial Location Information . . . . . . . . 9
5. Geodetic Coordinate Representation . . . . . . . . . . . . . . 12 4.3. Manual/Automatic Configuration of Location Information . . 12
6. Geodetic Shape Representation . . . . . . . . . . . . . . . . 13 5. Geodetic Coordinate Representation . . . . . . . . . . . . . . 13
7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 14 6. Geodetic Shape Representation . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6.1. Polygon Restriction . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6.2. Emergency Shape Representations . . . . . . . . . . . . . 15
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 16
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
12.1. Normative references . . . . . . . . . . . . . . . . . . . 19 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Appendix A. Creating a PIDF-LO from DHCP Geo Encoded Data . . . . 20 11.1. Normative references . . . . . . . . . . . . . . . . . . . 20
A.1. Latitude and Longitude . . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . . 20
A.2. Altitude . . . . . . . . . . . . . . . . . . . . . . . . . 22 Appendix A. Uncertainty in The RFC-3825 LCI Representation . . . 21
A.3. Generating the PIDF-LO . . . . . . . . . . . . . . . . . . 22 A.1. Conversion From LCI Form . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 A.2. Conversion To LCI Form . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 28 A.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 22
A.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 23
A.3. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 23
A.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 23
Appendix B. Creating a PIDF-LO from DHCP Geo Encoded Data . . . . 25
B.1. Latitude and Longitude . . . . . . . . . . . . . . . . . . 25
B.2. Altitude . . . . . . . . . . . . . . . . . . . . . . . . . 27
B.3. Generating the PIDF-LO . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . . . . 33
1. CHANGES SINCE LAST TIME 1. CHANGES SINCE LAST TIME
[[This section is informational only and will be removed before the [[This section is informational only and will be removed before the
final version.]] final version.]]
1.1. 03 changes 1.1. 04 changes
Removed some shape defintions, ellipses, arcbands. 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. Removed OMA shape definition comparisons.
Modified examples to use new civicAddr draft data. Modified examples to use new civicAddr draft data.
Made extensive references to the GeoShape Draft. Made extensive references to the GeoShape Draft.
1.2. 01 changes 1.3. 01 changes
minor changes to the abstract. minor changes to the abstract.
Minor changes to the introduction. Minor changes to the introduction.
Added and appendix to take implementers through how to create a Added and appendix to take implementers through how to create a
PIDF-LO from data received using DHCP option 123 as defined in [2]. PIDF-LO from data received using DHCP option 123 as defined in [3].
Rectified examples to use position and pos rather than location and Rectified examples to use position and pos rather than location and
point. point.
Corrected example 3 so that it does not violate SIP rules. Corrected example 3 so that it does not violate SIP rules.
Added addition geopriv elements to the status component of the figure Added addition geopriv elements to the status component of the figure
in "Using Location Information" to more accurately reflect the in "Using Location Information" to more accurately reflect the
cardinality issues. cardinality issues.
Revised text in section Geodetic Coordinate Representation. Removed Revised text in section Geodetic Coordinate Representation. Removed
last example as this was addressed with the change to position and last example as this was addressed with the change to position and
pos in previous examples. pos in previous examples.
2. Introduction 2. Introduction
The Presence Information Data Format Location Object (PIDF-LO) [3] is The Presence Information Data Format Location Object (PIDF-LO) [2] is
the IETF recommended way of encoding location information and the IETF recommended way of encoding location information and
associated privacy policies. Location information in a PIDF-LO may associated privacy policies. Location information in a PIDF-LO may
be described in a geospatial manner based on a subset of GMLv3, or as be described in a geospatial manner based on a subset of GMLv3, or as
civic location information [4]. A GML profile for expressing civic location information [5]. A GML profile for expressing
geodetic shapes in a PIDF-LO is described in [5].Uses for PIDF-LO are geodetic shapes in a PIDF-LO is described in [6].Uses for PIDF-LO are
envisioned in the context of numerous location based applications. envisioned in the context of numerous location based applications.
This document makes recommendations for formats and conventions to This document makes recommendations for formats and conventions to
make interoperability less problematic. make interoperability less problematic.
3. Terminology 3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1]. document are to be interpreted as described in [1].
skipping to change at page 7, line 12 skipping to change at page 8, line 12
than one way, each location description SHOULD reside in a than one way, each location description SHOULD reside in a
separate tuple. separate tuple.
Rule #3: Providing more than one location in a single presence Rule #3: Providing more than one location in a single presence
document (PIDF) MUST only be done if all objects describe the same document (PIDF) MUST only be done if all objects describe the same
location. location.
Rule #4: Providing more than one location in a single <location-info> Rule #4: Providing more than one location in a single <location-info>
element SHOULD be avoided where possible. element SHOULD be avoided where possible.
Rule #5: When providing more than one location in a single Rule #5: When providing more than one location in a single <location-
<location-info> element the locations MUST be provided by a common info> element the locations MUST be provided by a common source.
source.
Rule #6: Providing more than one location in a single <location-info> 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 element SHOULD only be done if they form a complex to describe the
same location. For example, a geodetic location describing a same location. For example, a geodetic location describing a
point, and a civic location indicating the floor in a building. point, and a civic location indicating the floor in a building.
Rule #7: Where a location complex is provided in a single Rule #7: Where a location complex is provided in a single <location-
<location-info> element, the macro locations MUST be provided info> element, the macro locations MUST be provided first. For
first. For example, a geodetic location describing an area, and a example, a geodetic location describing an area, and a civic
civic location indicating the floor MUST be represented with the location indicating the floor MUST be represented with the area
area first followed by the civic location. first followed by the civic location.
Rule #8: Where a PIDF document contains more than one tuple Rule #8: Where a PIDF document contains more than one tuple
containing a status element with a geopriv location element , the containing a status element with a geopriv location element , the
priority of tuples SHOULD be based on tuple position within the priority of tuples SHOULD be based on tuple position within the
PIDF document. That is to say, the tuple with the highest PIDF document. That is to say, the tuple with the highest
priority location occurs earliest in the PIDF document. Initial priority location occurs earliest in the PIDF document. Initial
priority SHOULD be determined by the originating UA, the final priority SHOULD be determined by the originating UA, the final
priority MAY be determined by a proxy along the way, or the UAS. priority MAY be determined by a proxy along the way, or the UAS.
Rule #9: Where multiple PIDF documents are contained within a single Rule #9: Where multiple PIDF documents are contained within a single
request, document selection SHOULD be based on document order. request, document selection SHOULD be based on document order.
The following examples illustrate the application of these rules. The following examples illustrate the application of these rules.
4.1. Single Civic Location Information 4.1. Single Civic Location Information
Jane is at a coffee shop on the ground floor of a large shopping 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 mall. Jane turns on her laptop and connects to the coffee-shop's
WiFi hotspot, Jane obtains a complete civic address for her current WiFi hotspot, Jane obtains a complete civic address for her current
location, for example using [6]. A Location Object is constructed location, for example using the DHCP Civic mechanism defined in [4].
consisting of a single PIDF document, with a single geopriv tuple, A Location Object is constructed consisting of a single PIDF
and a single location residing in the <location-info> element. This document, with a single geopriv tuple, and a single location residing
document is unambiguous, and should be interpreted correctly if sent in the <location-info> element. This document is unambiguous, and
of the network. should be interpreted consitently by receiving nodes if sent over the
network.
4.2. Civic and Geospatial Location Information 4.2. Civic and Geospatial Location Information
Mike is visiting his Seattle office and connects his laptop into the Mike is visiting his Seattle office and connects his laptop into the
Ethernet port in a spare cube. Mike's computer receives a location Ethernet port in a spare cube. Mike's computer receives a location
over DHCP as defined in [2]. In this case the location is a geodetic over DHCP as defined in RFC-3825 [3]. In this case the location is a
location, with the altitude represented as a building floor number. geodetic location, with the altitude represented as a building floor
This is constructed by Mike's computer into the following PIDF number. This is constructed by Mike's computer into the following
document: PIDF document:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape" xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape"
entity="pres:mike@seattle.example.com"> entity="pres:mike@seattle.example.com">
<tuple id="sg89ab"> <tuple id="sg89ab">
<status> <status>
<gp:geopriv> <gp:geopriv>
skipping to change at page 10, line 44 skipping to change at page 11, line 44
</cl:civicAddress> </cl:civicAddress>
</gp:location-info> </gp:location-info>
<gp:usage-rules/> <gp:usage-rules/>
</gp:geopriv> </gp:geopriv>
</status> </status>
<timestamp>2003-06-22T20:57:29Z</timestamp> <timestamp>2003-06-22T20:57:29Z</timestamp>
</tuple> </tuple>
</presence> </presence>
It is now clear that the main location of user is inside the It is now clear that the main location of user is inside the
rectangle bounded by the geodetic coordinates specfied. Further that rectangle bounded by the geodetic coordinates specified. Further
the user is on the second floor of the building located at these that the user is on the second floor of the building located at these
coordinates. coordinates.
4.3. Manual/Automatic Configuration of Location Information 4.3. Manual/Automatic Configuration of Location Information
Loraine has a predefined civic location stored in her laptop, since Loraine has a predefined civic location stored in her laptop, since
she normally lives in Sydney, the address in her address is for her she normally lives in Sydney, the address in her address is for her
Sydney-based apartment. Loraine decides to visit sunny San Sydney-based apartment. Loraine decides to visit sunny San
Francisco, and when she gets there she plugs in her laptop and makes 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 a call. Loraine's laptop receives a new location from the visited
network in San Francisco. As ths system cannot be sure that the pre- network in San Francisco. As this system cannot be sure that the
existing and new location describe the same place, Loraine's computer pre-existing and new location describe the same place, Loraine's
generates a new PIDF-LO and will use this to represent Loraine's computer generates a new PIDF-LO and will use this to represent
location. If Loraine's computer were to add the new location to her Loraine's location. If Loraine's computer were to add the new
existing PIDF location document (breaking rule #3), then the correct location to her existing PIDF location document (breaking rule #3),
information may still be interpretted by location recipient providing then the correct information may still be interpreted by location
Loraine's system applies rule #9. In this case the resulting order recipient providing Loraine's system applies rule #9. In this case
of location information in the PIDF document should be San Francisco the resulting order of location information in the PIDF document
first, followed by Sydney. Since the information is provided by should be San Francisco first, followed by Sydney. Since the
different sources, rule #8 should also be applied and the information information is provided by different sources, rule #8 should also be
placed in different tuples with San Francisco first. applied and the information placed in different tuples with San
Francisco first.
5. Geodetic Coordinate Representation 5. Geodetic Coordinate Representation
The geodetic examples provided in [3] are illustrated using the gml: The geodetic examples provided in RFC-4119 [2] are illustrated using
location element which uses the gml:coordinates elements (inside the the gml:location element which uses the gml:coordinates elements
gml:Point element) and this representation has several drawbacks. (inside the gml:Point element) and this representation has several
Firstly, it has been deprecated in later versions of GML (3.1 and drawbacks. Firstly, it has been deprecated in later versions of GML
beyond) making it inadvisable to use for new applications. Secondly, (3.1 and beyond) making it inadvisable to use for new applications.
the format of the coordinates type is opaque and so can be difficult Secondly, the format of the coordinates type is opaque and so can be
to parse and interpret to ensure consistent results, as the same difficult to parse and interpret to ensure consistent results, as the
geodetic location can be expressed in a variety of ways. The PIDF-LO same geodetic location can be expressed in a variety of ways. The
Geodetic Shapes specification [5] provides a specific GML profile for PIDF-LO Geodetic Shapes specification [6] provides a specific GML
expressing commonly used shapes using simple GML representations. profile for expressing commonly used shapes using simple GML
The shapes defined in [5] are the recommended shapes to ensure representations. The shapes defined in [6] are the recommended
interoperability between location based applications. shapes to ensure interoperability between location based
applications.
6. Geodetic Shape Representation 6. Geodetic Shape Representation
The cellular mobile world today makes extensive use of geodetic based The cellular mobile world today makes extensive use of geodetic based
location information for emergency and other location-based location information for emergency and other location-based
applications. Generally these locations are expressed as a point applications. Generally these locations are expressed as a point
(either in two or three dimensions) and an area or volume of (either in two or three dimensions) and an area or volume of
uncertainty around the point. In theory, the area or volume uncertainty around the point. In theory, the area or volume
represents a coverage in which the user has a relatively high represents a coverage in which the user has a relatively high
probability of being found, and the point is a convenient means of probability of being found, and the point is a convenient means of
defining the centroid for the area or volume. In practice, most defining the centroid for the area or volume. In practice, most
systems use the point as an absolute value and ignore the systems use the point as an absolute value and ignore the
uncertainty. It is difficult to determine if systems have been uncertainty. It is difficult to determine if systems have been
implement in this manner for simplicity, and even more difficult to implement in this manner for simplicity, and even more difficult to
predict if uncertainty will play a more important role in the future. predict if uncertainty will play a more important role in the future.
An important decision is whether an uncertainty area should be An important decision is whether an uncertainty area should be
specified. specified.
[5] defines eight shape types most of which are easily translated in The PIDF-LO Geodetic Shapes specification [6] defines eight shape
shapes definitions used in other applications and protocol, such as types most of which are easily translated in shapes definitions used
Open Mobile Alliance (OMA) Mobile Location Protocol (MLP). For in other applications and protocol, such as Open Mobile Alliance
completeness the shape defined in [5] are listed below: (OMA) Mobile Location Protocol (MLP). For completeness the shape
defined in [6] are listed below:
o Point (2d or 3d) o Point (2d or 3d)
o Polygon (2d) o Polygon (2d)
o Circle (2d) o Circle (2d)
o Ellipse (2d) o Ellipse (2d)
o Arc band (2d) o Arc band (2d)
o Sphere (3d circle) o Sphere (3d circle)
o Ellipsoid (3d) o Ellipsoid (3d)
o Prism (3d polygon) o Prism (3d polygon)
[5] also describes a standard set of coordinate reference systems The GeoShape specification [6] also describes a standard set of
(CRS), unit of measure and conventions relating to lines and coordinate reference systems (CRS), unit of measure and conventions
distances that will be repeated here. relating to lines and distances. GeoShape mandates the 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 metres using EPSG-9001.
6.1. Polygon Restriction
The Polygon shape type defined in [6] intentionally does not place
any constraints on the number of points that may be included to
define the bounds 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 of tens or even hundreds of points 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 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 ([7]) and OMA where the 16 point limit is already
imposed.
6.2. Emergency Shape Representations
In some parts of the world cellular networks constraints are placed
on the shape types that can be used to represent the 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 unilaterally lifted. The largest
impact likely being on PSAP CPE 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 in a
number of countries, most notably 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 the location of an emergency 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 7. Recommendations
As a summary this document gives a few recommendations on the usage As a summary this document gives a few recommendations on the usage
of location information in PIDF-LO. Nine rules specified in of location information in PIDF-LO. Nine rules specified in
Section 4 give guidelines on the ambiguity of PIDF-LO with regard to Section 4 give guidelines on the ambiguity of PIDF-LO with regard to
the occurrence of multiple location information. It is recommend the occurrence of multiple locations.
that only the shape types and shape representations described in [5]
be used to express geodetic locations for exchange between general It is recommend that only the shape types and shape representations
applications. By standardizing geodetic data representation described in [6] be used to express geodetic locations for exchange
interoperability issues are mitigated. 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 If Geodetic information is to be provided via DHCP, then a minimum
resolution of 20 bits SHOULD be specified for both the Latitude and resolution of 20 bits SHOULD be specified for both the Latitude and
Longitude fields to achieve sub 100 metre precision. Where only two Longitude fields to achieve sub 100 metre precision. Where only two
dimensional objects are required polygons SHOULD be used to express dimensional objects are required polygons SHOULD be used to express
the enclosed area. Where 3 dimensions are required a rectangular the enclosed area. Where 3 dimensions are required a rectangular
prism SHOULD be used. prism SHOULD be used.
8. Security Considerations 8. Security Considerations
skipping to change at page 18, line 5 skipping to change at page 20, line 5
This document does not introduce any IANA considerations. This document does not introduce any IANA considerations.
10. Acknowledgments 10. Acknowledgments
The authors would like to thank the GEOPRIV working group for their The authors would like to thank the GEOPRIV working group for their
discussions in the context of PIDF-LO, in particular Carl Reed, Ron discussions in the context of PIDF-LO, in particular Carl Reed, Ron
Lake, James Polk and Henning Schulzrinne. Furthermore, we would like Lake, James Polk and Henning Schulzrinne. Furthermore, we would like
to thank Jon Peterson as the author of PIDF-LO and Nadine Abbott for to thank Jon Peterson as the author of PIDF-LO and Nadine Abbott for
her constructive comments in clarifying some aspects of the document. her constructive comments in clarifying some aspects of the document.
11. Open Issues 11. References
Do we need to indicate which shapes are acceptable for emergency
calling? Ceratinly not all can be used today, for example the
polygon and prism types will not work with NENA i2 as it is defined
today due to restrictions over the VE2 interface [7].
12. References
12.1. Normative references 11.1. Normative references
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", March 1997. Levels", March 1997.
12.2. Informative References [2] Peterson, J., "A Presence-based GEOPRIV Location Object Format",
RFC 4119, December 2005.
[2] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host [3] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004. Configuration Information", RFC 3825, July 2004.
[3] Peterson, J., "A Presence-based GEOPRIV Location Object [4] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4
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 the Representation of Uncertainty in PIDF-LO",
January 2006.
[6] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4
and DHCPv6) Option for Civic Addresses Configuration and DHCPv6) Option for Civic Addresses Configuration
Information", draft-ietf-geopriv-dhcp-civil-09 (work in Information", draft-ietf-geopriv-dhcp-civil-09 (work in
progress), January 2006. progress), January 2006.
[7] "NENA Standard for the Implementation of the Wireless Emergency [5] Thomson, M. and J. Winterbottom, "Revised Civic Location Format
Service Protocol E2 Interface". for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-02 (work in
progress), April 2006.
[8] Schulzrinne, H., "A Document Format for Expressing Privacy [6] Thomson, M., "draft-thomson-geopriv-geo-shape, Geodetic Shapes
Preferences", draft-ietf-geopriv-common-policy-07 (work in for the Representation of Uncertainty in PIDF-LO", January 2006.
progress), February 2006.
[9] "3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project; 11.2. Informative References
[7] "3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project;
Technical Specification Group Code Network; Universal Technical Specification Group Code Network; Universal
Geographic Area Description (GAD)". Geographic Area Description (GAD)".
[10] "TR-45 J-STD-036-AD-2 Enhanced Wireless 9-1-1 Phase 2". [8] Schulzrinne, H., "A Document Format for Expressing Privacy
Preferences", draft-ietf-geopriv-common-policy-09 (work in
progress), April 2006.
Appendix A. Creating a PIDF-LO from DHCP Geo Encoded Data [9] "TR-45 J-STD-036-AD-2 Enhanced Wireless 9-1-1 Phase 2".
RFC-3825 [2] describes a means by which an end-point may learns it [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 zero point, the
resolution value ends up as zero; that is, it indicates that there 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 the probability of large
problems occurring, although the nature of the encoding is such that
any uncertainty can be greatly increased.
A.4. Conclusion
Uncertainty 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. 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 [3] describes a means by which an end-point may learn it
location from information encoded into DHCP option 123. The location from information encoded into DHCP option 123. The
following section describes how and end-point can take this following section describes how and end-point can take this
information and represent it in a well formed PIDF-LO describing this information and represent it in a well formed PIDF-LO describing this
geodetic location. geodetic location.
The location information described in RFC-3825 consists of a The location information described in RFC-3825 consists of a
latitude, longitude, altitude and datum. latitude, longitude, altitude and datum.
A.1. Latitude and Longitude B.1. Latitude and Longitude
The latitude and longitude values are represented in degrees and The latitude and longitude values are represented in degrees and
decimal degrees. Latitude values are positive if north of the decimal degrees. Latitude values are positive if north of the
equator, and negative if south of the equator. Similarly equator, and negative if south of the equator. Similarly
longitudinal values are positive if east of the Greenwich meridian, longitudinal values are positive if east of the Greenwich meridian,
and negative if west of the Greenwich meridian. and negative if west of the Greenwich meridian.
The latitude and longitude values are each 34 bit long fields The latitude and longitude values are each 34 bit long fields
consisting of a 9 bit integer component and a 25 bit fraction consisting of a 9 bit integer component and a 25 bit fraction
component, with negative numbers being represented in 2s complement component, with negative numbers being represented in 2s complement
skipping to change at page 22, line 5 skipping to change at page 27, line 10
in a total of 20 bits of precision. in a total of 20 bits of precision.
With -34.4167, 150.5333 encoded with 20 bits of precision for the With -34.4167, 150.5333 encoded with 20 bits of precision for the
LaRes and LoRes, the corners of the enclosing square are: LaRes and LoRes, the corners of the enclosing square are:
Point 1 (-34.4170, 150.5332) Point 1 (-34.4170, 150.5332)
Point 2 (-34.4170, 150.5337) Point 2 (-34.4170, 150.5337)
Point 3 (-34.4165, 150.5332) Point 3 (-34.4165, 150.5332)
Point 4 (-34.4165, 150.5337) Point 4 (-34.4165, 150.5337)
A.2. Altitude B.2. Altitude
The altitude elements define how the altitude is encoded and to what The altitude elements define how the altitude is encoded and to what
level of precision. The units for altitude are either metres, or level of precision. The units for altitude are either metres, or
floors, with the actual measurement being encoded in a similar manner floors, with the actual measurement being encoded in a similar manner
to those for latitude and longitude, but with 22 bit integer, and 8 to those for latitude and longitude, but with 22 bit integer, and 8
bit fractional components. bit fractional components.
A.3. Generating the PIDF-LO B.3. Generating the PIDF-LO
If altitude is not required, or is expressed in floors then a If altitude is not required, or is expressed in floors then a
geodetic location expressed by a polygon SHOULD be used, with points geodetic location expressed by a polygon SHOULD be used, with points
expressed in a counter-clockwise direction. If the altitude is expressed in a counter-clockwise direction. If the altitude is
expressed in floors and is required, the altitude SHOULD be expressed expressed in floors and is required, the altitude SHOULD be expressed
as a civic floor number as part of the same location-info element. as a civic floor number as part of the same <location-info> element.
In the example above the GML for the location would be expressed as In the example above the GML for the location would be expressed as
follows: follows:
<Polygon srsName="urn:ogc:def:crs:EPSG::4326" <Polygon srsName="urn:ogc:def:crs:EPSG::4326"
xmlns="http://www.opengis.net/gml"> xmlns="http://www.opengis.net/gml">
<exterior> <exterior>
<LinearRing> <LinearRing>
<pos>-34.4165 150.5332</pos> <pos>-34.4165 150.5332</pos>
<pos>-34.4170 150.5532</pos> <pos>-34.4170 150.5532</pos>
<pos>-34.4170 150.5537</pos> <pos>-34.4170 150.5537</pos>
<pos>-34.4165 150.5337</pos> <pos>-34.4165 150.5337</pos>
<pos>-34.4165 150.5332</pos> <pos>-34.4165 150.5332</pos>
</LinearRing> </LinearRing>
</exterior> </exterior>
</Polygon> </Polygon>
If a floor number of say 3 were included, then the location-info If a floor number of say 3 were included, then the location-;info
element would contain the above information and the following: element would contain the above information and the following:
<civicAddress <civicAddress
xlmns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> xlmns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<FLR>2</FLR> <FLR>2</FLR>
</civicAddress> </civicAddress>
When altitude is expressed as an integer and fractional component, as When altitude is expressed as an integer and fractional component, as
with the latitude and longitude, it expresses a range which requires 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 the prism form to be used. Care must be taken to ensure that the
points are defined in a counter-clowise direction to ensure that the points are defined in a counter-clockwise direction to ensure that
upward normal points up. the upward normal points up.
Extending the previous example to include an altitude expressed in Extending the previous example to include an altitude expressed in
metres rather than floors. AltRes is set to a value of 19, and the 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 Altitude value is set to 34. Using similar techniques as shown in
the latitude and longitude section, a range of altitudes between 32 the latitude and longitude section, a range of altitudes between 32
metres and 40 metres is described. The prism would therefore be metres and 40 metres is described. The prism would therefore be
defined as follows: defined as follows:
<Prism srsName="urn:ogc:def:crs:EPSG::4976" <Prism srsName="urn:ogc:def:crs:EPSG::4976"
xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape" xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape"
 End of changes. 39 change blocks. 
129 lines changed or deleted 347 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/