Subject: Re: null termination of keys

From: "Julian Satran" <[email-masked]>
Date: Tue, 4 Jun 2002 20:31:04 +0300

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 <[email-masked]>
Sent by: [email-masked]
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" <[email-masked]>, [email-masked]
        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" <[email-masked]>
>                                                     To:        Julian 
Satran/Haifa/IBM@IBMIL
>   06/04/2002 09:48 AM                               cc: [email-masked]
>   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

---

From: Luben Tuikov <[email-masked]>
Date: Tue, 04 Jun 2002 14:25:55 -0400

Julian Satran wrote:
> 
> 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.

There was no need for this, since I'm not trying to slow it down.

I was merely suggesting that _existing_ iSCSI concepts be put
down into a more formal manner.

Example of those are 4.1, 1.1 and the current work
by Robert about key dependencies.

That is, my suggestion was no changes at all, just rephrasing.
Then iSCSI will be cleaner and clearer to work with and to be
worked upon.

> In retrospect - the informal nature of almost all TCP/IP was not such a bad thing.

Not quite.

TCP/IP is formal _enough_ to disassociate ambiguities.
(E.g. RFC793/STD7 page 25, 26, 41, all full of inequalites,
equialities and definitions.)