Geopriv J. Winterbottom
Internet-Draft M. Thomson
Expires: September 4, 2006 Andrew Corporation
H. Tschofenig
Siemens
March 3, 2006
GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations
draft-ietf-geopriv-pdif-lo-profile-03.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 4, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Presence Information Data Format Location Object (PIDF-LO)
specification provides a flexible and versatile means to represent
location information. There are, however, circumstances that arise
when information needs to be constrained in how it is represented so
that the number of options that need to be implemented in order to
make use of it are reduced. There is growing interest in being able
Winterbottom, et al. Expires September 4, 2006 [Page 1]
Internet-Draft GEOPRIV PIDF-LO Profile March 2006
to use location information contained in a PIDF-LO for routing
applications. To allow successfully interoperability between
applications, location information needs to be normative and more
tightly constrained than is currently specified in the PIDF-LO. This
document makes recommendations on how to constrain, represent and
interpret locations in a PIDF-LO. It further recommends a subset of
GML that MUST be implemented by applications involved in location
based routing.
Table of Contents
1. CHANGES SINCE LAST TIME . . . . . . . . . . . . . . . . . . . 3
1.1. 03 changes . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. 01 changes . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Using Location Information . . . . . . . . . . . . . . . . . . 6
4.1. Single Civic Location Information . . . . . . . . . . . . 7
4.2. Civic and Geospatial Location Information . . . . . . . . 8
4.3. Manual/Automatic Configuration of Location Information . . 11
5. Geodetic Coordinate Representation . . . . . . . . . . . . . . 12
6. Geodetic Shape Representation . . . . . . . . . . . . . . . . 13
7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 18
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. Normative references . . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Creating a PIDF-LO from DHCP Geo Encoded Data . . . . 20
A.1. Latitude and Longitude . . . . . . . . . . . . . . . . . . 20
A.2. Altitude . . . . . . . . . . . . . . . . . . . . . . . . . 22
A.3. Generating the PIDF-LO . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 28
Winterbottom, et al. Expires September 4, 2006 [Page 2]
Internet-Draft GEOPRIV PIDF-LO Profile March 2006
1. CHANGES SINCE LAST TIME
[[This section is informational only and will be removed before the
final version.]]
1.1. 03 changes
Removed some shape defintions, ellipses, arcbands.
Removed OMA shape definition comparisons.
Modified examples to use new civicAddr draft data.
Made extensive references to the GeoShape Draft.
1.2. 01 changes
minor changes to the abstract.
Minor changes to the introduction.
Added and appendix to take implementers through how to create a
PIDF-LO from data received using DHCP option 123 as defined in [2].
Rectified examples to use position and pos rather than location and
point.
Corrected example 3 so that it does not violate SIP rules.
Added addition geopriv elements to the status component of the figure
in "Using Location Information" to more accurately reflect the
cardinality issues.
Revised text in section Geodetic Coordinate Representation. Removed
last example as this was addressed with the change to position and
pos in previous examples.
Winterbottom, et al. Expires September 4, 2006 [Page 3]
Internet-Draft GEOPRIV PIDF-LO Profile March 2006
2. Introduction
The Presence Information Data Format Location Object (PIDF-LO) [3] is
the IETF recommended way of encoding location information and
associated privacy policies. Location information in a PIDF-LO may
be described in a geospatial manner based on a subset of GMLv3, or as
civic location information [4]. A GML profile for expressing
geodetic shapes in a PIDF-LO is described in [5].Uses for PIDF-LO are
envisioned in the context of numerous location based applications.
This document makes recommendations for formats and conventions to
make interoperability less problematic.
Winterbottom, et al. Expires September 4, 2006 [Page 4]
Internet-Draft GEOPRIV PIDF-LO Profile March 2006
3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1].
In this document a "discrete location" is defined as a location that
can be found based on the information used to describe it. It is not
necessarily a single point in space, but may be an area or volume
depending on what is being defined and the required precision.
Winterbottom, et al. Expires September 4, 2006 [Page 5]
Internet-Draft GEOPRIV PIDF-LO Profile March 2006
4. Using Location Information
The PIDF format provides for an unbounded number of tuples. The
geopriv element resides inside the status component of a tuple, hence
a single PIDF document may contain an arbitrary number of location
objects some or all of which may be contradictory or complementary.
The actual location information is contained inside a <location-info>
element, and there may be one or more actual locations described
inside the <location-info> element.
Graphically, the structure of the PIDF/PIDF-LO can be depicted as
follows:
PIDF document
tuple 1
status
geopriv
location-info
civicAddress
location
usage-rules
geopriv 2
geopriv 3
.
.
.
tuple 2
tuple 3
All of these potential sources and storage places for location lead
to confusion for the generators, conveyors and users of location
information. Practical experience within the United States National
Emergency Number Association (NENA) in trying to solve these
ambiguities led the following conventions being adopted:
Rule #1: A geopriv element MUST describe a discrete location.
Rule #2: Where a discrete location can be uniquely described in more
than one way, each location description SHOULD reside in a
separate tuple.
Winterbottom, et al. Expires September 4, 2006 [Page 6]
Internet-Draft GEOPRIV PIDF-LO Profile March 2006
Rule #3: Providing more than one location in a single presence
document (PIDF) MUST only be done if all objects describe the same
location.
Rule #4: Providing more than one location in a single <location-info>
element SHOULD be avoided where possible.
Rule #5: When providing more than one location in a single
<location-info> element the locations MUST be provided by a common
source.
Rule #6: Providing more than one location in a single <location-info>
element SHOULD only be done if they form a complex to describe the
same location. For example, a geodetic location describing a
point, and a civic location indicating the floor in a building.
Rule #7: Where a location complex is provided in a single
<location-info> element, the macro locations MUST be provided
first. For example, a geodetic location describing an area, and a
civic location indicating the floor MUST be represented with the
area first followed by the civic location.
Rule #8: Where a PIDF document contains more than one tuple
containing a status element with a geopriv location element , the
priority of tuples SHOULD be based on tuple position within the
PIDF document. That is to say, the tuple with the highest
priority location occurs earliest in the PIDF document. Initial
priority SHOULD be determined by the originating UA, the final
priority MAY be determined by a proxy along the way, or the UAS.
Rule #9: Where multiple PIDF documents are contained within a single
request, document selection SHOULD be based on document order.
The following examples illustrate the application of these rules.
4.1. Single Civic Location Information
Jane is at a coffee shop on the ground floor of a large shopping
mall. Jane turns on her laptop and connects to the coffee-shop's
WiFi hotspot, Jane obtains a complete civic address for her current
location, for example using [6]. A Location Object is constructed
consisting of a single PIDF document, with a single geopriv tuple,
Winterbottom, et al. Expires September 4, 2006 [Page 7]
Internet-Draft GEOPRIV PIDF-LO Profile March 2006
and a single location residing in the <location-info> element. This
document is unambiguous, and should be interpreted correctly if sent
of the network.
4.2. Civic and Geospatial Location Information
Mike is visiting his Seattle office and connects his laptop into the
Ethernet port in a spare cube. Mike's computer receives a location
over DHCP as defined in [2]. In this case the location is a geodetic
location, with the altitude represented as a building floor number.
This is constructed by Mike's computer into the following PIDF
document:
Winterbottom, et al. Expires September 4, 2006 [Page 8]
Internet-Draft GEOPRIV PIDF-LO Profile March 2006
<?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="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape"
entity="pres:mike@seattle.example.com">
<tuple id="sg89ab">
<status>
<gp:geopriv>
<gp:location-info>
<cl:civicAddress>
<cl:FLR>2</cl:FLR>
</cl:civicAddress>
</gp:location-info>
<gp:usage-rules/>
</gp:geopriv>
</status>
<timestamp>2006-01-30T20:57:29Z</timestamp>
</tuple>
<tuple id="sg89ae">
<status>
<gp:geopriv>
<gp:location-info>
<Polygon srsName="urn:ogc:def::crs:EPSG::4326"
xmlns="http://www.opengis.net/gml">
<exterior>
<LinearRing>
<pos>37.775 -122.4194</pos>
<pos>37.555 -122.4194</pos>
<pos>37.555 -122.4264</pos>
<pos>37.775 -122.4264</pos>
<pos>37.775 -122.4194</pos>
</LinearRing>
</exterior>
</Polygon>
</gp:location-info>
<gp:usage-rules/>
</gp:geopriv>
</status>
<timestamp>2006-01-30T20:57:29Z</timestamp>
</tuple>
</presence>
The constructed PIDF document contains two geopriv elements each in a
separate PIDF tuple, the first being a civic address made up of only
floor, the second containing the provided geodetic information. If
the location is required for routing purposes, which information is
Winterbottom, et al. Expires September 4, 2006 [Page 9]
Internet-Draft GEOPRIV PIDF-LO Profile March 2006
used? Applying rule #8, we will likely fail, or at a minimum need to
fall back to the second tuple describing the geodetic location, a
route described by floor only is not precise enough in the normal
case to permit route selection. If rule #6 and #7 are applied, then
the revised PIDF-LO document creates a complex as shown below.
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape"
entity="pres:mike@seattle.example.com">
<tuple id="sg89ab">
<status>
<gp:geopriv>
<gp:location-info>
<Polygon srsName="urn:ogc:def:crs:EPSG::4326"
xmlns="http://www.opengis.net/gml">
<exterior>
<LinearRing>
<pos>37.775 -122.4194</pos>
<pos>37.555 -122.4194</pos>
<pos>37.555 -122.4264</pos>
<pos>37.775 -122.4264</pos>
<pos>37.775 -122.4194</pos>
</LinearRing>
</exterior>
</Polygon>
<cl:civicAddress>
<cl:FLR>2</cl:FLR>
</cl:civicAddress>
</gp:location-info>
<gp:usage-rules/>
</gp:geopriv>
</status>
<timestamp>2003-06-22T20:57:29Z</timestamp>
</tuple>
</presence>
It is now clear that the main location of user is inside the
rectangle bounded by the geodetic coordinates specfied. Further that
the user is on the second floor of the building located at these
coordinates.
Winterbottom, et al. Expires September 4, 2006 [Page 10]
Internet-Draft GEOPRIV PIDF-LO Profile March 2006
4.3. Manual/Automatic Configuration of Location Information
Loraine has a predefined civic location stored in her laptop, since
she normally lives in Sydney, the address in her address is for her
Sydney-based apartment. Loraine decides to visit sunny San
Francisco, and when she gets there she plugs in her laptop and makes
a call. Loraine's laptop receives a new location from the visited
network in San Francisco. As ths system cannot be sure that the pre-
existing and new location describe the same place, Loraine's computer
generates a new PIDF-LO and will use this to represent Loraine's
location. If Loraine's computer were to add the new location to her
existing PIDF location document (breaking rule #3), then the correct
information may still be interpretted by location recipient providing
Loraine's system applies rule #9. In this case the resulting order
of location information in the PIDF document should be San Francisco
first, followed by Sydney. Since the information is provided by
different sources, rule #8 should also be applied and the information
placed in different tuples with San Francisco first.
Winterbottom, et al. Expires September 4, 2006 [Page 11]
Internet-Draft GEOPRIV PIDF-LO Profile March 2006
5. Geodetic Coordinate Representation
The geodetic examples provided in [3] are illustrated using the gml:
location element which uses the gml:coordinates elements (inside the
gml:Point element) and this representation has several drawbacks.
Firstly, it has been deprecated in later versions of GML (3.1 and
beyond) making it inadvisable to use for new applications. Secondly,
the format of the coordinates type is opaque and so can be difficult
to parse and interpret to ensure consistent results, as the same
geodetic location can be expressed in a variety of ways. The PIDF-LO
Geodetic Shapes specification [5] provides a specific GML profile for
expressing commonly used shapes using simple GML representations.
The shapes defined in [5] are the recommended shapes to ensure
interoperability between location based applications.
Winterbottom, et al. Expires September 4, 2006 [Page 12]
Internet-Draft GEOPRIV PIDF-LO Profile March 2006
6. Geodetic Shape Representation
The cellular mobile world today makes extensive use of geodetic based
location information for emergency and other location-based
applications. Generally these locations are expressed as a point
(either in two or three dimensions) and an area or volume of
uncertainty around the point. In theory, the area or volume
represents a coverage in which the user has a relatively high
probability of being found, and the point is a convenient means of
defining the centroid for the area or volume. In practice, most
systems use the point as an absolute value and ignore the
uncertainty. It is difficult to determine if systems have been
implement in this manner for simplicity, and even more difficult to
predict if uncertainty will play a more important role in the future.
An important decision is whether an uncertainty area should be
specified.
[5] defines eight shape types most of which are easily translated in
shapes definitions used in other applications and protocol, such as
Open Mobile Alliance (OMA) Mobile Location Protocol (MLP). For
completeness the shape defined in [5] are listed below:
o Point (2d or 3d)
o Polygon (2d)
o Circle (2d)
o Ellipse (2d)
o Arc band (2d)
o Sphere (3d circle)
o Ellipsoid (3d)
o Prism (3d polygon)
[5] also describes a standard set of coordinate reference systems
(CRS), unit of measure and conventions relating to lines and
distances that will be repeated here.
Winterbottom, et al. Expires September 4, 2006 [Page 13]
Internet-Draft GEOPRIV PIDF-LO Profile March 2006
7. Recommendations
As a summary this document gives a few recommendations on the usage
of location information in PIDF-LO. Nine rules specified in
Section 4 give guidelines on the ambiguity of PIDF-LO with regard to
the occurrence of multiple location information. It is recommend
that only the shape types and shape representations described in [5]
be used to express geodetic locations for exchange between general
applications. By standardizing geodetic data representation
interoperability issues are mitigated.
If Geodetic information is to be provided via DHCP, then a minimum
resolution of 20 bits SHOULD be specified for both the Latitude and
Longitude fields to achieve sub 100 metre precision. Where only two
dimensional objects are required polygons SHOULD be used to express
the enclosed area. Where 3 dimensions are required a rectangular
prism SHOULD be used.
Winterbottom, et al. Expires September 4, 2006 [Page 14]
Internet-Draft GEOPRIV PIDF-LO Profile March 2006
8. Security Considerations
The primary security considerations relate to how location
information is conveyed and used, which are outside the scope of this
document. This document is intended to serve only as a set of
guidelines as to which elements MUST or SHOULD be implemented by
systems wishing to perform location dependent routing. The
ramification of such recommendations is that they extend to devices
and clients that wish to make use of such services.
Winterbottom, et al. Expires September 4, 2006 [Page 15]
Internet-Draft GEOPRIV PIDF-LO Profile March 2006
9. IANA Considerations
This document does not introduce any IANA considerations.
Winterbottom, et al. Expires September 4, 2006 [Page 16]
Internet-Draft GEOPRIV PIDF-LO Profile March 2006
10. Acknowledgments
The authors would like to thank the GEOPRIV working group for their
discussions in the context of PIDF-LO, in particular Carl Reed, Ron
Lake, James Polk and Henning Schulzrinne. Furthermore, we would like
to thank Jon Peterson as the author of PIDF-LO and Nadine Abbott for
her constructive comments in clarifying some aspects of the document.
Winterbottom, et al. Expires September 4, 2006 [Page 17]
Internet-Draft GEOPRIV PIDF-LO Profile March 2006
11. Open Issues
Do we need to indicate which shapes are acceptable for emergency
calling? Ceratinly not all can be used today, for example the
polygon and prism types will not work with NENA i2 as it is defined
today due to restrictions over the VE2 interface [7].
Winterbottom, et al. Expires September 4, 2006 [Page 18]
Internet-Draft GEOPRIV PIDF-LO Profile March 2006
12. References
12.1. Normative references
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", March 1997.
12.2. Informative References
[2] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004.
[3] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[4] Thomson, M. and J. Winterbottom, "Revised Civic Location Format
for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-01 (work in
progress), January 2006.
[5] Thomson, M., "draft-thomson-geopriv-geo-shape, Geodetic Shapes
for the Representation of Uncertainty in PIDF-LO",
January 2006.
[6] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4
and DHCPv6) Option for Civic Addresses Configuration
Information", draft-ietf-geopriv-dhcp-civil-09 (work in
progress), January 2006.
[7] "NENA Standard for the Implementation of the Wireless Emergency
Service Protocol E2 Interface".
[8] Schulzrinne, H., "A Document Format for Expressing Privacy
Preferences", draft-ietf-geopriv-common-policy-07 (work in
progress), February 2006.
[9] "3GPP TS 23.032 V6.0.0 3rd Generation Partnership Project;
Technical Specification Group Code Network; Universal
Geographic Area Description (GAD)".
[10] "TR-45 J-STD-036-AD-2 Enhanced Wireless 9-1-1 Phase 2".
Winterbottom, et al. Expires September 4, 2006 [Page 19]
Internet-Draft GEOPRIV PIDF-LO Profile March 2006
Appendix A. Creating a PIDF-LO from DHCP Geo Encoded Data
RFC-3825 [2] describes a means by which an end-point may learns it
location from information encoded into DHCP option 123. The
following section describes how and end-point can take this
information and represent it in a well formed PIDF-LO describing this
geodetic location.
The location information described in RFC-3825 consists of a
latitude, longitude, altitude and datum.
A.1. Latitude and Longitude
The latitude and longitude values are represented in degrees and
decimal degrees. Latitude values are positive if north of the
equator, and negative if south of the equator. Similarly
longitudinal values are positive if east of the Greenwich meridian,
and negative if west of the Greenwich meridian.
The latitude and longitude values are each 34 bit long fields
consisting of a 9 bit integer component and a 25 bit fraction
component, with negative numbers being represented in 2s complement
notation. The latitude and longitude fields are each proceeded by a
6 bit resolution field, the LaRes for latitude, and the LoRes for
longitude. The value in the LaRes field indicates the number of
significant bits to interpret in the Latitude field, while the value
in the LoRes field indicates the number of significant bits to
interpret in the Longitude field.
For example, if you are in Wollongong Australia which is located at
34 Degrees 25 minutes South and 150 degrees 32 minutes East this
would translate to -34.41667, 150.53333 in decimal degrees. If these
numbers are translated to their full 34 bit representations, then we
arrive the following:
Latitude = 111011101.1001010101010101000111010
Longitude = 0100101101000100010001000010100001
RFC-3825, uses the LaRes and LoRes values to specify a lower and
upper boundary for location thereby specifying an area. The size of
the area specified is directly related to the value specified in the
LaRes and LoRes fields.
Using the previous example, if LaRes is set 7, then lower latitude
boundary can be calculated as -256+128+64+16+8+4, which is -36
degrees, the upper boundary then becomes -256+128+64+16+8+4+2+1 which
is -35 degrees. LoRes may be used similarly for Longitude.
Winterbottom, et al. Expires September 4, 2006 [Page 20]
Internet-Draft GEOPRIV PIDF-LO Profile March 2006
So what level of precision is useful? Well, certain types of
applications and regulations call for different levels of precision,
and the required precision may vary depending on how the location was
determined. For Cellular 911 calls in the United States, for
example, if the network measures the location then the caller should
be within 100 metres, while if the handset does the measurement then
the location should be within 50 metres. Since DHCP is a network
based mechanism we will benchmark off 100 metres (approximately 330
ft) which is still a large area.
For simplicity we shall assume that we are defining a square, in
which we are equally to appear anywhere. The greatest distance
through this square is across the diagonal, so we make this 100
metres.
+----------------------+
| _/|
| _/ |
| _/ |
| _/ |
| _/ |
| 100_/ metres |
| _/ |
| _/ |
| _/ |
| _/ |
|_/ |
+----------------------+
The distance between the top and the bottom and the left and the
right is the same, the area being a square, and this works out to be
70.7 metres. When expressed in decimal degrees, the third point
after the decimal place represents about 100 metre precision, this
equates to 10 binary places of fractional part. A 70 metre distance
is required, so 11 fractional binary digits are necessary resulting
in a total of 20 bits of precision.
With -34.4167, 150.5333 encoded with 20 bits of precision for the
LaRes and LoRes, the corners of the enclosing square are:
Point 1 (-34.4170, 150.5332)
Point 2 (-34.4170, 150.5337)
Point 3 (-34.4165, 150.5332)
Point 4 (-34.4165, 150.5337)
Winterbottom, et al. Expires September 4, 2006 [Page 21]
Internet-Draft GEOPRIV PIDF-LO Profile March 2006
A.2. Altitude
The altitude elements define how the altitude is encoded and to what
level of precision. The units for altitude are either metres, or
floors, with the actual measurement being encoded in a similar manner
to those for latitude and longitude, but with 22 bit integer, and 8
bit fractional components.
A.3. Generating the PIDF-LO
If altitude is not required, or is expressed in floors then a
geodetic location expressed by a polygon SHOULD be used, with points
expressed in a counter-clockwise direction. If the altitude is
expressed in floors and is required, the altitude SHOULD 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 expressed as
follows:
<Polygon srsName="urn:ogc:def:crs:EPSG::4326"
xmlns="http://www.opengis.net/gml">
<exterior>
<LinearRing>
<pos>-34.4165 150.5332</pos>
<pos>-34.4170 150.5532</pos>
<pos>-34.4170 150.5537</pos>
<pos>-34.4165 150.5337</pos>
<pos>-34.4165 150.5332</pos>
</LinearRing>
</exterior>
</Polygon>
If a floor number of say 3 were included, then the location-info
element would contain the above information and the following:
<civicAddress
xlmns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<FLR>2</FLR>
</civicAddress>
When altitude is expressed as an integer and fractional component, as
with the latitude and longitude, it expresses a range which requires
the prism form to be used. Care must be taken to ensure that the
points are defined in a counter-clowise direction to ensure that the
upward normal points up.
Winterbottom, et al. Expires September 4, 2006 [Page 22]
Internet-Draft GEOPRIV PIDF-LO Profile March 2006
Extending the previous example to include an altitude expressed in
metres rather than floors. AltRes is set to a value of 19, and the
Altitude value is set to 34. Using similar techniques as shown in
the latitude and longitude section, a range of altitudes between 32
metres and 40 metres is described. The prism would therefore be
defined as follows:
<Prism srsName="urn:ogc:def:crs:EPSG::4976"
xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape"
xmlns:gml="http://www.opengis.net/gml">
<base>
<gml:Polygon>
<gml:exterior>
<gml:LinearRing>
<gml:pos>-34.4165 150.5332 32</gml:pos>
<gml:pos>-34.4170 150.5532 32</gml:pos>
<gml:pos>-34.4170 150.5537 32</gml:pos>
<gml:pos>-34.4165 150.5337 32</gml:pos>
<gml:pos>-34.4165 150.5332 32</gml:pos>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</base>
<height uom="urn:ogc:def:uom:EPSG::9001">
8
</height>
</Prism>
The Method value SHOULD be set to DHCP. Note that this case, the
DHCP is referring to the way in which location information was
delivered to the IP-device, and not necessarily how the location was
determined.
The timestamp value SHOULD be set to the time that location was
retrieved from the DHCP server.
The client application MAY insert any usage rules that are pertinent
to the user of the device and that comply with [8]. A guideline is
that the any retention-expiry value SHOULD NOT exceed the current
lease time.
The Provided-By element SHOULD NOT be populated as this is not
provided by the source of the location information.
The 3 completed PIDF-LO representations are provided below, and
Winterbottom, et al. Expires September 4, 2006 [Page 23]
Internet-Draft GEOPRIV PIDF-LO Profile March 2006
represent a location without altitude, a location with a civic
altitude, and a location represented as a 3 dimensional rectangular
prism.
<?xml version="1.0"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:pidf="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape"
xmlns:gml="http://www.opengis.net/gml"
entity="pres:user@example.com">
<tuple id="a6fea09">
<status>
<gp:geopriv>
<gp:location-info>
<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
<gml:exterior>
<gml:LinearRing>
<gml:pos>-34.4165 150.5332</gml:pos>
<gml:pos>-34.4170 150.5532</gml:pos>
<gml:pos>-34.4170 150.5537</gml:pos>
<gml:pos>-34.4165 150.5337</gml:pos>
<gml:pos>-34.4165 150.5332</gml:pos>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gp:location-info>
<gp:usage-rules/>
<gp:method>DHCP</gp:method>
</gp:geopriv>
</status>
<timestamp>2005-07-05T14:49:53+10:00</timestamp>
</tuple>
</presence>
Winterbottom, et al. Expires September 4, 2006 [Page 24]
Internet-Draft GEOPRIV PIDF-LO Profile March 2006
<?xml version="1.0"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:pidf="urn:ietf:params:xml:ns:pidf"
xmlns:cl=" urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://www.opengis.net/gml"
entity="pres:user@example.com">
<tuple id="a6fea09">
<status>
<gp:geopriv>
<gp:location-info>
<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
<gml:exterior>
<gml:LinearRing>
<gml:pos>-34.4165 150.5332</gml:pos>
<gml:pos>-34.4170 150.5532</gml:pos>
<gml:pos>-34.4170 150.5537</gml:pos>
<gml:pos>-34.4165 150.5337</gml:pos>
<gml:pos>-34.4165 150.5332</gml:pos>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
<cl:civilAddress>
<cl:FLR>2</cl:FLR>
</cl:civilAddress>
</gp:location-info>
<gp:usage-rules/>
<gp:method>DHCP</gp:method>
</gp:geopriv>
</status>
<timestamp>2005-07-05T14:49:53+10:00</timestamp>
</tuple>
</presence>
Winterbottom, et al. Expires September 4, 2006 [Page 25]
Internet-Draft GEOPRIV PIDF-LO Profile March 2006
<?xml version="1.0"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:pidf="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape"
xmlns:gml="http://www.opengis.net/gml"
entity="pres:user@example.com">
<tuple id="a6fea09">
<status>
<gp:geopriv>
<gp:location-info>
<gs:Prism srsName="urn:ogc:def:crs:EPSG::4976">
<gs:base>
<gml:Polygon>
<gml:exterior>
<gml:LinearRing>
<gml:pos>-34.4165 150.5332 32</gml:pos>
<gml:pos>-34.4170 150.5532 32</gml:pos>
<gml:pos>-34.4170 150.5537 32</gml:pos>
<gml:pos>-34.4165 150.5337 32</gml:pos>
<gml:pos>-34.4165 150.5332 32</gml:pos>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gs:base>
<gs:height uom="urn:ogc:def:uom:EPSG::9001">
8
</gs:height>
</gs:Prism>
</gp:location-info>
<gp:usage-rules/>
<gp:method>DHCP</gp:method>
</gp:geopriv>
</status>
<timestamp>2005-07-05T14:49:53+10:00</timestamp>
</tuple>
</presence>
Winterbottom, et al. Expires September 4, 2006 [Page 26]
Internet-Draft GEOPRIV PIDF-LO Profile March 2006
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
Winterbottom, et al. Expires September 4, 2006 [Page 27]
Internet-Draft GEOPRIV PIDF-LO Profile March 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Winterbottom, et al. Expires September 4, 2006 [Page 28]
