SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    iSCSI: BASE64 and numerical values




    I was going to suggest this myself :-) Julo
    ----- Forwarded by Julian Satran/Haifa/IBM on 05/18/2002 11:07 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:07 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




Home

Last updated: Sat May 18 05:18:44 2002
10150 messages in chronological order