Subject: Re: null termination of keys

From: "Julian Satran" <[email-masked]>
Date: Tue, 4 Jun 2002 16:07:29 +0300

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]>
06/04/2002 09:48 AM
Please respond to "Robert D. Russell"

        To:     Julian Satran/Haifa/IBM@IBMIL
        cc:     [email-masked]
        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 11:38:50 -0400

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:
> 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.
>   06/04/2002 09:48 AM                               cc:        [email-masked]
>   Please respond to "Robert D. Russell"             Subject:        Re: null termination of keys
> 
> 
> 
> Julian:
> 
> 7 is that implementations prefer to treat each key=value pair as one string,

---

From: Bill Studenmund <[email-masked]>
Date: Tue, 4 Jun 2002 09:49:52 -0700 (PDT)

> Let's hear some more voices.

As a C/C++ programmer, I really like the idea of having 0s at the end of a
key/value pair.

I agree with Bob that having key/value pairs terminated by NULs is easier.

Take care,

Bill

---

From: Martins Krikis <[email-masked]>
Date: Tue, 4 Jun 2002 11:31:04 -0700 (PDT)

I agree with Bob and the rest that having '\0'
after the last or only pair in the LTDS is much
nicer than not having it. There is no compelling
reason to try to save a byte here. Please, let's
put back the '\0' after the last or only pair.

Martins Krikis, Intel Corp.

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com