Geopriv J. Winterbottom
Internet-Draft M. Thomson
Expires: September 6, 2007 Andrew Corporation
H. Tschofenig
Siemens Networks GmbH & Co KG
March 5, 2007
GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations
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 September 6, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Winterbottom, et al. Expires September 6, 2007 [Page 1]
Internet-Draft GEOPRIV PIDF-LO Profile March 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.
Winterbottom, et al. Expires September 6, 2007 [Page 2]
Internet-Draft GEOPRIV PIDF-LO Profile March 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Using Location Information . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . 10
5. Geodetic Shape Representation . . . . . . . . . . . . . . . . 11
5.1. Polygon Restrictions . . . . . . . . . . . . . . . . . . . 12
5.2. Complex Shape Examples . . . . . . . . . . . . . . . . . . 12
5.2.1. Polygon Representation and Usage . . . . . . . . . . . 12
5.2.2. Prism Representation and Usage . . . . . . . . . . . . 14
5.2.3. Arc Band Respresentation and Usage . . . . . . . . . . 16
5.2.4. Ellipsoid Representation and Usage . . . . . . . . . . 18
5.3. Emergency Shape Representations . . . . . . . . . . . . . 20
6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative references . . . . . . . . . . . . . . . . . . . 26
10.2. Informative References . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 28
Winterbottom, et al. Expires September 6, 2007 [Page 3]
Internet-Draft GEOPRIV PIDF-LO Profile March 2007
1. 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 [4]. A GML profile for expressing
geodetic shapes in a PIDF-LO is described in [6]. Uses for PIDF-LO
are envisioned in the context of numerous location based
applications. This document makes recommendations for formats and
conventions to make interoperability less problematic.
Winterbottom, et al. Expires September 6, 2007 [Page 4]
Internet-Draft GEOPRIV PIDF-LO Profile March 2007
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1].
The definition for "Target" is taken from [5].
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.
Winterbottom, et al. Expires September 6, 2007 [Page 5]
Internet-Draft GEOPRIV PIDF-LO Profile March 2007
3. 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-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 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 contained 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.
Winterbottom, et al. Expires September 6, 2007 [Page 6]
Internet-Draft GEOPRIV PIDF-LO Profile March 2007
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 at the same time and by the same method.
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 or 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.
Winterbottom, et al. Expires September 6, 2007 [Page 7]
Internet-Draft GEOPRIV PIDF-LO Profile March 2007
3.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 [3].
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 consistently by receiving nodes if sent over
the network.
3.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. Mike's main location is 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 #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: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>
Winterbottom, et al. Expires September 6, 2007 [Page 8]
Internet-Draft GEOPRIV PIDF-LO Profile March 2007
3.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 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 the tuple containing the San Francisco location
first.
Winterbottom, et al. Expires September 6, 2007 [Page 9]
Internet-Draft GEOPRIV PIDF-LO Profile March 2007
4. Geodetic Coordinate Representation
The geodetic examples provided in 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 later versions of GML
(3.1 and beyond) making it inadvisable to use for new applications.
Secondly, the format of the coordinates type is opaque and so can be
difficult to parse and interpret to ensure consistent results, as the
same geodetic location can be expressed in a variety of ways. The
PIDF-LO Geodetic Shapes specification [6] provides a specific GML
profile for expressing commonly used shapes using simple GML
representations. The shapes defined in [6] are the recommended
shapes to ensure interoperability between location based
applications.
Winterbottom, et al. Expires September 6, 2007 [Page 10]
Internet-Draft GEOPRIV PIDF-LO Profile March 2007
5. Geodetic Shape Representation
The cellular mobile world today makes extensive use of geodetic based
location information for emergency and other location-based
applications. Generally these locations are expressed as a point
(either in two or three dimensions) and an area or volume of
uncertainty around the point. In theory, the area or volume
represents a coverage in which the user has a relatively high
probability of being found, and the point is a convenient means of
defining the centroid for the area or volume. In practice, most
systems use the point as an absolute value and ignore the
uncertainty. It is difficult to determine if systems have been
implemented in this manner for simplicity, and even more difficult to
predict if uncertainty will play a more important role in the future.
An important decision is whether an uncertainty area should be
specified.
The PIDF-LO Geodetic Shapes specification [6] defines eight shape
types most of which are easily translated into shapes definitions
used in other applications and protocols, such as Open Mobile
Alliance (OMA) Mobile Location Protocol (MLP). For completeness the
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
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 is included, a confidence of
Winterbottom, et al. Expires September 6, 2007 [Page 11]
Internet-Draft GEOPRIV PIDF-LO Profile March 2007
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 number of vertices 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 could
result in significant performance impacts. To mitigate this risk it
is recommended that Polygons be restricted to a maximum of 15
discrete points (16 including the repeated point) when the location
information is intended for use in real-time applications. This
limit of 15 points is chosen to allow moderately complex shape
definitions while at the same time enabling interoperation with other
location transporting protocols such as those defined in 3GPP ([7])
and OMA where the 15 point limit is already imposed.
Polygons are defined with the minimum distance between two adjacent
vertices (geodesic). A connecting line SHALL NOT cross another
connecting line of the same Polygon. Polygons SHOULD be defined with
the upward normal pointing up, this is accomplished by defining the
vertices in counter-clockwise direction.
Points specified in a polygon must be coplanar, and it is recommended
that where points are specified in 3 dimensions that all points
maintain the same altitude.
5.2. Complex Shape Examples
This section provides some examples of where some of the more complex
shapes are used, how they are determined, and how they are
represented in a PIDF-LO. Complete details on all of the Geoshape
types are provided in [6].
5.2.1. Polygon Representation and Usage
The polygon shape may be used to represent a building outline or
coverage area. The first and last points of the polygon must be the
same to form a closed shape. For example looking at the 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 having the
coordinates of point A.
Winterbottom, et al. Expires September 6, 2007 [Page 12]
Internet-Draft GEOPRIV PIDF-LO Profile March 2007
B-------------C
/ \
/ \
/ \
A D
| |
| |
| |
| |
H E
\ /
\ /
\ /
G--------------F
Winterbottom, et al. Expires September 6, 2007 [Page 13]
Internet-Draft GEOPRIV PIDF-LO Profile March 2007
<?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 represent a section of a building or range of
floors of building. The prism extrudes a polygon by providing a
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 extrusion from this base to the value specified in the height
element. If the height is negative, then the prism is extruded from
the top down, while a positive height extrudes from the bottom up.
The first and last points of the polygon must be the same to form a
closed shape.
For example looking at the cube below. If the prism is extruded from
Winterbottom, et al. Expires September 6, 2007 [Page 14]
Internet-Draft GEOPRIV PIDF-LO Profile March 2007
the bottom up, then the polygon forming the base of the prism is
defined with the points A, B, C, D, A. The height of the prism is the
distance between point A and point E in meters. The resulting
PIDF-LO is provided below.
G-----F
/| /|
/ | / |
H--+--E |
| C--|--B
| / | /
|/ |/
D-----A
Winterbottom, et al. Expires September 6, 2007 [Page 15]
Internet-Draft GEOPRIV PIDF-LO Profile March 2007
<?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 Usage
The arc band shape type is commonly generated in wireless systems
where timing advance or code offsets sequences are used to compensate
for distances between handsets and the access point. The arc band is
represented as two radii emanating from a central point, and two
angles which represent the starting angle and the opening angle of
the arc. In a cellular environment the central point is nominally
Winterbottom, et al. Expires September 6, 2007 [Page 16]
Internet-Draft GEOPRIV PIDF-LO Profile March 2007
the location of the cell tower, the two radii are determined by the
extent of the timing advance, and the two angles are generally
provisioned information.
For example, Paul is using a cellular wireless device and is 7 timing
advance symbols away from the cell tower. For a GSM-based network
this would place Paul roughly between 3,594 meters and 4,148 meters
from the cell tower, providing the inner and outer radius values. If
the start angle is 20 degrees from north, and the opening angle is
120 degrees, an arc band representing Paul's location would look
similar to the figure below.
N ^ ,.__
| a(s) / `-.
| 20 / `-.
|--. / `.
| `/ \
| /__ \
| . `-. \
| . `. \
|. \ \ .
---c-- a(o) -- | | -->
|. / 120 ' | E
| . / '
| . / ;
.,' /
r(i)`. /
(3594m) `. /
`. ,'
`. ,'
r(o)`'
(4148m)
The resulting PIDF-LO is reflected below.
Winterbottom, et al. Expires September 6, 2007 [Page 17]
Internet-Draft GEOPRIV PIDF-LO Profile March 2007
<?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 make on the arc band is that the center point
used in the definition of 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 volume most commonly produced by GPS systems.
It is used extensively in navigation systems and wireless location
networks. The ellipsoid is constructed around a central point
specified in three dimensions, and three axies perpendicular to one
Winterbottom, et al. Expires September 6, 2007 [Page 18]
Internet-Draft GEOPRIV PIDF-LO Profile March 2007
another are extended outwards from this point. These axies are
defined as the semi-major (M) axis, the semi-minor (m) axis, and the
vertical (v) axis respectively. An angle is used to express the
orientation of the ellipsoid. The orientation angle is measured in
degrees from north, and represents the 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.
Winterbottom, et al. Expires September 6, 2007 [Page 19]
Internet-Draft GEOPRIV PIDF-LO Profile March 2007
<?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 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 Public Safety Answer Point (PSAP) 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
Winterbottom, et al. Expires September 6, 2007 [Page 20]
Internet-Draft GEOPRIV PIDF-LO Profile March 2007
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. 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)
[8] reuses the NENA E2 interface [9] which restriction geodetic shape
representation to a point, a point with an uncertain circle, a point
with an altitude and an uncertainty circle. The NENA recommended
shapes can be represented in a PIDF-LO using the GeoShape Point,
GeoShape Circle, and GeoShape Sphere definitions respectively.
Winterbottom, et al. Expires September 6, 2007 [Page 21]
Internet-Draft GEOPRIV PIDF-LO Profile March 2007
6. Recommendations
As a summary, this document gives a few recommendations on the usage
of location information in PIDF-LO. Nine rules specified in
Section 3 give guidelines on avoiding ambiguity in PIDF-LO
interpretations when multiple locations may be provided to a Target
or location recipient.
It is recommended that only the shape types and shape representations
described in [6] 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 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.
In the absence of any application specific knowledge shapes and
volumes should assumed to have a corresponding confidence value of
68% when associated representing a Target's location.
Winterbottom, et al. Expires September 6, 2007 [Page 22]
Internet-Draft GEOPRIV PIDF-LO Profile March 2007
7. Security Considerations
The primary security considerations relate to how location
information is conveyed and used, which are outside the scope of this
document. This document is intended to serve only as a set of
guidelines as to which elements MUST or SHOULD be implemented by
systems wishing to perform location dependent routing. The
ramification of such recommendations is that they extend to devices
and clients that wish to make use of such services.
Winterbottom, et al. Expires September 6, 2007 [Page 23]
Internet-Draft GEOPRIV PIDF-LO Profile March 2007
8. IANA Considerations
This document does not introduce any IANA considerations.
Winterbottom, et al. Expires September 6, 2007 [Page 24]
Internet-Draft GEOPRIV PIDF-LO Profile March 2007
9. Acknowledgments
The authors would like to thank the GEOPRIV working group for their
discussions in the context of PIDF-LO, in particular Carl Reed, Ron
Lake, James Polk and Henning Schulzrinne. Furthermore, we would like
to thank Jon Peterson as the author of PIDF-LO and Nadine Abbott for
her constructive comments in clarifying some aspects of the document.
Winterbottom, et al. Expires September 6, 2007 [Page 25]
Internet-Draft GEOPRIV PIDF-LO Profile March 2007
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 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 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 Wireless Emergency
Service Protocol E2 Interface, NENA 05-001, Dec 2003".
[10] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004.
Winterbottom, et al. Expires September 6, 2007 [Page 26]
Internet-Draft GEOPRIV PIDF-LO Profile March 2007
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
Winterbottom, et al. Expires September 6, 2007 [Page 27]
Internet-Draft GEOPRIV PIDF-LO Profile March 2007
Full Copyright Statement
Copyright (C) The 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, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Winterbottom, et al. Expires September 6, 2007 [Page 28]