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

From: "geopriv issue tracker" <[email-masked]>
Date: Mon, 27 Jul 2009 04:17:14 -0000

#5: Client guidance about the datum field
-----------------------------+----------------------------------------------
 Reporter:  [email-masked]  |        Owner:  [email-masked]          
     Type:  defect           |       Status:  new                       
 Priority:  major            |    Milestone:  draft-ietf-geopriv-3825bis
Component:  rfc3825bis       |      Version:                            
 Severity:  -                |   Resolution:                            
 Keywords:                   |  
-----------------------------+----------------------------------------------
Changes (by [email-masked]):

  * owner:  => [email-masked]

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 27 Jul 2009 12:29:04 -0500

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.

As a side note:

> The resultant location value will be in error up to

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:[email-masked]]
> Sent: Monday, 27 July 2009 6:17 AM
> To: [email-masked]; [email-masked]; Thomson, Martin
> Cc: [email-masked]
> Subject: Re: [geopriv] #5: Client guidance about the datum field
> 
> Ticket URL:
> <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/5#comment:2>

------------------------------------------------------------------------------------------------
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]

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 28 Jul 2009 05:18:40 -0500

At 12:29 PM 7/27/2009, Thomson, Martin wrote:
>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.
>

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

>This is incorrect.  The error results in a shift in the 
>uncertainty/resolution of up to half the size of that uncertainty/resolution.
>
>--Martin
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 28 Jul 2009 06:15:03 -0500

> (i.e., the datum field) is what's being modified.

This is precisely why I objected to the inclusion of the "ver" tag.

> location and zero means to inform anything or anyone that they have

That was the decision that the WG made.  Both Richard and I sent detailed analyses that dealt with this problem from both perspectives.

> It's a heck of a time to try and introduce that ideal now.

But it's necessary.  If you don't understand the datum, then you can't use the data.  What if I decide that longitude zero runs through Moscow?  Other datums in common use result in subtle errors in some areas, very much less subtle in others.

> The practical result will be fewer emergency calls get to the correct

Yes.  Absolutely.

I don't like re-opening issues, because that shatters the illusion of progress.  However, it seems that you weren't across the full ramifications of the decision, so maybe we need to re-open that one.

---

From: [email-masked]
Date: Wed, 29 Jul 2009 10:19:27 +0200

> It's a heck of a time to try and introduce that ideal now.

It's hard to see what other choice a client might have if it doesn't 
understand the specified datum.  It's what we've agreed on for Alex's geo 
URI draft.

Given that you were one of the authors of 3825 can you clarify whether 
this was a deliberate omission or just sloppy specification?

Ray

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 29 Jul 2009 03:53:14 -0500

At 03:19 AM 7/29/2009, [email-masked] wrote:

>understand the specified datum.

no, it actually isn't. We assume it's WGS84 - as it's the most common 
CRS and the one everyone is moving towards, that's the safest way 
forward considering what I say  next.

>It's what we've agreed on for Alex's geo URI draft.

yeah Ray, but he isn't writing a bis that adds the concept of 
versioning the second time around.

If this were (time-machine alert) 2004, then this should have been 
written into 3825. I agree. But it's not 2004 -- and we shouldn't 
knowingly reduce the number of clients that get location they will 
keep without having the ability to inform anyone/thing there's a 
problem. Not when it affects emergency calling, which we all know 
your stance will affect it adversely.

>Given that you were one of the authors of 3825 can you clarify 
>whether this was a deliberate omission or just sloppy specification?

wow -- that's quality Monday morning quarterbacking 5 years later.

Do you really want me to go through all your RFCs and point out 
everything you missed as "sloppy specification design" on a public 
(worldwide) list?

I can - but oh... that's right, you haven't written any RFCs 
according to http://www.rfc-editor.org/rfcsearch.html

Perhaps you shouldn't make you attacks so personal until you've 
written your own RFCs for others to thrash.

James

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 29 Jul 2009 11:06:43 +0200

Moreover this is essentially a compatibility rule - what alternative would you propose as available to the device?

regards

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, July 29, 2009 9:19 AM
To: James M. Polk
Cc: [email-masked]; [email-masked]; Thomson, Martin
Subject: Re: [Geopriv] [geopriv] #5: Client guidance about the datum field

> It's a heck of a time to try and introduce that ideal now.

It's hard to see what other choice a client might have if it doesn't understand the specified datum.  It's what we've agreed on for Alex's geo URI draft.

Given that you were one of the authors of 3825 can you clarify whether this was a deliberate omission or just sloppy specification?

Ray

---

From: [email-masked]
Date: Wed, 29 Jul 2009 11:15:37 +0200

> forward considering what I say  next.

Unfortunately 3825 doesn't say that either.

If that *is* the way forward, that would mitigate the effect of the 
version flags, although one would hope that a trivial "datum = value & 
0x07" will make that unnecessary on future client implementations.

> versioning the second time around.

Agreed.
 
> your stance will affect it adversely.

My stance is based on an (implicit) understanding that clients would 
already suffer this problem if a new datum were introduced in future 
revisions of 3825.

> wow -- that's quality Monday morning quarterbacking 5 years later.

I apologise, that was poorly worded.

> written your own RFCs for others to thrash.

The first one is in the queue and due for publication September.

Ray

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 31 Jul 2009 10:36:39 +0200

Just a couple of reminders:

-The consensus after the virtual interim was the following (http://www.ietf.org/mail-archive/web/geopriv/current/msg07207.html 
):

The bis should provide guidance about what clients should do when they  
receive a datum they do not understand. For example, the document  
could recommend ignoring the bits that are not understood.

-Here's the thread from the last time we discussed this: http://www.ietf.org/mail-archive/web/geopriv/current/msg07090.html

Alissa

On Jul 29, 2009, at 11:15 AM, [email-masked] wrote:

> version flags, although one would hope that a trivial "datum = value  
> & 0x07" will make that unnecessary on future client implementations.
>
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv