|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI: Text/Operational keys: booleans and rangesLuben has a good point about range notation. Julo
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: hufferd@us.ibm.com Paul Koning <ni1d@arrl.net>@ece.cmu.edu on 03/12/2002 09:13:06 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: iSCSI: Text/Operational keys: booleans and ranges >>>>> "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
Home Last updated: Tue Mar 12 20:18:12 2002 9077 messages in chronological order |