Subject: Re:

From: "Julian Satran \(Actcom\)" <[email-masked]>
Date: Fri, 5 Jul 2002 06:54:20 +0300

Leading 0 where forbidden after a brief discussion.
As for unlikely to be used - I could argue for the contrary - as in the examples I gave in a previous notes.
Many string copied from humanly readable documents tend to be decimal-encoded.

Julo

Subject: iSCSI: leading zeros and decimal-encoded binary strings
From: Bill Studenmund <[email-masked]>
To: <[email-masked]>
Date: Tue, 2 Jul 2002 14:56:20 -0700 (PDT)

Here's the heart of what I dislike about decimal-encoded binary strings:
how do you convey the length of the binary string when you have leading
zero bits?

-14 says:

"When used to encode binary strings decimal constants have an implicit
byte-length that is the minimum number of bytes needed to represent the
base2 encoding of the decimal number."

How do leading zeros impact the "base2 encoding .."?

Consider "012". Obviously the number is 12. The question is how many bytes
are in the binary string? Is it one, since a number of three decimal digit
numbers fit in one byte (up to "255"), or is it two bytes in the string
since other three-decimal-digit numbers won't fit in one byte ("256"
through "999")?

The spec isn't clear, at least not to me.

Ok, so one or two-byte strings aren't that likely. The problem though is
that all of the byte sizes don't line up nicely with decimal digits (since
2^x = 10^y only works for x=0, y=0 AFAIK).

Since we can't force that binary strings don't start with a zero-byte (or
two), we need to support some way of communicating how long such a string
is.

Two suggestions:

1) Rip out the decimal binary strings bit

2) Come up with a table saying if you have so many digits which contain
leading zeros, you have a binary string of so many bytes.

Examples:

String:		Bytes in binary string:

00000000000000000012	  8
00072057594037927935	  8

   00000000000000012	  7
   00281474976710655	  7

     000000000000012	  6
     001099511627775	  6

       0000000000012	  5
       0004294967295	  5

          0000000012	  4
          0016777215	  4

            00000012	  3
            00065535	  3

               00012	  2
               00255	  2

The advantage of such a method is that you can easily force the right
number of leading zeros with printf format strings. For instance,
printf("%010d", an-int32-type) will do the right thing.

But we need to communicate that in the spec, and we don't.

Thoughts?

Take care,

Bill

P.S. I will be on vacation starting tomorrow through the weekend.

Subject: RE: iSCSI: leading zeros and decimal-encoded binary strings
From: [email-masked]
To: [email-masked], [email-masked]
Date: Tue, 2 Jul 2002 17:09:13 -0600

Bill,

There is an additional thing I don't like about decimal-encoded binary strings. We will have to put in support for a feature that is unlikely to be used. The only items defined as binary-values are CHAP and SRP binary strings which usually will be too long for decimal encoding anyway.

Take CHAP for instance. It C and R are defined as binary-values. R is 16 bytes so it can't be decimal encoded. C shorter than 8 bytes seems unlikely.

My preference would be to replace the definition of binary-value with the current definition of large-binary value, replace large-binary-value with binary-value (in 10.2 and 10.3) and get rid of regular-binary-value and large-binary-value. 

Regards,
Pat

-----Original Message-----
From: Bill Studenmund [mailto:[email-masked]]
Sent: Tuesday, July 02, 2002 2:56 PM
To: [email-masked]
Subject: iSCSI: leading zeros and decimal-encoded binary strings

Here's the heart of what I dislike about decimal-encoded binary strings:
how do you convey the length of the binary string when you have leading
zero bits?

-14 says:

"When used to encode binary strings decimal constants have an implicit
byte-length that is the minimum number of bytes needed to represent the
base2 encoding of the decimal number."

How do leading zeros impact the "base2 encoding .."?

Consider "012". Obviously the number is 12. The question is how many bytes
are in the binary string? Is it one, since a number of three decimal digit
numbers fit in one byte (up to "255"), or is it two bytes in the string
since other three-decimal-digit numbers won't fit in one byte ("256"
through "999")?

The spec isn't clear, at least not to me.

Ok, so one or two-byte strings aren't that likely. The problem though is
that all of the byte sizes don't line up nicely with decimal digits (since
2^x = 10^y only works for x=0, y=0 AFAIK).

Since we can't force that binary strings don't start with a zero-byte (or
two), we need to support some way of communicating how long such a string
is.

Two suggestions:

1) Rip out the decimal binary strings bit

2) Come up with a table saying if you have so many digits which contain
leading zeros, you have a binary string of so many bytes.

Examples:

String:		Bytes in binary string:

00000000000000000012	  8
00072057594037927935	  8

   00000000000000012	  7
   00281474976710655	  7

     000000000000012	  6
     001099511627775	  6

       0000000000012	  5
       0004294967295	  5

          0000000012	  4
          0016777215	  4

            00000012	  3
            00065535	  3

               00012	  2
               00255	  2

The advantage of such a method is that you can easily force the right
number of leading zeros with printf format strings. For instance,
printf("%010d", an-int32-type) will do the right thing.

But we need to communicate that in the spec, and we don't.

Thoughts?

Take care,

Bill

