Subject: Re: [Geopriv] [geopriv] #5: Client guidance about the datum field

From: "geopriv issue tracker" <[email-masked]>
Date: Wed, 11 Nov 2009 05:17:46 -0000

#5: Client guidance about the datum field
-----------------------------+----------------------------------------------
 Reporter:  rbarnes@…        |       Owner:  jmpolk@…                  
     Type:  defect           |      Status:  new                       
 Priority:  major            |   Milestone:  draft-ietf-geopriv-3825bis
Component:  rfc3825bis       |     Version:                            
 Severity:  -                |    Keywords:                            
-----------------------------+----------------------------------------------

Comment(by bernard_aboba@…):

 The proposed text will go into -03 unless I hear an objection.

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

---

From: "geopriv issue tracker" <[email-masked]>
Date: Thu, 12 Nov 2009 03:03:30 -0000

Here is the proposed new text of Section 2.2.1.2:

 2.2.1.2.  Server Version Selection

    A DHCP server that provides location information cannot provide
    options with both v0 and v1 formats in the same response. This is not
    useful since receiving two copies of the same Option (either in the
    same response or a separate response) causes a DHCP client to replace
    the information in the old Option with the information in the new
    Option.

    A server uses configuration to determine which version to send in a
    response. For example, where a mixture of v0 and v1 clients are
    expected, the server could be configured to send v0 or v1 depending
    on configuration (possibly making the choice based on information
    such as the client MAC address). Where few v0 clients are expected,
    the server could be configured to send only v1 responses.  Version 0
    options will provide resolution, while version 1 options will provide
    an area of uncertainty.

    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
    LoRes, LaRes, and AltRes values.  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 LoRes/LaRes/AltRes 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.  This results in a v0-only client either not obtaining
    location information (with no ability to indicate to the server that
    v1 was unsupported), or misinterpreting the option.

    Therefore, in situations where some clients are known to support only
    v0, by default the server SHOULD send a v0 response.  It is also
    RECOMMENDED that DHCPv4 client implementations support version 1, so
    the versioning capability added by this document does not cause
    errors interpreting the latitude, longitude and altitude values.

    Moving forward, clients not understanding a data value MUST assume a
    WGS84 datum (EPSG 4326 or 4979, depending on whether there is an
    altitude value present) and proceed accordingly.  Assuming that a
    less accurate location value is better than none, this ensures that
    some (perhaps less accurate) location is available to the client.

-- 
Ticket URL: <http://zinfandel.levkowetz.com/wg/geopriv/trac/ticket/5#comment:4>
geopriv <http://tools.ietf.org/geopriv/>

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 11 Nov 2009 21:51:28 -0600

Bernard

I noticed an error in what Marc and I provided 
below (way back when) for this AI.

In the last paragraph below, the word "data" 
needs to be replaced with "datum" to make sense.  Sorry for this error.

James

At 09:03 PM 11/11/2009, geopriv issue tracker wrote:
>Ticket URL: 
><http://zinfandel.levkowetz.com/wg/geopriv/trac/ticket/5#comment:4>

---

From: "geopriv issue tracker" <[email-masked]>
Date: Thu, 12 Nov 2009 04:44:21 -0000

#5: Client guidance about the datum field
-----------------------------+----------------------------------------------
 Reporter:  rbarnes@…        |        Owner:  jmpolk@…                  
     Type:  defect           |       Status:  closed                    
 Priority:  major            |    Milestone:  draft-ietf-geopriv-3825bis
Component:  rfc3825bis       |      Version:                            
 Severity:  -                |   Resolution:  fixed                     
 Keywords:                   |  
-----------------------------+----------------------------------------------
Changes (by bernard_aboba@…):

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

Comment:

 From James:

 I noticed an error in what Marc and I provided below (way back when) for
 this AI.

-- 
Ticket URL: <http://zinfandel.levkowetz.com/wg/geopriv/trac/ticket/5#comment:5>
geopriv <http://tools.ietf.org/geopriv/>