Subject: Re: iSCSI - decimal coded binary strings - a proposed resolution

From: "Julian Satran" <[email-masked]>
Date: Tue, 9 Jul 2002 08:50:47 +0300

Paul - I think we are talking again about two different thinks:

numerical values that could be more than 2**64 - I would not forbid it 
there
bit strings that could be longer than 64 bits - I find it acceptable

The new text could be:

decimal-constant: an unsigned decimal number - the digit 0 or a string of 
1 or more digits starting with a non-zero digit.  Decimal-constants are 
used to encode numerical values or binary strings. Decimal constants can 
be used to encode binary strings only if the stringlength is explicitly 
speci-fied. There is no implicit length for decimal strings. This encoding 
MUST NOT used for numerical values equal or greater than 2**64 or binary 
strings that could be longer than 64 bits.

Julo

Paul Koning <[email-masked]>
Sent by: [email-masked]
07/08/2002 10:36 PM
Please respond to Paul Koning

        To:     Julian Satran/Haifa/IBM@IBMIL
        cc:     [email-masked]
        Subject:        Re: iSCSI - decimal coded binary strings - a proposed resolution

>>>>> "Julian" == Julian Satran <[email-masked]> writes:

 Julian> Considering the widespread use of decimal encoding and the
 Julian> perceived difficulty of mapping them to a binary string -
 Julian> mainly due to the difficulty of matching lengths I suggest
 Julian> the following:

 Julian> Decimal encoding for binary strings will be used only where
 Julian> the length of the binary string is explicitly defined (by a
 Julian> constant or a rule that does not use the encoding itself)

 Julian> The definition for decimal constant becomes:

 Julian> decimal-constant: an unsigned decimal number - the digit 0 or
 Julian> a string of 1 or more digits starting with a non-zero
 Julian> digit. This encoding is not used for numerical values equal
 Julian> or greater than 2**64. Decimal-constants are used to encode
 Julian> numerical values or binary strings. Decimal constants can be
 Julian> used to encode binary strings only if the stringlength is
 Julian> explicitly specified. There is no implicit length for
 Julian> deci-mal strings.

The point about "no implicitic length" certainly helps.

I like David's suggestion (DLB's comments T.12) to disallow decimal
for data items that are capable of being larger than 2**64 -- rather
than tying it to whether the particular value being encoded happens to
be bigger or smaller than 2*64.  That way it essentially becomes a
property of the data type, which seems like a logical way to go.

Text to do that would be something like "This encoding is not used for
parameters that may have a value >= 2**64" or alternatively "This
encoding is used only with parameters whose largest permitted value is
less than 2**64".

                  paul

---

From: Paul Koning <[email-masked]>
Date: Tue, 9 Jul 2002 10:08:10 -0400

>>>>> "Julian" == Julian Satran <[email-masked]> writes:

 Julian> Paul - I think we are talking again about two different
 Julian> thinks:

 Julian> numerical values that could be more than 2**64 - I would not
 Julian> forbid it there

 Julian> bit strings that could be longer than 64 bits - I find it
 Julian> acceptable

 Julian> The new text could be:

 Julian> decimal-constant: an unsigned decimal number - the digit 0 or
 Julian> a string of 1 or more digits starting with a non-zero digit.
 Julian> Decimal-constants are used to encode numerical values or
 Julian> binary strings. Decimal constants can be used to encode
 Julian> binary strings only if the stringlength is explicitly
 Julian> speci-fied. There is no implicit length for decimal
 Julian> strings. This encoding MUST NOT used for numerical values
 Julian> equal or greater than 2**64 or binary strings that could be
 Julian> longer than 64 bits.

There currently are no numeric values >= 2**64.  But in any case, I
don't like the idea there either.  What I proposed makes the encoding
an attribute of the parameter -- either it can always be encoded in
decimal, or it never can be.

What you're proposing does that for binary strings.  But for numeric
values, the encoding permitted would depend on the particular value.
I don't see any sense in that extra complexity.

    paul

---

From: "Julian Satran \(Hotmail\)" <[email-masked]>
Date: Wed, 10 Jul 2002 13:00:01 +0300

Paul,

There seems to be something missing.
There is no decimal coding for numbers over 2**64.
And there no implied length for strings.
Where is the complexity?

Julo

---

From: Paul Koning <[email-masked]>
Date: Wed, 10 Jul 2002 09:09:52 -0400

> And there no implied length for strings.

If I understood correctly, you were proposing:

1. For binary strings, decimal coding is allowed only if the
particular string can never be longer than 64 bits.  In other words,
even in cases when some of the allowed values are less than 64 bits,
you're not allowed to use decimal, ever.  So the encoding rule is tied
to the parameter, not to its value.

2. On the other hand, for numbers, the proposed rule says that you can
encode the value in decimal whenever the value happens to be less than
2**64.  If 5 minutes later that same parameter happens to have a
value 2**64 or greater, then you cannot encode that particular value
in decimal.  So the encoding rule here is tied to the value, not the
parameter; a given parameter sometimes permits decimal and sometimes
not.

That's what I meant: it is extra complexity to have an encoding rule
for a variable that isn't the same for all possible values of the
variable.

	paul

---

From: "Randy Jennings" <[email-masked]>
Date: Wed, 10 Jul 2002 10:02:58 -0700

> >  Julian> longer than 64 bits.

Here is the problem:
Do you mean (parentheses added):

This encoding MUST NOT used for (numerical values equal or greater than
2**64) or (binary strings that could be longer than 64 bits).

or:

This encoding MUST NOT used for (numerical values equal or greater than
2**64 or binary strings) that could be longer than 64 bits.

The first is admittedly the more logical choice, but it is not the only
choice.  I originally read it as the second and wondered what Paul's issue
was.

This is the editorial clarity issue that David Black is talking about.  I
remember having this issue with spec 11 when I was primarily learning the
spec. However, as I care more about decoding the info instead of writing a
protocol state machine, I did not make note of these problems.  I apologize
for not going over spec 12-(15?) closely.  These issues may have been
addressed by other editorial comments, but when adding text, it should be
carefully scrutinized as well.

With a 'for' in front of binary strings, the sentence can only be
interpreted one way.  From your following email is the wording intended.

Sincerely,
Randy
Data Transit