draft-ietf-geopriv-pdif-lo-profile-07.txt   draft-ietf-geopriv-pdif-lo-profile-08.txt 
Geopriv J. Winterbottom Geopriv J. Winterbottom
Internet-Draft M. Thomson Internet-Draft M. Thomson
Updates: 4119 (if approved) Andrew Corporation Updates: 4119 (if approved) Andrew Corporation
Intended status: Standards Track H. Tschofenig Intended status: Standards Track H. Tschofenig
Expires: October 30, 2007 Nokia Siemens Networks Expires: December 31, 2007 Nokia Siemens Networks
April 28, 2007 June 29, 2007
GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations
draft-ietf-geopriv-pdif-lo-profile-07.txt draft-ietf-geopriv-pdif-lo-profile-08.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 October 30, 2007. This Internet-Draft will expire on December 31, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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
when information needs to be constrained in how it is represented so 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 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 make use of it are reduced. There is growing interest in being able
to use location information contained in a PIDF-LO for routing to use location information contained in a PIDF-LO for routing
applications. To allow successfully interoperability between applications. To allow successful interoperability between
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 RFC 4119 tightly constrained than is currently specified in the RFC 4119
(PIDF-LO). This document makes recommendations on how to constrain, (PIDF-LO). This document makes recommendations on how to constrain,
represent and interpret locations in a PIDF-LO. It further represent and interpret locations in a PIDF-LO. It further
recommends a subset of GML that is mandatory to implemented by recommends a subset of GML that is mandatory to implemented by
applications involved in location based routing. applications involved in location based routing.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
skipping to change at page 3, line 19 skipping to change at page 3, line 19
3. Using Location Information . . . . . . . . . . . . . . . . . . 6 3. Using Location Information . . . . . . . . . . . . . . . . . . 6
3.1. Single Civic Location Information . . . . . . . . . . . . 8 3.1. Single Civic Location Information . . . . . . . . . . . . 8
3.2. Civic and Geospatial Location Information . . . . . . . . 8 3.2. Civic and Geospatial Location Information . . . . . . . . 8
3.3. Manual/Automatic Configuration of Location Information . . 9 3.3. Manual/Automatic Configuration of Location Information . . 9
4. Geodetic Coordinate Representation . . . . . . . . . . . . . . 10 4. Geodetic Coordinate Representation . . . . . . . . . . . . . . 10
5. Geodetic Shape Representation . . . . . . . . . . . . . . . . 11 5. Geodetic Shape Representation . . . . . . . . . . . . . . . . 11
5.1. Polygon Restrictions . . . . . . . . . . . . . . . . . . . 12 5.1. Polygon Restrictions . . . . . . . . . . . . . . . . . . . 12
5.2. Shape Examples . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Shape Examples . . . . . . . . . . . . . . . . . . . . . . 13
5.2.1. Point . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2.1. Point . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2.2. Polygon . . . . . . . . . . . . . . . . . . . . . . . 14 5.2.2. Polygon . . . . . . . . . . . . . . . . . . . . . . . 14
5.2.3. Circle . . . . . . . . . . . . . . . . . . . . . . . . 15 5.2.3. Circle . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2.4. Ellipse . . . . . . . . . . . . . . . . . . . . . . . 16 5.2.4. Ellipse . . . . . . . . . . . . . . . . . . . . . . . 17
5.2.5. Arc Band . . . . . . . . . . . . . . . . . . . . . . . 18 5.2.5. Arc Band . . . . . . . . . . . . . . . . . . . . . . . 19
5.2.6. Sphere . . . . . . . . . . . . . . . . . . . . . . . . 19 5.2.6. Sphere . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2.7. Ellipsoid . . . . . . . . . . . . . . . . . . . . . . 20 5.2.7. Ellipsoid . . . . . . . . . . . . . . . . . . . . . . 21
5.2.8. Prism . . . . . . . . . . . . . . . . . . . . . . . . 22 5.2.8. Prism . . . . . . . . . . . . . . . . . . . . . . . . 23
6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 25 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.1. Normative references . . . . . . . . . . . . . . . . . . . 29
10.1. Normative references . . . . . . . . . . . . . . . . . . . 29 9.2. Informative References . . . . . . . . . . . . . . . . . . 29
10.2. Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . . . 31 Intellectual Property and Copyright Statements . . . . . . . . . . 31
1. Introduction 1. Introduction
The Presence Information Data Format Location Object (PIDF-LO) [2] is The Presence Information Data Format Location Object (PIDF-LO) [2] is
the recommended way of encoding location information and associated the recommended way of encoding location information and associated
privacy policies. Location information in a PIDF-LO may be described privacy policies. Location information in a PIDF-LO may be described
in a geospatial manner based on a subset of GMLv3, or as civic in a geospatial manner based on a subset of GMLv3, or as civic
location information [5]. A GML profile for expressing geodetic location information [6]. A GML profile for expressing geodetic
shapes in a PIDF-LO is described in [3]. Uses for PIDF-LO are shapes in a PIDF-LO is described in [4]. 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.
The PIDF-LO provides a general presence format for representing
location information, and permits specification of location
information relating to a whole range of aspects of a Target. The
general presence data model is described in [3] and caters for a
presence document to describe different aspects of the reachability
of a presentity. Continuing this approach, a presence document may
contain several geopriv objects that specify different locations and
aspects of reachability relating to a presentity. This degree of
flexibility is important, and and recommendations in this document
make no attempt to forbid the usage of a PIDF-LO in this manner.
This document provides a specific set of guidelines for building
preence documents when it is important to unambiguously convey
exactly one location.
2. Terminology 2. 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].
The definition for "Target" is taken from [6]. The definition for "Target" is taken from [7].
In this document a "discrete location" is defined as a place, point, 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 area or volume in which a Target can be found. It must be described
with sufficient precision to address the requirements of an intended with sufficient precision to address the requirements of an intended
application. application.
The term "compound location" is used to describe location information The term "compound location" is used to describe location information
represented by a composite of both civic and geodetic information. represented by a composite of both civic and geodetic information.
An example of compound location might be a geodetic polygon An example of compound location might be a geodetic polygon
describing the perimeter of a building and a civic element describing the perimeter of a building and a civic element
representing the floor in the building. representing the floor in the building.
The term _method_ is this document refers to the mechanism used to
determine the location of a Target. This may be something employed
by an LCS, or by the Target itself. It specifically does not refer
to the LCP used to deliver location information either to the Target
or the Recipient.
The term _source_ is used to refer to the LCS, node or device from
which a Recipient (Target or Third-Party) obtains location
information/
3. Using Location Information 3. Using Location Information
The PIDF format provides for an unbounded number of <tuple> elements. The PIDF format provides for an unbounded number of <tuple> elements.
Each <tuple> element contains a single <status> element that may Each <tuple> element contains a single <status> element that may
contain more than one <geopriv> element as a child element. Each contain more than one <geopriv> element as a child element. Each
<geopriv> element must contain at least the following two child <geopriv> element must contain at least the following two child
elements: <location-info> element and <usage-rules> element. One or elements: <location-info> element and <usage-rules> element. One or
more chunks of location information are contained inside a <location- more chunks of location information are contained inside a <location-
info> element. info> element.
skipping to change at page 7, line 14 skipping to change at page 7, line 14
do not have any particular order, but should be followed by creators do not have any particular order, but should be followed by creators
and consumers of location information contained in a PIDF-LO to and consumers of location information contained in a PIDF-LO to
ensure that a consistent interpretation of the data can be achieved. ensure that a consistent interpretation of the data can be achieved.
Rule #1: A <geopriv> element MUST describe a discrete location. Rule #1: A <geopriv> element MUST describe a discrete location.
Rule #2: Where a discrete location can be uniquely described in more Rule #2: Where a discrete location can be uniquely described in more
than one way, each location description SHOULD reside in a than one way, each location description SHOULD reside in a
separate <tuple> element. separate <tuple> element.
Rule #3: Providing more than one location chunk in a single presence Rule #3: Providing more than one geopriv element in a single
document (PIDF) MUST only be done if all objects refer to the same presence document (PIDF) MUST only be done if all objects refer to
place. the same place.
This may occur if a Target's location is determined using a This may occur if a Target's location is determined using a
series of different techniques. series of different techniques.
Rule #4: Providing more than one location chunk in a single Rule #4: Providing more than one location chunk in a single
<location-info> element SHOULD be avoided where possible. Rule #5 <location-info> element SHOULD be avoided where possible. Rule #5
and Rule #6 provide further refinement. and Rule #6 provide further refinement.
Rule #5: When providing more than one location chunk in a single Rule #5: When providing more than one location chunk in a single
<location-info> element the locations MUST be provided by a common <location-info> element the locations MUST be provided by a common
skipping to change at page 8, line 15 skipping to change at page 8, line 15
Rule #8: Where a PIDF document contains more than one <tuple> Rule #8: Where a PIDF document contains more than one <tuple>
element containing a <status> element with a <geopriv> element, element containing a <status> element with a <geopriv> element,
the priority of tuples SHOULD be based on position of the <tuple> the priority of tuples SHOULD be based on position of the <tuple>
element within the PIDF document. That is to say, the tuple with element within the PIDF document. That is to say, the tuple with
the highest priority location occurs earliest in the PIDF the highest priority location occurs earliest in the PIDF
document. document.
Rule #9: Where multiple PIDF documents can be sent or received Rule #9: Where multiple PIDF documents can be sent or received
together, say in a multi-part MIME body, and current location together, say in a multi-part MIME body, and current location
information is required by the recipient, then document selection information is required by the recipient, then document selection
SHOULD be based on document order, with the first document be SHOULD be based on document order, with the first document
considered first. considered first.
The following examples illustrate the application of these rules. The following examples illustrate the application of these rules.
3.1. Single Civic Location Information 3.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 the DHCP civic mechanism defined in [4]. location, for example using the DHCP civic mechanism defined in [5].
A Location Object is constructed consisting of a single PIDF A Location Object is constructed consisting of a single PIDF
document, with a single <tuple> element, a single <status> element, a document, with a single <tuple> element, a single <status> element, a
single <geopriv> element, and a single location chunk residing in the single <geopriv> element, and a single location chunk residing in the
<location-info> element. This document is unambiguous, and should be <location-info> element. This document is unambiguous, and should be
interpreted consistently by receiving nodes if sent over the network. interpreted consistently by receiving nodes if sent over the network.
3.2. Civic and Geospatial Location Information 3.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. In this case location information is Ethernet port in a spare cube. In this case location information is
geodetic location, with the altitude represented as a building floor geodetic location, with the altitude represented as a building floor
number. Mike's main location is the point specified by the geodetic number. Mike's main location is the point specified by the geodetic
coordinates. Further, Mike is on the second floor of the building coordinates. Further, Mike is on the second floor of the building
located at these coordinates. Applying rules #6 and #7 are applied, located at these coordinates. Applying rules #6 and #7, the
the resulting compound location information is shown below. resulting compound location information is shown below.
<?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:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
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 15 skipping to change at page 10, line 15
4. Geodetic Coordinate Representation 4. Geodetic Coordinate Representation
The geodetic examples provided in RFC 4119 [2] are illustrated using The geodetic examples provided in RFC 4119 [2] are illustrated using
the <gml:location> element, which uses the <gml:coordinates> element the <gml:location> element, which uses the <gml:coordinates> element
inside the <gml:Point> element and this representation has several inside the <gml:Point> element and this representation has several
drawbacks. Firstly, it has been deprecated in later versions of GML drawbacks. Firstly, it has been deprecated in later versions of GML
(3.1 and beyond) making it inadvisable to use for new applications. (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 Secondly, the format of the coordinates type is opaque and so can be
difficult to parse and interpret to ensure consistent results, as the difficult to parse and interpret to ensure consistent results, as the
same geodetic location can be expressed in a variety of ways. The same geodetic location can be expressed in a variety of ways. The
PIDF-LO Geodetic Shapes specification [3] provides a specific GML PIDF-LO Geodetic Shapes specification [4] provides a specific GML
profile for expressing commonly used shapes using simple GML profile for expressing commonly used shapes using simple GML
representations. The shapes defined in [3] are the recommended representations. The shapes defined in [4] are the recommended
shapes to ensure interoperability. shapes to ensure interoperability.
5. Geodetic Shape Representation 5. 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
implemented in this manner for simplicity, and even more difficult to implemented 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.
The PIDF-LO Geodetic Shapes specification [3] defines eight shape The PIDF-LO Geodetic Shapes specification [4] defines eight shape
types most of which are easily translated into shapes definitions types most of which are easily translated into shapes definitions
used in other applications and protocols, such as Open Mobile used in other applications and protocols, such as Open Mobile
Alliance (OMA) Mobile Location Protocol (MLP). For completeness the Alliance (OMA) Mobile Location Protocol (MLP). For completeness the
shapes defined in [3] are listed below: shapes defined in [4] are listed below:
o Point (2d and 3d) o Point (2d and 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) o Sphere (3d)
o Ellipsoid (3d) o Ellipsoid (3d)
o Prism (3d) o Prism (3d)
All above-listed shapes are mandatory to implement. All above-listed shapes are mandatory to implement.
The GeoShape specification [3] also describes a standard set of The GeoShape specification [4] also describes a standard set of
coordinate reference systems (CRS), unit of measure (UoM) and coordinate reference systems (CRS), unit of measure (UoM) and
conventions relating to lines and distances. The use of the WGS-84 conventions relating to lines and distances. The use of the WGS-84
coordinate reference system and the usage of EPSG-4326 (as identified coordinate reference system and the usage of EPSG-4326 (as identified
by the URN urn:ogc:def:crs:EPSG::4326) for two dimensional (2d) shape by the URN urn:ogc:def:crs:EPSG::4326) for two dimensional (2d) shape
representations and EPSG-4979 (as identified by the URN representations and EPSG-4979 (as identified by the URN
urn:ogc:def:crs:EPSG::4979) for three dimensional (3d) volume urn:ogc:def:crs:EPSG::4979) for three dimensional (3d) volume
representations is mandated. Distance and heights are expressed in representations is mandated. Distance and heights are expressed in
meters using EPSG-9001 (as identified by the URN meters using EPSG-9001 (as identified by the URN
urn:ogc:def:uom:EPSG::9001). Angular measures MUST use either urn:ogc:def:uom:EPSG::9001). Angular measures MUST use either
degrees or radians. Measures in degrees MUST be identified by the degrees or radians. Measures in degrees MUST be identified by the
skipping to change at page 12, line 24 skipping to change at page 12, line 24
omitted, since the number of dimensions in these CRSs is known. A omitted, since the number of dimensions in these CRSs is known. A
CRS MUST be specified using the above URN notation only, CRS MUST be specified using the above URN notation only,
implementations do not need to support user-defined CRSs. implementations do not need to support user-defined CRSs.
It is RECOMMENDED that where uncertainty is included, a confidence of It is RECOMMENDED that where uncertainty is included, a confidence of
68% (or one standard deviation) is used. Specifying a convention for 68% (or one standard deviation) is used. Specifying a convention for
confidence enables better use of uncertainty values. confidence enables better use of uncertainty values.
5.1. Polygon Restrictions 5.1. Polygon Restrictions
The Polygon shape type defined in [3] intentionally does not place The Polygon shape type defined in [4] intentionally does not place
any constraints on the number of vertices that may be included to any constraints on the number of vertices that may be included to
define the bounds of a polygon. This allows arbitrarily complex define the bounds of a polygon. This allows arbitrarily complex
shapes to be defined and conveyed in a PIDF-LO. However, where shapes to be defined and conveyed in a PIDF-LO. However, where
location information is to be used in real-time processing location information is to be used in real-time processing
applications, such as location dependent routing, having arbitrarily applications, such as location dependent routing, having arbitrarily
complex shapes consisting of tens or even hundreds of points could complex shapes consisting of tens or even hundreds of points could
result in significant performance impacts. To mitigate this risk it result in significant performance impacts. To mitigate this risk it
is recommended that Polygon shapes be restricted to a maximum of 15 is recommended that Polygon shapes be restricted to a maximum of 15
points (16 including the repeated point) when the location points (16 including the repeated point) when the location
information is intended for use in real-time applications. This information is intended for use in real-time applications. This
limit of 15 points is chosen to allow moderately complex shape limit of 15 points is chosen to allow moderately complex shape
definitions while at the same time enabling interoperation with other definitions while at the same time enabling interoperation with other
location transporting protocols such as those defined in 3GPP (see location transporting protocols such as those defined in 3GPP (see
[8]) and OMA where the 15 point limit is already imposed. [9]) and OMA where the 15 point limit is already imposed.
Polygons are defined with the minimum distance between two adjacent Polygons are defined with the minimum distance between two adjacent
vertices (geodesic). A connecting line SHALL NOT cross another vertices (geodesic). To avoid the incursion of significant errors
connecting line of the same Polygon. Polygons SHOULD be defined with length between adjacent vertices SHOULD be restricted to a maximum of
the upward normal pointing up, this is accomplished by defining the 130km. More information relating to this restriction is provided in
vertices in counter-clockwise direction. [4].
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 Points specified in a polygon MUST be coplanar, and it is RECOMMENDED
that where points are specified in 3 dimensions that all points that where points are specified in 3 dimensions that all points
maintain the same altitude. maintain the same altitude.
5.2. Shape Examples 5.2. Shape Examples
This section provides some examples of where some of the more complex This section provides some examples of where some of the more complex
shapes are used, how they are determined, and how they are shapes are used, how they are determined, and how they are
represented in a PIDF-LO. Complete details on all of the Geoshape represented in a PIDF-LO. Complete details on all of the Geoshape
types are provided in [3]. types are provided in [4].
5.2.1. Point 5.2.1. Point
The point shape type is the simplest form of geodetic LI, which is The point shape type is the simplest form of geodetic LI, which is
natively supported by GML. The gml:Point element is used when there natively supported by GML. The gml:Point element is used when there
is no known uncertainty. A point also forms part of a number of is no known uncertainty. A point also forms part of a number of
other geometries. A point may be specified using either WGS 84 other geometries. A point may be specified using either WGS 84
(latitude, longitude) or WGS 84 (latitude, longitude, altitude). The (latitude, longitude) or WGS 84 (latitude, longitude, altitude). The
next example shows a 2d point: next example shows a 2d point:
skipping to change at page 15, line 38 skipping to change at page 15, line 38
</gml:exterior> </gml:exterior>
</gml:Polygon> </gml:Polygon>
</gp:location-info> </gp:location-info>
<gp:usage-rules/> <gp:usage-rules/>
</gp:geopriv> </gp:geopriv>
</status> </status>
<timestamp>2007-06-22T20:57:29Z</timestamp> <timestamp>2007-06-22T20:57:29Z</timestamp>
</tuple> </tuple>
</presence> </presence>
Figure 6
In addition to the form shown in Figure 6 GML supports a posList
which provides a more compact representation for the coordinates of
the Polygon vertices than the discrete pos elements. The more
compact form is shown in Figure 7. Both forms are permitted.
<?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:posList>43.311 -73.422 43.211 -73.422
43.111 -73.322 43.111 -73.222
43.211 -73.122 43.311 -73.122
43.411 -73.222 43.411 -73.322
43.311 -73.422
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gp:location-info>
<gp:usage-rules/>
</gp:geopriv>
</status>
<timestamp>2007-06-22T20:57:29Z</timestamp>
</tuple>
</presence>
Figure 7
5.2.3. Circle 5.2.3. Circle
The circular area is used for coordinates in two-dimensional CRSs to The circular area is used for coordinates in two-dimensional CRSs to
describe uncertainty about a point. The definition is based on the describe uncertainty about a point. The definition is based on the
one-dimensional geometry in GML, gml:CircleByCenterPoint. The centre one-dimensional geometry in GML, gml:CircleByCenterPoint. The centre
point of a circular area is specified by using a two dimensional CRS; point of a circular area is specified by using a two dimensional CRS;
in three dimensions, the orientation of the circle cannot be in three dimensions, the orientation of the circle cannot be
specified correctly using this representation. A point with specified correctly using this representation. A point with
uncertainty that is specified in three dimensions should use the uncertainty that is specified in three dimensions should use the
Sphere shape type. Sphere shape type.
skipping to change at page 16, line 36 skipping to change at page 17, line 36
</status> </status>
</tuple> </tuple>
</presence> </presence>
5.2.4. Ellipse 5.2.4. Ellipse
An elliptical area describes an ellipse in two dimensional space. An elliptical area describes an ellipse in two dimensional space.
The ellipse is described by a center point, the length of its semi- The ellipse is described by a center point, the length of its semi-
major and semi-minor axes, and the orientation of the semi-major major and semi-minor axes, and the orientation of the semi-major
axis. Like the circular area (Circle), the ellipse MUST be specified axis. Like the circular area (Circle), the ellipse MUST be specified
using a two dimensional CRS. using the two dimensional CRS.
<?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="http://www.opengis.net/pidflo/1.0" xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
entity="pres:Ellipse@somecell.example.com"> entity="pres:Ellipse@somecell.example.com">
<tuple id="sg89ab7"> <tuple id="sg89ab7">
<status> <status>
skipping to change at page 22, line 45 skipping to change at page 23, line 45
</gp:geopriv> </gp:geopriv>
</status> </status>
<timestamp>2003-06-22T20:57:29Z</timestamp> <timestamp>2003-06-22T20:57:29Z</timestamp>
</tuple> </tuple>
</presence> </presence>
5.2.8. Prism 5.2.8. Prism
A prism may be used to represent a section of a building or range of A prism may be used to represent a section of a building or range of
floors of building. The prism extrudes a polygon by providing a floors of building. The prism extrudes a polygon by providing a
height element. It consists of a base made up of coplanar 3 points height element. It consists of a base made up of coplanar points
defined in 3 dimensions all at the same altitude. The prism is then 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 an extrusion from this base to the value specified in the height
element. If the height is negative, then the prism is extruded from 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 top down, while a positive height extrudes from the bottom up.
The first and last points of the polygon have to be the same. The first and last points of the polygon have to be the same.
For example, looking at the cube below. If the prism is extruded For example, looking at the cube below. If the prism is extruded
from the bottom up, then the polygon forming the base of the prism is from 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 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 distance between point A and point E in meters. The resulting
skipping to change at page 25, line 5 skipping to change at page 26, line 5
</gs:height> </gs:height>
</gs:Prism> </gs:Prism>
</gp:location-info> </gp:location-info>
<gp:usage-rules/> <gp:usage-rules/>
</gp:geopriv> </gp:geopriv>
</status> </status>
<timestamp>2007-06-22T20:57:29Z</timestamp> <timestamp>2007-06-22T20:57:29Z</timestamp>
</tuple> </tuple>
</presence> </presence>
6. Recommendations 6. Security Considerations
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 [3] 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.
7. Security Considerations
The primary security considerations relate to how location The primary security considerations relate to how location
information is conveyed and used, which are outside the scope of this information is conveyed and used, which are outside the scope of this
document. This document is intended to serve only as a set of document. This document is intended to serve only as a set of
guidelines as to which elements MUST or SHOULD be implemented by guidelines as to which elements MUST or SHOULD be implemented by
systems wishing to perform location dependent routing. The systems wishing to perform location dependent routing. The
ramification of such recommendations is that they extend to devices ramification of such recommendations is that they extend to devices
and clients that wish to make use of such services. and clients that wish to make use of such services.
8. IANA Considerations 7. IANA Considerations
This document does not introduce any IANA considerations. This document does not introduce any IANA considerations.
9. Acknowledgments 8. 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, Henning Schulzrinne, Jerome Grenier, Roger Marshall
to thank Jon Peterson as the author of PIDF-LO and Nadine Abbott for and Robert Sparks. Furthermore, we would like to thank Jon Peterson
her constructive comments in clarifying some aspects of the document. as the author of PIDF-LO and Nadine Abbott for her constructive
comments in clarifying some aspects of the document.
10. References 9. References
10.1. Normative references 9.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", BCP 14, RFC 2119, March 1997.
[2] Peterson, J., "A Presence-based GEOPRIV Location Object Format", [2] Peterson, J., "A Presence-based GEOPRIV Location Object Format",
RFC 4119, December 2005. RFC 4119, December 2005.
[3] Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape Application [3] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006.
[4] Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape Application
Schema for use by the Internet Engineering Task Force (IETF)", Schema for use by the Internet Engineering Task Force (IETF)",
Candidate OpenGIS Implementation Specification 06-142, Version: Candidate OpenGIS Implementation Specification 06-142, Version:
0.0.9, December 2006. 0.0.9, December 2006.
10.2. Informative References 9.2. Informative References
[4] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 [5] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4
and DHCPv6) Option for Civic Addresses Configuration and DHCPv6) Option for Civic Addresses Configuration
Information", RFC 4776, November 2006. Information", RFC 4776, November 2006.
[5] Thomson, M. and J. Winterbottom, "Revised Civic Location Format [6] Thomson, M. and J. Winterbottom, "Revised Civic Location Format
for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-05 (work in for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-05 (work in
progress), February 2007. progress), February 2007.
[6] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. [7] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
Polk, "Geopriv Requirements", RFC 3693, February 2004. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[7] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host [8] 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.
[8] "3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project; [9] "3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project;
Technical Specification Group Code Network; Universal Geographic Technical Specification Group Code Network; Universal Geographic
Area Description (GAD)". Area Description (GAD)".
Authors' Addresses Authors' Addresses
James Winterbottom James Winterbottom
Andrew Corporation Andrew Corporation
Wollongong Wollongong
NSW Australia NSW Australia
 End of changes. 39 change blocks. 
91 lines changed or deleted 131 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/