Subject: RE: [lemonade] WGLC compress-02

From: Randall Gellens <[email-masked]>
Date: Tue, 1 Aug 2006 17:58:03 -0700

At 11:14 AM +0300 7/31/06, &lt;[email-masked]&gt; wrote:

>  &gt;  Section 3:
>  &gt;  &quot;The client MUST NOT send any 
> commands until it has seen the result
>  &gt; of COMPRESS.&quot; This is fine, but can 
> the server send anything else in
>  &gt; the meantime? I mean I can turn it on at any time during the session.
>
>  The server can't send anything else (such as an 
> unsolicited response) in the meantime .  This 
> seems obvious but could be explicitly stated.
>  [ZÖr] This is true only if You issue the 
> command during login I guess - if You issue it 
> during some other time during the session, You 
> might get other responses as well.

The server can't send anything between the time 
it sees the COMPRESS command and when it sends 
the response to it.  So the only ambiguity comes 
if the client has an outstanding command (one 
that it hasn't seen the tagged response to). 
Clients would see responses related to the 
outstanding command before seeing responses to 
the COMPRESS, but presumably the client knows if 
it has outstanding responses and won't get 
confused.

This will need to be clarified when we do the 
SMTP COMPRESS draft, by the way (pipeling and 
COMPRESS).

>  &gt;From Your response below to my question 
> below it seems that this command can be used 
> only once - but the draft does not say that it 
> is the login phase during which it has to be 
> used when compression is desired.

If the command succeeds, it can't be reissued. 
See Section 3, where it says a BAD response is 
issued if COMPRESS is already active.

It can be issued at any time during the session, however.

>  Thank you.
>
>  &gt;
>  &gt;  Section 3 and section 5:
>  &gt;  How can it be turned off?
>
>  By logging out and back in.  The added 
> complexity of allowing it to be turned off 
> doesn't seem to be justified by the low utility.
>  [ZÖr] Question: if I do a quick reconnect, will 
> the compression state be restored? (in which 
> case disconnect will not help me much).

I wouldn't expect this to be the case.  It would 
need to be added to the reconnect document in 
order to do so, and I can't see any benefit. 
Plus, the reconnect document is morphing into a 
re-select.

>  Another thing is that when I store an email 
> that contains an uncompressable (JPG, ZIP) 
> file, I might want to switch compression off 
> before uploading it, and turn it back on 
> afterwards. I am sure that this has been 
> discussed, but I do not seem to be able to find 
> the related emails - so I ask it again to get 
> the right answers.

This is discussed in the document in Section 4. 
The compressing side uses the zlib API to set the 
level to 0 before sending such data, and resets 
it to a non-zero value afterwards.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Demagogue: One who preaches doctrines he knows to be untrue to men he
knows to be idiots.                                    --H.L. Mencken

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 2 Aug 2006 10:47:29 +0200

Randall Gellens writes:
> The server can't send anything between the time it sees the COMPRESS 
> command and when it sends the response to it.

It can, though... "* 8586513070 EXISTS" or "* ALERT Server shutdown in 
600 seconds" for example. Of course it's very unlikely.

> So the only ambiguity comes if the client has an outstanding command 
> (one that it hasn't seen the tagged response to). Clients would see 
> responses related to the outstanding command before seeing responses 
> to the COMPRESS, but presumably the client knows if it has 
> outstanding responses and won't get confused.

Yes. Lots of clients do this sort of thing and handle it just fine.

The other case (an outstanding command which is not completed before 
COMPRESS) is also well-defined, but at least some clients don't handle 
it. However, this is not a COMPRESS issue, it applies to any IMAP 
command pair where the second command is much faster than the first and 
the server can do concurrent execution. I've seen it with base IMAP 
(STORE 1:*+STORE 1 and a freezing  mutt).

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 02 Aug 2006 18:26:46 +0100

Randall Gellens wrote:

>>  >  Section 3 and section 5:
>>  >  How can it be turned off?
>>
>>  By logging out and back in.  The added complexity of allowing it to 
>> be turned off doesn't seem to be justified by the low utility.
>>  [ZÖr] Question: if I do a quick reconnect, will the compression 
>> state be restored? (in which case disconnect will not help me much).
>
> I wouldn't expect this to be the case.

Resuming compression state on both sides of the connection would be a 
nightmare. It sounds that reestablishing COMPRESS would be much simpler.

There is a similar issue with reestablishing TLS. However STARTTLS is 
already quite capable of doing that already. I would not want to 
complicate [server side] reconnect by tying TLS state to it.

> It would need to be added to the reconnect document in order to do so, 
> and I can't see any benefit. Plus, the reconnect document is morphing 
> into a re-select.

---

From: Randall Gellens <[email-masked]>
Date: Wed, 2 Aug 2006 14:20:12 -0700

At 10:47 AM +0200 8/2/06, Arnt Gulbrandsen wrote:

>>  The server can't send anything between the time it sees the 
>> COMPRESS command and when it sends the response to it.
>
>  It can, though... &quot;* 8586513070 EXISTS&quot; or &quot;* ALERT 
> Server shutdown in 600 seconds&quot; for example. Of course it's 
> very unlikely.

I thought the draft prohibited unsolicited responses after seeing 
COMPRESS.  Likely I'm thinking of something else.  But perhaps we 
should disallow this?
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Do files get embarrassed when they are unzipped?

---

From: Tony Hansen <[email-masked]>
Date: Wed, 02 Aug 2006 17:27:55 -0400

I don't see the problem with unsolicited responses arriving before the
"x OK Compression starting now" response. They just can't be compressed
and should be treated the same way as any other unsolicited responses to
any other command.

	Tony Hansen
	[email-masked]

Randall Gellens wrote:
>> Server shutdown in 600 seconds&quot; for example. Of course it's very
>> unlikely.
> 
> COMPRESS.  Likely I'm thinking of something else.  But perhaps we should
> disallow this?

---

From: Philip Guenther <[email-masked]>
Date: Wed, 2 Aug 2006 14:30:18 -0700

On Wed, 2 Aug 2006, Randall Gellens wrote:
...
> I thought the draft prohibited unsolicited responses after seeing COMPRESS. 
> Likely I'm thinking of something else.  But perhaps we should disallow this?

How can the server know that the client is going to send COMPRESS next? 
The restriction you suggest would effectively ban sending of untagged 
responses when no commands are pending.

Philip Guenther

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 2 Aug 2006 23:37:41 +0200

> COMPRESS.  Likely I'm thinking of something else.  But perhaps we 

The draft does not prohibit unsolicited responses after the client sends 
compress (before the server receives it), and that cannot be 
prohibited.

Arnt

---

From: Dave Cridland <[email-masked]>
Date: Wed, 02 Aug 2006 22:39:58 +0100

> and should be treated the same way as any other unsolicited 

Right. The ones arriving after the server's OK are actually harder to 
deal with, I find, but clients just have to be careful about that.

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: Randall Gellens <[email-masked]>
Date: Wed, 2 Aug 2006 15:00:50 -0700

At 11:37 PM +0200 8/2/06, Arnt Gulbrandsen wrote:

>  The draft does not prohibit unsolicited responses after the client 
> sends compress (before the server receives it), and that cannot be 
> prohibited.

Of course we can't prohibit sending unsolicited responses between 
when the client sent COMPRESS and when the server sees it.  I was 
talking about after the server sees it.  I was thinking perhaps we 
could prohibit unsolicited responses starting at the time that, after 
the server has seen COMPRESS, it has sent the tagged response to all 
outstanding commands, and ending at the time after it has sent the 
tagged response to COMPRESS.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
The two most common elements in the universe are hydrogen
and stupidity.                           --Harlan Ellison

---

From: Philip Guenther <[email-masked]>
Date: Wed, 2 Aug 2006 15:19:11 -0700

...
>> compress (before the server receives it), and that cannot be prohibited.
>
> Of course we can't prohibit sending unsolicited responses between when the 
> client sent COMPRESS and when the server sees it.  I was talking about after 
> the server sees it.  I was thinking perhaps we could prohibit unsolicited 
> responses starting at the time that, after the server has seen COMPRESS, it 
> has sent the tagged response to all outstanding commands, and ending at the 
> time after it has sent the tagged response to COMPRESS.

The moment when the server reads the COMPRESS command is not an observable 
event, so it's impossible to tell from the TCP stream whether a server's 
sending of untagged responses between the final tagged response and the 
tagged response to COMPRESS was legal or not.  Therefore the ban you 
describe would't help clients in any way as they would still have to 
handle such untagged responses.

Philip Guenther

---

From: Tony Hansen <[email-masked]>
Date: Wed, 02 Aug 2006 18:21:08 -0400

Randall Gellens wrote:
> Of course we can't prohibit sending unsolicited responses between when
> the client sent COMPRESS and when the server sees it.  I was talking
> about after the server sees it.  I was thinking perhaps we could
> prohibit unsolicited responses starting at the time that, after the
> server has seen COMPRESS, it has sent the tagged response to all

Why? The client will have to handle any unsolicited responses that were
in the pipeline anyway. So why have a prohibition on the server
generating some more before it sends the OK response? It seems like a
development choice for the server as to which way is easier, and has no
affect on the client implementation.

	Tony Hansen
	[email-masked]

---

From: Randall Gellens <[email-masked]>
Date: Wed, 2 Aug 2006 15:40:00 -0700

At 2:30 PM -0700 8/2/06, Philip Guenther wrote:

>  How can the server know that the client is going to send COMPRESS 
> next? The restriction you suggest would effectively ban sending of 
> untagged responses when no commands are pending.

No, I said &quot;seeing&quot; not &quot;sending&quot;.  Meaning after 
the server sees COMPRESS.  Of course the server can't know what the 
client is about to do :-)

But as Tony has pointed out none of this is needed.

-------------- Randomly-selected tag: ---------------
Rank of Catwoman among the "superheroes" American boys under the
age of ten say they would most like to be: 1.
                                              --(Harper's Index)

---

From: Randall Gellens <[email-masked]>
Date: Wed, 2 Aug 2006 15:38:17 -0700

At 5:27 PM -0400 8/2/06, Tony Hansen wrote:

>  &quot;x OK Compression starting now&quot; response. They just can't 
> be compressed

You're right -- there's no problem; data is compressed starting when 
the server sends the tagged OK to COMPRESS.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Violence is the last refuge of the incompetent.
                Salvador Hardin

---

From: Randall Gellens <[email-masked]>
Date: Wed, 2 Aug 2006 15:40:00 -0700

---

From: Randall Gellens <[email-masked]>
Date: Wed, 2 Aug 2006 15:38:17 -0700

---

From: Randall Gellens <[email-masked]>
Date: Wed, 2 Aug 2006 15:48:17 -0700

At 3:19 PM -0700 8/2/06, Philip Guenther wrote:

>  The moment when the server reads the COMPRESS command is not an 
> observable event, so it's impossible to tell from the TCP stream 
> whether a server's sending of untagged responses between the final 
> tagged response and the tagged response to COMPRESS was legal or 
> not.

Well, we often have prohibitions that are not strictly observable 
from the TCP stream, for example, SMTP requires servers to safeguard 
messages.  How can such a thing be observed on the wire?

Here is an excerpt from RFC 2821:

6.1 Reliable Delivery and Replies by Email

    When the receiver-SMTP accepts a piece of mail (by sending a 
&quot;250 OK&quot;
    message in response to DATA), it is accepting responsibility for
    delivering or relaying the message.  It must take this responsibility
    seriously.  It MUST NOT lose the message for frivolous reasons, such
    as because the host later crashes or because of a predictable
    resource shortage.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
In America, anyone can become president.  That's one of the
risks you take.                           --Adlai Stevenson

---

From: Randall Gellens <[email-masked]>
Date: Wed, 2 Aug 2006 18:31:31 -0700

In thinking about this some more, the prohibition might be needed on 
the client side, not the server.  The client should not send any 
commands to the server between the time it sends COMPRESS and when it 
gets the tagged response for it.   Otherwise there is ambiguity on 
the server side as to if the data was compressed or not, since the 
server doesn't know when the client saw the response.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Resistance is Useless!             (If less than one ohm.)

---

From: Tony Hansen <[email-masked]>
Date: Wed, 02 Aug 2006 22:52:35 -0400

This I agree with.

	Tony Hansen
	[email-masked]

Randall Gellens wrote:
> In thinking about this some more, the prohibition might be needed on the
> client side, not the server.  The client should not send any commands to
> the server between the time it sends COMPRESS and when it gets the
> tagged response for it.   Otherwise there is ambiguity on the server
> side as to if the data was compressed or not, since the server doesn't
> know when the client saw the response.

---

From: Philip Guenther <[email-masked]>
Date: Wed, 2 Aug 2006 19:58:58 -0700

On Wed, 2 Aug 2006, Randall Gellens wrote:
> client side, not the server.  The client should not send any commands to the 
> server between the time it sends COMPRESS and when it gets the tagged 
> response for it.   Otherwise there is ambiguity on the server side as to if 
> the data was compressed or not, since the server doesn't know when the client 
> saw the response.

Yep.  Arnt already put such a restriction in.  To quote compress-03:
     The client MUST NOT send any 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, and the server MUST
     compress starting with the first response after the OK.

Philip Guenther

---

From: "Ben Last" <[email-masked]>
Date: Thu, 3 Aug 2006 10:04:39 +0100

Randall Gellens [mailto:[email-masked]] wrote, at 03 August 2006

>In thinking about this some more, the prohibition might be needed on
the client side, not the server.
>The client should not send any commands to the server between the time
it sends COMPRESS and when it
>gets the tagged response for it.   Otherwise there is ambiguity on the
server side as to if the data
>was compressed or not, since the server doesn't know when the client
saw the response.
Agreed, fervently.  Also the client won't know whether the COMPRESS
command was accepted (or provoked a NO or BAD response), so it can't
begin compression anyway.

Regards
Ben
EMCC Software Ltd

---

From: "Ben Last" <[email-masked]>
Date: Thu, 3 Aug 2006 10:01:28 +0100

>I don't see the problem with unsolicited responses arriving before the
"x OK Compression starting now"
>response. They just can't be compressed and should be treated the same
way as any other unsolicited
>responses to any other command.
Speaking as a client developer here, I agree: as long as the client has
some way in which it can detect the change from uncompressed to
compressed server responses (ie, the x OK to the compress command), life
is simple.  No client should assume that, after sending the compression
start command, compression will start: the server is always at liberty
to say NO or BAD (and they so often do... :)

Regards
ben

---

From: <[email-masked]>
Date: Thu, 3 Aug 2006 14:15:50 +0300

Thank You Randall, just two questions and two comments (see [ZÖr] tags below).

Best regards: Zoltán Ördögh
E-mail: zoltan dot ordogh at nokia dot com
Phone: +358 50 386 0566

-----Original Message-----
From: ext Randall Gellens [mailto:[email-masked]] 
Sent: 02 August, 2006 03:58
To: Ordogh Zoltan (Nokia-TP-MSW/Tampere); [email-masked]
Subject: RE: [lemonade] WGLC compress-02

At 11:14 AM +0300 7/31/06, &lt;[email-masked]&gt; wrote:

>  &gt;  Section 3:
>  &gt;  &quot;The client MUST NOT send any commands until it has seen 
> the result  &gt; of COMPRESS.&quot; This is fine, but can the server 
> send anything else in  &gt; the meantime? I mean I can turn it on at 
> any time during the session.
>
>  The server can't send anything else (such as an unsolicited response) 
> in the meantime .  This seems obvious but could be explicitly stated.
>  [ZÖr] This is true only if You issue the command during login I guess 
> - if You issue it during some other time during the session, You might 
> get other responses as well.

The server can't send anything between the time it sees the COMPRESS command and when it sends the response to it.  So the only ambiguity comes if the client has an outstanding command (one that it hasn't seen the tagged response to). 
Clients would see responses related to the outstanding command before seeing responses to the COMPRESS, but presumably the client knows if it has outstanding responses and won't get confused.

This will need to be clarified when we do the SMTP COMPRESS draft, by the way (pipeling and COMPRESS).
[ZÖr] Certainly pipelining is an issue and we are going to have to deal with it any way. However, there might be a latency (we need to think about mobile devices here) between the client issuing the COMPRESS command and the server "seeing" it. Hence my dilemma. Client sends it, fine, but there might be other server responses coming from the server in the meantime (even after the server has "seen" the command since there might be latency on the way back as well). So, I suggest adding something like "The client MAY receive other responses from the server before before receiving the result of the COMPRESS command. The client MUST treat these "intermediate" responses as if the COMPRESS command was not issued." Or, something like this.
What do You think?

>  &gt;From Your response below to my question below it seems that this 
> command can be used only once - but the draft does not say that it is 
> the login phase during which it has to be used when compression is 
> desired.

If the command succeeds, it can't be reissued. 
See Section 3, where it says a BAD response is issued if COMPRESS is already active.
[ZÖr] I think it would be beneficial to capture this fact "If the command succeeds, it can't be reissued.". Turning on compression is one thing -.You can turn it on only once, fine. But how about when the compression method is to be changed (EG. DEFLATE to something else)? <- Just to think about being future-proof.

>  [ZÖr] Question: if I do a quick reconnect, will the compression state 
> be restored? (in which case disconnect will not help me much).

I wouldn't expect this to be the case.  It would need to be added to the reconnect document in order to do so, and I can't see any benefit. 
Plus, the reconnect document is morphing into a re-select.
[ZÖr] I did not see that "morphing" - probably it something I missed during the meeting. If RECONNECT will be changed, it will not be an issue, but if not, we need to address it one way or another.

>  Another thing is that when I store an email that contains an 
> uncompressable (JPG, ZIP) file, I might want to switch compression off 
> before uploading it, and turn it back on afterwards. I am sure that 
> this has been discussed, but I do not seem to be able to find the 
> related emails - so I ask it again to get the right answers.

This is discussed in the document in Section 4. 
The compressing side uses the zlib API to set the level to 0 before sending such data, and resets it to a non-zero value afterwards.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 3 Aug 2006 11:29:32 +0200

> deal with, I find, but clients just have to be careful about that.

Clients that support STARTTLS already know how to handle this.

Arnt

---

From: Randall Gellens <[email-masked]>
Date: Thu, 3 Aug 2006 09:57:12 -0700

Hi Zoltan,

I've edited the quoted text down to make it 
easier to follow (your email client's unfortunate 
lack of support for RFC 3676 quoting makes it 
very confusing).

>  [ZÖr] Certainly pipelining is an issue and we 
> are going to have to deal with it any way. 
> However, there might be a latency (we need to 
> think about mobile devices here) between the 
> client issuing the COMPRESS command and the 
> server &quot;seeing&quot; it. Hence my dilemma. 
> Client sends it, fine, but there might be other 
> server responses coming from the server in the 
> meantime (even after the server has 
> &quot;seen&quot; the command since there might 
> be latency on the way back as well). So, I 
> suggest adding something like &quot;The client 
> MAY receive other responses from the server 
> before before receiving the result of the 
> COMPRESS command. The client MUST treat these 
> &quot;intermediate&quot; responses as if the 
> COMPRESS command was not issued.&quot; Or, 
> something like this.
>  What do You think?

I think it is sufficient to say that compression 
starts on the server side when it sends the OK 
response to COMPRESS, and on the client side when 
it sees the OK response.

>  [ZÖr] I think it would be beneficial to capture 
> this fact &quot;If the command succeeds, it 
> can't be reissued.&quot;.

I think it is already captured since the draft 
says a BAD response is issued if COMPRESS is 
already active.

>  Turning on compression is one thing -.You can 
> turn it on only once, fine. But how about when 
> the compression method is to be changed (EG. 
> DEFLATE to something else)? &lt;- Just to think 
> about being future-proof.

I can't see any value in adding complexity just 
to permit either side to decide to renegotiate 
the compression algorithm.  I find it very hard 
to imagine a case where this would be useful.  If 
there is such a case, an additional TCP 
connection can established.  Existing IMAP 
clients often have multiple TCP connections to 
the IMAP server active.

>  [ZÖr] I did not see that &quot;morphing&quot; - 
> probably it something I missed during the 
> meeting.

The document itself has morphed.  Especially with 
client-side reconnect, it is mailbox selection 
that is being made quicker.

>  If RECONNECT will be changed, it will not be an 
> issue, but if not, we need to address it one 
> way or another.

Sorry for not being more clear in my earlier 
reply: even if there is a session-resumption 
draft, compression is extremely unlikely to be 
part of that.  It makes much more sense to 
reestablish compression that to resume it.

-------------- Randomly-selected tag: ---------------
To define recursion, we must first define recursion.

---

From: <[email-masked]>
Date: Fri, 4 Aug 2006 12:22:30 +0300

I've edited the quoted text down to make it easier to follow (your email client's unfortunate lack of support for RFC 3676 quoting makes it very confusing).
[ZÖr] Yes, I get this all the time.

