Re: iSCSI - re-phrase of 4.1

["Julian Satran" <Julian_Satran@il.ibm.com>]

The issue of leading 0s was brought up in the context of decimal numbers.
In the context of hex or base 64 encoding for binaries (not numbers) the leading 0 has value - it implies length -
0x0015 is different from 0x15.

Julo

Luben Tuikov <luben@splentec.com> Sent by: owner-ips@ece.cmu.edu 05/03/2002 05:18 PM Please respond to iSCSI; Please respond to Luben Tuikov

To:        "THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>         cc:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu         Subject:        Re: iSCSI - re-phrase of 4.1

> "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