Subject: iSCSI: Text/Operational keys: booleans and ranges

From: Luben Tuikov <[email-masked]>
Date: Mon, 11 Mar 2002 18:07:29 -0500

1. Is it possible to make all Boolean Text/Operational keys's
value range be ``0'' and ``1'', rather than the current
``Yes'', ``No''.

Since those are _Boolean_ values, what will be the objection to
this? 

A user interface will probably display ``Yes'' and ``No'', but
in the protocol, why burden implementations with string
comparison, case-sensitive on top of this, rather than use
strtol(), this making content check easier (strtol() will detect
range errors, e.g. ``OFMarker=hello'').

2. Why not make integer ranges, like OFMarkInt, use dash,
``-'' ASCII: 0x2d, like ``1-65535'', indicating all values in the interval.

The reason is that in the future there may be a text/operational key which can take only a set of
distinct integer values, but no range, e.g. ``SomeBit=0,4,8,16'', That is ``SomeBit'' is still an
integer variable but in negotiation it can choose between certain disctinct values. Furthermore the
standard text/operational code which many of you already have written will work in this situation,
only add atoi()/strtol() at the end...

Comments?

-- 
Luben

---

From: "Daniel F. Smith" <[email-masked]>
Date: Mon, 11 Mar 2002 16:07:39 -0800 (PST)

> value range be ``0'' and ``1'', rather than the current

An old trick is to use bit 0 of the first (UTF-8) character.
This gets:
	1 for "1", "Yes", "yes", "oui", "si" (but not "ja", "da" or "hai")
	0 for "0", "No", "non" (but not "ei")
Of course, it also allows great opportunity for obfuscation ("maybe" is
yes), and must therefore be a good thing.  B-)

Daniel Smith
--
IBM Almaden Research Center, 650 Harry Road, San Jose, CA 95120-6099, USA
K65B/C2 Phone: +1(408)927-2072 Fax: +1(408)927-3010

---

From: Paul Koning <[email-masked]>
Date: Tue, 12 Mar 2002 12:13:06 -0500

>>>>> "Luben" == Luben Tuikov <[email-masked]> writes:

 Luben> 1. Is it possible to make all Boolean Text/Operational keys's
 Luben> value range be ``0'' and ``1'', rather than the current
 Luben> ``Yes'', ``No''.

 Luben> Since those are _Boolean_ values, what will be the objection
 Luben> to this?

 Luben> A user interface will probably display ``Yes'' and ``No'', but
 Luben> in the protocol, why burden implementations with string
 Luben> comparison, case-sensitive on top of this, rather than use
 Luben> strtol(), this making content check easier (strtol() will
 Luben> detect range errors, e.g. ``OFMarker=hello'').

That's a reasonable enough proposal, but I'm not convinced it's worth
changing at this time.

 Luben> 2. Why not make integer ranges, like OFMarkInt, use dash,
 Luben> ``-'' ASCII: 0x2d, like ``1-65535'', indicating all values in
 Luben> the interval.

Same comment -- a bit less strongly since this is a last minute
addition.  A dash, or a colon, would be ok.  (Double colon?  No
thanks.)

 Luben> The reason is that in the future there may be a
 Luben> text/operational key which can take only a set of distinct
 Luben> integer values, but no range, e.g. ``SomeBit=0,4,8,16'', That
 Luben> is ``SomeBit'' is still an integer variable but in negotiation
 Luben> it can choose between certain disctinct values. Furthermore
 Luben> the standard text/operational code which many of you already
 Luben> have written will work in this situation, only add
 Luben> atoi()/strtol() at the end...

I'm assuming you're not proposing the addition of "sets of distinct
values" as a negotiation option in V1, right?

It's time to stop making changes, even small changes, and freeze the
spec.  If it's not broken, let it stand.

	paul

---

From: Luben Tuikov <[email-masked]>
Date: Tue, 12 Mar 2002 12:44:30 -0500

>         0 for "0", "No", "non" (but not "ei")

But this makes things worse as one would rely on low level
representation to figure out the value, so we are better off
comparing case sensitive strings... in the low level protocol
implementation...

How about ranges using the dash?

True, one could _count_ the commas to fugure out if it is a
list (number of commas > 1) or a range (number of commas = 1), but you have to add code to _count_
the commas.

Using a dash for ranges, the list of numerical values is
handled by default by the already existing code in your
implementation to intesect two strings of comma separated
objects.

Anyone?

-- 
Luben

---

From: Paul Koning <[email-masked]>
Date: Tue, 12 Mar 2002 13:50:58 -0500

>>>>> "Luben" == Luben Tuikov <[email-masked]> writes:
 Luben> How about ranges using the dash?

 Luben> True, one could _count_ the commas to fugure out if it is a
 Luben> list (number of commas > 1) or a range (number of commas = 1),
 Luben> but you have to add code to _count_ the commas.

That doesn't work, because sets can have two members.  So yes, a
separator different from comma makes sense for ranges.

 Luben> Using a dash for ranges, the list of numerical values is
 Luben> handled by default by the already existing code in your
 Luben> implementation to intesect two strings of comma separated
 Luben> objects.

Not true.  Integers and strings are different data types.  Sets of
strings are in the spec now, sets of integers are not.

I am opposed to changes that do not come with strong justifications
(such as "this change is needed to fix bug XYZ").  I don't see any
justification for sets of integers, so they should not be added until
and unless they are needed.

    paul

---

From: Luben Tuikov <[email-masked]>
Date: Tue, 12 Mar 2002 16:31:08 -0500

Paul Koning wrote:
Paul Koning> 
Paul Koning> >>>>> "Luben" == Luben Tuikov <[email-masked]> writes:
Paul Koning>  Luben> How about ranges using the dash?
Paul Koning> 
Paul Koning>  Luben> True, one could _count_ the commas to fugure out if it is a
Paul Koning>  Luben> list (number of commas > 1) or a range (number of commas = 1),
Paul Koning>  Luben> but you have to add code to _count_ the commas.
Paul Koning> 
Paul Koning> That doesn't work, because sets can have two members.

Implied in my original post:

I was merely pointing this out _considering_ the variable
which is currently processed. (i.e. is it a range or integer or string
by it's nature)

E.g. OFMarkInt cf. MaxRecvPDULength cf. TargetName (resp.)!

By the way, it is also my point that it doesn't work quite so well,
and this is why I started this thread.

Paul Koning>  Luben> Using a dash for ranges, the list of numerical values is
Paul Koning>  Luben> handled by default by the already existing code in your
Paul Koning>  Luben> implementation to intesect two strings of comma separated
Paul Koning>  Luben> objects.
Paul Koning> 
Paul Koning> Not true.  Integers and strings are different data types.  Sets of
Paul Koning> strings are in the spec now, sets of integers are not.

Paul, what is the intersection of ``hello,world'' and ``hello''?
How about ``1,20'' and ``1''? Anyway this is not important.

Anyway, back to the main issue: Paul, you agree that using a
different than comma character to denote ranges of integers is
a good thing?

-- 
Luben

``Beauty [Perfection] is achieved not when there is nothing to add,
  but when there is nothing to take away.''
     Antoine de Saint-Exupery

---

From: Paul Koning <[email-masked]>
Date: Tue, 12 Mar 2002 17:44:34 -0500

>>>>> "Luben" == Luben Tuikov <[email-masked]> writes:

 Luben> Anyway, back to the main issue: Paul, you agree that using a
 Luben> different than comma character to denote ranges of integers is
 Luben> a good thing?

Yes, I think that's a reasonable thing to do.

     paul