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

["Mallikarjun C." <cbm@rose.hp.com>]

Julian,

I agree with your proposal to denote ranges with ":".

Also, as somewhat of a digression, I think we need to say 
something about the legality (or lack there of) of a negotiation 
involving multiple ranges as in:

Key=a:b, c:d, e:f

My not-too-strong opinion is that it could be useful to allow this...
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668 
Roseville CA 95747
cbm@rose.hp.com

----- Original Message ----- 
From: "Julian Satran" <Julian_Satran@il.ibm.com>
To: "John Hufferd" <hufferd@us.ibm.com>
Cc: <ips@ece.cmu.edu>; "Paul Koning" <ni1d@arrl.net>; <owner-ips@ece.cmu.edu>
Sent: Tuesday, March 12, 2002 11:42 AM
Subject: Re: iSCSI: Text/Operational keys: booleans and ranges


> Luben has a good point about range notation. Julo
> 
> 
> 
> 
> John Hufferd/San Jose/IBM@IBMUS
> Sent by: owner-ips@ece.cmu.edu
> 12-03-02 20:37
> Please respond to John Hufferd
> 
>  
>         To:     Paul Koning <ni1d@arrl.net>
>         cc:     ips@ece.cmu.edu
>         Subject:        Re: iSCSI: Text/Operational keys: booleans and ranges
> 
>  
> 
> 
> 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
> 
> 
> 
> 
> 
> 
>