Subject: FW: [Geopriv] Resolution in RFC3825

From: "Marc Linsner" <[email-masked]>
Date: Thu, 13 Jul 2006 14:17:37 -0400

{resent as I never saw it hit the list)

Martin,

I remember the previous thread, I did not start this one.

Your conclusion in the previous thread was 'LCI resolution/uncertainty is
not useful'.

I believe what I wrote below agrees with the uncertainty portion of your
conclusion, but disagrees with your conclusion about resolution.  My
explanation is the understanding of the GeoPriv WG and the IESG which
approved RFC3825.

Again, if you can show a use case where RFC3825 is desired and uncertainty
needs to be conveyed, please identify it.

-Marc-

> -----Original Message-----
> From: Thomson, Martin [mailto:[email-masked]]
> Sent: Thursday, July 13, 2006 10:49 AM
> To: Marc Linsner; Winterbottom, James
> Cc: GEOPRIV
> Subject: RE: [Geopriv] Resolution in RFC3825
> 
> I don't think that we need to re-open this discussion - I have 
> explained previously why the argument below is wrong; I suggest that 
> you read the archives.
> 
> > -----Original Message-----
> > From: Marc Linsner [mailto:[email-masked]]
> > Sent: Friday, 14 July 2006 12:31 AM
> > To: Winterbottom, James
> > Cc: 'GEOPRIV'
> > Subject: [Geopriv] Resolution in RFC3825
> > 
> > [list and subject changed to reflect topic]
> > 
> > James,
> > 
> > Appendix A in the draft-ietf-geopriv-pdif-lo-profile-04.txt
> is wrong.
> > RFC3825 represents a point, and uncertainty is never mentioned, nor 
> > intended to be represented in LCI.  I am still searching
> for use cases
> > were
> RFC3825
> > may apply that uncertainty is normally expressed.
> > 
> > The fixed-point 2s-complement binary value in RFC3825 is
> also fixed at
> 34
> > bits of length.  If the value one is attempting to
> represent does not
> > match the 34-bit resolution allowed for, then it is prudent
> to express
> > the desired resolution.  If this feature were not
> available, it would
> > lead one to believe that 39.6 equals 39.60000000, which as
> you know,
> > is bad in the application of geo coordinates.
> > 
> > A side symptom of expressing resolution also filled the
> very desired
> > requirement in GeoPriv of the ability to 'fuzz up' the location.
> Using
> > the
> > example above, 39.6 implies 39.60000000 to 39.69999999,
> which at this
> > resolution covers a large territory.  This ability to represent this
> large
> > territory satisfied this Geopriv requirement.  The
> requirement was to
> > simply fuzz the location value, not express exact fuzziness, hence 
> > resolution
> is
> > not suitable to express uncertainty.
> > 
> > I hope this helps,
> > 
> > -Marc-
> > 
> > ________________________________
> > 
> > 	From: Winterbottom, James [mailto:[email-masked]]
> > 	Sent: Wednesday, July 12, 2006 7:35 PM
> > 	To: Marc Linsner
> > 	Cc: [email-masked]
> > 	Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New
> > phonebcpdraftwassubmitted)
> > 
> > 
> > 
> > 	Marc you are missing the point entirely.
> > 
> > 	No one is required to convey uncertainty, but RFC-3825
> stipulates
> > quite clearly how the values returned in option 123 are to be
> interpreted.
> > 
> > 	The shape described by the encoding in RFC-3825 is either a 4
> sided
> > polygon, or a prism, unless you use the maximum resolution, hence 
> > uncertainty is part of the interpretation and mobility
> > 
> > 	has absolutely nothing to do with it.
> > 
> > 
> > 
> > 	Are you suggesting that the way to interpret the values in
> RFC-3825
> > is not normative?
> > 
> > 
> > 
> > 	________________________________
> > 
> > 		From: Marc Linsner [mailto:[email-masked]]
> > 	Sent: Thursday, 13 July 2006 9:22 AM
> > 	To: Winterbottom, James
> > 	Cc: [email-masked]
> > 	Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New
> > phonebcpdraftwassubmitted)
> > 
> > 
> > 
> > 	Please identify the non-mobile application(s) that use geo and
> are
> > required to convey uncertainty.
> > 
> > 
> > 
> > 	-Marc-
> > 
> > 
> > 
> > 
> > 
> > 		Marc, this has nothing to do with mobile. It is to do
> with
> > the potential for massive errors to be introduced by the encoding 
> > technique used in RFC-3825. Please see appendix A of
> PIDF-LO profile
> > for more details.
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 		________________________________
> > 
> > 				From: Marc Linsner
> > [mailto:[email-masked]]
> > 		Sent: Wednesday, 12 July 2006 11:34 PM
> > 		To: Winterbottom, James; 'Stark, Barbara'; 'Andrew
> Newton';
> > 'Rohan Mahy'
> > 		Cc: 'Rosen, Brian'; [email-masked]
> > 		Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New
> > phonebcpdraftwassubmitted)
> > 
> > 
> > 
> > 		As stated in RFC3825, it is applicable to
> non-mobile environments.
> > 
> > 
> > 
> > 		-Marc-
> > 
> > 
> > 
> > 			________________________________
> > 
> > 						From: Winterbottom,
> James
> > [mailto:[email-masked]]
> > 			Sent: Tuesday, July 11, 2006 11:39 PM
> > 			To: Stark, Barbara; Andrew Newton; Rohan Mahy
> > 			Cc: Rosen, Brian; [email-masked]
> > 			Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit]
> New
> > phonebcpdraftwassubmitted)
> > 
> > 
> > 
> > 			I would be very cautious about recommending the
> use
> > of RFC-3825 encoding to report emergency locations given the issues
> raised
> > at IETF-65 in Dallas that are yet to be adequately resolved. In NENA
> we
> > put
> > a caveat around its use to the effect that location
> provided in this
> > manner must be regarded as a point only, and that encodings for 
> > resolution
> must
> > be
> > ignored.
> > 
> > 
> > 
> > 			Cheers
> > 
> > 			James
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >
> --------------------------------------------------------------
> ----------
> --
> > --
> > --------------------
> > 			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]
> > 
> > 			*****
> > 
> > 			The information transmitted is intended only for
> the
> > person or entity to which it is addressed and may contain
> confidential,
> > proprietary, and/or privileged material. Any review, retransmission, 
> > dissemination or other use of, or taking of any action in reliance
> upon
> > this
> > information by persons or entities other than the intended recipient
> is
> > prohibited. If you received this in error, please contact the sender
> and
> > delete the material from all computers. 162
> > 
> > 
> > 
> >
> --------------------------------------------------------------
> ----------
> --
> > --
> > --------------------
> > 		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]
> > 
> > 
> > 
> >
> --------------------------------------------------------------
> ----------
> --
> > --
> > --------------------
> > 	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
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/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
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv