>I don't agree with this at all.
>
>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.
this conclusion does not support a migration from one version to
another (where one of the primary fields in the original version
(i.e., the datum field) is what's being modified.
I put this to the WG, if they want to have some ver0 clients and some
ver1 clients guaranteeing that *every* ver0 client will have zero
location and zero means to inform anything or anyone that they have
no location.
Given that there is no statement in RFC 3825 like
"If a device does not understand the datum it MUST discard the data."
It's a heck of a time to try and introduce that ideal now.
further, as a matter of pragmatic coding, a non-fully compliant ver0
implementation might not have support for datums other than WGS84,
therefore, might not choose to have such a rigid enforcement of
Martin's rule (of "confused about the datum, delete all location data").
The obvious result will be that fewer existing client implementations
will possess location once the first ver1 server is installed, and
that shouldn't be the goal of anyone - given the main (but by no
means only) driver/motivation is emergency calling.
The practical result will be fewer emergency calls get to the correct PSAP.
James
>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
