RE: Section 4.1 clarifications

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

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