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

[Paul Koning <ni1d@arrl.net>]

>>>>> "Luben" == Luben Tuikov <luben@splentec.com> 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