Subject: RE: iSCSI: BASE64 and numerical values

From: Robert Snively <[email-masked]>
Date: Tue, 21 May 2002 11:43:35 -0700

I guess that my point was that we should be transmitting the
binary value, not the encoding of the binary value.

Especially if you care about the length, that is the most
compact version of transmission.

You are never using them in the text-encoded format, so
why transmit them in a text-encoded format.  The values are
ALWAYS used only in the binary format.  TCP/IP does not
have any requirement for them to ever be expressed in the
text-encoded format.

If you need to input them, describe them for debug purposes, or 
print them to a screen, then put them in the
format that is most natural for parsing to natural byte and
word boundaries, which is hexadecimal, but would be outside the
scope of the iSCSI document anyway.

Bob

> -----Original Message-----
> From: Bill Studenmund [mailto:[email-masked]]
> Sent: Tuesday, May 21, 2002 9:28 AM
> To: Robert Snively
> Cc: Julian Satran; [email-masked]
> Subject: RE: iSCSI: BASE64 and numerical values
> 
> 
> On Tue, 21 May 2002, Robert Snively wrote:
> 
> > I have been having continuing problems understanding why
> > iSCSI is considering any use of base64, and I find myself
> > in total agreement with Bill's clear exposition of the
> > situation.
> >
> > Upon reviewing RFC-2045, it is clear that base64 is a method
> > for containing handy binary values in a EMAIL structure that does
> > not use TCP/IP to transmit data, but rather uses obsolete
> > 7-bit ASCII or (slightly less obsolete) EBCDIC strings to
> > carry the data.  TCP/IP transmits data neutral octets,
> > so binary values can be carried in their native binary
> > string format (allowing for a possible requirement to pad
> > strings to an octet boundary).  The most standard way to
> > present those binary strings on a printer or as an input
> > value to a program is hexadecimal encoding.
> >
> > For those reasons, I agree with Bill that we should delete
> > base64 from the text and use hexadecimal as he suggests.
> 
> I must not have been totally clear. I'm not suggesting we 
> remove base64,
> I'm suggesting we limit its use to the cases where (IMHO) it 
> makes sense.
> While there will be much fewer cases in the text with the changes I
> suggest, it will still be in the spec.
> 
> Some of the cryptographic authentications throw around large binary
> strings. Quite large (compared to the numbers and strings we 
> often use)
> binary strings. The fact that if you support these modes of 
> authentication
> you are supposed to be able to accept four times as much text in login
> commands reflects the size of these strings.
> 
> Base64 is a real win for these. Hex can encode 4 bits per byte, while
> base64 can encode 6. Thus an n byte string will be about 
> 1.33*n bytes in
> base 64, while it will be 2n bytes in hex. That size 
> difference is why we
> want base64.
> 
> The main point I've been trying to make is that binary 
> strings and numbers
> are different things, and that encoding methods for one aren't really
> appropriate for the other. Specifics: decimal & hex work great for
> numbers, and hex and base64 work great for binary strings. That's it.
> Also, the hex for numbers isn't the same as the hex for 
> binary strings.
> One is the number in hex, the other is more like hexdump -x 
> without the
> spaces and without the offsets.
> 
> Take care,
> 
> Bill
> 
> 
>

---

From: Bill Studenmund <[email-masked]>
Date: Tue, 21 May 2002 12:37:32 -0700 (PDT)

> have any requirement for them to ever be expressed in the

Good question. The reason is that the WG decided that login negotiation
should be text based. So everything needs to be sent as human-readable
text.

Given that, we need some way to translate binary strings to human-readable
things in a space-efficient manner. Thus the interest in base64.

Take care,

Bill