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

From: "geopriv issue tracker" <[email-masked]>
Date: Mon, 21 Jun 2010 14:28:10 -0000

#33: Lat/Long and Datum
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:  bernard_aboba@…           
     Type:  defect                     |      Status:  new                       
 Priority:  major                      |   Milestone:  draft-ietf-geopriv-3825bis
Component:  rfc3825bis                 |     Version:  1.0                       
 Severity:  In WG Last Call            |    Keywords:                            
---------------------------------------+------------------------------------
 Comment 1:
 The document is unclear about whether or not the lat/lon values SHOULD or
 MUST be constrained to +-90 / +- 180.
 -- v4 option format says SHOULD for both
 -- Section 2.3 says MUST for lat, SHOULD for lon
 -- v6 option format doesn't specify
 I would suggest changing all of these to MUST, unless you're keeping the
 option formats open to allow for them to be redefined by different datums.

 Comment 2:
 In Section 2.2.1.2, it might be helpful to note that if a v0-only client
 does ignore the datum element and accept the option, then it is probably
 going to interpret it as WGS84, and thus at least get correct coordinate
 values, as long as the server sends WGS84.

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 22 Jun 2010 08:37:27 +0800

Regarding comment 1:

The situation could certainly use some cleaning up.  The v4 description should simply reference Section 2.3.

What is described in 2.3 is consistent with the "bad is better than none" philosophy.  I'm certainly OK with a sender being given a MUST directive, but a receiver needs to know what to do with bad inputs.  At least with longitude, there are cases where wrapping successfully corrects errors.

Text suggestion for comment 2:

OLD:
   ... If the RFC 3825 DHCPv4 client
   does not reject the option and utilizes the location data it will
   most likely assume a datum and interpret the LongUnc/LatUnc/AltUnc
   values as significant digits and apply them to the Latitude,
   Longitude, and Altitude values. The resultant location value will be
   in error up to a full degree of latitude and longitude, and a full
   increment of altitude.  ...
NEW:
   ... 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.  ...

--Martin

p.s. 
  Clamp latitude:
    latitude = max(-90, min(latitude, 90))
  Wrap longitude:
    longitude = (longitude + 180) % 360 - 180

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of geopriv issue tracker
> Sent: Tuesday, 22 June 2010 12:28 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Geopriv] [geopriv] #33: Lat/Long and Datum
> 
> #33: Lat/Long and Datum
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: "geopriv issue tracker" <[email-masked]>
Date: Tue, 22 Jun 2010 06:38:04 -0000

#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/>

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 22 Jun 2010 14:55:36 +0800

Looks good.

> Sent: Tuesday, 22 June 2010 4:38 PM
> Subject: Re: [Geopriv] [geopriv] #33: Lat/Long and Datum
> 
> #33: Lat/Long and Datum
> Ticket URL:
> <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/33#comment:1>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 22 Jun 2010 08:21:10 -0400

Great, thanks.

On Jun 22, 2010, at 2:55 AM, Thomson, Martin wrote:

>> --------------------------------------- 
>> +-------------------------------
>> -----
>> --------------------------------------- 
>> +-------------------------------
>> -----

---

From: "Carl Reed" <[email-masked]>
Date: Tue, 22 Jun 2010 08:31:19 -0600

Seems fine to me.

Carl