Re: [Geopriv] Consensus call: Basis for revisions to RFC 3825

From: James M. Polk ^lt;>
Date: Tue Apr 21 2009 - 02:36:40 EDT

At 08:42 PM 4/20/2009, Richard Barnes wrote:
>Based on the prior thread about the scope of 3825 fixes, it sounds
>like the closest of the three proposed documents


Can you please list the 3 documents you just comments on?

I saw nothing in the "[Geopriv] Signaling versions in 3825bis" thread
that discussed anything but 3825bis.

Are you talking about this thread "[Geopriv] Scope of 3825 fixes"?

If so, I don't like [1], but can live with it *AS* long as it doesn't do [2].

no one yet has given a valid reason why floors need be deprecated.
This is interesting, because this is saying to the WG that someone
has proven that there is harm being done using floors in RFC 3825,
and I don't believe that's the case, so I'd like the chairs to
clarify why this is even up for discussion?

Please do NOT conflate this issue with how a PIDF-LO carries floors

[3] wasn't discussed in SF, and used a different representation of X
and Y, requiring implementers to support more than one way of
encoding and decoding each coordinate. This does not make sense to me.

I am obviously in favor of [4], but this in no way has any backwards
compatibility issues - and I challenge anyone to tell me how it is
not backwards compatible?

They are different, in that [4] also can do a point (but without
everyone's least favorite function: resolution). I believe [1] and
[4] are orthogonal; [4] happens to do a lot more (including
confidence and uncertainty if desired) - and reuses RFC 4776's
(civic) TLV format.


> to what people want is draft-thomson-geopriv-3825bis-03. So I
> would like to put the following question to the group:
>Should the WG document for revisions to RFC 3825 be based on
>Please respond to the list by Monday, 27 April 2009.
>Geopriv mailing list

Geopriv mailing list
Received on Tue, 21 Apr 2009 01:36:40 -0500

This archive was generated by hypermail 2.1.8 : Tue Apr 21 2009 - 02:38:32 EDT