geopriv@ietf.org: Re: [Geopriv] [geopriv] #33: Lat/Long and Datum

#33: Lat/Long and Datum
---------------------------------------+------------------------------------
Reporter: bernard_aboba@… | Owner: bernard_aboba@…
Type: defect | Status: closed
Priority: major | Milestone: draft-ietf-geopriv-3825bis
Component: rfc3825bis | Version: 1.0
Severity: In WG Last Call | Resolution: fixed
Keywords: |
---------------------------------------+------------------------------------
Changes (by bernard_aboba@…):

* status: new => closed
* resolution: => fixed

Comment:

Recommended changes:

2.1. DHCPv6 Option

The DHCPv6 [RFC3315] option format is as follows:

Code: GEOCONF_GEODETIC (16 bits).

OptLen: Option Length (16). This option has a fixed length, so
that the value of this octet will always be 16.

LatUnc: 6 bits. When the Ver field = 1, this field represents
latitude uncertainty. The contents of this field is
undefined for other values of the Ver field.

Latitude: a 34 bit fixed point value consisting of 9 bits of
integer and 25 bits of fraction, interpreted as
described in Section 2.3.

LongUnc: 6 bits. When the Ver field = 1, this field represents
longitude uncertainty. The contents of this field is
undefined for other values of the Ver field.

Longitude: a 34 bit fixed point value consisting of 9 bits of
integer and 25 bits of fraction, interpreted as
described in Section 2.3.

AType: Altitude Type (4 bits).

AltUnc: 6 bits. When the Ver field = 1, this field represents
altitude uncertainty. The contents of this field is
undefined for other values of the Ver field.

Altitude: A 30 bit value defined by the AType field.

Ver: The Ver field is two bits, providing for four potential
versions. This specification defines the behavior of
version 1. The Ver field is always located at the same
offset from the beginning of the option, regardless of
the version in use.

Res: The Res field which is 3 bits, is reserved. These bits
have been used by [IEEE-802.11y], but are not defined
within this specification.

Datum: 3 bits. The Map Datum used for the coordinates given in
this Option.

2.2. DHCPv4 Option

The DHCPv4 option format is as follows:

Code: 8 bits. The code for the DHCPv4 option (123).

Length: 8 bits. The length of the DHCPv4 option, in octets.
For versions 0 and 1, the option length is 16.

LatUnc: 6 bits. When the Ver field = 0, this field represents
latitude resolution. When the Ver field = 1,
this field represents latitude uncertainty.

Latitude: a 34 bit fixed point value consisting of 9 bits of
signed integer and 25 bits of fraction, interpreted
as described in Section 2.3.

LongUnc: 6 bits. When the Ver field = 0, this field represents
longitude resolution. When the Ver field = 1,
this field represents longitude uncertainty.

Longitude: a 34 bit fixed point value consisting of 9 bits of
signed integer and 25 bits of fraction, interpreted
as described in Section 2.3.

AType: Altitude Type (4 bits).

AltUnc: 6 bits. When the Ver field = 0, this field represents
altitude resolution. When the Ver field = 1,
this field represents altitude uncertainty.

Altitude: A 30 bit value defined by the AType field.

Ver: The Ver field is two bits, providing for four potential
versions. This specification defines the behavior of
version 0 (originally specified in [RFC3825]) as well as
version 1. The Ver field is always located at the same
offset from the beginning of the option, regardless of
the version in use.

Res: The Res field which is 3 bits, is reserved. These bits
have been used by [IEEE-802.11y], but are not defined
within this specification.

Datum: 3 bits. The Map Datum used for the coordinates given in
this Option.

Section 2.2.1 new text:

An RFC 3825 DHCPv4 client that receives a version 1 option, as
defined in this document, will either reject the Option or will not
understand the additions to the Datum field and will misinterpret the
LongUnc, LatUnc, and AltUnc values.

If the RFC 3825 DHCPv4 client does not reject the option and utilizes
the location data it will most likely assume a datum. Assuming one
of the RFC 3825 datums causes correct interpretation of
Latitude/Longitude/Altitude values. The values for
LongUnc/LatUnc/AltUnc are mistakenly interpreted as representing
significant digits. The resultant location value will be in error up
to a full degree of latitude and longitude, and a full increment of
altitude.

This results in a version 0-only DHCPv4 client either not obtaining
location information (with no ability to indicate to the server that
version 1 was unsupported), or misinterpreting the option.
Therefore, in situations where some DHCPv4 clients are known to
support only version 0, by default the DHCPv4 server SHOULD send a
version 0 response.

2.3. Latitude and Longitude Fields

The Latitude and Longitude values in this specification are encoded
as 34 bit, twos complement, fixed point values with 9 integer bits
and 25 fractional bits. The exact meaning of these values is
determined by the datum; the description in this section applies to
the datums defined in this document.

New datums MUST define the way that the 34 bit values and the
respective 6 bit uncertainties are interpreted. This document uses
the same definition for all datums it specifies.

Latitude values encoded by the DHCP server MUST be constrained to the
range from -90 to +90 degrees. Location consumers MUST be prepared
to normalize values outside this range. Values outside the range are
normalized by clamping (e.g. values less than -90 degrees are set to
-90; values greater than 90 degrees are set to +90). Positive
latitudes are north of the equator and negative latitudes are south
of the equator.

Longitude values encoded by the DHCP server MUST be normalized to the
range from -180 to +180 degrees. Location consumers MUST be prepared
to normalize values outside this range. Values outside the range are
normalized by wrapping (e.g. adding or subtracting 360 until they
fall within the range of -180 to 180). Positive longitudes are east
of the Prime Meridian (Greenwich) and negative (2s complement)
longitudes are west of the Prime Meridian.

When encoding, Latitude and Longitude values are rounded to the
nearest 34-bit binary representation. This imprecision is considered
acceptable for the purposes to which this form is intended to be
applied and is ignored when decoding.

--
Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/33#comment:1>
geopriv <http://tools.ietf.org/geopriv/>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

geopriv@ietf.org

Monday, June 21, 2010

Re: [Geopriv] [geopriv] #33: Lat/Long and Datum

Followers

Blog Archive

Contributors