Re: iSCSI base64 and 12-92

[Martins Krikis <mkrikis@yahoo.com>]

--- Bill Studenmund <wrstuden@wasabisystems.com>
wrote:

> On Thu, 23 May 2002, Julian Satran wrote:
> 
> > If base 64 is neede for large integers there is no
> good reason to test
> > that it is not used for short integers.
> 
> I respectfully disagree. base64 is awkward for
> numbers, as it is not a
> numerical encoding. 

Me too. Base64 should not be allowed for anything
that's currently negotiable in the operational stage.

> At least if the length of the
> number (in octets) is
> variable. 1, 2, 4, and 8 octet numbers are fine. But
> 3, 5, 6, and 7 are
> just plain gross. We have to load them into a
> correspondingly larger data
> type (32 or 64-bit unsigned int as appropriate), and
> then mask off
> unsent bytes. Oh, and if we're on an LE box, we then
> have to byte-swap the
> thing.

That's not really the problem. For encoding a
small number in base64, you byte-swap if necessary,
pass the leading 0-bytes (if any), then run
your regular base64 encoding that operates on strings.
For decoding, you run the decoder (that operates
on strings) first, count the resulting bytes,
move it in your 32-bit or 64-bit register from the
"right end", add 0-bytes (if necessary) on the
left end and byteswap. 

But since we know in advance whether a key can take
just small numerical values or whether it can take
large ones (actually, none do, they all take something
to be looked up in various RFCs, which I doubt will
call them "large numbers" anyway), we don't want
to first check the key for 0b and then run it
through the procedure given above. Just calling
strtoul() is better. For those keys that can
take large number values (even though I'm fairly sure
that what's really needed there are binary strings
happening to represent large numbers),
we'll happily run just base64 decoders (and there
will not be any need to move the result into
32-bit or 64-bit registers or byteswap).

> Julo, have you actually coded a base64 decoder for
> the small (less than
> 2^64) ints we use in the protocol and verified its
> correctness? I will
> admit I haven't but that's because as I worked on
> it, it got very gross.
> And for no discernalbe benefit. Yes, we can do it.
> But I'd rather put the
> effort verifying this would take into making some
> other part of the code
> work well.

A decoder is a decoder, it does work even
on 0-length input. It works on strings, produces
"binary strings". Putting the right number of 
0-bytes to the left and byteswapping should not
go in the decoder, it should be a separate thing,
IMHO. But I also see no benefit in even allowing
the small numbers to be given in any representation
that cannot be thrown at strtoul() as is.

> I think what would be much easier for us is to just
> say that base64 is
> only usable for binary strings. Period.

Agreed.

> If there is a authentication protocol that needs to
> exchange large numbers
> that does not also specify the wire-format for said
> numbers, I suggest
> that for iSCSI we specify that the authentication
> protocol must provide
> the iSCSI negotiation code with a binary string
> representing/containing
> the number. The iSCSI negotiation code then passes
> said string to the
> authentication code on the other side. The code on
> the other side then
> interprets the string as a number.

Absolutely.

> Yes, this is a semantics step. But it means that we
> can get rid of
> exchanging numbers so large that we would really
> like base64 - from
> iscsi's point of view they are binary strings. The
> iscsi infrastructure
> doesn't need to bother with trying to think of them
> as numbers.

Yes. If no, then where are the large numbers that
we're worried about? I don't see any keys defined
as taking large numbers for values yet.

  Martins Krikis, Intel Corp.

Disclaimer: these opinions are mine and may not
            be those of my employer



__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com