draft-ietf-geopriv-relative-location-08.txt   rfc7035.txt 
GEOPRIV M. Thomson Internet Engineering Task Force (IETF) M. Thomson
Internet-Draft Microsoft Request for Comments: 7035 Microsoft
Intended status: Standards Track B. Rosen Category: Standards Track B. Rosen
Expires: March 10, 2014 Neustar ISSN: 2070-1721 Neustar
D. Stanley D. Stanley
Aruba Networks Aruba Networks
G. Bajko G. Bajko
Nokia Nokia
A. Thomson A. Thomson
Cisco Systems, Inc. Lookingglass
September 06, 2013 October 2013
Relative Location Representation Relative Location Representation
draft-ietf-geopriv-relative-location-08
Abstract Abstract
This document defines an extension to PIDF-LO (RFC4119) for the This document defines an extension to the Presence Information Data
expression of location information that is defined relative to a Format Location Object (PIDF-LO) (RFC 4119) for the expression of
reference point. The reference point may be expressed as a geodetic location information that is defined relative to a reference point.
or civic location, and the relative offset may be one of several The reference point may be expressed as a geodetic or civic location,
shapes. An alternative binary representation is described. and the relative offset may be one of several shapes. An alternative
binary representation is described.
Optionally, a reference to a secondary document (such as a map image) Optionally, a reference to a secondary document (such as a map image)
can be included, along with the relationship of the map coordinate can be included, along with the relationship of the map coordinate
system to the reference/offset coordinate system to allow display of system to the reference/offset coordinate system, to allow display of
the map with the reference point and the relative offset. the map with the reference point and the relative offset.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on March 10, 2014. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7035.
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 19 skipping to change at page 3, line 7
(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
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 ....................................................4
2. Conventions used in this document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document ...............................4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview ........................................................4
4. Relative Location . . . . . . . . . . . . . . . . . . . . . . 7 4. Relative Location ...............................................7
4.1. Relative Coordinate System . . . . . . . . . . . . . . . 7 4.1. Relative Coordinate System .................................8
4.2. Placement of XML Elements . . . . . . . . . . . . . . . . 8 4.2. Placement of XML Elements ..................................8
4.3. Binary Format . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Binary Format ..............................................9
4.4. Distances and Angles . . . . . . . . . . . . . . . . . . 9 4.4. Distances and Angles .......................................9
4.5. Value Encoding . . . . . . . . . . . . . . . . . . . . . 9 4.5. Value Encoding ............................................10
4.6. Relative Location Restrictions . . . . . . . . . . . . . 9 4.6. Relative Location Restrictions ............................10
4.7. Baseline TLVs . . . . . . . . . . . . . . . . . . . . . . 9 4.7. Baseline TLVs .............................................10
4.8. Reference TLV . . . . . . . . . . . . . . . . . . . . . . 9 4.8. Reference TLVs ............................................10
4.9. Shapes . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.9. Shapes ....................................................11
4.9.1. Point . . . . . . . . . . . . . . . . . . . . . . . . 10 4.9.1. Point ..............................................11
4.9.2. Circle or Sphere Shape . . . . . . . . . . . . . . . 11 4.9.2. Circle or Sphere Shape .............................12
4.9.3. Ellipse or Ellipsoid Shape . . . . . . . . . . . . . 12 4.9.3. Ellipse or Ellipsoid Shape .........................13
4.9.4. Polygon or Prism Shape . . . . . . . . . . . . . . . 14 4.9.4. Polygon or Prism Shape .............................15
4.9.5. Arc-Band Shape . . . . . . . . . . . . . . . . . . . 16 4.9.5. Arc-Band Shape .....................................18
4.10. Dynamic Location TLVs . . . . . . . . . . . . . . . . . . 18 4.10. Dynamic Location TLVs ....................................20
4.10.1. Orientation . . . . . . . . . . . . . . . . . . . . 18 4.10.1. Orientation .......................................20
4.10.2. Speed . . . . . . . . . . . . . . . . . . . . . . . 18 4.10.2. Speed .............................................20
4.10.3. Heading . . . . . . . . . . . . . . . . . . . . . . 18 4.10.3. Heading ...........................................20
4.11. Secondary Map Metadata . . . . . . . . . . . . . . . . . 19 4.11. Secondary Map Metadata ...................................21
4.11.1. Map URL . . . . . . . . . . . . . . . . . . . . . . 19 4.11.1. Map URL ...........................................21
4.11.2. Map Coordinate Reference System . . . . . . . . . . 19 4.11.2. Map Coordinate Reference System ...................21
4.11.3. Map Example . . . . . . . . . . . . . . . . . . . . 22 4.11.3. Map Example .......................................24
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5. Examples .......................................................24
5.1. Civic PIDF with Polygon Offset . . . . . . . . . . . . . 22 5.1. Civic PIDF with Polygon Offset ............................24
5.2. Geo PIDF with Circle Offset . . . . . . . . . . . . . . . 24 5.2. Geo PIDF with Circle Offset ...............................26
5.3. Civic TLV with Point Offset . . . . . . . . . . . . . . . 25 5.3. Civic TLV with Point Offset ...............................27
6. Schema Definition . . . . . . . . . . . . . . . . . . . . . . 25 6. Schema Definition ..............................................28
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations ........................................30
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations ............................................31
8.1. Relative Location Registry . . . . . . . . . . . . . . . 29 8.1. Relative Location Registry ................................31
8.2. URN Sub-Namespace Registration . . . . . . . . . . . . . 30 8.2. URN Sub-Namespace Registration ............................33
8.3. XML Schema Registration . . . . . . . . . . . . . . . . . 31 8.3. XML Schema Registration ...................................33
8.4. Geopriv Identifiers Registry . . . . . . . . . . . . . . 31 8.4. Geopriv Identifiers Registry ..............................34
8.4.1. Registration of Two-Dimentional Relative Coordinate 8.4.1. Registration of Two-Dimensional Relative
Reference System URN . . . . . . . . . . . . . . . . 32 Coordinate Reference System URN ....................35
8.4.2. Registration of Three-Dimentional Relative Coordinate 8.4.2. Registration of Three-Dimensional Relative
Reference System URN . . . . . . . . . . . . . . . . 32 Coordinate Reference System URN ....................35
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 9. Acknowledgements ...............................................35
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 10. References ....................................................36
10.1. Normative References . . . . . . . . . . . . . . . . . . 33 10.1. Normative References .....................................36
10.2. Informative References . . . . . . . . . . . . . . . . . 35 10.2. Informative References ...................................38
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
relative offset from that reference location. The reference location offset from that reference location. The reference location can be
can be represented in either civic or geodetic form. The reference represented in either civic or geodetic form. The reference location
location can also have dynamic components such as velocity. The can also have dynamic components such as velocity. The relative
relative offset is specified in meters using a Cartesian coordinate offset is specified in meters using a Cartesian coordinate system.
system.
In addition to the relative location, an optional URI can be provided In addition to the relative location, an optional URI can be provided
to a document that contains a map, floorplan or other spatially to a document that contains a map, floor plan, or other spatially
oriented information. Applications could use this information to oriented information. Applications could use this information to
display the relative location. Additional fields allow the map to be display the relative location. Additional fields allow the map to be
oriented and scaled correctly. oriented and scaled correctly.
Two formats are included: an XML form that is intended for use in Two formats are included: an XML form that is intended for use in
PIDF-LO [RFC4119] and a TLV format for use in other protocols such as PIDF-LO [RFC4119] and a TLV format for use in other protocols such as
those that already convey binary representation of location those that already convey binary representation of location
information defined in [RFC4776]. information defined in [RFC4776].
2. Conventions used in this document 2. Conventions Used in This Document
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.
Reference Reference
Location Location
o o
\ \
\ Offset \ Offset
\ \
_\| _\|
x x
Relative Relative
Location Location
This extension allows the creator of a location object to include two This extension allows the creator of a location object to include two
location values plus an offset. The two location values, named location values plus an offset. The two location values, named
"baseline" and "reference", combine to form the origin of the offset. "baseline" and "reference", combine to form the origin of the offset.
The final, relative location is described relative to this reference The final, relative location is described relative to this reference
point. point.
..--"""--.. ..--"""--..
.-' `-. .-' `-.
,' `. ,' `.
/ Reference \ / Reference \
/ o \ / o \
| \ | | \ |
| \ | | \ |
| \ | | \ |
\ _\| / \ _\| /
`. x .' \_ Baseline `. x .' \_ Baseline
`._ Relative _.' Location `._ Relative _.' Location
`--..___..--' `--..___..--'
The "baseline" location is included outside of the <relative- The baseline location is included outside of the <relative-location>
location> element. The baseline location is visible to a client that element. The baseline location is visible to a client that does not
does not understand relative location (i.e., it ignores the understand relative location (i.e., it ignores the
<relative-location> element). <relative-location> element).
A client that does understand relative location will interpret the A client that does understand relative location will interpret the
location within the relative element as a refinement of the baseline location within the relative element as a refinement of the baseline
location. This document defines both a "reference" location, which location. This document defines both a reference location, which
serves as a refinement of the baseline location and the starting serves as a refinement of the baseline location and the starting
point; and an offset, which describes the location of the Target point, and an offset, which describes the location of the Target
based on this starting point. based on this starting point.
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
and how much to put into the "reference" location. For example, the how much to put into the reference location. For example, 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.
Location objects SHOULD NOT have all location information in the Location objects SHOULD NOT have all location information in the
baseline location. Doing this would cause clients that do not baseline location. Doing this would cause clients that do not
understand relative location to incorrectly interpret the baseline understand relative location to incorrectly interpret the baseline
location (i.e., the reference point) as the actual, precise location location (i.e., the reference point) as the actual, precise location
of the client. The baseline location is intended to carry a location of the client. The baseline location is intended to carry a location
that encompasses both the reference location and the relative that encompasses both the reference location and the relative
location (i.e., the reference location plus offset). location (i.e., the reference location plus offset).
It is possible to provide a valid relative location with no It is possible to provide a valid relative location with no
information in the baseline. However, this provides recipients who information in the baseline. However, this provides recipients who
do not understand relative location with no information. A baseline do not understand relative location with no information. A baseline
location SHOULD include sufficient information to encompass both the location SHOULD include sufficient information to encompass both the
reference and relative locations while providing a baseline that is reference and relative locations while providing a baseline that is
as accurate as possible. 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 as either 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 civic.
Baseline and reference locations MAY also include dynamic location Baseline and reference locations MAY also include dynamic location
information [RFC5962]. information [RFC5962].
The relative location can be expressed using a point (2- or The relative location can be expressed using a point (2- or
3-dimensional), or a shape that includes uncertainty: circle, sphere, 3-dimensional) or a shape that includes uncertainty: circle, sphere,
ellipse, ellipsoid, polygon, prism or arc-band. Descriptions of ellipse, ellipsoid, polygon, prism, or arc-band. Descriptions of
these shapes can be found in [RFC5491]. these shapes can be found in [RFC5491].
Optionally, a reference to a 'map' document can be provided. The Optionally, a reference to a 'map' document can be provided. The
reference is a URI [RFC3986]. The document could be an image or reference is a URI [RFC3986]. The document could be an image or
dataset that represents a map, floorplan or other form. The type of dataset that represents a map, floor plan, or other form. The type
document the URI points to is described as a MIME media type of document the URI points to is described as a MIME media type
[RFC2046]. Metadata in the relative location can include the [RFC2046]. Metadata in the relative location can include the
location of the reference point in the map as well as an orientation location of the reference point in the map as well as an orientation
(angle from North) and scale to align the document Co-ordinate (angle from North) and scale to align the document Coordinate
Reference System (CRS) with the WGS84 [WGS84] CRS. The document is Reference System (CRS) with the World Geodetic System 1984 (WGS84)
assumed to be useable by the application receiving the PIDF with the [WGS84] CRS. The document is assumed to be usable by the application
relative location to locate the reference point in the map. This receiving the PIDF with the relative location to locate the reference
document does not describe any mechanisms for displaying or point in the map. This document does not describe any mechanisms for
manipulating the document other than providing the reference displaying or manipulating the document other than providing the
location, orientation and scale. reference location, orientation, and scale.
As an example, consider a relative location expressed as a point, As an example, consider a relative location expressed as a point,
relative to a civic location: relative to a civic location:
<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"
skipping to change at page 7, line 12 skipping to change at page 7, line 44
</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 (e.g., point, circle, ellipse). The Relative location is a shape (e.g., point, circle, ellipse). The
shape 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.
The baseline and reference locations are used to define a relative The baseline and reference locations are used to define a relative
datum. The reference location defines the origin of the coordinate datum. The reference location defines the origin of the coordinate
system. The centroid of the reference location is used when the system. The centroid of the reference location is used when the
reference location contains any uncertainty. reference location contains any uncertainty.
The axes in this coordinate system are originally oriented based on The axes in this coordinate system are originally oriented based on
the directions of East, North and Up from the reference location: the the directions of East, North, and Up from the reference location:
first (x) axis increases to the East, the second (y) axis points the first (x) axis increases to the East, the second (y) axis points
North, and the optional third (z) axis points Up. All axes of the North, and the optional third (z) axis points Up. All axes of the
coordinate system use meters as a basic unit. coordinate system use meters as a basic unit.
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 the relative coordinate system. The resulting
coordinate system axes are rotated so that the "y" axis is oriented Cartesian coordinate system axes are rotated so that the y axis is
along the direction described by the <orientation> element. The oriented along the direction described by the <orientation> element.
coordinate system also moves as described by the <speed> and The coordinate system also moves as described by the <speed> and
<heading> elements. <heading> elements.
The single timestamp included in the tuple (or equivalent) element The single timestamp included in the tuple (or equivalent) element
applies to all location elements, including all three components of a applies to all location elements, including all three components of a
relative location: baseline, reference and relative. This is relative location: baseline, reference, and relative. This is
particularly important when there are dynamic components to these particularly important when there are dynamic components to these
items. A location generator is responsible for ensuring the items. A location generator is responsible for ensuring the
consistency of these fields. consistency of these fields.
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
info> like a normal PIDF-LO. Relative location adds a new <relative- <location-info> like a normal PIDF-LO. Relative location adds a new
location> element to <location-info>. Within <relative-location>, <relative-location> element to <location-info>. Within
<reference> and <offset> elements are described. Within <offset> are <relative-location>, <reference> and <offset> elements are described.
the shape elements described below. This document extends PIDF-LO as Within <offset> are the shape elements described below. This
described in [RFC6848]. document extends PIDF-LO as described in [RFC6848].
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 ...
+------+------+------+------+------+------+------+ +------+------+------+------+------+------+------+
| T | N | Value ... | T | N | Value ...
+------+------+------+------+------+------+------+ +------+------+------+------+------+------+------+
Figure 1: TLV-tuple format Figure 1: TLV Tuple Format
Type field (T) is an 8-bit unsigned integer. The type codes used are The Type field (T) is an 8-bit unsigned integer. The type codes used
registered an IANA-managed "Relative Location Parameters" registry are registered in an IANA-managed "Relative Location Parameters"
defined by this document, and restricted to not include the values registry defined by this document and restricted to not include the
defined by the "CAtypes" registry. This restriction permits a values defined by the "Civic Address Types (CAtypes)" registry. This
location reference and offset to be coded within the same object restriction permits a location reference and offset to be coded
without type collisions. within the same object without type collisions.
The Length field (N) is defined as an 8-bit unsigned integer. This The Length field (N) is defined as an 8-bit unsigned integer. This
field can encode values from 0 to 255. The length field describes field can encode values from 0 to 255. The length field describes
the number of bytes in the Value. Length does not count the bytes the number of bytes in the Value. Length does 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 form includes both baseline and relative location encoded in TLV form includes both baseline and
reference location TLVs and a reference location TLVs. The reference reference location TLVs and relative location TLVs. The reference
TLVs are followed by the relative offset, and optional map TLDs TLVs are followed by the relative offset and optional map TLVs
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).
4.5. Value Encoding 4.5. Value Encoding
The binary form uses single-precision floating point values IEEE 754 The binary form uses single-precision floating-point values
[IEEE.754] to represent coordinates, distance and angle measures. [IEEE.754] to represent coordinates, distance, and angle measures.
Single precision values are 32-bit values with a sign bit, 8 exponent Single-precision values are 32-bit values with a sign bit, 8 exponent
bits and 23 fractional bits. This uses the interchange format bits, and 23 fractional bits. This uses the interchange format
defined in [IEEE.754] and Section 3.6 of [RFC1014], that is: sign, defined in [IEEE.754] and Section 3.6 of [RFC1014], that is: sign,
biased exponent and significand, with the most significant bit first. biased exponent and significand, with the most significant bit first.
Binary-encoded coordinate values are considered to be a single value Binary-encoded coordinate values are considered to be a single value
without uncertainty. When encoding a value that cannot be exactly without uncertainty. When encoding a value that cannot be exactly
represented, the best approximation MUST be selected according to represented, the best approximation MUST be selected according to
[Clinger1990]. [Clinger1990].
4.6. Relative Location Restrictions 4.6. Relative Location Restrictions
skipping to change at page 9, line 45 skipping to change at page 10, line 35
by the relative location. Any errors arising from an implementation by the relative location. Any errors arising from an implementation
not supporting or understanding elements of the reference point not supporting or understanding elements of the reference point
directly increases the error (or uncertainty) in the resulting directly increases the error (or uncertainty) in the resulting
location. location.
4.7. Baseline TLVs 4.7. Baseline TLVs
Baseline locations are described using the formats defined in Baseline locations are described using the formats defined in
[RFC4776] or [RFC6225]. [RFC4776] or [RFC6225].
4.8. Reference TLV 4.8. Reference TLVs
When a reference is encoded in binary form, the baseline and When a reference is encoded in binary form, the baseline and
reference locations are combined in a reference TLV. This TLV is reference locations are combined in a reference TLV. This TLV is
identified with the code 111 and contains civic address TLVs (if the identified with the code 111 and contains civic address TLVs (if the
baseline was a civic) or geo TLVs (if the baseline was a geo). baseline was a civic) or geo TLVs (if the baseline was a geo).
+------+------+------+------+------+------+ +------+------+------+------+------+------+
| 111 |Length| Reference TLVs | | 111 |Length| Reference TLVs |
+------+------+------+------+------+------+ +------+------+------+------+------+------+
Reference TLV Figure 2: 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 [WGS84] CRS. Shape data in the relative location uses a WGS84 [WGS84] CRS. Shape data in the relative
location 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.
Nine shape type codes are defined. Nine shape type codes are defined.
4.9.1. Point 4.9.1. Point
A point "shape" describes a single point with unknown uncertainty. A point "shape" describes a single point with unknown uncertainty.
It consists of a single set of coordinates. It consists of a single set of coordinates.
In a two-dimensional CRS, the coordinate includes two values; in a In a two-dimensional CRS, the coordinate includes two values; in a
three-dimensional CRS, the coordinate includes three values. three-dimensional CRS, the coordinate includes three values.
4.9.1.1. XML encoding 4.9.1.1. XML Encoding
A point is represented in GML using the following template: A point is represented in GML using the following template:
<gml:Point xmlns:gml="http://www.opengis.net/gml" <gml:Point xmlns:gml="http://www.opengis.net/gml"
srsName="$CRS-URN$"> srsName="$CRS-URN$">
<gml:pos>$Coordinate-1 $Coordinate-2$ $Coordinate-3$</gml:pos> <gml:pos>$Coordinate-1 $Coordinate-2$ $Coordinate-3$</gml:pos>
</gml:Point> </gml:Point>
GML Point Template Figure 3: GML Point Template
Where "$CRS-URN$" is replaced by a Where "$CRS-URN$" is replaced by a
urn:ietf:params:geopriv:relative:2d or "urn:ietf:params:geopriv:relative:2d" or
urn:ietf:params:geopriv:relative:3d and "$Coordinate-3$" is omitted "urn:ietf:params:geopriv:relative:3d" and "$Coordinate-3$" is omitted
if the CRS is two-dimensional. if the CRS is two-dimensional.
4.9.1.2. TLV encoding 4.9.1.2. TLV Encoding
The point shape is introduced by a TLV of 113 for a 2D point and 114 The point shape is introduced by a TLV of 113 for a 2D point and 114
for a 3D point. for a 3D point.
+------+------+ +------+------+
| 113/4|Length| | 113/4|Length|
+------+------+------+------+ +------+------+------+------+
| Coordinate-1 | | Coordinate-1 |
+------+------+------+------+ +------+------+------+------+
| Coordinate-2 | | Coordinate-2 |
+------+------+------+------+ +------+------+------+------+
| (3D-only) Coordinate-3 | | (3D-only) Coordinate-3 |
+------+------+------+------+ +------+------+------+------+
Point Encoding Figure 4: Point Encoding
4.9.2. Circle or Sphere Shape 4.9.2. Circle or Sphere Shape
A circle or sphere describes a single point with a single uncertainty A circle or sphere describes a single point with a single uncertainty
value in meters. value in meters.
In a two-dimensional CRS, the coordinate includes two values and the In a two-dimensional CRS, the coordinate includes two values, and the
resulting shape forms a circle. In a three-dimensional CRS, the resulting shape forms a circle. In a three-dimensional CRS, the
coordinate includes three values and the resulting shape forms a coordinate includes three values, and the resulting shape forms a
sphere. sphere.
4.9.2.1. XML encoding 4.9.2.1. XML Encoding
A circle is represented in and converted from GML using the following A circle is represented in and converted from GML using the following
template: template:
<gs:Circle xmlns:gml="http://www.opengis.net/gml" <gs:Circle 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:2d"> srsName="urn:ietf:params:geopriv:relative:2d">
<gml:pos>$Coordinate-1 $Coordinate-2$</gml:pos> <gml:pos>$Coordinate-1 $Coordinate-2$</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001"> <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
$Radius$ $Radius$
</gs:radius> </gs:radius>
</gs:Circle> </gs:Circle>
GML Circle Template Figure 5: GML Circle Template
A sphere is represented in and converted from GML using the following A sphere is represented in and converted from GML using the following
template: template:
<gs:Sphere xmlns:gml="http://www.opengis.net/gml" <gs:Sphere 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">
<gml:pos>$Coordinate-1 $Coordinate-2$ $Coordinate-3$</gml:pos> <gml:pos>$Coordinate-1 $Coordinate-2$ $Coordinate-3$</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001"> <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
$Radius$ $Radius$
</gs:radius> </gs:radius>
</gs:Sphere> </gs:Sphere>
GML Sphere Template Figure 6: GML Sphere Template
4.9.2.2. TLV encoding 4.9.2.2. TLV Encoding
A circular shape is introduced by a type code of 115. A spherical A circular shape is introduced by a type code of 115. A spherical
shape is introduced by a type code of 116. shape is introduced by a type code of 116.
+------+------+ +------+------+
| 115/6|Length| | 115/6|Length|
+------+------+------+------+ +------+------+------+------+
| Coordinate-1 | | Coordinate-1 |
+------+------+------+------+ +------+------+------+------+
| Coordinate-2 | | Coordinate-2 |
+------+------+------+------+ +------+------+------+------+
| (3D-only) Coordinate-3 | | (3D-only) Coordinate-3 |
+------+------+------+------+ +------+------+------+------+
| Radius | | Radius |
+------+------+------+------+ +------+------+------+------+
Circle or Sphere Encoding Figure 7: Circle or Sphere Encoding
4.9.3. Ellipse or Ellipsoid Shape 4.9.3. Ellipse or Ellipsoid Shape
A ellipse or ellipsoid describes a point with an elliptical or An ellipse or ellipsoid describes a point with an elliptical or
ellipsoidal uncertainty region. ellipsoidal uncertainty region.
In a two-dimensional CRS, the coordinate includes two values, plus a In a two-dimensional CRS, the coordinate includes two values plus a
semi-major axis, a semi-minor axis, a semi-major axis orientation semi-major axis, a semi-minor axis, a semi-major axis orientation
(clockwise from North). In a three-dimensional CRS, the coordinate (clockwise from North). In a three-dimensional CRS, the coordinate
includes three values and in addition to the two-dimensional values, includes three values, and in addition to the two-dimensional values,
an altitude uncertainty (semi-vertical) is added. an altitude uncertainty (semi-vertical) is added.
4.9.3.1. XML encoding 4.9.3.1. XML Encoding
An ellipse is represented in and converted from GML using the An ellipse is represented in and converted from GML using the
following template: following template:
<gs:Ellipse xmlns:gml="http://www.opengis.net/gml" <gs:Ellipse 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:2d"> srsName="urn:ietf:params:geopriv:relative:2d">
<gml:pos>$Coordinate-1 $Coordinate-2$</gml:pos> <gml:pos>$Coordinate-1 $Coordinate-2$</gml:pos>
<gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001"> <gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001">
$Semi-Major$ $Semi-Major$
</gs:semiMajorAxis> </gs:semiMajorAxis>
<gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001"> <gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001">
$Semi-Minor$ $Semi-Minor$
</gs:semiMinorAxis> </gs:semiMinorAxis>
<gs:orientation uom="urn:ogc:def:uom:EPSG::9102"> <gs:orientation uom="urn:ogc:def:uom:EPSG::9102">
$Orientation$ $Orientation$
</gs:orientation> </gs:orientation>
</gs:Ellipse> </gs:Ellipse>
GML Ellipse Template Figure 8: GML Ellipse Template
An ellipsoid is represented in and converted from GML using the An ellipsoid is represented in and converted from GML using the
following template: following template:
<gs:Ellipsoid xmlns:gml="http://www.opengis.net/gml" <gs:Ellipsoid 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">
<gml:pos>$Coordinate-1 $Coordinate-2$ $Coordinate-3$</gml:pos> <gml:pos>$Coordinate-1 $Coordinate-2$ $Coordinate-3$</gml:pos>
<gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001"> <gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001">
$Semi-Major$ $Semi-Major$
skipping to change at page 13, line 43 skipping to change at page 14, line 48
$Semi-Minor$ $Semi-Minor$
</gs:semiMinorAxis> </gs:semiMinorAxis>
<gs:verticalAxis uom="urn:ogc:def:uom:EPSG::9001"> <gs:verticalAxis uom="urn:ogc:def:uom:EPSG::9001">
$Semi-Vertical$ $Semi-Vertical$
</gs:verticalAxis> </gs:verticalAxis>
<gs:orientation uom="urn:ogc:def:uom:EPSG::9102"> <gs:orientation uom="urn:ogc:def:uom:EPSG::9102">
$Orientation$ $Orientation$
</gs:orientation> </gs:orientation>
</gs:Ellipsoid> </gs:Ellipsoid>
GML Ellipsoid Template Figure 9: GML Ellipsoid Template
4.9.3.2. TLV encoding 4.9.3.2. TLV Encoding
An ellipse is introduced by a type code of 117 and an ellipsoid is An ellipse is introduced by a type code of 117, and an ellipsoid is
introduced by a type code of 118. introduced by a type code of 118.
+------+------+ +------+------+
| 117/8|Length| | 117/8|Length|
+------+------+------+------+ +------+------+------+------+
| Coordinate-1 | | Coordinate-1 |
+------+------+------+------+ +------+------+------+------+
| Coordinate-2 | | Coordinate-2 |
+------+------+------+------+ +------+------+------+------+
| (3D-only) Coordinate-3 | | (3D-only) Coordinate-3 |
+------+------+------+------+------+------+------+------+ +------+------+------+------+------+------+------+------+
| Semi-Major Axis | Semi-Minor Axis | | Semi-Major Axis | Semi-Minor Axis |
+------+------+------+------+------+------+------+------+ +------+------+------+------+------+------+------+------+
| Orientation | (3D) Semi-Vertical Axis | | Orientation | (3D) Semi-Vertical Axis |
+------+------+------+------+------+------+------+------+ +------+------+------+------+------+------+------+------+
Ellipse or Ellipsoid Encoding Figure 10: Ellipse or Ellipsoid Encoding
4.9.4. Polygon or Prism Shape 4.9.4. Polygon or Prism Shape
A polygon or prism include a number of points that describe the outer A polygon or prism includes a number of points that describe the
boundary of an uncertainty region. A prism also includes an altitude outer boundary of an uncertainty region. A prism also includes an
for each point and prism height. altitude for each point and prism height.
At least 3 points MUST be included in a polygon. In order to At least 3 points MUST be included in a polygon. In order to
interoperate with existing systems, an encoding SHOULD include 15 or interoperate with existing systems, an encoding SHOULD include 15 or
fewer points, unless the recipient is known to support larger fewer points, unless the recipient is known to support larger
numbers. numbers.
4.9.4.1. XML Encoding 4.9.4.1. XML Encoding
A polygon is represented in and converted from GML using the A polygon is represented in and converted from GML using the
following template: following template:
skipping to change at page 14, line 49 skipping to change at page 16, line 26
$Coordinate2-1$ $Coordinate2-2$ $Coordinate2-1$ $Coordinate2-2$
$Coordinate3-1$ ... $Coordinate3-1$ ...
... ...
$CoordinateN-1$ $CoordinateN-2$ $CoordinateN-1$ $CoordinateN-2$
$Coordinate1-1$ $Coordinate1-2$ $Coordinate1-1$ $Coordinate1-2$
</gml:posList> </gml:posList>
</gml:LinearRing> </gml:LinearRing>
</gml:exterior> </gml:exterior>
</gml:Polygon> </gml:Polygon>
GML Polygon Template Figure 11: 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 perfectly A GML polygon that includes altitude cannot be represented perfectly
in TLV form. 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>
<gml:exterior> <gml:exterior>
skipping to change at page 15, line 44 skipping to change at page 17, line 32
</gml:posList> </gml:posList>
</gml:LinearRing> </gml:LinearRing>
</gml:exterior> </gml:exterior>
</gml:Polygon> </gml:Polygon>
</gs:base> </gs:base>
<gs:height uom="urn:ogc:def:uom:EPSG::9001"> <gs:height uom="urn:ogc:def:uom:EPSG::9001">
$Height$ $Height$
</gs:height> </gs:height>
</gs:Prism> </gs:Prism>
GML Prism Template Figure 12: GML Prism 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 three coordinate single "posList". Each <pos> element contains three coordinate
values. values.
4.9.4.2. TLV Encoding 4.9.4.2. TLV Encoding
A polygon containing 2D points uses a type code of 119. A polygon A polygon containing 2D points uses a type code of 119. A polygon
with 3D points uses a type code of 120. A prism uses a type code of with 3D points uses a type code of 120. A prism uses a type code of
121. The number of points can be inferred from the length of the 121. The number of points can be inferred from the length of the
TLV. TLV.
+------+------+ +------+------+
|119-21|Length| |119-21|Length|
+------+------+------+------+ +------+------+------+------+
| (3D-only) Height | | (3D-only) Height |
+------+------+------+------+ +------+------+------+------+
| Coordinate1-1 | | Coordinate1-1 |
+------+------+------+------+ +------+------+------+------+
| Coordinate1-2 | | Coordinate1-2 |
+------+------+------+------+ +------+------+------+------+
| (3D-only) Coordinate1-3 | | (3D-only) Coordinate1-3 |
+------+------+------+------+ +------+------+------+------+
| Coordinate2-1 | | Coordinate2-1 |
+------+------+------+------+ +------+------+------+------+
... ...
+------+------+------+------+ +------+------+------+------+
| CoordinateN-1 | | CoordinateN-1 |
+------+------+------+------+ +------+------+------+------+
| CoordinateN-2 | | CoordinateN-2 |
+------+------+------+------+ +------+------+------+------+
| (3D-only) CoordinateN-3 | | (3D-only) CoordinateN-3 |
+------+------+------+------+ +------+------+------+------+
Polygon or Prism Encoding Figure 13: Polygon or Prism Encoding
Note that unlike the polygon representation in GML, the first and Note that unlike the polygon representation in GML, the first and
last points are not the same point in the TLV representation. The last points are not the same point in the TLV representation. The
duplicated point is removed from the binary form. duplicated point is removed from the binary form.
4.9.5. Arc-Band Shape 4.9.5. Arc-Band Shape
A arc-band describes a region constrained by a range of angles and An arc-band describes a region constrained by a range of angles and
distances from a predetermined point. This shape can only be distances from a predetermined point. This shape can only be
provided for a two-dimensional CRS. provided for a two-dimensional CRS.
Distance and angular measures are defined in meters and degrees Distance and angular measures are defined in meters and degrees,
respectively. Both are encoded as single precision floating point respectively. Both are encoded as single-precision floating-point
values. values.
4.9.5.1. XML encoding 4.9.5.1. XML Encoding
An arc-band is represented in and converted from GML using the An arc-band is represented in and converted from GML using the
following template: following template:
<gs:ArcBand xmlns:gml="http://www.opengis.net/gml" <gs:ArcBand 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:2d"> srsName="urn:ietf:params:geopriv:relative:2d">
<gml:pos>$Coordinate-1$ $Coordinate-2$</gml:pos> <gml:pos>$Coordinate-1$ $Coordinate-2$</gml:pos>
<gs:innerRadius uom="urn:ogc:def:uom:EPSG::9001"> <gs:innerRadius uom="urn:ogc:def:uom:EPSG::9001">
$Inner-Radius$ $Inner-Radius$
skipping to change at page 17, line 28 skipping to change at page 19, line 28
$Outer-Radius$ $Outer-Radius$
</gs:outerRadius> </gs:outerRadius>
<gs:startAngle uom="urn:ogc:def:uom:EPSG::9102"> <gs:startAngle uom="urn:ogc:def:uom:EPSG::9102">
$Start-Angle$ $Start-Angle$
</gs:startAngle> </gs:startAngle>
<gs:openingAngle uom="urn:ogc:def:uom:EPSG::9102"> <gs:openingAngle uom="urn:ogc:def:uom:EPSG::9102">
$Opening-Angle$ $Opening-Angle$
</gs:openingAngle> </gs:openingAngle>
</gs:ArcBand> </gs:ArcBand>
GML Arc-Band Template Figure 14: GML Arc-Band Template
4.9.5.2. TLV Encoding 4.9.5.2. TLV Encoding
An arc-band is introduced by a type code of 122. An arc-band is introduced by a type code of 122.
+------+------+ +------+------+
| 122 |Length| | 122 |Length|
+------+------+------+------+ +------+------+------+------+
| Coordinate | | Coordinate |
+------+------+------+------+ +------+------+------+------+
| Coordinate | | Coordinate |
+------+------+------+------+------+------+------+------+ +------+------+------+------+------+------+------+------+
| Inner Radius | Outer Radius | | Inner Radius | Outer Radius |
+------+------+------+------+------+------+------+------+ +------+------+------+------+------+------+------+------+
| Start Angle | Opening Angle | | Start Angle | Opening Angle |
+------+------+------+------+------+------+------+------+ +------+------+------+------+------+------+------+------+
Arc-Band Encoding Figure 15: Arc-Band Encoding
4.10. Dynamic Location TLVs 4.10. Dynamic Location TLVs
Dynamic location elements use the definitions in [RFC5962]. Dynamic location elements use the definitions in [RFC5962].
4.10.1. Orientation 4.10.1. Orientation
The orientation of the target is described using one or two angles. The orientation of the Target is described using one or two angles.
Orientation uses a type code of 123. Orientation uses a type code of 123.
+------+------+ +------+------+
| 123 |Length| | 123 |Length|
+------+------+------+------+ +------+------+------+------+
| Angle | | Angle |
+------+------+------+------+ +------+------+------+------+
| (Optional) Angle | | (Optional) Angle |
+------+------+------+------+ +------+------+------+------+
Dynamic Orientation TLVs Figure 16: Dynamic Orientation TLVs
4.10.2. Speed 4.10.2. Speed
The speed of the target is a scalar value in meters per second. The speed of the Target is a scalar value in meters per second.
Speed uses a type code of 124. Speed uses a type code of 124.
+------+------+ +------+------+
| 124 |Length| | 124 |Length|
+------+------+------+------+ +------+------+------+------+
| Speed | | Speed |
+------+------+------+------+ +------+------+------+------+
Dynamic Speed TLVs Figure 17: Dynamic Speed TLVs
4.10.3. Heading 4.10.3. Heading
The heading, or direction of travel, is described using one or two The heading, or direction of travel, is described using one or two
angles. Heading uses a type code of 125. angles. Heading uses a type code of 125.
+------+------+ +------+------+
| 125 |Length| | 125 |Length|
+------+------+------+------+ +------+------+------+------+
| Angle | | Angle |
+------+------+------+------+ +------+------+------+------+
| (Optional) Angle | | (Optional) Angle |
+------+------+------+------+ +------+------+------+------+
Dynamic Heading TLVs Figure 18: Dynamic Heading TLVs
4.11. Secondary Map Metadata 4.11. Secondary Map Metadata
The optional "map" URL can be used to provide a user of relative The optional "map" URL can be used to provide a user of relative
location with a visual reference for the location information. This location with a visual reference for the location information. This
document does not describe how the recipient uses the map nor how it document does not describe how the recipient uses the map nor how it
locates the reference or offset within the map. Maps can be simple locates the reference or offset within the map. Maps can be simple
images, vector files, 2-D or 3-D geospatial databases, or any other images, vector files, 2D or 3D geospatial databases, or any other
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:" ([RFC2616]) or "https:" ([RFC2818]) URL MUST be used An "http:" [RFC2616] or "https:" [RFC2818] URL MUST be used unless
unless the entity creating the PIDF-LO is able to ensure that the entity creating the PIDF-LO is able to ensure that authorized
authorized recipients of this data are able to use other URI schemes. recipients of this data are able to use other URI schemes. A "type"
A "type" attribute MUST be present and specifies the kind of map the attribute MUST be present and specifies the kind of map the URL
URL points to. Map types are specified as MIME media types as points to. Map types are specified as MIME media types as recorded
recorded in the IANA Media Types registry. For example <map in the IANA Media Types registry, for example, <map type="image/png">
type="image/png">https://www.example.com/floorplans/123South/floor-2< https://www.example.com/floorplans/123South/floor-2</map>.
/map>.
In binary, the map type is a separate TLV from the map URL. The In binary, the map type is a separate TLV from the map URL. The
media type uses a type code of 126; the URL uses a type code of 127. media type uses a type code of 126; the URL uses a type code of 127.
+------+------+------+------+------+-- --+------+ +------+------+------+------+------+------+------+
| 126 |Length| Map Media Type ... | 126 |Length| Map Media Type ...
+------+------+------+------+------+-- --+------+ +------+------+------+------+------+------+------+
| 127 |Length| Map Image URL ... | 127 |Length| Map Image URL ...
+------+------+------+------+------+-- --+------+ +------+------+------+------+------+------+------+
Map URL TLVs Figure 19: Map URL TLVs
Note that the binary form restricts data to 255 octets. This Note that the binary form restricts data to 255 octets. This
restriction could be problematic for URLs in particular. restriction could be problematic for URLs in particular.
Applications that use the XML form, but cannot guarantee that a Applications that use the XML form, but cannot guarantee that a
binary form won't be used, are encouraged to limit the size of the binary form won't be used, are encouraged to limit the size of the
URL to fit within this restriction. URL to fit within this restriction.
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
skipping to change at page 20, line 16 skipping to change at page 22, line 19
o The unit of measure used o The unit of measure used
This document provides elements that allow for a mapping between the This document provides elements that allow for a mapping between the
local coordinate reference system used for the relative location and local coordinate reference system used for the relative location and
the coordinate reference system used for the map where they are not the coordinate reference system used for the map where they are not
the same. the same.
4.11.2.1. Map Reference Point Offset 4.11.2.1. Map Reference Point Offset
This optional element identifies the coordinates of the reference This optional element identifies the coordinates of the reference
point as it appears in the map. This value is measured in a map-type point as it appears in the map. This value is measured in a map-
dependent manner, using the coordinate system of the map. type-dependent manner, using the coordinate system of the map.
For image maps, coordinates start from the upper left corner and For image maps, coordinates start from the upper left corner, and
coordinates are first counted by column with positive values to the coordinates are first counted by column with positive values to the
right; then rows are counted with positive values toward the bottom right; then, rows are counted with positive values toward the bottom
of the image. For such an image, the first item is columns, the of the image. For such an image, the first item is columns, the
second rows and any third value applies to any third dimension used second rows, and any third value applies to any third dimension used
in the image coordinate space. in the image coordinate space.
The <offset> element contains 2 (or 3) coordinates similar to a GML The <offset> element contains 2 (or 3) coordinates similar to a GML
"pos". For example: <pos>. For example:
<offset> 2670.0 1124.0 1022.0</offset> <offset> 2670.0 1124.0 1022.0</offset>
Map Reference Point Example XML
The map reference point uses a type code of 129. The map reference point uses a type code of 129.
+------+------+ +------+------+
| 129 |Length| | 129 |Length|
+------+------+------+------+ +------+------+------+------+
| Coordinate-1 | | Coordinate-1 |
+------+------+------+------+ +------+------+------+------+
| Coordinate-2 | | Coordinate-2 |
+------+------+------+------+ +------+------+------+------+
| (3D-only) Coordinate-3 | | (3D-only) Coordinate-3 |
+------+------+------+------+ +------+------+------+------+
Map Reference Point Coordinates TLV Figure 20: Map Reference Point Coordinates TLV
If omitted, a value containing all zeros is assumed. If the If omitted, a value containing all zeros is assumed. If the
coordinates provided contain fewer values than are needed, the first coordinates provided contain fewer values than are needed, the first
value from the set is applied in place of any absent values. Thus, value from the set is applied in place of any absent values. Thus,
if a single value is provided, that value is used for Coordinate-2 if a single value is provided, that value is used for Coordinate-2
and Coordinate-3 (if required). If two values are provided and three and Coordinate-3 (if required). If two values are provided and three
are required, the value of Coordinate-1 is used in place of are required, the value of Coordinate-1 is used in place of
Coordinate-3. Coordinate-3.
4.11.2.2. Map Orientation 4.11.2.2. Map Orientation
The map orientation includes the orientation of the map direction in The map orientation includes the orientation of the map direction in
relation to the Earth. Map orientation is expressed relative to the relation to the Earth. Map orientation is expressed relative to the
orientation of the relative coordinate system. This means that map orientation of the relative coordinate system. This means that map
orientation with respect to WGS84 North is the sum of the orientation orientation with respect to WGS84 North is the sum of the orientation
field, plus any orientation included in a dynamic portion of the field and any orientation included in a dynamic portion of the
reference location. Both values default to zero if no value is reference location. Both values default to zero if no value is
specified. specified.
This type uses a single precision floating point value of degrees This type uses a single-precision floating-point value of degrees
relative to North. relative to North.
In XML, the <orientation> element contains a single floating point In XML, the <orientation> element contains a single floating-point
value, example <orientation>67.00</orientation>. In TLV form map value, for example, <orientation>67.00</orientation>. In TLV form,
orientation uses the code 130: map orientation uses the code 130:
+------+------+------+------+------+------+ +------+------+------+------+------+------+
| 130 |Length| Angle | | 130 |Length| Angle |
+------+------+------+------+------+------+ +------+------+------+------+------+------+
Map Orientation TLV Figure 21: Map Orientation TLV
4.11.2.3. Map Scale 4.11.2.3. Map Scale
The optional map scale describes the relationship between the units The optional map scale describes the relationship between the units
of measure used in the map, relative to the meters unit used in the of measure used in the map, relative to the meters unit used in the
relative coordinate system. relative coordinate system.
This type uses a sequence of IEEE 754 [IEEE.754] single precision This type uses a sequence of IEEE 754 [IEEE.754] single-precision
floating point values to represent scale as a sequence of numeric floating-point values to represent scale as a sequence of numeric
values. The units of these values are dependent on the type of map, values. The units of these values are dependent on the type of map
and could for example be pixels per meter for an image. and could, for example, be pixels per meter for an image.
A scaling factor is provided for each axis in the coordinate system. A scaling factor is provided for each axis in the coordinate system.
For a two-dimensional coordinate system, two values are included to For a two-dimensional coordinate system, two values are included to
allow for different scaling along the x and y axes independently. allow for different scaling along the x and y axes independently.
For a three-dimensional coordinate system, three values are specified For a three-dimensional coordinate system, three values are specified
for the x, y and z axes. Decoders can determine the number of for the x, y, and z axes. Decoders can determine the number of
scaling factors by examining the length field. scaling factors by examining the length field.
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 a single scale value, or MAY In XML, the <scale> element MAY contain a single scale value or MAY
contain 2 (or 3) values in XML list form. In TLV form, scale uses a contain 2 (or 3) values in XML list form. In TLV form, scale uses a
type code of 131. The length of the TLV determines how many scale type code of 131. The length of the TLV determines how many scale
values are present: values are present:
+------+------+------+------+------+------+ +------+------+------+------+------+------+
| 131 |Length| Scale(s) ... | 131 |Length| Scale(s) ...
+------+------+------+------+------+------+ +------+------+------+------+------+------+
Map Scale TLV Figure 22: 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 Figure 23: Map Example
5. Examples 5. Examples
The examples in this section combine elements from [RFC3863], The examples in this section combine elements from [RFC3863],
[RFC4119], [RFC4479], [RFC5139], and [OGC.GeoShape]. [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"
skipping to change at page 26, line 4 skipping to change at page 28, line 6
| 127 | http://maps.example.com/3400Wacker/A6 | | 127 | http://maps.example.com/3400Wacker/A6 |
| | | | | |
| 129 | 0.0 4120.0 | | 129 | 0.0 4120.0 |
| | | | | |
| 130 | 113.0 | | 130 | 113.0 |
| | | | | |
| 131 | 10.6 | | 131 | 10.6 |
+--------+-------------------------------------------------+ +--------+-------------------------------------------------+
6. Schema Definition 6. Schema Definition
Note: The pattern value for "mimeType" has been folded onto multiple
lines. Whitespace has been added to conform to comply with Note: The pattern value for "mimeType" has been folded onto
document formatting restrictions. Extra whitespace around the multiple lines. Whitespace has been added to conform to comply
line endings MUST be removed before using this schema. with document formatting restrictions. Extra whitespace around
the line endings MUST be removed before using this schema.
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema <xs:schema
xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative" xmlns:rel="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:relative" targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:relative"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<!-- [[NOTE TO RFC-EDITOR: Please replace all instances of the URL
'http://ietf.org/rfc/rfcXXXX.txt' with the URL of published
document and remove this note.]] -->
<xs:annotation> <xs:annotation>
<xs:appinfo <xs:appinfo
source="urn:ietf:params:xml:schema:pidf:geopriv10:relative"> source="urn:ietf:params:xml:schema:pidf:geopriv10:relative">
Relative Location for PIDF-LO Relative Location for PIDF-LO
</xs:appinfo> </xs:appinfo>
<xs:documentation source="http://ietf.org/rfc/rfcXXXX.txt"> <xs:documentation source="http://ietf.org/rfc/rfc7035.txt">
This schema defines a location representation that allows for This schema defines a location representation that allows for
the description of locations that are relative to another. the description of locations that are relative to another.
An optional map reference is also defined. An optional map reference is also defined.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
<xs:import namespace="http://www.opengis.net/gml"/> <xs:import namespace="http://www.opengis.net/gml"/>
<xs:element name="relative-location" type="rel:relativeType"/> <xs:element name="relative-location" type="rel:relativeType"/>
skipping to change at page 28, line 19 skipping to change at page 30, line 18
&quot;([!#-\[\]-~]|[\t ]*|\\[\t !-~])*&quot;))*"/> &quot;([!#-\[\]-~]|[\t ]*|\\[\t !-~])*&quot;))*"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="doubleList"> <xs:simpleType name="doubleList">
<xs:list itemType="xs:double"/> <xs:list itemType="xs:double"/>
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
xml schema relative-location
7. Security Considerations 7. Security Considerations
This document describes a data format. To a large extent, security This document describes a data format. To a large extent, security
properties of this depend on how this data is used. properties of this depend on how this data is used.
Privacy for location data is typically important. Adding relative Privacy for location data is typically important. Adding relative
location may increase the precision of the location, but does not location may increase the precision of the location but does not
otherwise alter its privacy considerations, which are discussed in otherwise alter its privacy considerations, which are discussed in
[RFC4119]. [RFC4119].
The map URL provided in a relative location could accidentally reveal The map URL provided in a relative location could accidentally reveal
information if a Location Recipient uses the URL to acquire the map. information if a Location Recipient uses the URL to acquire the map.
The coverage area of a map, or parameters of the URL itself, could The coverage area of a map, or parameters of the URL itself, could
provide information about the location of a Target. In combination provide information about the location of a Target. In combination
with other information that could reveal the set of potential Targets with other information that could reveal the set of potential Targets
that the Location Recipient has location information for, acquiring a that the Location Recipient has location information for, acquiring a
map could leak significant information. In particular, it is map could leak significant information. In particular, it is
important to note that the Target and Location Recipient are often important to note that the Target and Location Recipient are often
the same entity. the same entity.
Access to map URLs MUST be secured with TLS [RFC5246] (that is, Access to map URLs MUST be secured with TLS [RFC5246] (that is,
restricting the map URL to be an https URI), unless the map URL restricting the map URL to be an https URI), unless the map URL
cannot leak information about the Target's location. This restricts cannot leak information about the Target's location. This restricts
information about the map URL to the entity serving the map request. information about the map URL to the entity serving the map request.
If the map URL conveys more information about a target than a map If the map URL conveys more information about a Target than a map
server is authorized to receive, that URL MUST NOT be included in the server is authorized to receive, that URL MUST NOT be included in the
PIDF-LO. PIDF-LO.
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". This shares a page, entitled "Civic and Relative Parameters". This shares a page, titled "Civic Address Types
Location Parameters" with the existing "Civic Address Types Registry Registry" with the existing "Civic Address Types (CAtypes)" registry.
(CAtypes)" registry. As defined in [RFC5226], this new registry As defined in [RFC5226], this new registry operates under "IETF
operates under "IETF Review" rules. 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 (RLtype): 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
which describes the value in sufficient detail so that that describes the value in sufficient detail so that
interoperability between independent implementations is possible. interoperability between independent implementations is possible.
Values requested to be assigned into this registry MUST NOT conflict Values requested to be assigned into this registry MUST NOT conflict
with values assigned in the "Civic Address Types Registry (CAtypes)" with values assigned in the "Civic Address Types (CAtypes)" registry
registry or vice versa, unless the IANA considerations section for or vice versa, unless the IANA Considerations section for the new
the new value explicitly overrides this prohibition and the document value explicitly overrides this prohibition and the document defining
defining the value describes how conflicting TLV codes will be the value describes how conflicting TLV codes will be interpreted by
interpreted by implementations. To ensure this, the CAtypes entries implementations. To ensure this, the CAtypes entries are explicitly
are explicitly reserved in the initial values table below. Those reserved in the initial values table below. Those reserved entries
reserved entries can be changed, but only with caution as explained can be changed, but only with caution, as explained here.
here.
To make this clear for future users of the registry, the following To make this clear for future users of the registry, the following
note is added to the "Civic Address Types Registry (CAtypes)": The note is added to the "Civic Address Types (CAtypes)" registry:
registration of new values should be accompanied by a corresponding
reservation in the "Relative Location Parameters" registry. The registration of new values should be accompanied by a
corresponding reservation in the Relative Location Parameters
registry.
Similarly, the "Relative Location Parameters" registry bears the Similarly, the "Relative Location Parameters" registry bears the
note: The registration of new values should be accompanied by a note:
corresponding reservation in the "Civic Address Types Registry
(CAtypes)" registry. The registration of new values should be accompanied by a
corresponding reservation in the Civic Address Types (CAtypes)
registry.
The values defined are: The values defined are:
+--------+----------------------------------------+-----------+ +--------+----------------------------------------+-----------+
| RLtype | description | Reference | | RLtype | description | Reference |
+--------+----------------------------------------+-----------+ +--------+----------------------------------------+-----------+
| 0-40 | RESERVED by CAtypes registry | this RFC | | 0-40 | RESERVED by CAtypes registry | RFC 7035 &|
| 128 | | & RFC4776 | | 128 | | RFC 4776 |
+--------+----------------------------------------+-----------+ +--------+----------------------------------------+-----------+
| 111 | relative location reference | this RFC | | 111 | relative location reference | RFC 7035 |
| 113 | relative location shape 2D point | this RFC | | 113 | relative location shape 2D point | RFC 7035 |
| 114 | relative location shape 3D point | this RFC | | 114 | relative location shape 3D point | RFC 7035 |
| 115 | relative location shape circular | this RFC | | 115 | relative location shape circular | RFC 7035 |
| 116 | relative location shape spherical | this RFC | | 116 | relative location shape spherical | RFC 7035 |
| 117 | relative location shape elliptical | this RFC | | 117 | relative location shape elliptical | RFC 7035 |
| 118 | relative location shape ellipsoid | this RFC | | 118 | relative location shape ellipsoid | RFC 7035 |
| 119 | relative location shape 2D polygon | this RFC | | 119 | relative location shape 2D polygon | RFC 7035 |
| 120 | relative location shape 3D polygon | this RFC | | 120 | relative location shape 3D polygon | RFC 7035 |
| 121 | relative location shape prism | this RFC | | 121 | relative location shape prism | RFC 7035 |
| 122 | relative location shape arc-band | this RFC | | 122 | relative location shape arc-band | RFC 7035 |
| 123 | relative location dynamic orientation | this RFC | | 123 | relative location dynamic orientation | RFC 7035 |
| 124 | relative location dynamic speed | this RFC | | 124 | relative location dynamic speed | RFC 7035 |
| 125 | relative location dynamic heading | this RFC | | 125 | relative location dynamic heading | RFC 7035 |
| 126 | relative location map type | this RFC | | 126 | relative location map type | RFC 7035 |
| 127 | relative location map URI | this RFC | | 127 | relative location map URI | RFC 7035 |
| 129 | relative location map coordinates | this RFC | | 129 | relative location map coordinates | RFC 7035 |
| 130 | relative location map angle | this RFC | | 130 | relative location map angle | RFC 7035 |
| 131 | relative location map scale | this RFC | | 131 | relative location map scale | RFC 7035 |
+--------+----------------------------------------+-----------+ +--------+----------------------------------------+-----------+
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).
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head> <head>
<title>GEOPRIV Relative Location</title> <title>GEOPRIV Relative Location</title>
</head> </head>
<body> <body>
<h1>Format for representing relative location</h1> <h1>Format for representing relative location</h1>
<h2>urn:ietf:params:xml:ns:pidf:geopriv10:relative</h2> <h2>urn:ietf:params:xml:ns:pidf:geopriv10:relative</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfcXXXX.txt"> <p>See <a href="http://www.rfc-editor.org/rfc/rfc7035.txt">
RFCXXXX</a>.</p> RFC 7035</a>.</p>
</body> </body>
</html> </html>
<!--
[[NOTE TO RFC-EDITOR: Please replace all instances of RFCXXXX
with the number of the published 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:relative URI: urn:ietf:params:xml:schema:pidf:geopriv10:relative
Registratant Contact: IETF, GEOPRIV working group Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org),
(geopriv@ietf.org), Martin Thomson (martin.thomson@skype.net). Martin Thomson (martin.thomson@skype.net)
Schema The XML for this schema is found in Section 6 of this Schema: The XML for this schema is found in Section 6 of this
document. document.
8.4. Geopriv Identifiers Registry 8.4. Geopriv Identifiers Registry
This section registers two URNs for use in identifying relative This section registers two URNs for use in identifying relative
coordinate reference systems. These are added to a new "Geopriv coordinate reference systems. These are added to a new "Geopriv
Identifiers" registry according to the procedures in Section 4 of Identifiers" registry according to the procedures in Section 4 of
[RFC3553]. The "Geopriv Identifiers" registry is entered under the [RFC3553]. The "Geopriv Identifiers" registry is entered under the
"Uniform Resource Name (URN) Namespace for IETF Use" category. "Uniform Resource Name (URN) Namespace for IETF Use" category.
Registrations in this registry follow the IETF Review [RFC5226] Registrations in this registry follow the "IETF Review" [RFC5226]
policy. policy.
Registry name: Geopriv Identifiers Registry name: Geopriv Identifiers
URN Prefix: urn:ietf:params:geopriv: URN Prefix: urn:ietf:params:geopriv:
Specification: RFCXXXX (this document) Specification: RFC 7035 (this document)
Respository: [Editor/IANA note: please include a link to the Repository: http://www.iana.org/assignments/geopriv-identifiers
registry location.]
Index value: Values in this registry are URNs or URN prefixes that Index value: Values in this registry are URNs or URN prefixes that
start with the prefix "urn:ietf:params:geopriv:". Each is start with the prefix "urn:ietf:params:geopriv:". Each is
registered independently. registered independently.
Each registration in the "Geopriv Identifiers" registry requires the Each registration in the "Geopriv Identifiers" registry requires the
following information: following information:
URN The complete URN that is used, or the prefix for that URN. URN: The complete URN that is used or the prefix for that URN.
Description: A summary description for the URN or URN prefix. Description: A summary description for the URN or URN prefix.
Specification: A reference to a specification describing the URN or Specification: A reference to a specification describing the URN or
URN prefix. URN prefix.
Contact: Email for the person or groups making the registration. Contact: Email for the person or groups making the registration.
Index value: As described in [RFC3553], URN prefixes that are Index value: As described in [RFC3553], URN prefixes that are
registered include a description of how the URN is constructed. registered include a description of how the URN is constructed.
This is not applicable for specific URNs. This is not applicable for specific URNs.
The "Geopriv Identifiers" registry has two initial registrations, The "Geopriv Identifiers" registry has two initial registrations,
included in the following sections. included in the following sections.
8.4.1. Registration of Two-Dimentional Relative Coordinate Reference 8.4.1. Registration of Two-Dimensional Relative Coordinate Reference
System URN System URN
This section registers the "urn:ietf:params:geopriv:relative:2d" URN This section registers the "urn:ietf:params:geopriv:relative:2d" URN
in the "Geopriv Identifiers" registry. in the "Geopriv Identifiers" registry.
URN urn:ietf:params:geopriv:relative:2d URN: urn:ietf:params:geopriv:relative:2d
Description: A two-dimensional relative coordinate reference system Description: A two-dimensional relative coordinate reference system
Specification: RFCXXXX (this document) Specification: RFC 7035 (this document)
Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin
Thomson (martin.thomson@skype.net). Thomson (martin.thomson@skype.net)
Index value: N/A. Index value: N/A
8.4.2. Registration of Three-Dimentional Relative Coordinate Reference 8.4.2. Registration of Three-Dimensional Relative Coordinate Reference
System URN System URN
This section registers the "urn:ietf:params:geopriv:relative:3d" URN This section registers the "urn:ietf:params:geopriv:relative:3d" URN
in the "Geopriv Identifiers" registry. in the "Geopriv Identifiers" registry.
URN urn:ietf:params:geopriv:relative:3d URN: urn:ietf:params:geopriv:relative:3d
Description: A three-dimensional relative coordinate reference Description: A three-dimensional relative coordinate reference
system system
Specification: RFCXXXX (this document) Specification: RFC 7035 (this document)
Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin
Thomson (martin.thomson@skype.net). Thomson (martin.thomson@skype.net)
Index value: N/A. Index value: N/A
9. Acknowledgements 9. Acknowledgements
This is the product of a design team on relative location. Besides This document is the product of a design team on relative location.
the authors, this team included: Marc Linsner, James Polk, and James Besides the authors, this team included Marc Linsner, James Polk, and
Winterbottom. James Winterbottom.
10. References 10. References
10.1. Normative References 10.1. Normative References
[Clinger1990]
Clinger, W., "How to Read Floating Point Numbers
Accurately", Proceedings of Conference on Programming
Language Design and Implementation, pp. 92-101, 1990.
[IEEE.754] IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE
Standard 754-2008, August 2008.
[OGC.GML-3.1.1]
Cox, S., Daisey, P., Lake, R., Portele, C., and A.
Whiteside, "Geographic information - Geography Markup
Language (GML)", OpenGIS 03-105r1, April 2004,
<http://portal.opengeospatial.org/files/
?artifact_id=4700>.
[OGC.GeoShape]
Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape
Application Schema for use by the Internet Engineering
Task Force (IETF)", OGC Best Practice 06-142r1, Version:
1.0, April 2007.
[RFC1014] Sun Microsystems, Inc., "XDR: External Data Representation [RFC1014] Sun Microsystems, Inc., "XDR: External Data Representation
standard", RFC 1014, June 1987. standard", RFC 1014, June 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996. November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
IETF URN Sub-namespace for Registered Protocol IETF URN Sub-namespace for Registered Protocol
Parameters", BCP 73, RFC 3553, June 2003. Parameters", BCP 73, RFC 3553, June 2003.
skipping to change at page 34, line 31 skipping to change at page 37, line 46
[RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic [RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic
Host Configuration Protocol Options for Coordinate-Based Host Configuration Protocol Options for Coordinate-Based
Location Configuration Information", RFC 6225, July 2011. Location Configuration Information", RFC 6225, July 2011.
[RFC6848] Winterbottom, J., Thomson, M., Barnes, R., Rosen, B., and [RFC6848] Winterbottom, J., Thomson, M., Barnes, R., Rosen, B., and
R. George, "Specifying Civic Address Extensions in the R. George, "Specifying Civic Address Extensions in the
Presence Information Data Format Location Object (PIDF- Presence Information Data Format Location Object (PIDF-
LO)", RFC 6848, January 2013. LO)", RFC 6848, January 2013.
[OGC.GML-3.1.1]
Cox, S., Daisey, P., Lake, R., Portele, C., and A.
Whiteside, "Geographic information - Geography Markup
Language (GML)", OpenGIS 03-105r1, April 2004, <http://
portal.opengeospatial.org/files/?artifact_id=4700>.
[OGC.GeoShape]
Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape
Application Schema for use by the Internet Engineering
Task Force (IETF)", OGC Best Practice 06-142r1, Version:
1.0, April 2007.
[IEEE.754]
IEEE, "IEEE Standard for Binary Floating-Point
Arithmetic", IEEE Standard 754-1985, January 2003.
[Clinger1990]
Clinger, W., "How to Read Floating Point Numbers
Accurately", Proceedings of Conference on Programming
Language Design and Implementation pp. 92-101, 1990, <ftp:
//ftp.ccs.neu.edu/pub/people/will/howtoread.ps>.
[WGS84] US National Imagery and Mapping Agency, "Department of [WGS84] US National Imagery and Mapping Agency, "Department of
Defense (DoD) World Geodetic System 1984 (WGS 84), Third Defense (DoD) World Geodetic System 1984 (WGS 84), Third
Edition ", NIMA TR8350.2, January 2000. Edition", NIMA TR8350.2, January 2000.
10.2. Informative References 10.2. Informative References
[RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,
W., and J. Peterson, "Presence Information Data Format W., and J. Peterson, "Presence Information Data Format
(PIDF)", RFC 3863, August 2004. (PIDF)", RFC 3863, August 2004.
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July
2006. 2006.
skipping to change at page 36, line 4 skipping to change at page 39, line 31
EMail: br@brianrosen.net EMail: br@brianrosen.net
Dorothy Stanley Dorothy Stanley
Aruba Networks Aruba Networks
1322 Crossman Ave 1322 Crossman Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
EMail: dstanley@arubanetworks.com EMail: dstanley@arubanetworks.com
Gabor Bajko Gabor Bajko
Nokia Nokia
323 Fairchild Drive 323 Fairchild Drive
Mountain View, CA 94043 Mountain View, CA 94043
US US
EMail: gabor.bajko@nokia.com EMail: gabor.bajko@nokia.com
Allan Thomson Allan Thomson
Cisco Systems, Inc. Lookingglass Cyber Solutions
170 West Tasman Drive 1001 S Kenwood Avenue
San Jose, CA 95134 Baltimore, MD 21224
US US
EMail: althomso@cisco.com EMail: athomson@lgscout.com
 End of changes. 159 change blocks. 
461 lines changed or deleted 454 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/