RE: [Geopriv] RFC 3825 Updates

From: Brian Rosen ^lt;>
Date: Fri Feb 02 2007 - 07:54:05 EST

Could I ask the chairs to figure out a way to stop this incessant bickering?

I have an opinion about the matter, but so what, we have a lot of opinions.
What we need is a rough consensus on whether 3825 is useful as is, or needs
to be changed.

We have heard all of these arguments over and over, and I don't think we are
changing anyone's mind here.

Maybe we should ask for a hum in Prague. Maybe we should ask for comments
from people who haven't weighed in. Maybe we should seek more outside
experts. But just to continue to have Martin D, Martin T and James W
repeating the same thing over and over, while John S, Marc L and
occasionally Henning (who doesn't need an initial to distinguish him from
any other Henning) repeat the same thing over and over isn't getting us

Oh, just for the record, while I think some of the wording in 3825 was
poorly chosen, I see the value in the resolution parameter, understand how I
use it to construct a PIDF-LO with geoshapes, don't think uncertainty has a
practical value in the DHCP location configuration use case, and don't think
3825 needs to be changed.


From: Henning Schulzrinne []
Sent: Friday, February 02, 2007 4:44 AM
To: Dawson, Martin
Subject: Re: [Geopriv] RFC 3825 Updates

It is common practice to send encodings of real number quantities in
protocols whose inherent precision is constrained by the encoding rules -
conversion to a real quantity assumes proceeding digits are zero. Adding
another parameter to further (artificially?) constrain the protocol's
encoding precision serves no value - it's not something I've seen in other
protocols - and, as above, carries a contradictory interpretation.
I'm curious how you would do this with fixed-point binary numbers, unless
you add a length or mask parameter of some sort.

Geopriv mailing list
Received on Fri, 2 Feb 2007 07:54:05 -0500

This archive was generated by hypermail 2.1.8 : Fri Feb 02 2007 - 07:53:55 EST