draft-ietf-geopriv-relative-location-05.txt   draft-ietf-geopriv-relative-location-06.txt 
GEOPRIV M. Thomson GEOPRIV M. Thomson
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track B. Rosen Intended status: Standards Track B. Rosen
Expires: December 07, 2013 Neustar Expires: January 16, 2014 Neustar
D. Stanley D. Stanley
Aruba Networks Aruba Networks
G. Bajko G. Bajko
Nokia Nokia
A. Thomson A. Thomson
Cisco Systems, Inc. Cisco Systems, Inc.
June 05, 2013 July 15, 2013
Relative Location Representation Relative Location Representation
draft-ietf-geopriv-relative-location-05 draft-ietf-geopriv-relative-location-06
Abstract Abstract
This document defines an extension to PIDF-LO (RFC4119) for the This document defines an extension to PIDF-LO (RFC4119) for the
expression of location information that is defined relative to a expression of location information that is defined relative to a
reference point. The reference point may be expressed as a geodetic reference point. The reference point may be expressed as a geodetic
or civic location, and the relative offset may be one of several or civic location, and the relative offset may be one of several
shapes. An alternative binary representation is described. 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)
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 07, 2013. This Internet-Draft will expire on January 16, 2014.
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
skipping to change at page 2, line 24 skipping to change at page 2, line 24
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Relative Location . . . . . . . . . . . . . . . . . . . . . . 7 4. Relative Location . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Relative Coordinate System . . . . . . . . . . . . . . . 7 4.1. Relative Coordinate System . . . . . . . . . . . . . . . 7
4.2. Placement of XML Elements . . . . . . . . . . . . . . . . 7 4.2. Placement of XML Elements . . . . . . . . . . . . . . . . 8
4.3. Binary Format . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Binary Format . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Distances and Angles . . . . . . . . . . . . . . . . . . 8 4.4. Distances and Angles . . . . . . . . . . . . . . . . . . 9
4.5. Value Encoding . . . . . . . . . . . . . . . . . . . . . 8 4.5. Value Encoding . . . . . . . . . . . . . . . . . . . . . 9
4.6. Relative Location Restrictions . . . . . . . . . . . . . 9 4.6. Relative Location Restrictions . . . . . . . . . . . . . 9
4.7. Baseline TLVs . . . . . . . . . . . . . . . . . . . . . . 9 4.7. Baseline TLVs . . . . . . . . . . . . . . . . . . . . . . 9
4.8. Reference TLV . . . . . . . . . . . . . . . . . . . . . . 9 4.8. Reference TLV . . . . . . . . . . . . . . . . . . . . . . 9
4.9. Shapes . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.9. Shapes . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.9.1. Point . . . . . . . . . . . . . . . . . . . . . . . . 10 4.9.1. Point . . . . . . . . . . . . . . . . . . . . . . . . 10
4.9.2. Circle or Sphere Shape . . . . . . . . . . . . . . . 11 4.9.2. Circle or Sphere Shape . . . . . . . . . . . . . . . 11
4.9.3. Ellipse or Ellipsoid Shape . . . . . . . . . . . . . 12 4.9.3. Ellipse or Ellipsoid Shape . . . . . . . . . . . . . 12
4.9.4. Polygon or Prism Shape . . . . . . . . . . . . . . . 14 4.9.4. Polygon or Prism Shape . . . . . . . . . . . . . . . 14
4.9.5. Arc-Band Shape . . . . . . . . . . . . . . . . . . . 16 4.9.5. Arc-Band Shape . . . . . . . . . . . . . . . . . . . 16
4.10. Dynamic Location TLVs . . . . . . . . . . . . . . . . . . 18 4.10. Dynamic Location TLVs . . . . . . . . . . . . . . . . . . 18
4.10.1. Orientation . . . . . . . . . . . . . . . . . . . . 18 4.10.1. Orientation . . . . . . . . . . . . . . . . . . . . 18
4.10.2. Speed . . . . . . . . . . . . . . . . . . . . . . . 18 4.10.2. Speed . . . . . . . . . . . . . . . . . . . . . . . 18
4.10.3. Heading . . . . . . . . . . . . . . . . . . . . . . 18 4.10.3. Heading . . . . . . . . . . . . . . . . . . . . . . 18
4.11. Secondary Map Metadata . . . . . . . . . . . . . . . . . 18 4.11. Secondary Map Metadata . . . . . . . . . . . . . . . . . 19
4.11.1. Map URL . . . . . . . . . . . . . . . . . . . . . . 19 4.11.1. Map URL . . . . . . . . . . . . . . . . . . . . . . 19
4.11.2. Map Coordinate Reference System . . . . . . . . . . 19 4.11.2. Map Coordinate Reference System . . . . . . . . . . 19
4.11.3. Map Example . . . . . . . . . . . . . . . . . . . . 21 4.11.3. Map Example . . . . . . . . . . . . . . . . . . . . 22
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Civic PIDF with Polygon Offset . . . . . . . . . . . . . 22 5.1. Civic PIDF with Polygon Offset . . . . . . . . . . . . . 22
5.2. Geo PIDF with Circle Offset . . . . . . . . . . . . . . . 23 5.2. Geo PIDF with Circle Offset . . . . . . . . . . . . . . . 24
5.3. Civic TLV with Point Offset . . . . . . . . . . . . . . . 24 5.3. Civic TLV with Point Offset . . . . . . . . . . . . . . . 25
6. Schema Definition . . . . . . . . . . . . . . . . . . . . . . 25 6. Schema Definition . . . . . . . . . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
8.1. Relative Location Registry . . . . . . . . . . . . . . . 28 8.1. Relative Location Registry . . . . . . . . . . . . . . . 29
8.2. URN Sub-Namespace Registration . . . . . . . . . . . . . 29 8.2. URN Sub-Namespace Registration . . . . . . . . . . . . . 30
8.3. XML Schema Registration . . . . . . . . . . . . . . . . . 30 8.3. XML Schema Registration . . . . . . . . . . . . . . . . . 30
8.4. Registration of Relative Coordinate Reference System URNs 30 8.4. Geopriv Identifiers Registry . . . . . . . . . . . . . . 31
8.4.1. Registration of 2D CRS URN . . . . . . . . . . . . . 31 8.4.1. Registration of Two-Dimentional Relative Coordinate
8.4.2. Registration of 3D CRS URN . . . . . . . . . . . . . 31 Reference System URN . . . . . . . . . . . . . . . . 32
8.5. CAtype Registration . . . . . . . . . . . . . . . . . . . 31 8.4.2. Registration of Three-Dimentional Relative Coordinate
Reference System URN . . . . . . . . . . . . . . . . 32
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.1. Normative References . . . . . . . . . . . . . . . . . . 32 10.1. Normative References . . . . . . . . . . . . . . . . . . 33
10.2. Informative References . . . . . . . . . . . . . . . . . 34 10.2. Informative References . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
This document describes a format for the expression of relative This document describes a format for the expression of relative
location information. location information.
A relative location is formed of a reference location, plus a A relative location is formed of a reference location, plus a
relative offset from that reference location. The reference location relative offset from that reference location. The reference location
can be represented in either civic or geodetic form. The reference can be represented in either civic or geodetic form. The reference
location can also have dynamic components such as velocity. The location can also have dynamic components such as velocity. The
relative offset is specified in meters using a Cartesian coordinate relative 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 illustration. to a document that contains a map, floorplan or other spatially
Applications could use this information to display the relative oriented information. Applications could use this information to
location. Additional fields allow the map to be oriented and scaled display the relative location. Additional fields allow the map to be
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
skipping to change at page 4, line 17 skipping to change at page 4, line 17
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. A "baseline" location is included location values plus an offset. The two location values, named
outside of the <relative-location> element. The baseline location is "baseline" and "reference", combine to form the origin of the offset.
visible to a client that does not understand relative location (i.e., The final, relative location is described relative to this reference
it ignores the <relative-location> element). point.
..--"""--..
.-' `-.
,' `.
/ Reference \
/ o \
| \ |
| \ |
| \ |
\ _\| /
`. x .' \_ Baseline
`._ Relative _.' Location
`--..___..--'
The "baseline" location is included outside of the <relative-
location> element. The baseline location is visible to a client that
does not understand relative location (i.e., it ignores the
<relative-location> element).
A client that does understand relative location will interpret the 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. A relative location is determined, which gives the location. This document defines both a "reference" location, which
reference location for the relative offset. serves as a refinement of the baseline location and the starting
point; and an offset, which describes the location of the Target
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 how much to put into the "reference" location. For example, all and how much to put into the "reference" location. For example, the
location information could be put inside the <relative-location>
element, so that clients that do not understand relative location
would receive no location information at all. Alternatively, the
baseline location value could be precise enough to specify a building baseline location value could be precise enough to specify a building
that contains the relative location, and the reference location could that contains the relative location, and the reference location could
specify a point within the building from which the offset is specify a point within the building from which the offset is
measured. measured.
The baseline location SHOULD be general enough to describe both the
reference location and the relative location (reference plus offset).
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. of the client. The baseline location is intended to carry a location
that encompasses both the reference location and the relative
..--"""--.. location (i.e., the reference location plus offset).
.-' `-.
,' `.
/ Reference \
/ o \
| \ |
| \ |
| \ |
\ _\| /
`. x .' \_ Baseline
`._ Relative _.' Location
`--..___..--'
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 either as a
geodetic location [OGC.GeoShape] or a civic address [RFC4776]. If geodetic location [OGC.GeoShape] or a civic address [RFC4776]. If
skipping to change at page 7, line 45 skipping to change at page 8, line 5
The binary form uses different shape type identifiers for 2D and 3D The binary form uses different shape type identifiers for 2D and 3D
shapes. shapes.
Dynamic location information [RFC5962] in the baseline or reference Dynamic location information [RFC5962] in the baseline or reference
location alters relative coordinate system. The resulting Cartesian location alters relative coordinate system. The resulting Cartesian
coordinate system axes are rotated so that the "y" axis is oriented coordinate system axes are rotated so that the "y" axis is oriented
along the direction described by the <orientation> element. The along the direction described by the <orientation> element. The
coordinate system also moves as described by the <speed> and coordinate system also moves as described by the <speed> and
<heading> elements. <heading> elements.
The single timestamp included in the tuple (or equivalent) element
applies to all location elements, including all three components of a
relative location: baseline, reference and relative. This is
particularly important when there are dynamic components to these
items. A location generator is responsible for ensuring the
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 <location-
info> like a normal PIDF-LO. Relative location adds a new <relative- info> like a normal PIDF-LO. Relative location adds a new <relative-
location> element to <location-info>. Within <relative-location>, location> element to <location-info>. Within <relative-location>,
<reference> and <offset> elements are described. Within <offset> are <reference> and <offset> elements are described. Within <offset> are
the shape elements described below. This document extends PIDF-LO as the shape elements described below. This document extends PIDF-LO as
described in [RFC6848]. described in [RFC6848].
4.3. Binary Format 4.3. Binary Format
skipping to change at page 9, line 4 skipping to change at page 9, line 19
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
[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. bits and 23 fractional bits. This uses the interchange format
defined in [IEEE.754] and Section 3.6 of [RFC1014], that is: sign,
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
More than one relative shape MUST NOT be included in either a PIDF-LO More than one relative shape MUST NOT be included in either a PIDF-LO
or TLV encoding of location for a given reference point. or TLV encoding of location for a given reference point.
skipping to change at page 9, line 33 skipping to change at page 9, line 51
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 TLV
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 reference locations are combined in a reference TLV. This TLV is
contains civic address TLVs (if the baseline was a civic) or geo TLVs identified with the code 111 and contains civic address TLVs (if the
(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 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
skipping to change at page 18, line 12 skipping to change at page 18, line 12
Arc-Band Encoding 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.
+------+------+ +------+------+
| 123 |Length| | 123 |Length|
+------+------+------+------+ +------+------+------+------+
| Angle | | Angle |
+------+------+------+------+ +------+------+------+------+
| (Optional) Angle | | (Optional) Angle |
+------+------+------+------+ +------+------+------+------+
Dynamic Orientation TLVs 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.
+------+------+ +------+------+
| 124 |Length| | 124 |Length|
+------+------+------+------+ +------+------+------+------+
| Speed | | Speed |
+------+------+------+------+ +------+------+------+------+
Dynamic Speed TLVs 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. angles. Heading uses a type code of 125.
+------+------+ +------+------+
| 125 |Length| | 125 |Length|
+------+------+------+------+ +------+------+------+------+
| Angle | | Angle |
+------+------+------+------+ +------+------+------+------+
| (Optional) Angle | | (Optional) Angle |
+------+------+------+------+ +------+------+------+------+
Dynamic Heading TLVs Dynamic Heading TLVs
skipping to change at page 19, line 23 skipping to change at page 19, line 26
In XML, the map is a <map> element defined within <relative-location> In XML, the map is a <map> element defined within <relative-location>
and contains the URL. The URL is encoded as a UTF-8 encoded string. and contains the URL. The URL is encoded as a UTF-8 encoded string.
An "http:" or "https:" URL MUST be used unless the entity creating An "http:" or "https:" URL MUST be used unless the entity creating
the PIDF-LO is able to ensure that authorized recipients of this data the PIDF-LO is able to ensure that authorized recipients of this data
are able to use other URI schemes. A "type" attribute MUST be are able to use other URI schemes. A "type" attribute MUST be
present and specifies the kind of map the URL points to. Map types present and specifies the kind of map the URL points to. Map types
are specified as MIME media types as recorded in the IANA Media Types are specified as MIME media types as recorded in the IANA Media Types
registry. For example <map type="image/png">https://www.example.com/ registry. For example <map type="image/png">https://www.example.com/
floorplans/123South/floor-2</map>. floorplans/123South/floor-2</map>.
In binary, the map type is a separate TLV from the map URL: 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.
+------+------+------+------+------+-- --+------+ +------+------+------+------+------+-- --+------+
| 126 |Length| Map Media Type ... | 126 |Length| Map Media Type ...
+------+------+------+------+------+-- --+------+ +------+------+------+------+------+-- --+------+
| 127 |Length| Map Image URL ... | 127 |Length| Map Image URL ...
+------+------+------+------+------+-- --+------+ +------+------+------+------+------+-- --+------+
Map URL TLVs Map URL TLVs
Note that the binary form restricts data to 255 octets. This
restriction could be problematic for URLs in particular.
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
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
map described by a 3-D geometric model of the building may contain a map described by a 3-D geometric model of the building may contain a
complete CRS description in it. For some kinds of maps, typically complete CRS description in it. For some kinds of maps, typically
described as images, the CRS used within the map must define the described as images, the CRS used within the map must define the
following: following:
o The CRS origin o The CRS origin
o The CRS axes used and their orientation o The CRS axes used and their orientation
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
skipping to change at page 20, line 19 skipping to change at page 20, line 27
dependent manner, using the coordinate system of the map. 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 Map Reference Point Example XML
The map referenc point uses a type code of 129.
+------+------+ +------+------+
| 128 |Length| | 129 |Length|
+------+------+------+------+ +------+------+------+------+
| Coordinate-1 | | Coordinate-1 |
+------+------+------+------+ +------+------+------+------+
| Coordinate-2 | | Coordinate-2 |
+------+------+------+------+ +------+------+------+------+
| (3D-only) Coordinate-3 | | (3D-only) Coordinate-3 |
+------+------+------+------+ +------+------+------+------+
Map Reference Point Coordinates TLV Map Reference Point Coordinates TLV
skipping to change at page 21, line 6 skipping to change at page 21, line 19
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, plus 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: value, example <orientation>67.00</orientation>. In TLV form map
orientation uses the code 130:
+------+------+------+------+------+------+ +------+------+------+------+------+------+
| 129 |Length| Angle | | 130 |Length| Angle |
+------+------+------+------+------+------+ +------+------+------+------+------+------+
Map Orientation TLV 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.
skipping to change at page 21, line 42 skipping to change at page 22, line 12
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, the length of contain 2 (or 3) values in XML list form. In TLV form, scale uses a
the TLV determines how many scale values are present: type code of 131. The length of the TLV determines how many scale
values are present:
+------+------+------+------+------+------+ +------+------+------+------+------+------+
| 130 |Length| Scale(s) ... | 131 |Length| Scale(s) ...
+------+------+------+------+------+------+ +------+------+------+------+------+------+
Map Scale TLV Map Scale TLV
4.11.3. Map Example 4.11.3. Map Example
An example of expressing a map is: An example of expressing a map is:
<rel:map> <rel:map>
<rel:url type="image/jpeg"> <rel:url type="image/jpeg">
http://example.com/map.jpg http://example.com/map.jpg
</rel:url> </rel:url>
<rel:offset>200 210</rel:offset> <rel:offset>200 210</rel:offset>
<rel:orientation>68</rel:orientation> <rel:orientation>68</rel:orientation>
<rel:scale>2.90 -2.90</rel:scale> <rel:scale>2.90 -2.90</rel:scale>
</rel:map> </rel:map>
skipping to change at page 25, line 22 skipping to change at page 25, line 41
| 26 | Suite 213 | | 26 | Suite 213 |
| | | | | |
| 28 | Reception Area | | 28 | Reception Area |
| | | | | |
| 115 | 100 70 | | 115 | 100 70 |
| | | | | |
| 126 | image/png | | 126 | image/png |
| | | | | |
| 127 | http://maps.example.com/3400Wacker/A6 | | 127 | http://maps.example.com/3400Wacker/A6 |
| | | | | |
| 128 | 0.0 4120.0 | | 129 | 0.0 4120.0 |
| | | | | |
| 129 | 113.0 | | 130 | 113.0 |
| | | | | |
| 130 | 10.6 | | 131 | 10.6 |
+--------+-------------------------------------------------+ +--------+-------------------------------------------------+
6. Schema Definition 6. Schema Definition
<?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 <!-- [[NOTE TO RFC-EDITOR: Please replace all instances of the URL
skipping to change at page 28, line 5 skipping to change at page 28, line 25
xml schema relative-location 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 fractional bits in IEEE 754 [IEEE.754] floating point values can The map URL provided in a relative location could accidentally reveal
be used as a covert channel. For values of either zero or infinity, information if a Location Recipient uses the URL to acquire the map.
non-zero fraction bits could be used to convey information. If the The coverage area of a map, or parameters of the URL itself, could
presence of covert channels is not desired then the fractional bits provide information about the location of a Target. In combination
MUST be set to zero. There is no need to represent NaN (not a with other information that could reveal the set of potential Targets
number) in this encoding. that the Location Recipient has location information for, acquiring a
map could leak significant information. In particular, it is
important to note that the Target and Location Recipient are often
the same entity.
8. IANA Considerations 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
cannot leak information about the Target's location. This restricts
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
server is authorized to receive, that URL MUST NOT be included in the
PIDF-LO.
8. IANA Considerations
8.1. Relative Location Registry 8.1. Relative Location Registry
This document creates a new registry called "Relative Location This document creates a new registry called "Relative Location
Parameters". As defined in [RFC5226], this registry operates under Parameters". As defined in [RFC5226], this registry operates under
"IETF Review" rules. "IETF Review" rules.
The content of this registry includes: The content of this registry includes:
Relative Location Code: Numeric identifier, assigned by IANA. Relative Location Code: Numeric identifier, assigned by IANA.
Brief description: Short description identifying the meaning of the Brief description: Short description identifying the meaning of the
element. element.
Reference to published specification: A stable reference to an RFC Reference to published specification: A stable reference to an RFC
which describes the value in sufficient detail so that which 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 CAtypes registry or vice versa, unless with values assigned in the CAtypes registry or vice versa, unless
the IANA considerations section for the new value explicitly the IANA considerations section for the new value explicitly
overrides this prohibition and the document defining the value overrides this prohibition and the document defining the value
describes how conflicting TLV codes will be interpreted by describes how conflicting TLV codes will be interpreted by
implementations. implementations. To ensure this, the CAtypes entries are explicitly
reserved in the initial values table below. Those reserved entries
can be changed, but only with caution as explained here.
The values defined are: The values defined are:
+--------+----------------------------------------+-----------+ +--------+----------------------------------------+-----------+
| RLtype | description | Reference | | RLtype | description | Reference |
+--------+----------------------------------------+-----------+ +--------+----------------------------------------+-----------+
| 0-40 | RESERVED by CAtypes registry | this RFC |
| 128 | | & RFC4776 |
+--------+----------------------------------------+-----------+
| 111 | relative location reference | this RFC | | 111 | relative location reference | this RFC |
| 113 | relative location shape 2D point | this RFC | | 113 | relative location shape 2D point | this RFC |
| 114 | relative location shape 3D point | this RFC | | 114 | relative location shape 3D point | this RFC |
| 115 | relative location shape circular | this RFC | | 115 | relative location shape circular | this RFC |
| 116 | relative location shape spherical | this RFC | | 116 | relative location shape spherical | this RFC |
| 117 | relative location shape elliptical | this RFC | | 117 | relative location shape elliptical | this RFC |
| 118 | relative location shape ellipsoid | this RFC | | 118 | relative location shape ellipsoid | this RFC |
| 119 | relative location shape 2D polygon | this RFC | | 119 | relative location shape 2D polygon | this RFC |
| 120 | relative location shape 3D polygon | this RFC | | 120 | relative location shape 3D polygon | this RFC |
| 121 | relative location shape prism | this RFC | | 121 | relative location shape prism | this RFC |
| 122 | relative location shape arc-band | this RFC | | 122 | relative location shape arc-band | this RFC |
| 123 | relative location dynamic orientation | this RFC | | 123 | relative location dynamic orientation | this RFC |
| 124 | relative location dynamic speed | this RFC | | 124 | relative location dynamic speed | this RFC |
| 125 | relative location dynamic heading | this RFC | | 125 | relative location dynamic heading | this RFC |
| 126 | relative location map type | this RFC | | 126 | relative location map type | this RFC |
| 127 | relative location map URI | this RFC | | 127 | relative location map URI | this RFC |
| 128 | relative location map coordinates | this RFC | | 129 | relative location map coordinates | this RFC |
| 129 | relative location map angle | this RFC | | 130 | relative location map angle | this RFC |
| 130 | relative location map scale | this RFC | | 131 | relative location map scale | this RFC |
+--------+----------------------------------------+-----------+ +--------+----------------------------------------+-----------+
8.2. URN Sub-Namespace Registration 8.2. URN Sub-Namespace Registration
This document registers a new XML namespace, as per the guidelines in This document registers a new XML namespace, as per the guidelines in
[RFC3688]). [RFC3688]).
URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative
Registrant Contact:IETF, GEOPRIV working group (geopriv@ietf.org), Registrant Contact:IETF, GEOPRIV working group (geopriv@ietf.org),
skipping to change at page 30, line 11 skipping to change at page 31, line 4
with the number of the published with the number of the published
document and remove this note.]] --> document and remove this note.]] -->
END END
8.3. XML Schema Registration 8.3. XML Schema Registration
This section registers an XML schema as per the procedures in This section registers an XML schema as per the procedures in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:pidf:geopriv10:relativeLocation URI: urn:ietf:params:xml:schema:pidf:geopriv10:relativeLocation
Registratant Contact: IETF, GEOPRIV working group Registratant Contact: IETF, GEOPRIV working group
(geopriv@ietf.org), Martin Thomson (martin.thomson@skype.net). (geopriv@ietf.org), Martin Thomson (martin.thomson@skype.net).
Schema The XML for this schema is the entirety of Section 6 of this Schema The XML for this schema is the entirety of Section 6 of this
document. document.
8.4. Registration of Relative Coordinate Reference System URNs 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]. Registrations in this registry follow the IETF Review [RFC3553]. The "Geopriv Identifiers" registry is entered under the
[RFC5226] policy. "Uniform Resource Name (URN) Namespace for IETF Use" category.
Registrations in this registry follow the IETF Review [RFC5226]
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: RFCXXXX (this document)
Respository: [Editor/IANA note: please include a link to the Respository: [Editor/IANA note: please include a link to the
registry location.] registry location.]
skipping to change at page 31, line 12 skipping to change at page 32, line 5
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 2D CRS URN 8.4.1. Registration of Two-Dimentional Relative Coordinate Reference
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: RFCXXXX (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 3D CRS URN 8.4.2. Registration of Three-Dimentional Relative Coordinate Reference
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: RFCXXXX (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.5. CAtype Registration
This section adds a new entry to the CAtype registry defined by
[RFC6848].
Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:relative
Local Name: REL
Description: Relative location from a reference point
Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
(geopriv@ietf.org).
Specification: RFCXXXX
Schema: urn:ietf:params:xml:schema:pidf:geopriv10:relativeLocation
Type: A
9. Acknowledgements 9. Acknowledgements
This is the product of a design team on relative location. Besides This is the product of a design team on relative location. Besides
the authors, this team included: Marc Linsner, James Polk, and James the authors, this team included: Marc Linsner, James Polk, and James
Winterbottom. Winterbottom.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC1014] Sun Microsystems, Inc., "XDR: External Data Representation
standard", RFC 1014, June 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An [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.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
skipping to change at page 32, line 50 skipping to change at page 33, line 34
Configuration Information", RFC 4776, November 2006. Configuration Information", RFC 4776, November 2006.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for Presence Information Data Format Location Format for Presence Information Data Format Location
Object (PIDF-LO)", RFC 5139, February 2008. Object (PIDF-LO)", RFC 5139, February 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO) Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations", Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009. RFC 5491, March 2009.
[RFC5962] Schulzrinne, H., Singh, V., Tschofenig, H., and M. [RFC5962] Schulzrinne, H., Singh, V., Tschofenig, H., and M.
Thomson, "Dynamic Extensions to the Presence Information Thomson, "Dynamic Extensions to the Presence Information
Data Format Location Object (PIDF-LO)", RFC 5962, Data Format Location Object (PIDF-LO)", RFC 5962,
September 2010. September 2010.
 End of changes. 61 change blocks. 
112 lines changed or deleted 144 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/