P.S. I will be on vacation starting tomorrow through the weekend.

Subject: RE: iSCSI: leading zeros and decimal-encoded binary strings
From: Bill Studenmund <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Date: Tue, 2 Jul 2002 16:37:13 -0700 (PDT)

On Tue, 2 Jul 2002 [email-masked] wrote:

> Bill,
>
> There is an additional thing I don't like about decimal-encoded binary
> strings. We will have to put in support for a feature that is unlikely
> to be used. The only items defined as binary-values are CHAP and SRP
> binary strings which usually will be too long for decimal encoding
> anyway.
>
> Take CHAP for instance. It C and R are defined as binary-values. R is
> 16 bytes so it can't be decimal encoded. C shorter than 8 bytes seems
> unlikely.
>
> My preference would be to replace the definition of binary-value with
> the current definition of large-binary value, replace
> large-binary-value with binary-value (in 10.2 and 10.3) and get rid of
> regular-binary-value and large-binary-value.

That's my prefered choice.

Take care,

Bill

---

From: Martins Krikis <[email-masked]>
Date: Fri, 5 Jul 2002 07:02:22 -0700 (PDT)

--- "Julian Satran (Actcom)"
<[email-masked]> wrote:
> As for unlikely to be used - I could argue for the
> contrary - as in the examples I gave in a previous
> notes.

Julian,

You are right about the leading 0, thus Bill's 
example was a bad one. He is right however about
the inability to express the leading nul-bytes of
a binary string when it is encoded in decimal.

The examples you gave previously (unless some
have escaped me) were really bad. I have yet to
see a true "binary string" (and not a number)
encoded in decimal.

Martins Krikis, Intel Corp.

Disclaimer: these opinions are mine and may not
            be those of my employer.

__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

---

From: "Julian Satran \(Actcom\)" <[email-masked]>
Date: Fri, 5 Jul 2002 18:37:51 +0300

Martins,

In fact reading your note I went back and found an error we may want to
correct:

TargetPortalGroupTag is a 16 bit binary string and not an number (there is
no TPGT that is lower or higher than another TPGT).

As for IP addresses they are just for illustration - each of the address
item is a an 8 bit  binary string of fixed length usually encoded decimal.

There are no good examples that need decimals other than TPGT but I see no
point in disallowing them for vendor keys and future extensions. Any
implementation will have the conversion routines. Restricting the use of
decimals beyond what we did does not strike me as useful.

Julo
----- Original Message -----
From: "Martins Krikis" <[email-masked]>
To: "Julian Satran (Actcom)" <[email-masked]>; "ips"
<[email-masked]>
Sent: Friday, July 05, 2002 5:02 PM

---

From: Martins Krikis <[email-masked]>
Date: Fri, 5 Jul 2002 09:25:12 -0700 (PDT)

> no TPGT that is lower or higher than another TPGT).

Again, I don't have draft 14 in front of me but
13 says that TPGT is "a simple unsigned-integer
between 1 and 65535" (2.4.1 (e)) and a "numerical-
value-from-1-to-65535" (11.9). I would prefer it if
you did not change this to a "binary string" just
to prove a point that there are binary strings
for which decimal encoding is natural. That, IMO,
would be a very profound change at an extremely
late stage. (If you do, I'll make sure all my
TPGTs start with 0x00 and deny all attemts to
encode them in decimal :-)).

> There are no good examples that need decimals other

Even TPGT is not a good example, as it is defined
to be a number, for now at least.

> decimals beyond what we did does not strike me as

Others (and there are many) here seem to be 
disagreeing with you.

The conversion, while possible, will likely
first use some common library routine, then
byteswap (if running on little-endian), then
do a pass to eliminate leading 0-bytes, which
are not representable in decimal. 

OK, my final argument. Here are two binary
strings, encoded in hex: 0x01 and 0x0001.
Can you give us an example of encoding both
of them in decimal in such a way that they
can be distinguished?

Disclaimer: these opinions are my own and may
            not be those of my employer.

---

From: "Julian Satran \(Actcom\)" <[email-masked]>
Date: Fri, 5 Jul 2002 21:25:12 +0300

The trouble with the current definition is that TPGT has no number
characteristics at all (there is no ordering defined).
For implementations the changes is irrelevant.
And you may continue to use whatever you want. I do not see how 0 will
prevent somebody encode it in decimal (as most do).
And believe me I do not change things to prove a point - I am too old for
that.

As for you conversion rules - some of the steps are  there regardless of
where you com from - hex to string may be subject to byteswap too!
(specially if you define it as a number!).

My point was that once you have decimal in the is no point is forbidding it
in some instances.

Julo
----- Original Message -----
From: "Martins Krikis" <[email-masked]>
To: "Julian Satran (Actcom)" <[email-masked]>; "ips"
<[email-masked]>
Sent: Friday, July 05, 2002 7:25 PM
Subject: Re: iSCSI: Decimal encoding - why 64 bits ?

---

From: Paul Koning <[email-masked]>
Date: Fri, 5 Jul 2002 14:32:29 -0400

I believe there are a bunch of comments in favor of not allowing
decimal for bitstrings (only for integers) and only one against.

This seems to be "rough consensus".

     paul