RE: iSCSI - long key values

["KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>]

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