Re: [Geopriv] Direction for draft-ietf-geopriv-binary-lci

"Dawson, Martin" <Martin.Dawson@andrew.com> Mon, 25 February 2008 07:57 UTC

Return-Path: <geopriv-bounces@ietf.org>
X-Original-To: ietfarch-geopriv-archive@core3.amsl.com
Delivered-To: ietfarch-geopriv-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2141728C1E8; Sun, 24 Feb 2008 23:57:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.049
X-Spam-Level: *
X-Spam-Status: No, score=1.049 tagged_above=-999 required=5 tests=[AWL=-1.414, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_65=0.6, MANGLED_TOOL=2.3, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuKEI-3KUIAd; Sun, 24 Feb 2008 23:57:47 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF68A3A6CB2; Sun, 24 Feb 2008 23:57:47 -0800 (PST)
X-Original-To: geopriv@core3.amsl.com
Delivered-To: geopriv@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BFDE3A6CB5 for <geopriv@core3.amsl.com>; Sun, 24 Feb 2008 23:57:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKphzejA1yAm for <geopriv@core3.amsl.com>; Sun, 24 Feb 2008 23:57:45 -0800 (PST)
Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 544D528C19D for <geopriv@ietf.org>; Sun, 24 Feb 2008 23:56:59 -0800 (PST)
X-SEF-Processed: 5_0_0_910__2008_02_25_02_09_11
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 25 Feb 2008 02:09:11 -0600
Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Feb 2008 01:56:42 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 25 Feb 2008 01:56:40 -0600
Message-ID: <EB921991A86A974C80EAFA46AD428E1E0398FD9E@aopex4.andrew.com>
In-Reply-To: <8C19339E-69B9-4B55-8E3C-243F454BA8DB@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Geopriv] Direction for draft-ietf-geopriv-binary-lci
Thread-Index: Ach3ddClllUI4OQBRDe5Hr5xtybDuwAAHN6w
References: <47B1C37E.1080009@bbn.com> <54D3F05B-B4B2-4D19-BC54-7A8B9BEFBCBC@cisco.com> <EB921991A86A974C80EAFA46AD428E1E0398FCAE@aopex4.andrew.com> <8E2C87FA-B24A-4591-B17B-B590613E5266@cisco.com> <EB921991A86A974C80EAFA46AD428E1E0398FCFE@aopex4.andrew.com> <8C19339E-69B9-4B55-8E3C-243F454BA8DB@cisco.com>
From: "Dawson, Martin" <Martin.Dawson@andrew.com>
To: Cullen Jennings <fluffy@cisco.com>
X-OriginalArrivalTime: 25 Feb 2008 07:56:42.0304 (UTC) FILETIME=[F57C3C00:01C87783]
Cc: GEOPRIV <geopriv@ietf.org>
Subject: Re: [Geopriv] Direction for draft-ietf-geopriv-binary-lci
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <http://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:geopriv@ietf.org>
List-Help: <mailto:geopriv-request@ietf.org?subject=help>
List-Subscribe: <http://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: geopriv-bounces@ietf.org
Errors-To: geopriv-bounces@ietf.org

Hi Cullen,

Here's the text from 3825 for LaRes:

" .This value is the number of high-order Latitude bits that should be
   considered valid.  Any bits entered to the right of this limit should
   not be considered valid and might be purposely false, or zeroed by
   the sender.

   The examples in the appendix illustrate that a smaller value in the
   resolution field increases the area within which the device is
   located."

In the example you suggest, you don't have any mechanism to communicate
the 0.01 part using DHCP. You've only got significant digits. Using the
decimal version of 3825, and assuming you wanted to send 20.0, you'd
send something like:

020.000000 with Res set to 4. which is 020.000000 to 020.099999 (let's
say 20.01).

So, yes, you'd be stuck with something between 0 and 100 (99.999...) if
you wanted to enclose your region.

Now, you may have been wanting to apply a typical interpretation of
precision - except that it's usually a half the significance of the
remaining digits.

i.e. 20.0 is 20.00 +/- 0.05 which is 19.05 to 20.05

I don't believe the 3825 text points to that interpretation. But,
nevertheless, this also doesn't give me any power to represent specific
areas because the size of the area isn't coupled to the precision with
which a point is measured. It's certainly not a satisfactory
representation of your 19.09 to 20.01 (I'm prepared to stand corrected
but I think that .a 08 difference in latitude accounts for about 9km) -
or the infinite number of other possible regions that could be anywhere
within that range.

If 3825 *intends* to convey the interpretation that the precision is
plus or minus the maximum value of the remaining "insignificant" digits
then it needs to say so. It doesn't - and, in fact, the example in 3825
is consistent with the "the other digits can be anything"
interpretation.

Regardless, and this is the important thing, there should be no talk of
3825 being useful for conveying "areas" or "regions". Significant digits
(or precision) alone do not have the necessary expressive power to do
this. Since it's not possible for the sender to communicate a specific
region using DHCP, it's really really important that receivers don't
attempt to interpret the received value that way - it's just a point
with significant digit numerators or precision (and it's unclear what
use those are to the receiver). I would actually prefer 3825 to make
this clarification explicitly - currently it leaves readers with the
opposite impression - as does binary-lci.

Cheers,
Martin

-----Original Message-----
From: Cullen Jennings [mailto:fluffy@cisco.com] 
Sent: Monday, 25 February 2008 5:15 PM
To: Dawson, Martin
Cc: Richard Barnes; GEOPRIV
Subject: Re: [Geopriv] Direction for draft-ietf-geopriv-binary-lci


On Feb 24, 2008, at 5:53 PM, Dawson, Martin wrote:
> I'm not sure that there's anything more to be said as far as working  
> through the example.
>
> The range is 15.999 to 16.034
>
> 3825 allows me to encode it as a 34 bit fixed decimal number, with 9  
> bits before the decimal point. The only binary range that completely  
> encloses the target range is 0-32 degrees. The *next smallest* range  
> is 0-16 and that leaves out the upper 0.034 degrees of the  
> region(which is actually the largest part of it). So - the 3825  
> encoding that includes the whole region is:
>
> 0000xxxxx.xxxxxxxxxxxxxxxxxxxxxxxxx with Res set to 4
>
> Of course, you have to put some numbers in the other 21 non- 
> siginficant bits when you populate the fields in the option but, by  
> definition, they are not significant; they can be anything.
>
Let me see if I follow your argument here.... Lets just change the  
example slightly to 19.09 and 20.01 and work in base 10 instead of  
base 2. You are saying that if I wanted to represent the measurement  
20+/-0.01 with significant digits in base 10, I would need to write  
100 because only 0 to 100 fully covered the range 19.09 to 20.01 ? I  
was sort of expecting I could write 20.0


------------------------------------------------------------------------------------------------
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
http://www.ietf.org/mailman/listinfo/geopriv