Re: iSCSI: Decimal encoding - why 64 bits ?

[Paul Koning <ni1d@arrl.net>]

Excerpt of message (sent 5 July 2002) by Julian Satran \(Actcom\):
> If you fear about extended precision arithmetic you should carefully look at
> what key=values are.
> Precluding the use of large numerical values by forbidding their encoding is
> not a good way of considering this - we have also base64 for large numbers
> (and hex) and if you have to have a use for larger numbers you have to have
> the arithmetic to handle it.

There are no numbers in the draft that come even close to 32 bits (the
biggest is about 24 bits) so any possible future use of 64 bit
integers is entirely speculative.
 
> As for the second subject - forbidding the use decimals for binary strings -
> we never discussed it or agreed on this.

I thought we had, but it doesn't really matter if we discussed it in
the past; we're discussing it now.
 
> I wonder how natural it will feel for somebody to have and IP address
> encoded exclusively in hex, or a TargetPortalGroup appearing as decimal in a
> directory and having to be transliterated.

What does this have to do with the subject that we're discussing?
Those aren't integers bigger than 32 bits.

The two areas that are being argued about are:

1. Integer-type attributes that require 64 bits rather than 32 bits.
   Such attributes do not currently exist.  We could let the rules say
   that such attributes, if/when they appear in the future, can be 
   encoded in decimal.  That doesn't affect any current
   implementations because there are no such attributes at present.

2. Bitstring attributes, as found in crypto variables.  Those are
   either always, or almost always, much larger than 2^64.  The
   request from a significant number of people is to disallow decimal
   encoding for those attributes even in the very rare case that the
   value encoded is < 2^64.
   I support that change because allowing the decimal encoding there
   adds no value at all and only complicates code to no purpose.

      paul