Re: null termination of keys

["Julian Satran" <Julian_Satran@il.ibm.com>]

Luben,

You may be interested in pursuing a "Formal-iSCSI" and pass it through IETF as iSCSI-2.
Many of us although appreciate the beauty of formalism want this standard out and used by people to build equipment.
In retrospect - the informal nature of almost all TCP/IP was not such a bad thing.

Julo

Luben Tuikov <luben@splentec.com> Sent by: luben@ns.splentec.com 06/04/2002 06:38 PM Please respond to iSCSI; Please respond to Luben Tuikov

To:        Julian Satran/Haifa/IBM@IBMIL         cc:        "Robert D. Russell" <rdr@io.iol.unh.edu>, ips@ece.cmu.edu         Subject:        Re: null termination of keys

Julian,

I agree with Robert. Robert's point of view (as any academic
in the computer/math sciences) is CONSISTENCY. Which is, btw,
a _good_ thing!

The reason is simple: a key=value pair is an entity
starting with non-NUL char (cf. def. of key) and
ending with NUL (0x0) char.

With such a simple definition, parsing the keys is a walk
in the park.

In the draft we are lacking clear-cut, precise
definition of concepts, objects, their interactions
and algorithmic steps.

If we have those set, then finishing and/or changing
iSCSI will be extremely easy.

Take for example the concepts of ``immediate data'' and
``unsolicied data'' and their interactions -- what a spaghetti.

If we define those properly, then we can express many
constraints simply, such as ``A + B <= FirstBurstSize''
where A is blah-blah, and B is blah-blah;
``TargetQueueSize=Max... - blah + 1'' and so on.

Many of us, I'm sure, are reading the draft and re-writing
it, in terms of definitions like the above, in order
to clearly understand it... and you know what happens
then... _inconsistencies_ are found.

This is why, for example, very recently it was decided
that 4.1 should contain definitions in it... even though
it was prompted for a while back.

BTW, I'm surprised that only _one_ person objected to
such a _BIG_ change(s) in the draft. Considering from
personal experience and scaling properly, we
should've seen at least 100 people complaining...

-- 
Luben
P.S. The above definition of a key=value pair would also
solve by default the problem with more than one NUL char,
rather than you explicitly having to put more text in the
draft. Of course putting more than one NUL char would be
frowned upon but a proper parser following the above rule
would have no problem with it... But I digress...


Julian Satran wrote:
> 
> Bob,
> 
> The reason it was put in is to to enable "parsing" without the C bit.
> With key spanning PDUs before having the C bit the sender had to avoid sending a 0 if this was the
> last byte of the PDU as he had no other means of signaling continuation. A 0 at the end of a PDU
> meant end-of-LTDS.
> 
> Now that we have the C bit we can live with or without having a 0 at the end of the last PDU.
> Let's hear some more voices.
> 
> Regards,
> Julo
> 
>   "Robert D. Russell" <rdr@io.iol.unh.edu>
>                                                     To:        Julian Satran/Haifa/IBM@IBMIL
>   06/04/2002 09:48 AM                               cc:        ips@ece.cmu.edu
>   Please respond to "Robert D. Russell"             Subject:        Re: null termination of keys
> 
> 
> 
> Julian:
> 
> Draft 12-96, section 4.1 defines an LTDS and then says:
> 
> "Every key=value pair, excluding the last or only pair in a LTDS,
> MUST be followed by one null (0x00) delimiter; the last or only pair
> in a LTDS ends at the LTDS end."
> 
> This brings us back to where we were in draft 6 -- that key=value pairs
> are separated by nulls, not terminated by nulls.  If I remember
> correctly, one of the primary reasons that this was changed going to draft
> 7 is that implementations prefer to treat each key=value pair as one string,
> and in C and C++, strings are null terminated.
> 
> I do not believe this change is in any way necessary for the LTDS or
> C-bit mechanism, and would request that it be put back to the way it has
> been from draft 7 through draft 12-94:
> 
> "Every key=value pair, including the last or only pair in a LTDS,
> MUST be followed by one null (0x00) delimiter."
> 
> Thanks
> 
> Bob Russell