SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: iSCSI - long key values



    Good point, Marjorie, I hadn't considered that. I just wanted to avoid
    having "length" always being provided.
    
    Julian, I know it is a small thing in the grand scheme of things, but can we
    pursue closure (consensus) on key=value pairs spanning PDUs, which would
    also facilitate the "jumbo" strings?
    
    
    Stephen
    
    -----Original Message-----
    From: KRUEGER,MARJORIE (HP-Roseville,ex1)
    [mailto:marjorie_krueger@hp.com]
    Sent: Wednesday, September 19, 2001 3:12 PM
    To: ips@ece.cmu.edu
    Subject: RE: iSCSI - long key values
    
    
    You should know by the key which values will be allowed to be long.  So no
    special character is necessary, when you see "key", expect length, value?
    
    Marjorie 
    
    > -----Original Message-----
    > From: Wheat, Stephen R [mailto:stephen.r.wheat@intel.com]
    > Sent: Wednesday, September 19, 2001 2:09 PM
    > To: 'deva@stargateip.com'; ips@ece.cmu.edu
    > Subject: RE: iSCSI - long key values
    > 
    > 
    > I don't know if like that idea or not.  But, if we did want 
    > to do this, then
    > I propose a syntax variation so as to indicate when the 
    > length field would
    > be there and when it would not.
    > 
    > Something akin to:
    > 
    >    key=value[,value]*
    > 
    > or
    > 
    >    key>=length,value[,value]*
    >       ^---- pick some character not allowed in a "key" name.
    > 
    > Stephen
    > 
    > 
    > -----Original Message-----
    > From: Dev [mailto:deva@stargateip.com]
    > Sent: Wednesday, September 19, 2001 12:26 PM
    > To: Wheat, Stephen R; 'Julian Satran'; ips@ece.cmu.edu
    > Subject: RE: iSCSI - long key values
    > 
    > 
    > If a value could span mutliple PDUs (a jumbo string, if you want these
    > strings to be called so..)
    > then it will be helpful to have the value length as below
    > key = length, "value"
    > 
    > Thanks
    > 
    > Deva
    > Adaptec
    > 
    > -----Original Message-----
    > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    > Wheat, Stephen R
    > Sent: Wednesday, September 19, 2001 8:06 AM
    > To: 'Julian Satran'; ips@ece.cmu.edu
    > Subject: RE: iSCSI - long key values
    > 
    > 
    > Julian,
    > 
    > Maybe I'm missing something, but I think the new "value extension"
    > discussion is around how to send very long "values" in a list 
    > of key=value
    > pairs.  IF we may have key=value pairs arbitrarily span PDUs, then the
    > sending of a long value is done simply by sending one text 
    > response PDU
    > after another, some may have nothing but a 4KB "value" component of a
    > key=value pair.  The concatenation of the individual "value" 
    > components is
    > then done on the Initiator side, through the process of 
    > concatenating the
    > text responses (in order, of course).
    > 
    > So, am I missing something here?
    > 
    > Stephen
    > 
    > -----Original Message-----
    > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
    > Sent: Tuesday, September 18, 2001 9:31 PM
    > To: ips@ece.cmu.edu
    > Subject: RE: iSCSI - long key values
    > 
    > 
    > Stephen,
    > 
    > It is still on the "to consider list".
    > 
    > How would that affect the individula value "extension" that we are
    > considering now?
    > 
    > Julo
    > 
    > "Wheat, Stephen R" <stephen.r.wheat@intel.com> on 18-09-2001 17:57:36
    > 
    > Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>
    > 
    > To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
    > cc:
    > Subject:  RE: iSCSI - long key values
    > 
    > 
    > 
    > Julian,
    > 
    > Almost a month ago, we had a thread on values spanning PDU boundaries.
    > 
    > See: "Re: Target record not to span PDUs?"
    > 
    > Anyway, that thread discussion ended without conclusion.  I 
    > believe Robert
    > Snively's and my proposal to allow records to span PDUs is 
    > still valid;
    > I'll
    > let Robert speak for himself.
    > 
    > Furthermore, I believe that the proposal would thus avoid 
    > this problem you
    > are now addressing, with far less complexity.
    > 
    > Please reconsider this proposal.
    > 
    > Stephen
    > 
    > 
    > -----Original Message-----
    > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
    > Sent: Monday, September 17, 2001 11:26 PM
    > To: ips@ece.cmu.edu
    > Subject: iSCSI - long key values
    > 
    > 
    > Dear colleagues,
    > 
    > Ofer brought recently to my attention that some security key 
    > values are
    > likely to exceed our stated limit
    > of 255 bytes for a value.  A good example may be a 
    > certificate (or chained
    > certificate).
    > 
    > We have to enable those to be in the Login phase.
    > 
    > To handle this we might want to consider the following 
    > options (but not
    > only those):
    > 
    >    enable a "long hexadecimal coding" that should indicate a 
    > "long" value
    >    (e.g. use 0L instead of 0x) and raise the limit for those keys to
    >    something longer (say 3072 bytes?)
    >    enable "concatenated" values and indicate them through a 
    > "coding scheme"
    >    as follows:
    >      the value "0sxx" indicates a name suffix (as in "key = 
    > 0s08" means
    >      that the keys "key00" , "key01" etc) have to be concatenated
    >      use the "suffixed keys" to "build the value"
    >    use a named key coding (as in "0Nname" in a value means 
    > that you have to
    >    use later get=value to get a "binary response" containing the whole
    >    binary object)
    > 
    > 
    > I  think that option 2 (limited to a 3 digit prefix?) covers 
    > well what we
    > need and offers some extension space and option 1 is probably 
    > good enough
    > for certificates.
    > 
    > Comments?
    > 
    > Julo
    > 
    > 
    > 
    > 
    


Home

Last updated: Wed Sep 19 19:17:20 2001
6609 messages in chronological order