RE: iSCSI: Decimal encoding - why 64 bits ?

["Julian Satran" <Julian_Satran@il.ibm.com>]

David,

I went back to the mailing list - and there was a clear consensus to keep
it to 64 bits (my original proposal was unlimited and  I suggested rhen 128
to alleviate concerns about conversion difficulty for unlimited numbers).

The issue was raised without checking the libraries:

In Gnu 64bit integers are fully supported
In Windows - here is the quote from MSDN:

                                                                            
                                                                            
                                                                            
                                                                            
     long-suffix unsigned-suffix(subscript: opt)                            
                                                                            
     unsigned-suffix : one of                                               
                                                                            
     u U                                                                    
                                                                            
     long-suffix : one of                                                   
                                                                            
     l L                                                                    
                                                                            
     64-bit integer-suffix :                                                
                                                                            
     i64                                                                    
                                                                            
     To specify integer constants using octal or hexadecimal notation,      
     use a prefix that denotes the base. To specify an integer constant     
     of a given integral type, use a suffix that denotes the type.          
                                                                            
     To specify a decimal constant, begin the specification with a          
     nonzero digit. For example:                                            
                                                                            
                                                                            
     int i = 157;   // Decimal constant                                     
     int j = 0198;  // Not a decimal number; erroneous octal constant       
     int k = 0365;  // Leading zero specifies octal constant, not decimal   
                                                                            
                                                                            
     To specify an octal constant, begin the specification with 0,          
     followed by a sequence of digits in the range 0 through 7. The         
     digits 8 and 9 are errors in specifying an octal constant. For         
     example:                                                               
                                                                            
                                                                            
     int i = 0377;   // Octal constant                                      
     int j = 0397;   // Error: 9 is not an octal digit                      
                                                                            
                                                                            
     To specify a hexadecimal constant, begin the specification with 0x     
     or 0X (the case of the "x" does not matter), followed by a sequence    
     of digits in the range 0 through 9 and a (or A) through f (or F).      
     Hexadecimal digits a (or A) through f (or F) represent values in the   
     range 10 through 15. For example:                                      
                                                                            
                                                                            
     int i = 0x3fff;   // Hexadecimal constant                              
     int j = 0X3FFF;   // Equal to i                                        
                                                                            
                                                                            
     To specify an unsigned type, use either the u or U suffix. To          
     specify a long type, use either the l or L suffix. For example:        
                                                                            
                                                                            
     unsigned uVal = 328u;             // Unsigned value                    
     long lVal = 0x7FFFFFL;            // Long value specified              
                                       //  as hex constant                  
     unsigned long ulVal = 0776745ul;  // Unsigned long value               
                                                                            
                                                                            
                                                                            
                                                                            


I don't know about Windmills - but I assume that most modern development
environments are supporting 64bit integers.

Are we going to take for granted any assertion made on the list?

Julo



                                                                                                                                            
                      Black_David@emc.c                                                                                                     
                      om                       To:       Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu                                     
                                               cc:                                                                                          
                      07/02/2002 10:36         Subject:  RE: iSCSI: Decimal encoding - why 64 bits ?                                        
                      PM                                                                                                                    
                      Please respond to                                                                                                     
                      Black_David                                                                                                           
                                                                                                                                            
                                                                                                                                            



Easy does it.  First of all - if someone will go find the mail
thread that discussed this (I also recall a discussion of
numbers vs. binary items) I'll take a look at it and make a
WG chair determination of what was or was not concluded.

Kevin's comment that decimal ought to be limited to 32 bits
is still valid at this point - a reference to prior discussions
without specifics isn't enough to dismiss it.  My rough
recollection of the discussion partially matches Julian's -
we reduced the required size to 64 bits from unlimited on
the assumption that platforms could cope with this ... and
now Kevin has raised the issue that two platforms he
considers important don't cope well with 64 bit arithmetic.
I don't recall discussion of whether to limit to 32 bits vs.
64 bits.

For now, this issue is open.

Thanks,
--David
 -----Original Message-----
 From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
 Sent: Tuesday, July 02, 2002 3:23 PM
 To: ips@ece.cmu.edu
 Subject: RE: iSCSI: Decimal encoding - why 64 bits ?


 It was never supposed to be removed. Many values are passed around as
 decimal.
 We can't make any progress if we keep hitting the same things
 again-and-again after a decent consensus has been reached.
 And none of you has brought an argument that was not heard and dismissed
 before.

 Remember we moved from unlimited length decimal to 64 bit to alleviate
 implementer fears.

 Julo

                                                                           
   Bill Studenmund                                                         
   <wrstuden@wasabisystem         To:        "THALER,PAT                   
   s.com>                 (A-Roseville,ex1)" <pat_thaler@agilent.com>      
                                  cc:        "LEMAY,KEVIN                  
                          (A-Roseville,ex1)" <kevin_lemay@agilent.com>,    
   07/02/2002 10:03 PM    Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu> 
   Please respond to Bill                                                  
   Studenmund                     Subject:        RE: iSCSI: Decimal       
                          encoding - why 64 bits ?                         
                                                                           
                                                                           
                                                                           




 On Tue, 2 Jul 2002, THALER,PAT (A-Roseville,ex1) wrote:

 > Bill,
 >

 > The decimal encoding is not just for numbers. It is also allowed for
 > binary-values. Both CHAP and SRP exchange items that are identified as
 > binary-values. In general these will be longer than 64 bits, but in
 > cases where they are 64 bits or less the decimal encoding is currently
 > allowed so we would have to support it.

 I thought we had a big discussion about this, and we decided that decimal
 was only used for numbers, hex for numbers and binary, and base64 only for
 binary items. ??

 Doh! I just looked in -14, and the text doesn't reflect that
 understanding. Hmmm.

 > The issue is that currently decimal encoding is allowed for
 > binary-values and numbers less than 64 bits. There is little need for
 > it over 32 bits. We have two other entirely adequate representations
 > for those numbers. Why have something in there that causes extra code
 > for no benefit?

 All I can say is I thought it was removed. :-|

 Take care,

 Bill