RE: iSCSI: BASE64 and numerical values

[Bill Studenmund <wrstuden@wasabisystems.com>]

On Tue, 21 May 2002, Michael Krueger wrote:

> > One thing I haven't figured out how to do is add implicit binary length to
> > the numbers used for CHAP challenges (and possibly others). It's a little
> > bit of semantics (since we define the length for binary strings), but the
> > ones I came up with felt heavy and cumbersome.

Please note I was mistaken about CHAP. It uses strings, so numbers don't
need lengths AFAIK.

> I think we've been making this more complicated than necessary.  Here's what

Probably. :-)

> I think is a relatively simple way to define the implicit lengths of binary
> items that have been represented by hexadecimal or base-64 ASCII strings.
>
> BASE-64 REPRESENTATION OF A BINARY ITEM

[snip]

> HEXADECIMAL REPRESENTATION OF A BINARY ITEM
>
> Suppose that, in analogy with RFC 2045, we limit the number of "input bits"
> to a multiple of eight bits.  Let N be the number of digits in the string

Sounds good. Also, if we don't, when decoding hex strings, you have to get
to the end of the string to figure out if you have an odd or even # of
nibbles. Really messy.

> representation, where N must even.  The binary item's (implicit) length in
> bytes, L, is then given by L = N / 2.
>
> I am not aware of any application in which the length of a binary item is
> not a multiple of eight bits.  (It's certainly not the case for CHAP.)  The
> only other multiple we could support without an explicit length field would
> be multiples of 4 bits; however, this would only work with hex encoding, not
> base64.  I therefore believe it makes sense to limit IMPLICIT binary item
> lengths to multiples of eight bits.  If someone ever introduced a binary
> item whose length were not a multiple of eight bits, it could simply be
> accompanied by second key that functions as an explicit length field.

Sounds good.

Take care,

Bill