>  [ZÖr] Certainly pipelining is an issue and we are going to have to 
> deal with it any way.
> However, there might be a latency (we need to think about mobile 
> devices here) between the client issuing the COMPRESS command and the 
> Client sends it, fine, but there might be other server responses 
> coming from the server in the meantime (even after the server has 
> &quot;seen&quot; the command since there might be latency on the way 
> back as well). So, I suggest adding something like &quot;The client 
> MAY receive other responses from the server before before receiving 
> the result of the COMPRESS command. The client MUST treat these 
> &quot;intermediate&quot; responses as if the COMPRESS command was not 
> issued.&quot; Or, something like this.
>  What do You think?

I think it is sufficient to say that compression starts on the server side when it sends the OK response to COMPRESS, and on the client side when it sees the OK response.
[ZÖr] So, You agree to what I wrote but You do not see value in adding it to the draft? I can live with this as long as You confirm that text I suggested above is valid.

>  [ZÖr] I think it would be beneficial to capture this fact &quot;If 
> the command succeeds, it can't be reissued.&quot;.

I think it is already captured since the draft says a BAD response is issued if COMPRESS is already active.
[ZÖr] BAD response will come only when COMPRESS is already active, not in any other case, right? (Just checking future-proofness where other compression algorythms mgith be added.)

