iSCSI: BASE64 and numerical values

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

Yes for regular numerical values it makes sense. We will have to keep it for large numerical values used for cryptography.  Julo
----- Forwarded by Julian Satran/Haifa/IBM on 05/18/2002 11:18 AM -----

Bill Studenmund <wrstuden@wasabisystems.com> Sent by: owner-ips@ece.cmu.edu 05/15/2002 05:46 AM Please respond to Bill Studenmund

To:        <ips@ece.cmu.edu>         cc:                 Subject:        iSCSI: BASE64 and numerical values

I was looking at the latest draft (Julian's 12-90.pdf), and thinking about
this. I see some problems, and I'd like to suggest we DROP support for
using base64 to encode numberical values. Definitely keep it for binary
strings, just not numbers.

The reason I suggest this is base64 encodes arbitrary-length binary
streams. To consider that stream a number, we need to add some more
structure. "Network Byte Order" is the first thing that comes to mind.
We've got ntohs() and ntohl(), also known as ntoh16() and ntoh32() on some
systems, which will save the day.

Unfortunatlely since the base64 stream can be arbitrary length, we'd need
something like ntoh24() too. We could after all have used just three bytes
to encode that number, especially since the spec discourages leading
zero-characters (encoded as 'A's).

Also, since regular-numerical-values can go up to just shy of 2**64, in
principle the only thing saving us from needing ntoh40(), ntoh48(), and
ntoh56() is the fact that I don't think we have any numerical parameters
that have valid values that large.

So I'd like to suggest we disallow using base64 to encode numbers.
Byte-swapping an arbitrary-length byte stream seems really messy.
Alternatively, I'd like to suggest we constrain base64-encoded numbers to
be 1, 2, 4, or 8 bytes long when decoded, and to be in network byte order.

Sorry for not catching this last week when we were looking at section 4.1.

Thoughts?

Take care,

Bill


----- Forwarded by Julian Satran/Haifa/IBM on 05/18/2002 11:18 AM -----

"Michael Krueger" <michael.krueger@windriver.com> Sent by: owner-ips@ece.cmu.edu 05/15/2002 09:04 PM Please respond to "Michael Krueger"

To:        "Bill Studenmund" <wrstuden@wasabisystems.com>, <ips@ece.cmu.edu>         cc:                 Subject:        RE: iSCSI: BASE64 and numerical values

> So I'd like to suggest we disallow using base64 to encode numbers.
> Byte-swapping an arbitrary-length byte stream seems really messy.
> Alternatively, I'd like to suggest we constrain base64-encoded numbers to
> be 1, 2, 4, or 8 bytes long when decoded, and to be in network byte order.

Bill, thanks for bringing this up, because I wanted to make the same point.
Implementing base-64 encoding for numbers is a fair amount of work for very
little benefit--no, let me be blunt: for ZERO benefit.  As I understand it,
the whole idea of the text-based login was to make it human-readable and to
allow cutting and pasting of values from, say, a management console.  Maybe
I lack imagination, but I cannot conceive of any real-world circumstance
under which a NUMBER would be displayed on a console or entered by a human
(except, perhaps, by a pathologically mischievous one ;-) in base-64
encoding.  A BINARY ITEM, yes, but a NUMBER, never.

Let's keep it simple: decimal and hexadecimal for numbers, hexadecimal and
base 64 for binary items.

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