Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-compress-05.txt - comments

From: <[email-masked]>
Date: Wed, 1 Nov 2006 12:43:43 +0200

Hi Randall,

>>  3. Wording change suggestion in section 3:
>>  OK The server will compress its responses and expects the client to 
>> compress its commands.
>>  to:
>>  OK The server and the client will compress all data that it may send
>
>"data that it may send" sounds funny.  The original text is 
>very clear about which side compresses what (commands versus 
>responses). 
>Is there something about it you don't like?

Yes, in another thread I replied already that it is the "expects" that I
do not like. That's what I tried to change, but I collapsed the client
commands and server responses into a single "data", I guess this is
something I should not have done.
I would like to get rid of "expects" though because it hints that it
might not happen.

>>  4. Wording change suggestion in section 3:
>>  The client MUST NOT send any further commands until it has seen the 
>> result of COMPRESS.
>>  to:
>>  After the client has sent the COMPRESS command, the client MUST NOT 
>> send any commands until it has seen the result of COMPRESS.
>
>I think the original wording is better as it is more compact and says 
>what it needs to.  But perhaps I'm missing something.  What about it 
>don't you like?

Here, the intent was to clarify the exact interval - I mean only the end
of the interval clear, but the beginning is not. What I miss here is
that the client MUST NOT send anything between issuing the COMPRESS
command and receiving the response to it. We do not know when the
"client silence" starts.

>>  5. Clarification/wording change suggestion in section 3:
>>  (Responses issued by the server before the OK response will, of 
>> course, still be uncompressed.)
>>  to:
>>  Therefore, responses issued by the server before the OK response 
>> will all be uncompressed, and delayed client requests that have 
>> been sent uncompressed (before turning compression on) may result 
>> in compressed responses.
>
>What are "delayed client requests"?  Do you mean commands sent by the 
>client before it sent COMPRESS that were delayed by underlying 
>network (perhaps routed differently)?  Or do you mean something else? 
>If the server receives uncompressed commands after it has sent the OK 
>to COMPRESS, will it interpret them correctly?  The original text 
>implies no, but your suggested text states yes.

No, this is exactly what I meant - perhaps the wording is not right, but
this is what I tried to capture. Latency of commands/responses.
I did not think about the second question You raised, but it's a good
one - I looked at it from the client point view only.
Let's check using a use case here. Let's assume that client issues
commands a, b, COMPRESS, d, e.
My proposal:
 - server receives a, b, COMPRESS, d, e (the right order)
 - server responds a, b, COMPRESS, d, e (the right order, again).
 - there is some latency, therefore client receives repsonses a,
COMPRESS, b, d, e
Your question:
 - server receives a, COMPRESS, b, d, e (not in the right order)

In theory, TCP/IP should guarantee the right order and we should not
worry about his at all. Just a tought that's been bugging me. It's
better to ask than not to say anything.

>>  7. Wording change suggestion in section 4:
>>  the same way as is recommended for servers
>>  the same way as it is recommended for servers later
>
>Why do you want to change "as is" to "as it is"?  The suggested 
>wording sounds awkward to me, and implies that a source other than 
>this draft is doing the recommending.

It sounded like the "it" was missing.

>>  9. Question in section 5:
>>  capability  =/ "COMPRESS=" algorithm
>>                        ;; multiple COMPRESS capabilities allowed
>>  So, if I had multiple algorithms, would it be COMPRESS=1,2,3 or 
>> COMPRESS=1,COMPRESS=2,COMPRESS=3? I would guess the second.
>
>That's correct, and matches what has been done for some other 
>extensions.
>
>Note that the ABNF for your first alternate would be
>	"COMPRESS=" algorithm *( "," algorithm )