>  If RECONNECT will be changed, it will not be an issue, but if not, we 
> need to address it one way or another.

Sorry for not being more clear in my earlier
reply: even if there is a session-resumption draft, compression is extremely unlikely to be part of that.  It makes much more sense to reestablish compression that to resume it.
[ZÖr] I recognize this as a good thing - it is possible to quickly turn compression off by using RECONNECT then.

---

From: Tony Hansen <[email-masked]>
Date: Fri, 04 Aug 2006 09:03:08 -0400

> [ZÖr] So, You agree to what I wrote but You do not see value in adding it to the draft? I can live with this as long as You confirm that text I suggested above is valid.

Your analysis is correct.

The compression starts on the server side immediately >>after<< it has
issued the OK response and its trailing CRLF. Unsolicited responses sent
by the server >>before<< it issues the OK response must still be
uncompressed.

Here is some suggested replacement text for this text from section 3:

<    The client MUST NOT send any commands until it has seen the result
<    ... compress starting with the first response after the OK.

    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.

    If the server issues an OK response, the server MUST compress
    starting with the first response after the CRLF ending the OK
    response. (Unsolicited responses issued by the server before the OK
    response will, of course, still be uncompressed.) If the server
    issues a BAD or NO respnose, the server MUST NOT turn on
    compression.

