draft-ietf-geopriv-pdif-lo-profile-12.txt   draft-ietf-geopriv-pdif-lo-profile-13.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: March 16, 2009 Nokia Siemens Networks Expires: March 21, 2009 Nokia Siemens Networks
September 12, 2008 September 17, 2008
GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations
draft-ietf-geopriv-pdif-lo-profile-12.txt draft-ietf-geopriv-pdif-lo-profile-13.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 March 16, 2009. This Internet-Draft will expire on March 21, 2009.
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. when information needs to be constrained in how it is represented.
In these circumstances the range of options that need to be In these circumstances the range of options that need to be
implemented are reduced. There is growing interest in being able to implemented are reduced. There is growing interest in being able to
use location information contained in a PIDF-LO for routing use location information contained in a PIDF-LO for routing
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 . . . . . . . . . . . . 9 3.1. Single Civic Location Information . . . . . . . . . . . . 9
3.2. Civic and Geospatial Location Information . . . . . . . . 9 3.2. Civic and Geospatial Location Information . . . . . . . . 9
3.3. Manual/Automatic Configuration of Location Information . . 10 3.3. Manual/Automatic Configuration of Location Information . . 10
3.4. Multiple Location Objects in a Single PIDF-LO . . . . . . 11 3.4. Multiple Location Objects in a Single PIDF-LO . . . . . . 11
4. Geodetic Coordinate Representation . . . . . . . . . . . . . . 13 4. Geodetic Coordinate Representation . . . . . . . . . . . . . . 13
5. Geodetic Shape Representation . . . . . . . . . . . . . . . . 14 5. Geodetic Shape Representation . . . . . . . . . . . . . . . . 14
5.1. Polygon Restrictions . . . . . . . . . . . . . . . . . . . 15 5.1. Polygon Restrictions . . . . . . . . . . . . . . . . . . . 15
5.2. Shape Examples . . . . . . . . . . . . . . . . . . . . . . 16 5.2. Shape Examples . . . . . . . . . . . . . . . . . . . . . . 16
5.2.1. Point . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2.1. Point . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2.2. Polygon . . . . . . . . . . . . . . . . . . . . . . . 17 5.2.2. Polygon . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.3. Circle . . . . . . . . . . . . . . . . . . . . . . . . 19 5.2.3. Circle . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2.4. Ellipse . . . . . . . . . . . . . . . . . . . . . . . 20 5.2.4. Ellipse . . . . . . . . . . . . . . . . . . . . . . . 21
5.2.5. Arc Band . . . . . . . . . . . . . . . . . . . . . . . 21 5.2.5. Arc Band . . . . . . . . . . . . . . . . . . . . . . . 22
5.2.6. Sphere . . . . . . . . . . . . . . . . . . . . . . . . 23 5.2.6. Sphere . . . . . . . . . . . . . . . . . . . . . . . . 24
5.2.7. Ellipsoid . . . . . . . . . . . . . . . . . . . . . . 24 5.2.7. Ellipsoid . . . . . . . . . . . . . . . . . . . . . . 25
5.2.8. Prism . . . . . . . . . . . . . . . . . . . . . . . . 26 5.2.8. Prism . . . . . . . . . . . . . . . . . . . . . . . . 27
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.1. Normative references . . . . . . . . . . . . . . . . . . . 32 9.1. Normative references . . . . . . . . . . . . . . . . . . . 33
9.2. Informative References . . . . . . . . . . . . . . . . . . 32 9.2. Informative References . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . . . 34 Intellectual Property and Copyright Statements . . . . . . . . . . 35
1. Introduction 1. Introduction
The Presence Information Data Format Location Object (PIDF-LO) The Presence Information Data Format Location Object (PIDF-LO)
[RFC4119] is the recommended way of encoding location information and [RFC4119] is the 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 [RFC5139]. A GML profile for expressing civic location information [RFC5139]. A GML profile for expressing
geodetic shapes in a PIDF-LO is described in [GeoShape]. Uses for geodetic shapes in a PIDF-LO is described in [GeoShape]. Uses for
PIDF-LO are envisioned in the context of numerous location based PIDF-LO are envisioned in the context of numerous location based
skipping to change at page 10, line 26 skipping to change at page 10, line 26
<gml:pos>-43.5723 153.21760</gml:pos> <gml:pos>-43.5723 153.21760</gml:pos>
</gml:Point> </gml:Point>
<cl:civicAddress> <cl:civicAddress>
<cl:FLR>2</cl:FLR> <cl:FLR>2</cl:FLR>
</cl:civicAddress> </cl:civicAddress>
</gp:location-info> </gp:location-info>
<gp:usage-rules/> <gp:usage-rules/>
<method>Wiremap</method> <method>Wiremap</method>
</gp:geopriv> </gp:geopriv>
<timestamp>2007-06-22T20:57:29Z</timestamp> <timestamp>2007-06-22T20:57:29Z</timestamp>
<dm:deviceID>mac:8a-sd-7d-7d-70-cf</dm:deviceID> <dm:deviceID>
urn:uuid:f81d4fae-7dec-11d0-a765-8afd7d7d70cf
</dm:deviceID>
</dm:device> </dm:device>
</presence> </presence>
Figure 2 Figure 2
3.3. Manual/Automatic Configuration of Location Information 3.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 is for her Sydney-based she normally lives in Sydney, the address is for her Sydney-based
apartment. Loraine decides to visit sunny San Francisco, and when apartment. Loraine decides to visit sunny San Francisco, and when
skipping to change at page 11, line 35 skipping to change at page 11, line 35
<gml:pos>-34.410649 150.87651</gml:pos> <gml:pos>-34.410649 150.87651</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001"> <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
30 30
</gs:radius> </gs:radius>
</gs:Circle> </gs:Circle>
</gp:location-info> </gp:location-info>
<gp:usage-rules/> <gp:usage-rules/>
<method>GPS</method> <method>GPS</method>
</gp:geopriv> </gp:geopriv>
<timestamp>2007-06-22T20:57:29Z</timestamp> <timestamp>2007-06-22T20:57:29Z</timestamp>
<dm:deviceID>mac:12-34-56-78-90-ab</dm:deviceID> <dm:deviceID>
urn:uuid:f81d4fae-7dec-11d0-a765-1234567890ab
</dm:deviceID>
</dm:device> </dm:device>
<dm:person id="ness"> <dm:person id="ness">
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
<civicAddress xml:lang="en-AU"> <civicAddress xml:lang="en-AU">
<country>AU</country> <country>AU</country>
<A1>NSW</A1> <A1>NSW</A1>
<A3>Wollongong</A3> <A3>Wollongong</A3>
<A4>North Wollongong</A4> <A4>North Wollongong</A4>
<RD>Flinders</RD><STS>Street</STS> <RD>Flinders</RD><STS>Street</STS>
skipping to change at page 14, line 44 skipping to change at page 14, line 44
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. The above-listed shapes are MUST implement.
The GeoShape specification [GeoShape] also describes a standard set The GeoShape specification [GeoShape] also describes a standard set
of coordinate reference systems (CRS), unit of measure (UoM) and of 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
URN urn:ogc:def:uom:EPSG::9102, measures in radians MUST be URN urn:ogc:def:uom:EPSG::9102, measures in radians MUST be
identified by the URN urn:ogc:def:uom:EPSG::9101 identified by the URN urn:ogc:def:uom:EPSG::9101. Angles
representing bearings are measured in a clockwise direction from
Northing, as defined by the WGS84 CRS, not magnetic north.
Implementations MUST specify the CRS using the srsName attribute on Implementations MUST specify the CRS using the srsName attribute on
the outermost geometry element. The CRS MUST NOT be respecified or the outermost geometry element. The CRS MUST NOT be respecified or
changed for any sub-elements. The srsDimension attribute SHOULD be changed for any sub-elements. The srsDimension attribute SHOULD be
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 Numerical values for coordinates and measures are expressed using the
95% is used. Specifying a convention for confidence enables better lexical representation for "double" defined in
[W3C.REC-xmlschema-2-20041028]. Leading zeros and trailing zeros
past the decimal point are not significant; for instance "03.07500"
is equivalent to "3.075".
It is RECOMMENDED that uncertainty is expressed at a confidence of
95% or higher. Specifying a convention for confidence enables better
use of uncertainty values. use of uncertainty values.
5.1. Polygon Restrictions 5.1. Polygon Restrictions
The Polygon shape type defined in [GeoShape] intentionally does not The Polygon shape type defined in [GeoShape] intentionally does not
place any constraints on the number of vertices that may be included place any constraints on the number of vertices that may be included
to define the bounds of a polygon. This allows arbitrarily complex to 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
is recommended that Polygon shapes be restricted to a maximum of 15 Polygon shapes SHOULD be restricted to a maximum of 15 points (16
points (16 including the repeated point) when the location including the repeated point) when the location information is
information is intended for use in real-time applications. This intended for use in real-time applications. This limit of 15 points
limit of 15 points is chosen to allow moderately complex shape is chosen to allow moderately complex shape definitions while at the
definitions while at the same time enabling interoperation with other same time enabling interoperation with other location transporting
location transporting protocols such as those defined in 3GPP (see protocols such as those defined in 3GPP (see [3GPP-TS-23_032]) and
[3GPP-TS-23_032]) and OMA where the 15 point limit is already OMA where the 15 point limit is already imposed.
imposed.
The edges of a polygon are defined by the shortest path between two The edges of a polygon are defined by the shortest path between two
points in space (not a geodesic curce). To avoid significant errors points in space (not a geodesic curve). Two dimensioanl points MAY
arising from potential geodesic interpolation, the length between be interpreted as having a zero valure for their altitude component.
adjacent vertices SHOULD be restricted to a maximum of 130km. More To avoid significant errors arising from potential geodesic
information relating to this restriction is provided in [GeoShape]. interpolation, the length between adjacent vertices SHOULD be
restricted to a maximum of 130km. More information relating to this
restriction is provided in [GeoShape].
A connecting line SHALL NOT cross another connecting line of the same A connecting line SHALL NOT cross another connecting line of the same
Polygon. Polygon.
Polygons SHOULD be defined with the upward normal pointing up. This Polygons MUST be defined with the upward normal pointing up. This is
is accomplished by defining the vertices in a counter-clockwise accomplished by defining the vertices in a counter-clockwise
direction. direction.
Points specified in a polygon MUST be coplanar and it is RECOMMENDED Points specified in a polygon using 3 dimensional coordinates MUST
that where points are specified in 3 dimensions that all points all have 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 [GeoShape]. types are provided in [GeoShape].
5.2.1. Point 5.2.1. Point
skipping to change at page 16, line 44 skipping to change at page 17, line 23
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326"> <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-34.407 150.883</gml:pos> <gml:pos>-34.407 150.883</gml:pos>
</gml:Point> </gml:Point>
</gp:location-info> </gp:location-info>
<gp:usage-rules/> <gp:usage-rules/>
<method>Wiremap</method> <method>Wiremap</method>
</gp:geopriv> </gp:geopriv>
<timestamp>2007-06-22T20:57:29Z</timestamp> <timestamp>2007-06-22T20:57:29Z</timestamp>
<dm:deviceID>mac:12-34-56-78-90-ab</dm:deviceID> <dm:deviceID>
urn:uuid:f81d4fae-7dec-11d0-a765-1234567890ab
</dm:deviceID>
</dm:device> </dm:device>
</presence> </presence>
Figure 4 Figure 4
Figure 5 shows a 3d point: Figure 5 shows a 3d point:
<?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:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
skipping to change at page 17, line 24 skipping to change at page 18, line 24
<gp:location-info> <gp:location-info>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4979" <gml:Point srsName="urn:ogc:def:crs:EPSG::4979"
xmlns:gml="http://www.opengis.net/gml"> xmlns:gml="http://www.opengis.net/gml">
<gml:pos>-34.407 150.883 24.8</gml:pos> <gml:pos>-34.407 150.883 24.8</gml:pos>
</gml:Point> </gml:Point>
</gp:location-info> </gp:location-info>
<gp:usage-rules/> <gp:usage-rules/>
<method>Wiremap</method> <method>Wiremap</method>
</gp:geopriv> </gp:geopriv>
<timestamp>2007-06-22T20:57:29Z</timestamp> <timestamp>2007-06-22T20:57:29Z</timestamp>
<dm:deviceID>mac:12-34-56-78-90-ab</dm:deviceID> <dm:deviceID>
urn:uuid:f81d4fae-7dec-11d0-a765-1234567890ab
</dm:deviceID>
</dm:device> </dm:device>
</presence> </presence>
Figure 5 Figure 5
5.2.2. Polygon 5.2.2. Polygon
The polygon shape may be used to represent a building outline or The polygon shape may be used to represent a building outline or
coverage area. The first and last points of the polygon have to be coverage area. The first and last points of the polygon have to be
the same. For example, looking at the hexagon in Figure 6 with the same. For example, looking at the hexagon in Figure 6 with
skipping to change at page 26, line 48 skipping to change at page 27, line 48
Figure 15 Figure 15
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 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. The height of the Prism MUST be a positive value. The
the top down, while a positive height extrudes from the bottom up. 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 in Figure 16. If the prism is For example, looking at the cube in Figure 16. If the prism is
extruded from the bottom up, then the polygon forming the base of the extruded 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 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. prism is the distance between point A and point E in meters.
G-----F G-----F
/| /| /| /|
/ | / | / | / |
H--+--E | H--+--E |
skipping to change at page 32, line 28 skipping to change at page 33, line 28
[GeoShape] [GeoShape]
Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape
Application Schema for use by the Internet Engineering Application Schema for use by the Internet Engineering
Task Force (IETF)", Candidate OpenGIS Implementation Task Force (IETF)", Candidate OpenGIS Implementation
Specification 06-142r1, Version: 1.0, April 2007. Specification 06-142r1, Version: 1.0, April 2007.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for Presence Information Data Format Location Format for Presence Information Data Format Location
Object (PIDF-LO)", RFC 5139, February 2008. Object (PIDF-LO)", RFC 5139, February 2008.
[W3C.REC-xmlschema-2-20041028]
Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition", World Wide Web Consortium
Recommendation REC-xmlschema-2-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
9.2. Informative References 9.2. Informative References
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses (DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information", RFC 4776, November 2006. Configuration Information", RFC 4776, November 2006.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004. J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[3GPP-TS-23_032] [3GPP-TS-23_032]
 End of changes. 17 change blocks. 
48 lines changed or deleted 69 lines changed or added

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