Datum is information that tells a device how to interpret the data. If the device does not know of or support the datum, then it has no basis upon which to interpret the data.
If a device does not understand the datum it MUST discard the data.
If datum=4 is specified for locations on the moon, interpreting this as WGS84 would lead to errors.
As a side note:
> The resultant location value will be in error up to
> a full degree of latitude and longitude, and a full increment of altitude.
This is incorrect. The error results in a shift in the uncertainty/resolution of up to half the size of that uncertainty/resolution.
--Martin
> -----Original Message-----
> From: geopriv issue tracker [mailto:trac@tools.ietf.org]
> Sent: Monday, 27 July 2009 6:17 AM
> To: jmpolk@cisco.com; bernard_aboba@hotmail.com; Thomson, Martin
> Cc: geopriv@ietf.org
> Subject: Re: [geopriv] #5: Client guidance about the datum field
>
> #5: Client guidance about the datum field
> -----------------------------+-----------------------------------------
> -----
> Reporter: rbarnes@bbn.com | Owner: jmpolk@cisco.com
> Type: defect | Status: new
> Priority: major | Milestone: draft-ietf-geopriv-
> 3825bis
> Component: rfc3825bis | Version:
> Severity: - | Resolution:
> Keywords: |
> -----------------------------+-----------------------------------------
> -----
> Changes (by bernard_aboba@hotmail.com):
>
> * owner: => jmpolk@cisco.com
>
>
> Comment:
>
> Proposed resolution (from James & Marc):
>
> "The choice of a DHC server sending a version 0 or version 1 option
> to a client is an administrative choice. A domain administrator will
> decide which version fits their environment best, providing
> resolution (version 0) or an area of uncertainty (version 1). An RFC
> 3825 client that receives a version 1 option, as defined in this
> document, will not understand the additions to the datum field and
> will misinterpret the LoRes, LaRes, and AltRes values. If the RFC
> 3825 client continues to utilize 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.
>
> Implementations are RECOMMENDED to upgrade to be [RFC3825bis]
> compatible so the versioning capability added by this document does
> not cause errors interpreting the latitude, longitude and altitude
> values.
>
> Moving forward, any datum value not understood MUST assume a WGS84
> datum (EPSG 4326 or 4979, depending on if there is an altitude value
> present) and proceed accordingly. This allows that some location,
> although less accurate, is available to the client. This requirement
> is based on the premise that a less accurate location value is better
> than no location value."
>
> --
> Ticket URL:
> <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/5#comment:2>
> geopriv <http://tools.ietf.org/geopriv/>
>
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