> [ZÖr] BAD response will come only when COMPRESS is already active, not in any other case, right? (Just checking future-proofness where other compression algorythms mgith be added.)

I think the text in -03 is adequate and complete.

    Result: OK The server will compress its responses and expects the
               client to compress its commands.
            NO The server doesn't support the requested mechanism.
           BAD Command unknown, invalid argument, or COMPRESS already
               active.

So there are three cases that could lead to a BAD response; compression
already being active is one of those cases.

> [ZÖr] I recognize this as a good thing - it is possible to quickly turn compression off by using RECONNECT then.

Instead of reconnecting to turn off compression, it is also possible,
and even easier, to dynamically crank down the level of compression at
any time during the conversation. This could set the amount of
compression to 0 while leaving the compression layer in place. Once
you're done with a section of the conversation that needs no
compression, dynamically crank it back up again. Both the server and
client have full control.

	Tony Hansen
	[email-masked]

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 4 Aug 2006 15:34:07 +0200

Tony Hansen writes:
>>  I think it is sufficient to say that compression starts on the 
>>  server side when it sends the OK response to COMPRESS, and on the 
>>  client side when it sees the OK response.
>>  [ZÖr] So, You agree to what I wrote but You do not see value in 
>>  adding it to the draft? I can live with this as long as You confirm 
>>  that text I suggested above is valid.
>
> issued the OK response and its trailing CRLF. Unsolicited responses 
> sent by the server >>before<< it issues the OK response must still be 
> uncompressed.
>
>     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.
>
>     response. (Unsolicited responses issued by the server before the 
>     OK response will, of course, still be uncompressed.) If the 
>     server issues a BAD or NO respnose, the server MUST NOT turn on 
>     compression.

Seems a little superfluous.... but since I tend to be a little on the 
brief side, I added the text. Except the word unsolicited, which IMO 
restricts the sentence unjustifiedly.

Arnt

---

From: Tony Hansen <[email-masked]>
Date: Fri, 04 Aug 2006 09:55:17 -0400

Arnt Gulbrandsen wrote:
> brief side, I added the text. 

sounds good

> Except the word unsolicited, which IMO

sounds good

	Tony Hansen
	[email-masked]

---

From: <[email-masked]>
Date: Fri, 4 Aug 2006 17:11:28 +0300

Tony and Arnt,
thank You.
I have no further questions/comments.

-----Original Message-----
From: ext Arnt Gulbrandsen [mailto:[email-masked]] 
Sent: 04 August, 2006 16:34
To: [email-masked]
Subject: Re: [lemonade] WGLC compress-02

>     server issues a BAD or NO respnose, the server MUST NOT turn on 

Seems a little superfluous.... but since I tend to be a little on the brief side, I added the text. Except the word unsolicited, which IMO restricts the sentence unjustifiedly.

Arnt