|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: Section 4.1 clarificationsPat, I suggest that we say that support for large decimal integers and define large decimal integers is limited to 100 digits (or 200)? Julo
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
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 |