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:
>#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@…):
> 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/>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
