iSCSI: BASE64 and numerical values

[Bill Studenmund <wrstuden@wasabisystems.com>]

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