iSCSI: RE: iSCSI 4.1 & 4.2

["Michael Krueger" <michael.krueger@windriver.com>]

On Sat, 27 Apr 2002 19:15:07 +0300, Julian Satran wrote:
>
> As binary seems to indicate how a value is going to be stored
> (which is none of the protocol's business :-)) please read
> "numerical" in all the places in my previous note that said
> binary.

I apologize for not making my point more clearly in my earlier messages, but
the whole reason I started this thread is because I believe that binary and
numeric items are different and must be handled as such by implementations
and in the spec.  Although I brought up the issue of conversion from decimal
representation to binary data as an example, the decimal conversion issue
itself is NOT my primary concern.  Here are some general definitions of
binary and numeric items that I hope will make my point:


NUMERIC ITEM

Definition:  An integer represented by a string.

Properties:  *  Numeric items can be signed.  (This is true even if
                all numeric items in the spec are specified as
                unsigned.)
             *  Numeric items have a natural ordering, namely, that
                of the integers they represent:
                    -1 < 4 < 42
                    -0x1 < 0x4 < 0x2a
             *  Number and arrangement of bits in internal
                representation of numeric items does not matter.
             *  Numeric items may have a valid range, but their
                internal representation need not have a specific
                size as long as it is large enough to hold all
                values in the valid range.
             *  Numeric items represented by different numbers of
                digits or bits may equal each other:
                      4 =   04 =   004 = the number four
                    0x4 = 0x04 = 0x004 = the number four

Example:     CHAP_A


BINARY ITEM

Definition:  An ordered sequence of bits represented by a string.

Properties:  *  Binary items have no sign, by definition.
             *  Binary items have no implicit ordering: without
                additional information, it's not possible to say
                one binary item is greater or less than another.
             *  Number and arrangement of bits in internal
                representation of binary items DOES matter.
             *  Size is a property of a binary item.  Unless its
                size is specified by some other mechanism, it must
                be determined from the number of digits in its
                string representation:
                    0x4   = the  4-bit pattern 0100
                    0x04  = the  8-bit pattern 00000100
                    0x004 = the 12-bit pattern 000000000100
             *  In general, binary items of different sizes are NOT
                equal to each other:
                    0x4 <> 0x04 <> 0x004

Example:     CHAP_C


Given these definitions, I have the following comments on the rewritten
sections:

On Sat, 27 Apr 2002 19:38:57 +0300, Julian Satran wrote:
> Here are the rephrased 4.1 & 4.2 for better context:
. . .
> regular-numerical-value :  an unsigned integer less than 2**64
> encoded as a decimal constant, hex constant, or base-64 con-stant
>
> large-numerical-value :  an unsigned integer larger than 2**64-1
> encoded as a hex constant, or base-64 constant
>
> numerical-value: a regular-numerical-value or a large
> numeri-cal-value
>
> numeric-range: two numerical-values separated by a tilde
. . .
> The value offered can be an numerical-value, a numerical-range
> defined by lower and upper value - both integers separated by tilde,
> a a text-value, a boolean-value (Yes or No), or a list of comma
> sepa-rated text-values. A range MAY ONLY be offered if it is
> explicitly allowed for a key. A selected value can be an
> numerical-value, a text-value or a boolean-value.

The fact that the text reads "both integers separated by tilde" suggests the
need for a distinction between binary and numeric items.  A range only makes
sense for numeric items ("integers"), not for binary items.  However, since
no formal distinction is made between binary and numeric items, the wording
above suggests that it is legal to specify the value for a (numeric) key
like CHAP_A in base 64; it also suggests that it is legal to specify a
64-bit value for a (binary) key like CHAP_C in decimal.

Let's examine this last case a little more closely.  There's nothing in the
CHAP RFC (RFC 1994) that specifies an a priori length for the CHAP
challenge, CHAP_C.  Suppose the following unusual CHAP challenge is to be
sent to an iSCSI target:

    CHAP_C=0x00000000deadbeef

In the CHAP RFC, the length of the challenge is specified by the
"Value-Size" byte in the packet, which in this case would be 0x08.  The 8
bytes of the challenge would then be transmitted immediately after the
Value-Size byte.

Unlike the CHAP RFC, the iSCSI spec does not define a mechanism for
specifying the length of the CHAP_C challenge value.  According to the
proposed rewording of the spec, a perverse implementer could take the 64-bit
value above and decide to represent it in decimal, which is perfectly legal:

    CHAP_C=3735928559

Now, what is the length of the CHAP challenge?  Since there's no simple
correspondence between decimal digits and bit positions, it's impossible to
say.  If the leading zeroes in the hexadecimal number above seem too
contrived, consider this:  How do you unambiguously represent the 8-bit
pattern 00000100 in decimal?  4?  04?  004?  Without the addition of an
explicit length field, it's impossible to know how many bits are meant.

The size of a numeric item like CHAP_A is irrelevant and therefore may be
specified in decimal, with or without leading zeroes.  A binary item like
CHAP_C has a size, and without the addition of an explicit size field, only
the hexadecimal and base-64 representations make sense.

In addition to the problem of ambiguity in the decimal representation of
binary items, failure to distinguish numeric and binary items imposes the
additional burden of supporting base-64 representation for all numeric
items.  This is possible, of course, but offers very little value for the
added complexity.

In reality, of course, an implementer will probably have two generic
conversion routines, one for numeric items [probably using strtoul() to
convert a decimal or hexadecimal string representation to a 32-bit unsigned
integer, with overflow detection] and one for binary items (capable of
converting arbitrary-length hexadecimal or base-64 string representation to
a arbitrary-length sequence of up to N bytes, where N = 255 unless otherwise
specified).  The former routine would be used for a key like CHAP_A, and the
latter for a key like CHAP_C.  If somebody tried to specify a base-64 string
for CHAP_A or a decimal string for CHAP_C, I doubt most implementations
would handle this properly . . . nor should they, since neither case is very
likely to happen in reality.

I would just like to see the spec line up a little better with reality.

Michael

--
Michael J. Krueger              mailto:michael.krueger@windriver.com
Wind River Networks                         http://www.windriver.com
500 Wind River Way                               phone: 510-749-2130
Alameda, CA  94501                                 fax: 510-749-2010