[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Photuris // Variable-Precision numbers
I find the treatment of variable-precision numbers still confusing.
The number of significant bits should be the number of bits you need to
look at to determine the number. If the number of significant bits is t,
then the numbers representable range from 0 to 2^{t}-1, inclusive.
The problem is for the case t = 1. It is inconsistent to have no bits in the
value field at all. For t=1, you should be able to represent either 0 or 1.
Size Value Represents (decimal)
0000 0
0001 00 0 *** This is what you want
0001 01 1 *** This is what you want
0002 00 0
0002 01 1
0002 02 2
0002 03 3
0003 00 0
...
0003 07 7
0004 00 0
... and so on...
==============================================================================
Return-Path: <bsimpson@morningstar.com>
Date: Sun, 15 Oct 95 02:23:19 GMT
From: "William Allen Simpson" <bsimpson@morningstar.com>
To: ipsec@ans.net
Subject: Re: Photuris // Variable-Precision numbers
As I said, I had to think about it some more. Sorry, should have gotten
back to you on that, but here is what I actually wrote:
Each variable precision number is composed of two parts.
Size two or four octets. Number of significant bits used
in the Value field. Always transmitted most
significant octet first.
A Size of zero has no Value field; value is zero.
A Size of one has no Value field; value is one.
When the most significant octet is in the range 0
through 254 (0xfe), the field is two octets. Both
octets are used to indicate the size of the Value
field.
When the most significant octet is 255 (0xff), the
field is four octets. The remaining three octets
are used to indicate the size of the Value field.
Value variable. The bits used are right justified and
zero filled on octet boundaries; that is, any unused
bits are in the most significant octet. Always
transmitted most significant octet first.
The shorter forms SHOULD NOT be used when the Size indicates a number
of significant bits which happen to be zero.
> From: rivest@theory.lcs.mit.edu (Ron Rivest)
> Representing a value of one by a Size of one, and no value field, is
> inconsistent with the purpose of the Size field, and rules out the
> possibility of having a Size field of one with a real value field of length
> one. (I am interpreting the Size field to mean the length of the Value
> field only; the 2 bytes of the Size field are not counted.)
>
> What you want is something like (bytes given in hex):
>
> Size Value Represents (decimal)
> 00 0
> 01 00 0
> 01 01 1
> 01 02 2
> ...
> 01 FF 255
> 02 00 00 0
> 02 00 01 1
> ...
> 02 FF FF 65535
> and so on.
>
> Correct?
>
Not quite, the Size is _bits_ not _bytes_:
Size Value Represents (decimal)
0000 0
0001 1
0002 00 0
0002 01 1
0002 02 2
...
0008 01 1 (8 significant bits)
0008 FF 255
0009 0001 1 (9 significant bits)
...
ff223344 00...01 1 (many significant bits ;-)
Bill.Simpson@um.cc.umich.edu
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2