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

From: "Julian Satran" <[email-masked]>
Date: Tue, 12 Mar 2002 09:17:59 +0200

Luben,

For the booleans - 1 and 0 are also integers. The parsing of strings is 
already mandated (for keys and string values) so no harm in letting them 
be text.

For ranges - I think you have a good point and if I don't hear anything 
against it I will introduce it in 12 (I would suggest a colon or a 
double-colon instead of dash).

Regards,
Julo

Luben Tuikov <[email-masked]>
Sent by: [email-masked]
12-03-02 01:07
Please respond to iSCSI

        To:     iSCSI <[email-masked]>, Julian Satran/Haifa/IBM@IBMIL
        cc: 
        Subject:        iSCSI: Text/Operational keys: booleans and ranges

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: "John Hufferd" <[email-masked]>
Date: Tue, 12 Mar 2002 10:37:37 -0800

I agree with Paul, leave good enough alone for now.  We are trying to get
to last call, and changes which not absolutely needed are causing time to
elapse which is not worth the change.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: [email-masked]

Paul Koning <[email-masked]>@ece.cmu.edu on 03/12/2002 09:13:06 AM

Sent by:    [email-masked]

To:    [email-masked]
cc:
Subject:    Re: iSCSI: Text/Operational keys: booleans and ranges

>>>>> "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