This is what I wanted to hear - should it be described already here? (To
prepare clients/servers to deal with the *( "," algorithm ) part?

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Dave Cridland <[email-masked]>
Date: Wed, 01 Nov 2006 12:13:58 +0000

> better to ask than not to say anything.
No, we shouldn't worry about it at all.

I vaguely recall something about reliable streams in RFC3501, but 
basically any protocol used below IMAP in the stack has to sort this 
out for us. TCP does, as do COMPRESS=DEFLATE and TLS. (Which both 
gain reliability from lower down in the stack and simply pass it up)

> prepare clients/servers to deal with the *( "," algorithm ) part?

No, it'd be "[...] COMPRESS=DEFLATE COMPRESS=NEWONE [...]", like 
AUTH= works, and that's already covered by the ABNF.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: <[email-masked]>
Date: Wed, 1 Nov 2006 15:22:31 +0200

Thank You Dave,

>I vaguely recall something about reliable streams in RFC3501, 
>but basically any protocol used below IMAP in the stack has to 
>sort this out for us. TCP does, as do COMPRESS=DEFLATE and 
>TLS. (Which both gain reliability from lower down in the stack 
>and simply pass it up)

In a related thread - because I did not provide enough information - it
was mentioned that the different order might originate from server
processing the commands in different order. I guess this is something we
do not need to worry about, because it's a basic requirement in IMAP to
process the commands in an orderly fashion, right?

>> This is what I wanted to hear - should it be described already here? 
>> (To prepare clients/servers to deal with the *( "," algorithm ) part?
>
>No, it'd be "[...] COMPRESS=DEFLATE COMPRESS=NEWONE [...]", 
>like AUTH= works, and that's already covered by the ABNF.

Ok.

---

From: Dave Cridland <[email-masked]>
Date: Wed, 01 Nov 2006 13:43:33 +0000

> process the commands in an orderly fashion, right?
No, that's *not* a basic requirement.

IMAP servers can process commands in any order they like, including 
concurrently, as long as the reordering has no side-effects. Equally, 
clients which depend on certain commands being processed in-order 
need to issue them one at a time, and not pipeline them.

I think someone suggested the example of:

C: A01 CAPABILITY
C: A02 COMPRESS DEFLATE
S: A02 OK Compression starts here
// Now compressed
S: * CAPABILITY [...]
S: A01 OK completed

The untagged capability response is here compressed, but it isn't in 
this next example:

C: A01 CAPABILITY
C: A02 COMPRESS DEFLATE
S: * CAPABILITY [...]
S: A02 OK Compression starts here
// Now compressed
S: A01 OK completed

However, this is pretty contrived - COMPRESS needs to be issued as 
early as possible in IMAP, and you need the CAPABILITY strings to 
know whether to use it or not, and nothing else can be pipelined 
either in an obviously useful way, as far as I can think of.

Dave.

---

From: <[email-masked]>
Date: Wed, 1 Nov 2006 16:03:36 +0200

Thank You Dave,

>IMAP servers can process commands in any order they like, 
>including concurrently, as long as the reordering has no 
>side-effects. Equally, clients which depend on certain 
>commands being processed in-order need to issue them one at a 
>time, and not pipeline them.
>
>The untagged capability response is here compressed, but it 
>isn't in this next example:
>
>C: A01 CAPABILITY
>C: A02 COMPRESS DEFLATE
>S: * CAPABILITY [...]
>However, this is pretty contrived - COMPRESS needs to be 
>issued as early as possible in IMAP, and you need the 
>CAPABILITY strings to know whether to use it or not, and 
>nothing else can be pipelined either in an obviously useful 
>way, as far as I can think of.

Now this does not sound bulletproof, but I am not worried because we are
not server vendors, so we have nothing to worry about as long as the
server works correctly.

---

From: Dave Cridland <[email-masked]>
Date: Wed, 01 Nov 2006 14:38:08 +0000

> not server vendors, so we have nothing to worry about as long as the

Both AUTHENTICATE and STARTTLS have almost precisely the same 
properties, since they both alter the protocol stack by inserting 
layers, so it's a well known issue.

COMPRESS and AUTHENTICATE both negotiate the layer properties in the 
application layer, which is nice, because a failure to negotiate is 
easily recoverable, whereas STARTTLS negotiates the layer properties 
within TLS, but nevertheless, the general technique is well known.

Dave.

---

From: Randall Gellens <[email-masked]>
Date: Wed, 1 Nov 2006 11:33:30 -0800

>  I would like to get rid of "expects" though because it hints that it

But we're talking about an example of a comment inserted by the 
server in its tagged command response.  This is very, very different 
from normative language in a specification.  Please see my more 
detailed comments on this in my message from yesterday.  I think the 
existing wording is fine.

>  command and receiving the response to it. We do not know when the

I think the existing wording is very clear: "MUST NOT send any 
further commands".

However, in re-reading the text in the draft, I do have some 
unrelated suggestions:

     The client MUST NOT send any further commands until it has seen the
     result of COMPRESS. If the response was OK, the client MUST compress
     starting with the first command after COMPRESS. If the server
     response was BAD or NO, the client MUST NOT turn on compression.

The past-tense "was" should be changed to the present-tense "is":

     The client MUST NOT send any further commands until it has seen the
     result of COMPRESS. If the response is OK, the client MUST compress
     starting with the first command after COMPRESS. If the server
     response is BAD or NO, the client MUST NOT turn on compression.

>  this is what I tried to capture. Latency of commands/responses.

Keep in mind that IMAP uses TCP, which provides a reliable, ordered stream.

>   - there is some latency, therefore client receives repsonses a,

TCP provides a reliable, ordered stream, so the responses won't be 
out of order unless the server sends them out of order.

>   - server receives a, COMPRESS, b, d, e (not in the right order)

My question about the server receiving uncompressed commands after 
sending the OK for COMPRESS is about a situation that would occur if 
the client violates the specification by sending an uncompressed 
command after COMPRESS.  In such a case, I'm not sure what the 
compression library will do with the uncompressed data.

>  better to ask than not to say anything.

This isn't anything we need to discuss, because TCP is used and we 
can rely on it.

>  It sounded like the "it" was missing.

I think the existing wording is better.

>  prepare clients/servers to deal with the *( "," algorithm ) part?

My apologies: when I said "that's correct" I was incorrect because 
both of your examples use commas, so I was sloppy in my reply.  The 
ABNF I wrote above was to illustrate why commas are not used: if they 
were used, the ABNF in the document would look like what I wrote. 
Since the ABNF doesn't look like that, commas are not used.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
I distrust those people who know so well what God wants them to
do, because I notice it always coincides with their own desires.
    --Susan B. Anthony

---

From: <[email-masked]>
Date: Thu, 2 Nov 2006 13:26:26 +0200

Hi Randall,

>>   >>  The client MUST NOT send any further commands until it 
>has seen 
>> the
>>>>  result of COMPRESS.
>>>>   to:
>>>>   After the client has sent the COMPRESS command, the client MUST 
>>>> NOT  send any commands until it has seen the result of COMPRESS.
>>>
>>  Here, the intent was to clarify the exact interval - I mean 
>only the 
>> end  of the interval clear, but the beginning is not. What I 
>miss here 
>> is  that the client MUST NOT send anything between issuing the 
>> COMPRESS  command and receiving the response to it. We do not know 
>> when the  "client silence" starts.
>

This sounds good - it would settle my comment.