draft-ietf-geopriv-relative-location-04.txt   draft-ietf-geopriv-relative-location-05.txt 
GEOPRIV M. Thomson GEOPRIV M. Thomson
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track B. Rosen Intended status: Standards Track B. Rosen
Expires: September 20, 2013 Neustar Expires: December 07, 2013 Neustar
D. Stanley D. Stanley
Aruba Networks Aruba Networks
G. Bajko G. Bajko
Nokia Nokia
A. Thomson A. Thomson
Cisco Systems, Inc. Cisco Systems, Inc.
March 19, 2013 June 05, 2013
Relative Location Representation Relative Location Representation
draft-ietf-geopriv-relative-location-04.txt draft-ietf-geopriv-relative-location-05
Abstract Abstract
This document defines an extension to PIDF-LO (RFC4119) for the This document defines an extension to PIDF-LO (RFC4119) for the
expression of location information that is defined relative to a expression of location information that is defined relative to a
reference point. The reference point may be expressed as a geodetic reference point. The reference point may be expressed as a geodetic
or civic location, and the relative offset may be one of several or civic location, and the relative offset may be one of several
shapes. Optionally, a reference to a secondary document (such as a shapes. An alternative binary representation is described.
map image) can be included, along with the relationship of the map
coordinate system to the reference/offset coordinate system to allow Optionally, a reference to a secondary document (such as a map image)
display of the map with the reference point and the relative offset. can be included, along with the relationship of the map coordinate
Also included in this document is a Type/Length/Value (TLV) system to the reference/offset coordinate system to allow display of
representation of the relative location for use in other protocols the map with the reference point and the relative offset.
that use TLVs.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on September 20, 2013. This Internet-Draft will expire on December 07, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 2, line 25 skipping to change at page 2, line 22
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Relative Location . . . . . . . . . . . . . . . . . . . . . . 6 4. Relative Location . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Relative Coordinate System . . . . . . . . . . . . . . . 6 4.1. Relative Coordinate System . . . . . . . . . . . . . . . 7
4.2. Placement of XML Elements . . . . . . . . . . . . . . . . 7 4.2. Placement of XML Elements . . . . . . . . . . . . . . . . 7
4.3. Binary Format . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Binary Format . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Distances and Angles . . . . . . . . . . . . . . . . . . 8 4.4. Distances and Angles . . . . . . . . . . . . . . . . . . 8
4.5. Value Encoding . . . . . . . . . . . . . . . . . . . . . 8 4.5. Value Encoding . . . . . . . . . . . . . . . . . . . . . 8
4.6. Relative Location Restrictions . . . . . . . . . . . . . 8 4.6. Relative Location Restrictions . . . . . . . . . . . . . 9
4.7. Baseline TLVs . . . . . . . . . . . . . . . . . . . . . . 8 4.7. Baseline TLVs . . . . . . . . . . . . . . . . . . . . . . 9
4.8. Reference TLV . . . . . . . . . . . . . . . . . . . . . . 8 4.8. Reference TLV . . . . . . . . . . . . . . . . . . . . . . 9
4.9. Shapes . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.9. Shapes . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.9.1. Point . . . . . . . . . . . . . . . . . . . . . . . . 9 4.9.1. Point . . . . . . . . . . . . . . . . . . . . . . . . 10
4.9.2. Circle or Sphere Shape . . . . . . . . . . . . . . . 10 4.9.2. Circle or Sphere Shape . . . . . . . . . . . . . . . 11
4.9.3. Ellipse or Ellipsoid Shape . . . . . . . . . . . . . 11 4.9.3. Ellipse or Ellipsoid Shape . . . . . . . . . . . . . 12
4.9.4. Polygon or Prism Shape . . . . . . . . . . . . . . . 13 4.9.4. Polygon or Prism Shape . . . . . . . . . . . . . . . 14
4.9.5. Arc-Band Shape . . . . . . . . . . . . . . . . . . . 15 4.9.5. Arc-Band Shape . . . . . . . . . . . . . . . . . . . 16
4.10. Dynamic Location TLVs . . . . . . . . . . . . . . . . . . 17 4.10. Dynamic Location TLVs . . . . . . . . . . . . . . . . . . 18
4.10.1. Orientation . . . . . . . . . . . . . . . . . . . . 17 4.10.1. Orientation . . . . . . . . . . . . . . . . . . . . 18
4.10.2. Speed . . . . . . . . . . . . . . . . . . . . . . . 17 4.10.2. Speed . . . . . . . . . . . . . . . . . . . . . . . 18
4.10.3. Heading . . . . . . . . . . . . . . . . . . . . . . 17 4.10.3. Heading . . . . . . . . . . . . . . . . . . . . . . 18
4.11. Secondary Map Metadata . . . . . . . . . . . . . . . . . 17 4.11. Secondary Map Metadata . . . . . . . . . . . . . . . . . 18
4.11.1. Map URL . . . . . . . . . . . . . . . . . . . . . . 18 4.11.1. Map URL . . . . . . . . . . . . . . . . . . . . . . 19
4.11.2. Map Coordinate Reference System . . . . . . . . . . 18 4.11.2. Map Coordinate Reference System . . . . . . . . . . 19
4.11.3. Map Example . . . . . . . . . . . . . . . . . . . . 20 4.11.3. Map Example . . . . . . . . . . . . . . . . . . . . 21
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Civic PIDF with Polygon Offset . . . . . . . . . . . . . 21 5.1. Civic PIDF with Polygon Offset . . . . . . . . . . . . . 22
5.2. Geo PIDF with Circle Offset . . . . . . . . . . . . . . . 22 5.2. Geo PIDF with Circle Offset . . . . . . . . . . . . . . . 23
5.3. Civic TLV with Point Offset . . . . . . . . . . . . . . . 23 5.3. Civic TLV with Point Offset . . . . . . . . . . . . . . . 24
6. Schema Definition . . . . . . . . . . . . . . . . . . . . . . 24 6. Schema Definition . . . . . . . . . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
8.1. Relative Location Registry . . . . . . . . . . . . . . . 27 8.1. Relative Location Registry . . . . . . . . . . . . . . . 28
8.2. URN Sub-Namespace Registration . . . . . . . . . . . . . 28 8.2. URN Sub-Namespace Registration . . . . . . . . . . . . . 29
8.3. XML Schema Registration . . . . . . . . . . . . . . . . . 29 8.3. XML Schema Registration . . . . . . . . . . . . . . . . . 30
8.4. CRS public identifier registration . . . . . . . . . . . 30 8.4. Registration of Relative Coordinate Reference System URNs 30
8.4.1. Registration of 2D CRS URN . . . . . . . . . . . . . 31
8.4.2. Registration of 3D CRS URN . . . . . . . . . . . . . 31
8.5. CAtype Registration . . . . . . . . . . . . . . . . . . . 31 8.5. CAtype Registration . . . . . . . . . . . . . . . . . . . 31
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.1. Normative References . . . . . . . . . . . . . . . . . . 31 10.1. Normative References . . . . . . . . . . . . . . . . . . 32
10.2. Informative References . . . . . . . . . . . . . . . . . 33 10.2. Informative References . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
This document describes a format for the expression of relative This document describes a format for the expression of relative
location information. location information.
A relative location is formed of a reference location, plus a A relative location is formed of a reference location, plus a
relative offset from that reference location. The reference location relative offset from that reference location. The reference location
can be represented in either civic or geodetic form. The reference can be represented in either civic or geodetic form. The reference
location can also have dynamic components such as velocity. The location can also have dynamic components such as velocity. The
skipping to change at page 4, line 5 skipping to change at page 4, line 5
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Overview 3. Overview
This document describes an extension to PIDF-LO [RFC4119] as updated This document describes an extension to PIDF-LO [RFC4119] as updated
by [RFC5139] and [RFC5491], to allow the expression of a location as by [RFC5139] and [RFC5491], to allow the expression of a location as
an offset relative to a reference. an offset relative to a reference.
This extension effectively allows the creator of a location object to Reference
include two location values plus an offset. The "baseline" location Location
that is given outside of the <relative-location> element is what will o
be visible to a client that does not understand that extension (i.e., \
one that ignores the <relative-location> element). A client that \ Offset
does understand this extension will interpret the location within the \
relative element as a refinement of the baseline location, which _\|
gives the reference location for the relative offset. x
Relative
Location
This extension allows the creator of a location object to include two
location values plus an offset. A "baseline" location is included
outside of the <relative-location> element. The baseline location is
visible to a client that does not understand relative location (i.e.,
it ignores the <relative-location> element).
A client that does understand relative location will interpret the
location within the relative element as a refinement of the baseline
location. A relative location is determined, which gives the
reference location for the relative offset.
Creators of location objects with relative location thus have a Creators of location objects with relative location thus have a
choice of how much information to put into the "baseline" location choice of how much information to put into the "baseline" location
and how much to put into the "reference" location. For example, all and how much to put into the "reference" location. For example, all
location information could be put inside the <relative-location> location information could be put inside the <relative-location>
element, so that clients that do not understand relative location element, so that clients that do not understand relative location
would receive no location information at all. Alternatively, the would receive no location information at all. Alternatively, the
baseline location value could be precise enough to specify a building baseline location value could be precise enough to specify a building
that contains the relative location, and the reference location could that contains the relative location, and the reference location could
specify a point within the building from which the offset is specify a point within the building from which the offset is
measured. measured.
The baseline location SHOULD be general enough to describe both the The baseline location SHOULD be general enough to describe both the
reference location and the relative location (reference plus offset). reference location and the relative location (reference plus offset).
In particular, while it is possible to put all location information Location objects SHOULD NOT have all location information in the
into the "reference" location (leaving an universally broad baseline location. Doing this would cause clients that do not
"baseline"), location objects SHOULD NOT have all location understand relative location to incorrectly interpret the baseline
information in the baseline location. Doing this would cause clients location (i.e., the reference point) as the actual, precise location
that do not understand relative location to incorrectly interpret the of the client.
baseline location (i.e., the reference point) as the actual, precise
location of the client. ..--"""--..
.-' `-.
,' `.
/ Reference \
/ o \
| \ |
| \ |
| \ |
\ _\| /
`. x .' \_ Baseline
`._ Relative _.' Location
`--..___..--'
It is possible to provide a valid relative location with no
information in the baseline. However, this provides recipients who
do not understand relative location with no information. A baseline
location SHOULD include sufficient information to encompass both the
reference and relative locations while providing a baseline that is
as accurate as possible.
Both the baseline and the reference location are defined either as a Both the baseline and the reference location are defined either as a
geodetic location [OGC.GeoShape] or a civic address [RFC4776]. If geodetic location [OGC.GeoShape] or a civic address [RFC4776]. If
the baseline location was expressed as a geodetic location, the the baseline location was expressed as a geodetic location, the
reference MUST be geodetic. If the baseline location was expressed reference MUST be geodetic. If the baseline location was expressed
as a civic address, the reference MUST be a civic. as a civic address, the reference MUST be a civic.
Baseline and reference locations MAY also include dynamic location Baseline and reference locations MAY also include dynamic location
information [RFC5962]. information [RFC5962].
skipping to change at page 5, line 39 skipping to change at page 6, line 24
<ca:A1>NSW</ca:A1> <ca:A1>NSW</ca:A1>
<ca:A3>Wollongong</ca:A3> <ca:A3>Wollongong</ca:A3>
<ca:A4>North Wollongong</ca:A4> <ca:A4>North Wollongong</ca:A4>
<ca:RD>Flinders</ca:RD> <ca:RD>Flinders</ca:RD>
<ca:STS>Street</ca:STS> <ca:STS>Street</ca:STS>
<ca:HNO>123</ca:HNO> <ca:HNO>123</ca:HNO>
</ca:civicAddress> </ca:civicAddress>
<rel:relative-location> <rel:relative-location>
<rel:reference> <rel:reference>
<ca:civicAddress xml:lang="en-AU"> <ca:civicAddress xml:lang="en-AU">
<ca:INT N="Door" R="A">Front</ca:INT> <ca:LMK>Front Door</ca:LMK>
</ca:civicAddress> </ca:civicAddress>
</rel:reference> </rel:reference>
<rel:offset> <rel:offset>
<gml:Point xmlns:gml="http://www.opengis.net/gml" <gml:Point xmlns:gml="http://www.opengis.net/gml"
srsName="urn:ietf:params:geopriv:relative:2d"> srsName="urn:ietf:params:geopriv:relative:2d">
<gml:pos>100 50</gml:pos> <gml:pos>100 50</gml:pos>
</gml:Point> </gml:Point>
</rel:offset> </rel:offset>
</rel:relative-location> </rel:relative-location>
</gp:location-info> </gp:location-info>
skipping to change at page 6, line 20 skipping to change at page 7, line 7
<rel:scale>20. -20.</rel:scale> <rel:scale>20. -20.</rel:scale>
</rel:map> </rel:map>
</gp:geopriv> </gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID> <dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp> <dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp>
</dm:device> </dm:device>
</presence> </presence>
4. Relative Location 4. Relative Location
Relative location is a shape (point, circle, ellipse...). The shape Relative location is a shape (e.g., point, circle, ellipse). The
is defined with a CRS that has a datum defined as the reference shape is defined with a CRS that has a datum defined as the reference
(which appears as a civic address or geodetic location in the tuple), (which appears as a civic address or geodetic location in the tuple),
and the shape coordinates as meter offsets North/East of the datum and the shape coordinates as meter offsets North/East of the datum
measured in meters (with an optional Z offset relative to datum measured in meters (with an optional Z offset relative to datum
altitude). An optional angle allows the reference CRS be to rotated altitude). An optional angle allows the reference CRS be to rotated
with respect to North. with respect to North.
4.1. Relative Coordinate System 4.1. Relative Coordinate System
The relative coordinate reference system uses a coordinate system The relative coordinate reference system uses a coordinate system
with two or three axes. with two or three axes.
skipping to change at page 7, line 7 skipping to change at page 7, line 40
Any coordinates in the relative shapes use the described Cartesian Any coordinates in the relative shapes use the described Cartesian
coordinate system. In the XML form, this uses a URN of coordinate system. In the XML form, this uses a URN of
"urn:ietf:params:geopriv:relative:2d" for two-dimensional shapes and "urn:ietf:params:geopriv:relative:2d" for two-dimensional shapes and
"urn:ietf:params:geopriv:relative:3d" for three-dimensional shapes. "urn:ietf:params:geopriv:relative:3d" for three-dimensional shapes.
The binary form uses different shape type identifiers for 2D and 3D The binary form uses different shape type identifiers for 2D and 3D
shapes. shapes.
Dynamic location information [RFC5962] in the baseline or reference Dynamic location information [RFC5962] in the baseline or reference
location alters relative coordinate system. The resulting Cartesian location alters relative coordinate system. The resulting Cartesian
coordinate system axes are rotated so that the 'y' axis is oriented coordinate system axes are rotated so that the "y" axis is oriented
along the direction described by the <orientation> element. The along the direction described by the <orientation> element. The
coordinate system also moves as described by the <speed> and coordinate system also moves as described by the <speed> and
<heading> elements. <heading> elements.
4.2. Placement of XML Elements 4.2. Placement of XML Elements
The baseline of the reference location is represented as <location- The baseline of the reference location is represented as <location-
info> like a normal PIDF-LO. Relative location adds a new <relative- info> like a normal PIDF-LO. Relative location adds a new <relative-
location> element to <location-info>. Within <relative-location>, location> element to <location-info>. Within <relative-location>,
<reference> and <offset> elements are described. Within <offset> are <reference> and <offset> elements are described. Within <offset> are
skipping to change at page 7, line 31 skipping to change at page 8, line 15
4.3. Binary Format 4.3. Binary Format
This document describes a way to encode the relative location in a This document describes a way to encode the relative location in a
binary TLV form for use in other protocols that use TLVs to represent binary TLV form for use in other protocols that use TLVs to represent
location. location.
A type-length-value encoding is used. A type-length-value encoding is used.
+------+------+------+------+------+------+------+ +------+------+------+------+------+------+------+
| Type |Length| Value ... | Type |Length| Value ...
+------+------+------+------+------+------+ +------+------+------+------+------+------+------+
| X | N | Value ... | T | N | Value ...
+------+------+------+------+------+------+------+ +------+------+------+------+------+------+------+
Figure 1: TLV-tuple format Figure 1: TLV-tuple format
Type field (X) is defined as a single byte. The type codes used are Type field (T) is an 8-bit unsigned integer. The type codes used are
registered an IANA-managed 'RLtypes' registry defined by this registered an IANA-managed "Relative Location Parameters" registry
document, and restricted to not include the values defined by the defined by this document, and restricted to not include the values
CAtypes registry. This restriction permits a location reference and defined by the "CAtypes" registry. This restriction permits a
offset to be coded with unique TLVs. location reference and offset to be coded within the same object
without type collisions.
The Length field (N) is defined as an unsigned integer that is one The Length field (N) is defined as an 8-bit unsigned integer. This
byte in length. This field can encode values from 0 to 255. The field can encode values from 0 to 255. The length field describes
length field describes the number of bytes in the Value. Length does the number of bytes in the Value. Length does not count the bytes
not count the bytes used for the Type or Length. used for the Type or Length.
The Value field is defined separately for each type. The Value field is defined separately for each type.
Each element of the relative location has a unique TLV assignment. A Each element of the relative location has a unique TLV assignment. A
relative location encoded in TLV would have the baseline location relative location encoded in TLV form includes both baseline and
TLVs and a reference location TLV which contains within it the reference location TLVs and a reference location TLVs. The reference
reference refinement TLVs. The reference TLVs are followed by the TLVs are followed by the relative offset, and optional map TLDs
relative offset, and optional map TLDs described in this document. described in this document.
4.4. Distances and Angles 4.4. Distances and Angles
All distance measures used in shapes are expressed in meters. All distance measures used in shapes are expressed in meters.
All orientation angles used in shapes are expressed in degrees. All orientation angles used in shapes are expressed in degrees.
Orientation angles are measured from WGS84 Northing to Easting with Orientation angles are measured from WGS84 Northing to Easting with
zero at Northing. Orientation angles in the relative coordinate zero at Northing. Orientation angles in the relative coordinate
system start from the second coordinate axis (y or Northing) and system start from the second coordinate axis (y or Northing) and
increase toward the first axis (x or Easting). increase toward the first axis (x or Easting).
skipping to change at page 9, line 15 skipping to change at page 9, line 47
+------+------+------+------+------+------+ +------+------+------+------+------+------+
| 111 |Length| Reference TLVs | | 111 |Length| Reference TLVs |
+------+------+------+------+------+------+ +------+------+------+------+------+------+
Reference TLV Reference TLV
4.9. Shapes 4.9. Shapes
Shape data is used to represent regions of uncertainty for the Shape data is used to represent regions of uncertainty for the
reference and relative locations. Shape data in the reference reference and relative locations. Shape data in the reference
location uses a [WGS84] CRS. Shape data in the relative location location uses a WGS84 [WGS84] CRS. Shape data in the relative
uses a relative CRS. location uses a relative CRS.
The XML form for shapes uses Geography Markup Language (GML) The XML form for shapes uses Geography Markup Language (GML)
[OGC.GML-3.1.1], consistent with the rules in [RFC5491]. Reference [OGC.GML-3.1.1], consistent with the rules in [RFC5491]. Reference
locations use the CRS URNs specified in [RFC5491]; relative locations locations use the CRS URNs specified in [RFC5491]; relative locations
use either a 2D CRS (urn:ietf:params:geopriv:relative:2d), or a 3D use either a 2D CRS (urn:ietf:params:geopriv:relative:2d), or a 3D
(urn:ietf:params:geopriv:relative:3d), depending on the shape type. (urn:ietf:params:geopriv:relative:3d), depending on the shape type.
The binary form of each shape uses a different shape type for 2d and The binary form of each shape uses a different shape type for 2d and
3d shapes. 3d shapes.
skipping to change at page 14, line 13 skipping to change at page 15, line 13
GML Polygon Template GML Polygon Template
Alternatively, a series of "pos" elements can be used in place of the Alternatively, a series of "pos" elements can be used in place of the
single "posList". Each "pos" element contains two or three single "posList". Each "pos" element contains two or three
coordinate values. coordinate values.
Note that the first point is repeated at the end of the sequence of Note that the first point is repeated at the end of the sequence of
coordinates and no explicit count of the number of points is coordinates and no explicit count of the number of points is
provided. provided.
A GML polygon that includes altitude cannot be represented completely A GML polygon that includes altitude cannot be represented perfectly
in binary. When converting to the binary representation, a two in TLV form. When converting to the binary representation, a two
dimensional CRS is used and altitude is removed from each coordinate. dimensional CRS is used and altitude is removed from each coordinate.
A prism is represented in and converted from GML using the following A prism is represented in and converted from GML using the following
template: template:
<gs:Prism xmlns:gml="http://www.opengis.net/gml" <gs:Prism xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:gs="http://www.opengis.net/pidflo/1.0"
srsName="urn:ietf:params:geopriv:relative:3d"> srsName="urn:ietf:params:geopriv:relative:3d">
<gs:base> <gs:base>
<gml:Polygon> <gml:Polygon>
skipping to change at page 18, line 19 skipping to change at page 19, line 19
form of representation understood by both the sender and recipient. form of representation understood by both the sender and recipient.
4.11.1. Map URL 4.11.1. Map URL
In XML, the map is a <map> element defined within <relative-location> In XML, the map is a <map> element defined within <relative-location>
and contains the URL. The URL is encoded as a UTF-8 encoded string. and contains the URL. The URL is encoded as a UTF-8 encoded string.
An "http:" or "https:" URL MUST be used unless the entity creating An "http:" or "https:" URL MUST be used unless the entity creating
the PIDF-LO is able to ensure that authorized recipients of this data the PIDF-LO is able to ensure that authorized recipients of this data
are able to use other URI schemes. A "type" attribute MUST be are able to use other URI schemes. A "type" attribute MUST be
present and specifies the kind of map the URL points to. Map types present and specifies the kind of map the URL points to. Map types
are specified as mime media types as recorded in the IANA Media Types are specified as MIME media types as recorded in the IANA Media Types
registry. For example <map type="image/png">https://www.example.com/ registry. For example <map type="image/png">https://www.example.com/
floorplans/123South/floor-2</map>. In binary, the map type is a floorplans/123South/floor-2</map>.
separate TLV from the map URL:
In binary, the map type is a separate TLV from the map URL:
+------+------+------+------+------+-- --+------+ +------+------+------+------+------+-- --+------+
| 126 |Length| Map Media Type ... | 126 |Length| Map Media Type ...
+------+------+------+------+------+-- --+------+ +------+------+------+------+------+-- --+------+
| 127 |Length| Map Image URL ... | 127 |Length| Map Image URL ...
+------+------+------+------+------+-- --+------+ +------+------+------+------+------+-- --+------+
Map URL TLVs Map URL TLVs
4.11.2. Map Coordinate Reference System 4.11.2. Map Coordinate Reference System
The CRS used by the map depends on the type of map. For example, a The CRS used by the map depends on the type of map. For example, a
map described by a 3-D geometric model of the building may contain a map described by a 3-D geometric model of the building may contain a
complete CRS description in it. For some kinds of maps, typically complete CRS description in it. For some kinds of maps, typically
described as images, the CRS used within the map must define the described as images, the CRS used within the map must define the
skipping to change at page 20, line 41 skipping to change at page 21, line 41
Alternatively, a single scaling value MAY be used to apply the same Alternatively, a single scaling value MAY be used to apply the same
scaling factor to all coordinate components. scaling factor to all coordinate components.
Images that use a rows/columns coordinate system often use a left- Images that use a rows/columns coordinate system often use a left-
handed coordinate system. A negative value for the y/rows-axis handed coordinate system. A negative value for the y/rows-axis
scaling value can be used to account for any change in direction scaling value can be used to account for any change in direction
between the y-axis used in the relative coordinate system and the between the y-axis used in the relative coordinate system and the
rows axis of the image coordinate system. rows axis of the image coordinate system.
In XML, the <scale> element may contain the single scale value, or In XML, the <scale> element MAY contain a single scale value, or MAY
may contain 2 (or 3) values similar to a GML "pos" with separate contain 2 (or 3) values in XML list form. In TLV form, the length of
scale values. In TLV form: the TLV determines how many scale values are present:
+------+------+------+------+------+ +------+------+------+------+------+------+
| 130 |Length| Scales ... | 130 |Length| Scale(s) ...
+------+------+------+------+------+ +------+------+------+------+------+------+
Map Scale TLV Map Scale TLV
4.11.3. Map Example 4.11.3. Map Example
An example of expressing a map is: An example of expressing a map is:
<rel:map> <rel:map>
<rel:url type="image/jpeg"> <rel:url type="image/jpeg">
http://example.com/map.jpg http://example.com/map.jpg
</rel:url> </rel:url>
<rel:offset>200 210</rel:offset> <rel:offset>200 210</rel:offset>
<rel:orientation>68</rel:orientation> <rel:orientation>68</rel:orientation>
<rel:scale>2.90 -2.90</rel:scale> <rel:scale>2.90 -2.90</rel:scale>
</rel:map> </rel:map>
Map Example Map Example
5. Examples 5. Examples
The examples in this section combine elements from [RFC3863],
[RFC4119], [RFC4479], [RFC5139], and [OGC.GeoShape].
5.1. Civic PIDF with Polygon Offset 5.1. Civic PIDF with Polygon Offset
<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"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative" xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:ness@example.com"> entity="pres:ness@example.com">
<dm:device id="nesspc-1"> <dm:device id="nesspc-1">
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
<ca:civicAddress xml:lang="en-AU"> <ca:civicAddress xml:lang="en-AU">
<ca:country>AU</ca:country> <ca:country>AU</ca:country>
<ca:A1>NSW</ca:A1> <ca:A1>NSW</ca:A1>
<ca:A3>Wollongong</ca:A3> <ca:A3>Wollongong</ca:A3>
<ca:A4>North Wollongong</ca:A4> <ca:A4>North Wollongong</ca:A4>
<ca:RD>Flinders</ca:RD> <ca:RD>Flinders</ca:RD>
<ca:STS>Street</ca:STS> <ca:STS>Street</ca:STS>
<ca:HNO>123</ca:HNO> <ca:HNO>123</ca:HNO>
</ca:civicAddress> </ca:civicAddress>
<rel:relative-location> <rel:relative-location>
<rel:reference> <rel:reference>
<ca:civicAddress xml:lang="en-AU"> <ca:civicAddress xml:lang="en-AU">
<ca:INT N="Building">A</ca:INT> <ca:LMK>Front Door</ca:LMK>
<ca:INT N="Level">I</ca:INT> <ca:BLD>A</ca:BLD>
<ca:INT N="Suite">113</ca:INT> <ca:FLR>I</ca:FLR>
<ca:INT N="Door" R="A">Front</ca:INT> <ca:ROOM>113</ca:ROOM>
</ca:civicAddress> </ca:civicAddress>
</rel:reference>
<rel:offset> </rel:reference>
<gml:Polygon xmlns:gml="http://www.opengis.net/gml" <rel:offset>
srsName="urn:ietf:params:geopriv:relative:2d"> <gml:Polygon xmlns:gml="http://www.opengis.net/gml"
<gml:exterior> srsName="urn:ietf:params:geopriv:relative:2d">
<gml:LinearRing> <gml:exterior>
<gml:pos>433.0 -734.0</gml:pos> <!--A--> <gml:LinearRing>
<gml:pos>431.0 -733.0</gml:pos> <!--F--> <gml:pos>433.0 -734.0</gml:pos> <!--A-->
<gml:pos>431.0 -732.0</gml:pos> <!--E--> <gml:pos>431.0 -733.0</gml:pos> <!--F-->
<gml:pos>433.0 -731.0</gml:pos> <!--D--> <gml:pos>431.0 -732.0</gml:pos> <!--E-->
<gml:pos>434.0 -732.0</gml:pos> <!--C--> <gml:pos>433.0 -731.0</gml:pos> <!--D-->
<gml:pos>434.0 -733.0</gml:pos> <!--B--> <gml:pos>434.0 -732.0</gml:pos> <!--C-->
<gml:pos>433.0 -734.0</gml:pos> <!--A--> <gml:pos>434.0 -733.0</gml:pos> <!--B-->
</gml:LinearRing> <gml:pos>433.0 -734.0</gml:pos> <!--A-->
</gml:exterior> </gml:LinearRing>
</gml:Polygon> </gml:exterior>
</rel:offset> </gml:Polygon>
</rel:relative-location> </rel:offset>
</gp:location-info> </rel:relative-location>
<gp:usage-rules/> </gp:location-info>
<gp:method>GPS</gp:method> <gp:usage-rules/>
</gp:geopriv> <gp:method>GPS</gp:method>
<dm:deviceID>mac:1234567890ab</dm:deviceID> </gp:geopriv>
<dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp> <dm:deviceID>mac:1234567890ab</dm:deviceID>
</dm:device> <dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp>
</presence> </dm:device>
</presence>
5.2. Geo PIDF with Circle Offset 5.2. Geo PIDF with Circle Offset
<?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"
xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative" xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:point2d@example.com"> entity="pres:point2d@example.com">
<dm:device id="point2d"> <dm:device id="point2d">
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326"> <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-34.407 150.883</gml:pos> <gml:pos>-34.407 150.883</gml:pos>
<gml:radius uom="urn:ogc:def:uom:EPSG::9001"> <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
50.0 50.0
</gml:radius> </gs:radius>
</gs:Circle> </gs:Circle>
<rel:relative-location> <rel:relative-location>
<rel:reference> <rel:reference>
<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>
</rel:reference> </rel:reference>
<rel:offset> <rel:offset>
<gml:Circle xmlns:gml="http://www.opengis.net/gml" <gs:Circle xmlns:gml="http://www.opengis.net/gml"
srsName="urn:ietf:params:geopriv:relative:2d"> srsName="urn:ietf:params:geopriv:relative:2d">
<gml:pos>500.0 750.0</gml:pos> <gml:pos>500.0 750.0</gml:pos>
<gml:radius uom="urn:ogc:def:uom:EPSG::9001"> <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
5.0 5.0
</gml:radius> </gs:radius>
</gml:Circle> </gs:Circle>
</rel:offset> </rel:offset>
<rel:map> <rel:map>
<rel:urltype="image/png"> <rel:url type="image/png">
https://www.example.com/flrpln/123South/flr-2 https://www.example.com/flrpln/123South/flr-2
</rel:url> </rel:url>
<rel:offset> 2670.0 1124.0 1022.0</rel:offset> <rel:offset>2670.0 1124.0 1022.0</rel:offset>
<rel:orientation>67.00</rel:orientation> <rel:orientation>67.00</rel:orientation>
<rel:scale>10</rel:scale> <rel:scale>10 -10</rel:scale>
</rel:map> </rel:map>
</rel:relative-location> </rel:relative-location>
</gp:location-info> </gp:location-info>
<gp:usage-rules/> <gp:usage-rules/>
<gp:method>Wiremap</gp:method> <gp:method>Wiremap</gp:method>
</gp:geopriv> </gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID> <dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp> <dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp>
</dm:device> </dm:device>
</gp:geopriv> </presence>
</status>
<timestamp>2003-06-22T20:57:29Z</timestamp>
</tuple>
</presence>
5.3. Civic TLV with Point Offset 5.3. Civic TLV with Point Offset
+--------+-------------------------------------------------+ +--------+-------------------------------------------------+
| Type | Value | | Type | Value |
+--------+-------------------------------------------------+ +--------+-------------------------------------------------+
| 0 | en | | 0 | en |
| | | | | |
| 1 | IL | | 1 | IL |
| | | | | |
skipping to change at page 27, line 21 skipping to change at page 28, line 18
be used as a covert channel. For values of either zero or infinity, be used as a covert channel. For values of either zero or infinity,
non-zero fraction bits could be used to convey information. If the non-zero fraction bits could be used to convey information. If the
presence of covert channels is not desired then the fractional bits presence of covert channels is not desired then the fractional bits
MUST be set to zero. There is no need to represent NaN (not a MUST be set to zero. There is no need to represent NaN (not a
number) in this encoding. number) in this encoding.
8. IANA Considerations 8. IANA Considerations
8.1. Relative Location Registry 8.1. Relative Location Registry
This document creates a new registry called 'Relative Location This document creates a new registry called "Relative Location
Parameters'. As defined in [RFC5226], this registry operates under Parameters". As defined in [RFC5226], this registry operates under
"IETF Review" rules. "IETF Review" rules.
The content of this registry includes: The content of this registry includes:
Relative Location Code: Numeric identifier, assigned by IANA. Relative Location Code: Numeric identifier, assigned by IANA.
Brief description: Short description identifying the meaning of the Brief description: Short description identifying the meaning of the
element. element.
Reference to published specification: A stable reference to an RFC Reference to published specification: A stable reference to an RFC
skipping to change at page 27, line 47 skipping to change at page 28, line 44
with values assigned in the CAtypes registry or vice versa, unless with values assigned in the CAtypes registry or vice versa, unless
the IANA considerations section for the new value explicitly the IANA considerations section for the new value explicitly
overrides this prohibition and the document defining the value overrides this prohibition and the document defining the value
describes how conflicting TLV codes will be interpreted by describes how conflicting TLV codes will be interpreted by
implementations. implementations.
The values defined are: The values defined are:
+--------+----------------------------------------+-----------+ +--------+----------------------------------------+-----------+
| RLtype | description | Reference | | RLtype | description | Reference |
+--------+-------+--------------------------------+-----------+ +--------+----------------------------------------+-----------+
| 111 | relative location reference | this RFC | | 111 | relative location reference | this RFC |
| 113 | relative location shape 2D point | this RFC | | 113 | relative location shape 2D point | this RFC |
| 114 | relative location shape 3D point | this RFC | | 114 | relative location shape 3D point | this RFC |
| 115 | relative location shape circular | this RFC | | 115 | relative location shape circular | this RFC |
| 116 | relative location shape spherical | this RFC | | 116 | relative location shape spherical | this RFC |
| 117 | relative location shape elliptical | this RFC | | 117 | relative location shape elliptical | this RFC |
| 118 | relative location shape ellipsoid | this RFC | | 118 | relative location shape ellipsoid | this RFC |
| 119 | relative location shape 2D polygon | this RFC | | 119 | relative location shape 2D polygon | this RFC |
| 120 | relative location shape 3D polygon | this RFC | | 120 | relative location shape 3D polygon | this RFC |
| 121 | relative location shape prism | this RFC | | 121 | relative location shape prism | this RFC |
| 122 | relative location shape arc-band | this RFC | | 122 | relative location shape arc-band | this RFC |
| 123 | relative location dynamic orientation | this RFC | | 123 | relative location dynamic orientation | this RFC |
| 124 | relative location dynamic speed | this RFC | | 124 | relative location dynamic speed | this RFC |
| 125 | relative location dynamic heading | this RFC | | 125 | relative location dynamic heading | this RFC |
| 126 | relative location map type | this RFC | | 126 | relative location map type | this RFC |
| 127 | relative location map URI | this RFC | | 127 | relative location map URI | this RFC |
| 128 | relative location map coordinates | this RFC | | 128 | relative location map coordinates | this RFC |
| 129 | relative location map angle | this RFC | | 129 | relative location map angle | this RFC |
| 130 | relative location map scale | this RFC | | 130 | relative location map scale | this RFC |
+--------+-------+--------------------------------+-----------+ +--------+----------------------------------------+-----------+
8.2. URN Sub-Namespace Registration 8.2. URN Sub-Namespace Registration
This document registers a new XML namespace, as per the guidelines in This document registers a new XML namespace, as per the guidelines in
[RFC3688]). [RFC3688]).
URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative
Registrant Contact:IETF, GEOPRIV working group (geopriv@ietf.org), Registrant Contact:IETF, GEOPRIV working group (geopriv@ietf.org),
Martin Thomson (martin.thomson@skype.net). Martin Thomson (martin.thomson@skype.net).
skipping to change at page 29, line 37 skipping to change at page 30, line 10
<!-- [[NOTE TO RFC-EDITOR: Please replace all instances of RFCXXXX <!-- [[NOTE TO RFC-EDITOR: Please replace all instances of RFCXXXX
with the number of the published with the number of the published
document and remove this note.]] --> document and remove this note.]] -->
END END
8.3. XML Schema Registration 8.3. XML Schema Registration
This section registers an XML schema as per the procedures in This section registers an XML schema as per the procedures in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:pidf:geopriv10:relativeLocation URI: urn:ietf:params:xml:schema:pidf:geopriv10:relativeLocation
Registrant Contact:IETF, GEOPRIV working group (geopriv@ietf.org), Registratant Contact: IETF, GEOPRIV working group
Martin Thomson (martin.thomson@skype.net). (geopriv@ietf.org), Martin Thomson (martin.thomson@skype.net).
The XML for this schema is the entirety of Section 6 Schema The XML for this schema is the entirety of Section 6 of this
of this document. document.
8.4. CRS public identifier registration 8.4. Registration of Relative Coordinate Reference System URNs
This section registers two public identifiers as per the procedures This section registers two URNs for use in identifying relative
in [RFC3688]. coordinate reference systems. These are added to a new "Geopriv
Identifiers" registry according to the procedures in Section 4 of
[RFC3553]. Registrations in this registry follow the IETF Review
[RFC5226] policy.
URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative:2d Registry name: Geopriv Identifiers
Registrant Contact:IETF, GEOPRIV working group (geopriv@ietf.org), URN Prefix: urn:ietf:params:geopriv:
Martin Thomson (martin.thomson@skype.net).
XML: Specification: RFCXXXX (this document)
BEGIN Respository: [Editor/IANA note: please include a link to the
<?xml version="1.0"?> registry location.]
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>GEOPRIV Relative Location 2d CRS</title>
</head>
<body>
<h1>Identifier for a 2D CRS in relative location</h1>
<h2>urn:ietf:params:xml:ns:pidf:geopriv10:relative:2d</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfcXXXX.txt">
RFCXXXX</a>.</p>
</body>
</html>
<!-- [[NOTE TO RFC-EDITOR: Please replace all instances of RFCXXXX
with the number of the published document
and remove this note.]] -->
END
URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative:3d Index value: Values in this registry are URNs or URN prefixes that
start with the prefix "urn:ietf:params:geopriv:". Each is
registered independently.
Registrant Contact:IETF, GEOPRIV working group (geopriv@ietf.org) Each registration in the "Geopriv Identifiers" registry requires the
Martin Thomson (martin.thomson@skype.net). following information:
XML: URN The complete URN that is used, or the prefix for that URN.
BEGIN Description: A summary description for the URN or URN prefix.
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" Specification: A reference to a specification describing the URN or
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> URN prefix.
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head> Contact: Email for the person or groups making the registration.
<title>GEOPRIV Relative Location 3d CRS</title>
</head> Index value: As described in [RFC3553], URN prefixes that are
<body> registered include a description of how the URN is constructed.
<h1>Identifier for a 3D CRS in relative location</h1> This is not applicable for specific URNs.
<h2>urn:ietf:params:xml:ns:pidf:geopriv10:relative:3d</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfcXXXX.txt"> The "Geopriv Identifiers" registry has two initial registrations,
RFCXXXX</a>.</p> included in the following sections.
</body>
</html> 8.4.1. Registration of 2D CRS URN
<!-- [[NOTE TO RFC-EDITOR: Please replace all instances of RFCXXXX
with the number of the published This section registers the "urn:ietf:params:geopriv:relative:2d" URN
document and remove this note.]] --> in the "Geopriv Identifiers" registry.
END
URN urn:ietf:params:geopriv:relative:2d
Description: A two-dimensional relative coordinate reference system
Specification: RFCXXXX (this document)
Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin
Thomson (martin.thomson@skype.net).
Index value: N/A.
8.4.2. Registration of 3D CRS URN
This section registers the "urn:ietf:params:geopriv:relative:3d" URN
in the "Geopriv Identifiers" registry.
URN urn:ietf:params:geopriv:relative:3d
Description: A three-dimensional relative coordinate reference
system
Specification: RFCXXXX (this document)
Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin
Thomson (martin.thomson@skype.net).
Index value: N/A.
8.5. CAtype Registration 8.5. CAtype Registration
This section adds a new entry to the CAtype registry defined by This section adds a new entry to the CAtype registry defined by
[RFC6848]. [RFC6848].
Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative
Local Name: REL Local Name: REL
Description: Relative location from a reference point Description: Relative location from a reference point
Contact: The IESG (iesg@ietf.org); the GEOPRIV working group Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
(geopriv@ietf.org). (geopriv@ietf.org).
Specification: RFCXXXX Specification: RFCXXXX
Schema: urn:ietf:params:xml:schema:pidf:geopriv10:relativeLocation Schema: urn:ietf:params:xml:schema:pidf:geopriv10:relativeLocation
Type: A Type: A
skipping to change at page 31, line 49 skipping to change at page 32, line 28
the authors, this team included: Marc Linsner, James Polk, and James the authors, this team included: Marc Linsner, James Polk, and James
Winterbottom. Winterbottom.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
IETF URN Sub-namespace for Registered Protocol
Parameters", BCP 73, RFC 3553, June 2003.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
[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.
[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.
skipping to change at page 33, line 9 skipping to change at page 33, line 43
[IEEE.754] [IEEE.754]
IEEE, "IEEE Standard for Binary Floating-Point IEEE, "IEEE Standard for Binary Floating-Point
Arithmetic", IEEE Standard 754-1985, January 2003. Arithmetic", IEEE Standard 754-1985, January 2003.
[Clinger1990] [Clinger1990]
Clinger, W., "How to Read Floating Point Numbers Clinger, W., "How to Read Floating Point Numbers
Accurately", Proceedings of Conference on Programming Accurately", Proceedings of Conference on Programming
Language Design and Implementation pp. 92-101, 1990, <ftp: Language Design and Implementation pp. 92-101, 1990, <ftp:
//ftp.ccs.neu.edu/pub/people/will/howtoread.ps>. //ftp.ccs.neu.edu/pub/people/will/howtoread.ps>.
[WGS84] US National Imagery and Mapping Agency, "Department of
Defense (DoD) World Geodetic System 1984 (WGS 84), Third
Edition ", NIMA TR8350.2, January 2000.
10.2. Informative References 10.2. Informative References
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,
January 2004. W., and J. Peterson, "Presence Information Data Format
(PIDF)", RFC 3863, August 2004.
[WGS84] US National Imagery and Mapping Agency , ""Department of [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July
Defense (DoD) World Geodetic System 1984 (WGS 84), Third 2006.
Edition"", NIMA TR8350.2, January 2000.
Authors' Addresses Authors' Addresses
Martin Thomson Martin Thomson
Microsoft Microsoft
3210 Porter Drive 3210 Porter Drive
Palo Alto, CA 94304 Palo Alto, CA 94304
US US
Phone: +1 650-353-1925 Phone: +1 650-353-1925
 End of changes. 61 change blocks. 
230 lines changed or deleted 285 lines changed or added

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