draft-ietf-geopriv-pdif-lo-profile-01.txt   draft-ietf-geopriv-pdif-lo-profile-02.txt 
Geopriv J. Winterbottom Geopriv J. Winterbottom
Internet-Draft M. Thomson Internet-Draft M. Thomson
Expires: January 19, 2006 Nortel Expires: August 8, 2006 Andrew Corporation
H. Tschofenig H. Tschofenig
Siemens Siemens
July 18, 2005 February 4, 2006
GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations
draft-ietf-geopriv-pdif-lo-profile-01.txt draft-ietf-geopriv-pdif-lo-profile-02.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 January 19, 2006. This Internet-Draft will expire on August 8, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
The Presence Information Data Format Location Object (PIDF-LO) The Presence Information Data Format Location Object (PIDF-LO)
specification provides a flexible and versatile means to represent specification provides a flexible and versatile means to represent
location information. There are, however, circumstances that arise location information. There are, however, circumstances that arise
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
skipping to change at page 3, line 7 skipping to change at page 3, line 7
tightly constrained than is currently specified in the PIDF-LO. This tightly constrained than is currently specified in the PIDF-LO. This
document makes recommendations on how to constrain, represent and document makes recommendations on how to constrain, represent and
interpret locations in a PIDF-LO. It further looks at existing interpret locations in a PIDF-LO. It further looks at existing
communications standards that make use of geodetic information for communications standards that make use of geodetic information for
routing purposes and recommends a subset of GML that MUST be routing purposes and recommends a subset of GML that MUST be
implemented by applications to allow location dependent routing to implemented by applications to allow location dependent routing to
occur. occur.
Table of Contents Table of Contents
1. CHANGES SINCE LAST TIME . . . . . . . . . . . . . . . . . . 4 1. CHANGES SINCE LAST TIME . . . . . . . . . . . . . . . . . . . 4
1.1 01 changes . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. 01 changes . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Using Location Information . . . . . . . . . . . . . . . . . 7 4. Using Location Information . . . . . . . . . . . . . . . . . . 7
4.1 Single Civic Location Information . . . . . . . . . . . . 8 4.1. Single Civic Location Information . . . . . . . . . . . . 8
4.2 Civic and Geospatial Location Information . . . . . . . . 9 4.2. Civic and Geospatial Location Information . . . . . . . . 9
4.3 Manual/Automatic Configuration of Location Information . . 11 4.3. Manual/Automatic Configuration of Location Information . . 11
5. Geodetic Coordinate Representation . . . . . . . . . . . . . 12 5. Geodetic Coordinate Representation . . . . . . . . . . . . . . 12
6. Uncertainty in Location Representation . . . . . . . . . . . 14 6. Uncertainty in Location Representation . . . . . . . . . . . . 14
6.1 Arc band . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Arc band . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2 Ellipsoid Point With Uncertainty Circle . . . . . . . . . 18 6.2. Ellipsoid Point With Uncertainty Circle . . . . . . . . . 18
6.3 Polygon . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.3. Polygon . . . . . . . . . . . . . . . . . . . . . . . . . 21
7. Baseline Geometry . . . . . . . . . . . . . . . . . . . . . 23 7. Baseline Geometry . . . . . . . . . . . . . . . . . . . . . . 24
7.1 Zero Dimensions . . . . . . . . . . . . . . . . . . . . . 23 7.1. Zero Dimensions . . . . . . . . . . . . . . . . . . . . . 24
7.2 One Dimensions . . . . . . . . . . . . . . . . . . . . . . 23 7.2. One Dimensions . . . . . . . . . . . . . . . . . . . . . . 24
7.3 Two Dimensions . . . . . . . . . . . . . . . . . . . . . . 24 7.3. Two Dimensions . . . . . . . . . . . . . . . . . . . . . . 25
7.4 Three Dimensions . . . . . . . . . . . . . . . . . . . . . 24 7.4. Three Dimensions . . . . . . . . . . . . . . . . . . . . . 25
7.5 Envelopes . . . . . . . . . . . . . . . . . . . . . . . . 24 7.5. Envelopes . . . . . . . . . . . . . . . . . . . . . . . . 25
7.6 Temporal Dimensions . . . . . . . . . . . . . . . . . . . 25 7.6. Temporal Dimensions . . . . . . . . . . . . . . . . . . . 26
7.7 Units of Measure . . . . . . . . . . . . . . . . . . . . . 25 7.7. Units of Measure . . . . . . . . . . . . . . . . . . . . . 26
7.8 Coordinate Reference System (CRS) . . . . . . . . . . . . 25 7.8. Coordinate Reference System (CRS) . . . . . . . . . . . . 26
8. Recommendations . . . . . . . . . . . . . . . . . . . . . . 27 8. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 28
9. Security Considerations . . . . . . . . . . . . . . . . . . 28 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 29 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 30 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 31 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 32
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
13.1 Normative references . . . . . . . . . . . . . . . . . . 32 13.1. Normative references . . . . . . . . . . . . . . . . . . . 33
13.2 Informative References . . . . . . . . . . . . . . . . . 32 13.2. Informative References . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 33 Appendix A. Creating a PIDF-LO from DHCP Geo Encoded Data . . . . 34
A. Creating a PIDF-LO from DHCP Geo Encoded Data . . . . . . . 34 A.1. Latitude and Longitude . . . . . . . . . . . . . . . . . . 34
A.1 Latitude and Longitude . . . . . . . . . . . . . . . . . . 34 A.2. Altitude . . . . . . . . . . . . . . . . . . . . . . . . . 36
A.2 Altitude . . . . . . . . . . . . . . . . . . . . . . . . . 36 A.3. Generating the PIDF-LO . . . . . . . . . . . . . . . . . . 36
A.3 Generating the PIDF-LO . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
Intellectual Property and Copyright Statements . . . . . . . 41 Intellectual Property and Copyright Statements . . . . . . . . . . 42
1. CHANGES SINCE LAST TIME 1. CHANGES SINCE LAST TIME
1.1 01 changes 1.1. 01 changes
minor changes to the abstract. minor changes to the abstract.
Minor changes to the introduction. Minor changes to the introduction.
Added and appendix to take implementers through how to create a Added and appendix to take implementers through how to create a
PIDF-LO from data received using DHCP option 123 as defined in [3]. PIDF-LO from data received using DHCP option 123 as defined in [3].
Rectified examples to use position and pos rather than location and Rectified examples to use position and pos rather than location and
point. point.
skipping to change at page 8, line 42 skipping to change at page 8, line 42
PIDF document. That is to say, the tuple with the highest PIDF document. That is to say, the tuple with the highest
priority location occurs earliest in the PIDF document. Initial priority location occurs earliest in the PIDF document. Initial
priority SHOULD be determined by the originating UA, the final priority SHOULD be determined by the originating UA, the final
priority MAY be determined by a proxy along the way. priority MAY be determined by a proxy along the way.
Rule #9: Where multiple PIDF documents are contained within a single Rule #9: Where multiple PIDF documents are contained within a single
request, document selection SHOULD be based on document order. request, document selection SHOULD be based on document order.
The following examples illustrate the useful of these rules. The following examples illustrate the useful of these rules.
4.1 Single Civic Location Information 4.1. Single Civic Location Information
Jane is at a coffee shop on the ground floor of a large shopping Jane is at a coffee shop on the ground floor of a large shopping
mall. Jane turns on her laptop and connects to mall. Jane turns on her laptop and connects to the coffee-shop's
the coffee-shop's WiFi hotspot, Jane obtains a complete civic address WiFi hotspot, Jane obtains a complete civic address for her current
for her current location, for example using [5]. She constructs a location, for example using [5]. She constructs a Location Object
Location Object which consists of a single PIDF document, with a which consists of a single PIDF document, with a single geopriv
single geopriv tuple, with a single location residing in the tuple, with a single location residing in the <location-info>
<location-info> element. This is largely unambiguous, and if this element. This is largely unambiguous, and if this location is sent
location is sent over the network, providing it understands civic over the network, providing it understands civic addresses, correct
addresses, correct handling of any request should be possible. handling of any request should be possible.
4.2 Civic and Geospatial Location Information 4.2. Civic and Geospatial Location Information
Mike is visiting his Seattle office and connects his laptop into the Mike is visiting his Seattle office and connects his laptop into the
Ethernet port in a spare cube. Mike's computer receives a location Ethernet port in a spare cube. Mike's computer receives a location
over DHCP as defined in [3]. In this case the location is a geodetic over DHCP as defined in [3]. In this case the location is a geodetic
location, with the altitude represented as a building floor number. location, with the altitude represented as a building floor number.
This is constructed by Mike's computer into the following PIDF This is constructed by Mike's computer into the following PIDF
document: document:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
skipping to change at page 11, line 36 skipping to change at page 11, line 36
</gp:geopriv> </gp:geopriv>
</status> </status>
<timestamp>2003-06-22T20:57:29Z</timestamp> <timestamp>2003-06-22T20:57:29Z</timestamp>
</tuple> </tuple>
</presence> </presence>
It is now clear that the main location of user is a geodetic location It is now clear that the main location of user is a geodetic location
at latitude 37.775 and longitude -122.4194. Further that the user is at latitude 37.775 and longitude -122.4194. Further that the user is
on the second floor of the building located at those coordinates. on the second floor of the building located at those coordinates.
4.3 Manual/Automatic Configuration of Location Information 4.3. Manual/Automatic Configuration of Location Information
Erin has a predefined civic location stored in her laptop, since she Erin has a predefined civic location stored in her laptop, since she
normally lives in Sydney, the address in her address is for her normally lives in Sydney, the address in her address is for her
Sydney-based apartment. Erin decides to visit sunny San Francisco, Sydney-based apartment. Erin decides to visit sunny San Francisco,
and when she gets there she plugs in her laptop and makes a call. and when she gets there she plugs in her laptop and makes a call.
Erin's laptop receives a new location from the visited network in San Erin's laptop receives a new location from the visited network in San
Francisco and adds this to her existing PIDF location document. Francisco and adds this to her existing PIDF location document.
Applying rule #9, the resulting order of location information in the Applying rule #9, the resulting order of location information in the
PIDF document should be San Francisco first, followed by Sydney. PIDF document should be San Francisco first, followed by Sydney.
Since the information is provided by different sources, rule #8 Since the information is provided by different sources, rule #8
skipping to change at page 14, line 50 skipping to change at page 14, line 50
impossible using base GML. However, only a subset of GML, namely impossible using base GML. However, only a subset of GML, namely
feature.xsd, is mandatory for a PIDF-LO implementation. Extending feature.xsd, is mandatory for a PIDF-LO implementation. Extending
GML to easily represent these shapes may lead to interoperability GML to easily represent these shapes may lead to interoperability
issues and so is not recommended. The authors of this document were issues and so is not recommended. The authors of this document were
unable to find a means to express either an ellipse or and ellipsoid unable to find a means to express either an ellipse or and ellipsoid
using only the elements defined in feature.xsd. using only the elements defined in feature.xsd.
The following sections describe four shapes that can be defined in The following sections describe four shapes that can be defined in
GML, and show the equivalent representation in 3GPP MLP [4]. GML, and show the equivalent representation in 3GPP MLP [4].
6.1 Arc band 6.1. Arc band
Arc band is used primarily where timing advance (TA) information is Arc band is used primarily where timing advance (TA) information is
known. Timing advance is a mechanism used in wireless communications known. Timing advance is a mechanism used in wireless communications
to help ensure that handsets and base-stations remained synchronized. to help ensure that handsets and base-stations remained synchronized.
Timing advance is stepped based on signal propagation and is fairly Timing advance is stepped based on signal propagation and is fairly
deterministic, for GSM each increase in TA value represents 553.85 deterministic, for GSM each increase in TA value represents 553.85
metres. metres.
The arc band type was developed to represent the area between two The arc band type was developed to represent the area between two
successive TA values and an antenna opening. This is presented in successive TA values and an antenna opening. This is presented in
skipping to change at page 18, line 37 skipping to change at page 18, line 40
being used, and how to interpret it is important, and this is being used, and how to interpret it is important, and this is
particularly true if the shape must also be validated as is the case particularly true if the shape must also be validated as is the case
above. above.
Ensuring the legality of this shape type when represented in GML is Ensuring the legality of this shape type when represented in GML is
more complex than in MLP as the type must first be determined before more complex than in MLP as the type must first be determined before
its validity can be assessed. Users of this shape type may be better its validity can be assessed. Users of this shape type may be better
served by a formal shape definition being introduced into GeoPriv so served by a formal shape definition being introduced into GeoPriv so
that these problems can be more readily overcome. that these problems can be more readily overcome.
6.2 Ellipsoid Point With Uncertainty Circle 6.2. Ellipsoid Point With Uncertainty Circle
This shape type is used extensively over the North American NENA This shape type is used extensively over the North American NENA
defined E2 interface for transporting mobile geodetic location from defined E2 interface for transporting mobile geodetic location from
the MPC/GMLC to the ALI and subsequently the PSAPs. In 3GPP this is the MPC/GMLC to the ALI and subsequently the PSAPs. In 3GPP this is
defined as a WGS-84 point (ellipsoid point), and a radius or defined as a WGS-84 point (ellipsoid point), and a radius or
uncertainty around that point, specified in metres. The 3GPP MLP uncertainty around that point, specified in metres. The 3GPP MLP
representation for an ellipsoid point with uncertainty is defined as representation for an ellipsoid point with uncertainty is defined as
follows: follows:
<pd> <pd>
skipping to change at page 21, line 4 skipping to change at page 21, line 5
<timestamp>2004-12-01T09:28:43+10:00</timestamp> <timestamp>2004-12-01T09:28:43+10:00</timestamp>
</tuple> </tuple>
</presence> </presence>
This type does not have all of the problems associated with the arc This type does not have all of the problems associated with the arc
band representation, in that the radius of the circle is relative to band representation, in that the radius of the circle is relative to
the centre, and so the validation is unnecessary. However it does the centre, and so the validation is unnecessary. However it does
suffer from the potential problem that the application still needs to suffer from the potential problem that the application still needs to
determine the type of uncertainty being represented, though this determine the type of uncertainty being represented, though this
maybe made more clear through the explicit use of the gml: maybe made more clear through the explicit use of the gml:
CircleByCenterPoint element. CircleByCenterPoint element.
6.3 Polygon 6.3. Polygon
A polygon is defined as a set of points to form an enclosed bounded A polygon is defined as a set of points to form an enclosed bounded
shape. It is here that GML and the 3GPP shapes are most similar. shape. It is here that GML and the 3GPP shapes are most similar.
The representation for a polygon in GML is given first: The representation for a polygon in GML is given first:
<?xml version="1.0"?> <?xml version="1.0"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:pidf="urn:ietf:params:xml:ns:pidf" xmlns:pidf="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:gml="http://opengis.net/gml" xmlns:gml="http://opengis.net/gml"
skipping to change at page 23, line 21 skipping to change at page 24, line 21
measure.xsd, units.xsd, gmlBase.xsd, dictionary.xsd, xLinks.xsd and measure.xsd, units.xsd, gmlBase.xsd, dictionary.xsd, xLinks.xsd and
basicTypes.xsd, as being necessary to support. This provides for a basicTypes.xsd, as being necessary to support. This provides for a
vast range of possibilities which would pose significant vast range of possibilities which would pose significant
complications to implementors wish to develop location dependent complications to implementors wish to develop location dependent
routing applications. By agreeing to a minimal set of data routing applications. By agreeing to a minimal set of data
appropriate for routing, a minimum set of GML that MUST be appropriate for routing, a minimum set of GML that MUST be
implemented by a given application type can also be set. This does implemented by a given application type can also be set. This does
not preclude the additional functionality from being implemented, not preclude the additional functionality from being implemented,
merely that it may not be understood by some nodes. merely that it may not be understood by some nodes.
7.1 Zero Dimensions 7.1. Zero Dimensions
The minimum supported set of elements is position/Point/pos provided The minimum supported set of elements is position/Point/pos provided
by geometryBasic0d1d.xsd. by geometryBasic0d1d.xsd.
Thus a point location has only one representation as follows: Thus a point location has only one representation as follows:
<gml:position xmlns:gml="http://www.opengis.net/gml"> <gml:position xmlns:gml="http://www.opengis.net/gml">
<gml:Point srsName="urn:ogc:def:crs:EPSG:4326"> <gml:Point srsName="urn:ogc:def:crs:EPSG:4326">
<gml:pos>4.5 -36.2</gml:pos> <gml:pos>4.5 -36.2</gml:pos>
</gml:Point> </gml:Point>
skipping to change at page 23, line 43 skipping to change at page 24, line 43
The <location> and <coord> objects MUST NOT be used since they are The <location> and <coord> objects MUST NOT be used since they are
deprecated in GML 3.1 and their functionality can be substituted with deprecated in GML 3.1 and their functionality can be substituted with
the above-described elements. the above-described elements.
Note that pos allows altitude to be expressed based on the selected Note that pos allows altitude to be expressed based on the selected
Coordinate Reference Systems (e.g., EPSG:4979 or EPSG:4326). Most Coordinate Reference Systems (e.g., EPSG:4979 or EPSG:4326). Most
Coordinate Reference Systems use altitude above the geoid and not Coordinate Reference Systems use altitude above the geoid and not
altitude above the ground. altitude above the ground.
7.2 One Dimensions 7.2. One Dimensions
Support for one dimensional shapes (such as the LineString or the Support for one dimensional shapes (such as the LineString or the
posList object)is not required except as a part of two dimensional posList object)is not required except as a part of two dimensional
shapes. shapes.
geometryBasic0d1d.xsd provides these geometric properties and geometryBasic0d1d.xsd provides these geometric properties and
objects. objects.
7.3 Two Dimensions 7.3. Two Dimensions
The examples previously used were all contructed using elements from The examples previously used were all contructed using elements from
this schema which reuse functionality from geometryBasic2d.xsd. As this schema which reuse functionality from geometryBasic2d.xsd. As
was described earlier the arcband definition in GML is problematic was described earlier the arcband definition in GML is problematic
for producing a closed solid and SHOULD consequently be avoided. As for producing a closed solid and SHOULD consequently be avoided. As
a result of this, elements required exclusively for representing the a result of this, elements required exclusively for representing the
arcband shape have not been included in the minimum supported element arcband shape have not been included in the minimum supported element
set. The minimum element set is therefore restricted to circle and set. The minimum element set is therefore restricted to circle and
polygon. polygon.
skipping to change at page 24, line 42 skipping to change at page 25, line 42
above, is inline with the model used by the 3GPP. above, is inline with the model used by the 3GPP.
Polygon: Polygon:
extentOf/ extentOf/
Polygon/ Polygon/
exterior/ exterior/
LinearRing/ LinearRing/
pos or posList -> Polygon pos or posList -> Polygon
7.4 Three Dimensions 7.4. Three Dimensions
Support for three dimensions is not required Support for three dimensions is not required
7.5 Envelopes 7.5. Envelopes
The Envelope element is a representation of a bounding box and can be The Envelope element is a representation of a bounding box and can be
expressed in two or three dimensions. Defining a space using the expressed in two or three dimensions. Defining a space using the
Envelope element should be done with extreme caution due to Envelope element should be done with extreme caution due to
continuity problems at the extremities of the CRS. In WGS-84, two continuity problems at the extremities of the CRS. In WGS-84, two
envelopes are required at the 180th meridian. The minimum set of envelopes are required at the 180th meridian. The minimum set of
elements required to support an Envelope are: elements required to support an Envelope are:
boundBy/ boundBy/
Envelope/ Envelope/
upperCorner/ upperCorner/
Point/ Point/
Pos Pos
lowerCorner/ lowerCorner/
Point/ Point/
Pos/ Pos/
7.6 Temporal Dimensions 7.6. Temporal Dimensions
Support for temporal elements is not required Support for temporal elements is not required
7.7 Units of Measure 7.7. Units of Measure
The base SI units as a minimum MUST be supported. For measures of The base SI units as a minimum MUST be supported. For measures of
distance this is metres. The EPSG URN for metres is: distance this is metres. The EPSG URN for metres is:
metres = urn:ogc:def:uom:EPSG:9001:6.6 metres = urn:ogc:def:uom:EPSG:9001:6.6
Angles are frequently expressed in terms of both degrees and radians, Angles are frequently expressed in terms of both degrees and radians,
consequently both MUST be implemented. consequently both MUST be implemented.
degrees = urn:ogc:def:uom:EPSG:9102:6.6 degrees = urn:ogc:def:uom:EPSG:9102:6.6
radians = urn:ogc:def:uom:EPSG:9101:6.6 radians = urn:ogc:def:uom:EPSG:9101:6.6
Further units of measurement are not required. Further units of measurement are not required.
7.8 Coordinate Reference System (CRS) 7.8. Coordinate Reference System (CRS)
There are a very large number of coordinate reference systems in There are a very large number of coordinate reference systems in
existence today, but many are, however, not in widespread use. existence today, but many are, however, not in widespread use.
Existing communications protocols such as those used in both the Existing communications protocols such as those used in both the
ANSI, 3GPP and NENA standards (see [6], [7], [8]) have standardized ANSI, 3GPP and NENA standards (see [6], [7], [8]) have standardized
on WGS-84. It is recommended for routing purpose that only WGS-84 on WGS-84. It is recommended for routing purpose that only WGS-84
coordinate types MUST be implemented and further that this set be coordinate types MUST be implemented and further that this set be
restricted to the following: restricted to the following:
WGS84(2D) = urn:ogc:def:crs:EPSG:6.6:4326 WGS84(2D) = urn:ogc:def:crs:EPSG:6.6:4326
skipping to change at page 32, line 7 skipping to change at page 33, line 7
Need to go through the rules to enhance clarity. These rules are Need to go through the rules to enhance clarity. These rules are
highly likely to be important in quite a number of Location Dependent highly likely to be important in quite a number of Location Dependent
Routing (LDR) based applications, including ECRIT. General feedback Routing (LDR) based applications, including ECRIT. General feedback
is that they are not clear or precise enough yet. Henning has is that they are not clear or precise enough yet. Henning has
provide some good feedback here that I have not had time to provide some good feedback here that I have not had time to
incorporate yet, some of these comments will hopefully be easier to incorporate yet, some of these comments will hopefully be easier to
resolve if open issue 1 above is also resoved. resolve if open issue 1 above is also resoved.
13. References 13. References
13.1 Normative references 13.1. Normative references
[1] Peterson, J., "A Presence-based GEOPRIV Location Object Format", [1] Peterson, J., "A Presence-based GEOPRIV Location Object Format",
draft-ietf-geopriv-pidf-lo-03 (work in progress), RFC 4119, December 2005.
September 2004.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", March 1997. Levels", March 1997.
13.2 Informative References 13.2. Informative References
[3] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host [3] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004. Configuration Information", RFC 3825, July 2004.
[4] "Mobile Location Protocol (MLP), OMA, Candidate Version 3.1", [4] "Mobile Location Protocol (MLP), OMA, Candidate Version 3.1",
March 2004. March 2004.
[5] 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", draft-ietf-geopriv-dhcp-civil-06 (work in Information", draft-ietf-geopriv-dhcp-civil-09 (work in
progress), May 2005. progress), January 2006.
[6] "TR-45 J-STD-036-AD-2 Enhanced Wireless 9-1-1 Phase 2". [6] "TR-45 J-STD-036-AD-2 Enhanced Wireless 9-1-1 Phase 2".
[7] "3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project; [7] "3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project;
Technical Specification Group Code Network; Universal Technical Specification Group Code Network; Universal
Geographic Area Description (GAD)". Geographic Area Description (GAD)".
[8] "NENA Standard for the Implementation of the Wireless Emergency [8] "NENA Standard for the Implementation of the Wireless Emergency
Service Protocol E2 Interface". Service Protocol E2 Interface".
[9] Schulzrinne, H., "A Document Format for Expressing Privacy [9] Schulzrinne, H., "A Document Format for Expressing Privacy
Preferences", draft-ietf-geopriv-common-policy-04 (work in Preferences", draft-ietf-geopriv-common-policy-06 (work in
progress), February 2005. progress), October 2005.
[10] Peterson, J., "A Presence Architecture for the Distribution of [10] Peterson, J., "A Presence Architecture for the Distribution of
GEOPRIV Location Objects", draft-ietf-geopriv-pres-02 (work in GEOPRIV Location Objects", draft-ietf-geopriv-pres-02 (work in
progress), September 2004. progress), September 2004.
Authors' Addresses
James Winterbottom
Nortel
Wollongong
NSW Australia
Email: winterb@nortel.com
Martin Thomson
Nortel
Wollongong
NSW Australia
Email: martin.thomson@nortel.com
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: Hannes.Tschofenig@siemens.com
Appendix A. Creating a PIDF-LO from DHCP Geo Encoded Data Appendix A. Creating a PIDF-LO from DHCP Geo Encoded Data
RFC-3825 [3] describes a means by which an end-point may learns it RFC-3825 [3] describes a means by which an end-point may learns it
location from information encoded into DHCP option 123. The location from information encoded into DHCP option 123. The
following section describes how and end-point can take this following section describes how and end-point can take this
information and represent it in a well formed PIDF-LO describing this information and represent it in a well formed PIDF-LO describing this
geodetic location. geodetic location.
The location information described in RFC-3825 consists of a The location information described in RFC-3825 consists of a
latitude, longitude, altitude and datum. latitude, longitude, altitude and datum.
A.1 Latitude and Longitude A.1. Latitude and Longitude
The latitude and longitude values are represented in degrees and The latitude and longitude values are represented in degrees and
decimal degrees. Latitude values are positive if north of the decimal degrees. Latitude values are positive if north of the
equator, and negative if south of the equator. Similarly equator, and negative if south of the equator. Similarly
longitudinal values are positive if east of the Greenwich meridian, longitudinal values are positive if east of the Greenwich meridian,
and negative if west of the Greenwich meridian. and negative if west of the Greenwich meridian.
The latitude and longitude values are each 34 bit long fields The latitude and longitude values are each 34 bit long fields
consisting of a 9 bit integer component and a 25 bit fraction consisting of a 9 bit integer component and a 25 bit fraction
component, with negative numbers being represented in 2s complement component, with negative numbers being represented in 2s complement
skipping to change at page 36, line 5 skipping to change at page 36, line 5
in a total of 20 bits of precision. in a total of 20 bits of precision.
With -34.4167, 150.5333 encoded with 20 bits of precision for the With -34.4167, 150.5333 encoded with 20 bits of precision for the
LaRes and LoRes, the corners of the enclosing square are: LaRes and LoRes, the corners of the enclosing square are:
Point 1 (-34.4170, 150.5332) Point 1 (-34.4170, 150.5332)
Point 2 (-34.4170, 150.5337) Point 2 (-34.4170, 150.5337)
Point 3 (-34.4165, 150.5332) Point 3 (-34.4165, 150.5332)
Point 4 (-34.4165, 150.5337) Point 4 (-34.4165, 150.5337)
A.2 Altitude A.2. Altitude
The altitude elements define how the altitude is encoded and to what The altitude elements define how the altitude is encoded and to what
level of precision. The units for altitude are either metres, or level of precision. The units for altitude are either metres, or
floors, with the actual measurement being encoded in a similar manner floors, with the actual measurement being encoded in a similar manner
to those for latitude and longitude, but with 22 bit integer, and 8 to those for latitude and longitude, but with 22 bit integer, and 8
bit fractional components. bit fractional components.
A.3 Generating the PIDF-LO A.3. Generating the PIDF-LO
If altitude is not required, or is expressed in floors then a If altitude is not required, or is expressed in floors then a
geodetic location expressed by a polygon SHOULD be used. If the geodetic location expressed by a polygon SHOULD be used. If the
altitude is expressed in floors and is required, the altitude SHOULD altitude is expressed in floors and is required, the altitude SHOULD
be expressed as a civic floor number as part of the same location- be expressed as a civic floor number as part of the same location-
info element. In the example above the GML for the location would be info element. In the example above the GML for the location would be
expressed as follows: expressed as follows:
<gml:extentOf> <gml:extentOf>
<gml:Polygon> <gml:Polygon>
skipping to change at page 41, line 5 skipping to change at page 41, line 5
</gp:location-info> </gp:location-info>
<gp:usage-rules> <gp:usage-rules>
</gp:usage-rules> </gp:usage-rules>
<method>DHCP</method> <method>DHCP</method>
</gp:geopriv> </gp:geopriv>
</status> </status>
<timestamp>2005-07-05T14:49:53+10:00</timestamp> <timestamp>2005-07-05T14:49:53+10:00</timestamp>
</tuple> </tuple>
</presence> </presence>
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
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: Hannes.Tschofenig@siemens.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 41, line 41 skipping to change at page 42, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 34 change blocks. 
101 lines changed or deleted 99 lines changed or added

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