SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: Section 4.1 clarifications




    Pat,

    I suggest that we say that support for large decimal integers and define large decimal integers is limited to 100 digits (or 200)?

    Julo


    "THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>

    04/25/2002 11:23 PM
    Please respond to "THALER,PAT (A-Roseville,ex1)"

           
            To:        Julian Satran/Haifa/IBM@IBMIL, Michael Krueger <michael.krueger@windriver.com>
            cc:        ips@ece.cmu.edu, iSCSI Team <iscsiteam@windriver.com>
            Subject:        RE: Section 4.1 clarifications

           


    Julian,
     
    I think Michael's point is that the decimal encoding for a 1024 byte binary is around 2500 characters (if I've done the math right) while the hexadecimal encoding is 2050 characters and someone anticipating the binary might not have made wherever they store the string before conversion big enough for the extra ~450 characters.
     
    The extra storage is small compared to the amount of data one may be moving later once the connection is up, but I also don't see the readability argument as applying to these large constants. Therefore, it would be reasonable to cut down on the encoding options for the large constants.
     
    Regards,
    Pat
     
    -----Original Message-----
    From:
    Julian Satran [mailto:Julian_Satran@il.ibm.com]
    Sent:
    Thursday, April 25, 2002 12:59 PM
    To:
    Michael Krueger
    Cc:
    ips@ece.cmu.edu; iSCSI Team
    Subject:
    RE: Section 4.1 clarifications


    I could say that the use of decimal encoding for large integers is discouraged although I have a hard time understanding your point.

    Converting a large decimal does not seem to me as a space or time consuming operation.


    Julo


    "Michael Krueger" <michael.krueger@windriver.com>

    04/25/2002 10:34 PM
    Please respond to "Michael Krueger"

           
           To:        Julian Satran/Haifa/IBM@IBMIL

           cc:        <ips@ece.cmu.edu>, "iSCSI Team" <iscsiteam@windriver.com>

           Subject:        RE: Section 4.1 clarifications


         



    Julo,

    > The integer representation was discussed a long time ago on the
    > list and it was decided that decimal should be allowed as it might
    > be copied from some human readable tables. I would hate to make
    > this type of changes this late.

    I agree that decimal encoding should be retained for NUMERIC CONSTANTS, for
    the reasons you state.  However, I do not believe it makes any sense to
    allow decimal representations of BINARY ITEMS.

    I think a concrete example might help here.  I am in the process of
    implementing CHAP authentication.  Section 10.5 of the spec states that
    CHAP_A and CHAP_I are "numbers" and CHAP_C and CHAP_R are "binary items and
    their binary length (not the length of the character string that represents
    them in encoded form) MUST not exceed 1024 bytes."

    When I parse CHAP_A and CHAP_I, which I'm calling "numeric constants," I'll
    allow decimal or hexadecimal representations, but I certainly won't be able
    to cope with a number whose decoded value is wider than 4 bytes . . . and I
    doubt that anyone else will, either.  [Let's face the fact that unless they
    are explicitly told to expect decoded values longer than, say, 4 bytes,
    implementers will use stroul() or its equivalent in a situation like this.]

    When I parse CHAP_C and CHAP_R, which I'm calling "binary items," I expect
    numbers whose decoded values could be up to 1024 bytes long.  I can easily
    convert hexadecimal or base-64 representations of such values into binary
    data; however, I WILL NOT be able to cope with decimal encoding, which in
    this case could have up to 2,467 digits . . . and I doubt that anyone else
    will, either.  (The "human readable tables" argument goes out the window in
    this case as well . . . who will be typing those 2,467 decimal digits?)

    As the wording of Section 10.5 already shows, there is a need to make a
    distinction between "numeric constants" ("numbers") and "binary items."  I
    am only suggesting that this be done consistently throughout the spec, with
    a single clear definition for each term.

    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: Thu Apr 25 23:18:22 2002
9803 messages in chronological order