On Jun 22, 2010, at 2:55 AM, Thomson, Martin wrote:
> 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
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
