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

From: Thomson, Martin ^lt;Martin.Thomson@andrew.com>
Date: Tue Jun 22 2010 - 02:55:36 EDT

Looks good.

> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of geopriv issue tracker
> Sent: Tuesday, 22 June 2010 4:38 PM
> To: bernard_aboba@hotmail.com
> Cc: geopriv@ietf.org
> Subject: 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:
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Option Code (TBD) | OptLen (16) |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | LatUnc | Latitude +
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Lat (cont'd) | LongUnc | Longitude +
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Longitude (cont'd) | AT | AltUnc | Altitude +
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Altitude (cont'd) |Ver| Res |Datum|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> 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:
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Code 123 | Length | LatUnc | Latitude +
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Latitude (cont'd) | LongUnc | +
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Longitude |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | AType | AltUnc | Altitude +
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Alt.(cont'd) |Ver| Res |Datum|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> 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 mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Received on Tue, 22 Jun 2010 14:55:36 +0800

This archive was generated by hypermail 2.1.8 : Tue Jun 22 2010 - 02:54:06 EDT