RE: [Geopriv] Resolution in RFC3825

From: Thomson, Martin ^lt;Martin.Thomson@andrew.com>
Date: Thu Jul 13 2006 - 10:49:25 EDT

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:mlinsner@cisco.com]
> 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:James.Winterbottom@andrew.com]
> Sent: Wednesday, July 12, 2006 7:35 PM
> To: Marc Linsner
> Cc: Ecrit@ietf.org
> 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:mlinsner@cisco.com]
> Sent: Thursday, 13 July 2006 9:22 AM
> To: Winterbottom, James
> Cc: Ecrit@ietf.org
> 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:mlinsner@cisco.com]
> Sent: Wednesday, 12 July 2006 11:34 PM
> To: Winterbottom, James; 'Stark, Barbara'; 'Andrew
Newton';
> 'Rohan Mahy'
> Cc: 'Rosen, Brian'; Ecrit@ietf.org
> 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:James.Winterbottom@andrew.com]
> Sent: Tuesday, July 11, 2006 11:39 PM
> To: Stark, Barbara; Andrew Newton; Rohan Mahy
> Cc: Rosen, Brian; Ecrit@ietf.org
> 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
> Geopriv@ietf.org
> 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
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Thu, 13 Jul 2006 09:49:25 -0500

This archive was generated by hypermail 2.1.8 : Thu Jul 13 2006 - 11:22:31 EDT