Re: iSCSI - re-phrase of 4.1

[Mark Bakke <mbakke@cisco.com>]

The problem with not allowing leading zeroes in binary (hex)
encodings is that some keys, such as CHAP_C, are not guaranteed
to always be the same length.  Currently, we get the length
from counting the number of hex digits for the key.  If leading
zeroes are not allowed, this won't work.

Since leading zeroes don't hurt a hex constant anyway (e.g. these
would come after the 0x, so we won't confuse them with octal),
we should allow them so we don't have to introduce length fields.

--
Mark

Luben Tuikov wrote:
> 
> > "THALER,PAT (A-Roseville,ex1)" wrote:
> >
> > hex-constant: unsigned hexadecimal constant described by regu-lar expression "0[xX][0-9a-zA-Z]+"
> > Hexidecimal only uses the alphabet up to F so the regular expression should be:
> > "0[xX][0-9a-fA-F]+"
> 
> Wasn't there some consenus that there will be no extra leading 0, unless
> part of the base identifier (and thus at most one)? Else I can
> put 1e9 zeros like this: 0x0000...03 to be a valid hex const.
> 
> Also why do we need to _restrict_ as to the sign of
> a hex constant. I'm sure that sooner or later it will
> have its applications. If a value cannot be negative
> and a node sent it as negative then the peer will
> reply with Reject or appropriately.
> 
> Isn't all this the whole point of interoperability and
> the use of Reject, et al?
> 
> Thus,
> hex const: 0[xX][1-9A-Fa-f]+[0-9A-Fa-f]*
> 
> And similarly for the others.
> 
> --
> Luben

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054