Subject: Re: [lemonade] Compress result code

From: "Burger, Eric" <[email-masked]>
Date: Tue, 11 Jul 2006 19:20:30 -0400

How would a client not know? If it loses its mind and decides, "I want compression now," the server KEEPS COMPRESSION ON and says, "Here you go: compression is on."

Or, am I missing the point: the client, which by the way is already handling transport-layer encryption (because it can have a dialog with the server in the first place) is really going to invoke another instance of a transport-layer compression engine that will compress / decompress the already compressed stream?

--
Sent from my Palm Treo - Sorry if Terse

 -----Original Message-----
From: 	Dave Cridland [mailto:[email-masked]]
Sent:	Tuesday, July 11, 2006 07:08 PM Eastern Standard Time
To:	Burger, Eric
Cc:	Enhancements to Internet email to support diverse service enivronments
Subject:	Re: [lemonade] Compress result code

On Tue Jul 11 18:50:22 2006, Burger, Eric wrote:
> Why "NO" if the connection is already compressed?  Wouldn't "OK" be 
> ok?
> Otherwise, if the connection is already compressed, and I see a 
> "NO", I
> might think that the connection is now no longer compressed.

In my code, a successful result to a COMPRESS command inserts a new 
compression layer.

NO is fine.

BAD is arguably better, except that there are times when you don't 
know if the TLS layer has already done compression for you, as a 
client, so it's a good faith error - a NO - rather than a bug - a BAD.

I'd be happy with a second COMPRESS command causing a BAD, though.

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
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Dave Cridland <[email-masked]>
Date: Wed, 12 Jul 2006 00:27:23 +0100

On Wed Jul 12 00:20:30 2006, Burger, Eric wrote:
> How would a client not know? If it loses its mind and decides, "I 
> want compression now," the server KEEPS COMPRESSION ON and says, 
> "Here you go: compression is on."
> 
> 
My client has, unfortunately, no idea at all if the TLS 
implementation has negotiated compression. It's a product of the API. 
So where TLS is compressing, I want COMPRESS to say NO. If it said 
BAD, it'd raise a dialog box telling the user I screwed up.

> Or, am I missing the point: the client, which by the way is already 
> handling transport-layer encryption (because it can have a dialog 
> with the server in the first place) is really going to invoke 
> another instance of a transport-layer compression engine that will 
> compress / decompress the already compressed stream?

Transport-layer, no. Application layer, yes.

If my client were to send two COMPRESS commands, then an OK to the 
second would break it. It'd be broken anyway, of course, in order to 
send the second COMPRESS, so realistically, I think we should say BAD 
here.

Dave.

---

From: Lyndon Nerenberg <[email-masked]>
Date: Tue, 11 Jul 2006 17:37:26 -0600 (MDT)

> If my client were to send two COMPRESS commands, then an OK to the second 
> would break it. It'd be broken anyway, of course, in order to send the second 
> COMPRESS, so realistically, I think we should say BAD here.

If your client can't tell what the TLS layer is doing then it cannot know 
that the TLS layer didn't decide to turn compression off (why is 
immaterial) after that first COMPRESS command was issued.

Since the IMAP stream cannot know what the TLS layer is doing, COMPRESS is 
at best a hint, and could very well be a no-op.  Therefore the responses 
of OK and NO are equally valid (and content free), and BAD should only be 
issued when the server does not support the COMPRESS command at all.

--lyndon

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 12 Jul 2006 00:55:56 +0100

Lyndon Nerenberg wrote:

> If your client can't tell what the TLS layer is doing then it cannot 
> know that the TLS layer didn't decide to turn compression off (why is 

Right.

> Since the IMAP stream cannot know what the TLS layer is doing, 
> COMPRESS is at best a hint, and could very well be a no-op.  Therefore 
> the responses of OK and NO are equally valid

I am Ok with this.

> (and content free),

> and BAD should only be issued when the server does not support the 
> COMPRESS command at all.

If the client sends COMPRESS twice this is clearly an error and the 
second COMPRESS must result in BAD. But I wouldn't complain about server 
that sends NO.

---

From: Lyndon Nerenberg <[email-masked]>
Date: Tue, 11 Jul 2006 18:01:07 -0700

On Jul 11, 2006, at 4:55 PM, Alexey Melnikov wrote:

> second COMPRESS must result in BAD. But I wouldn't complain about  
> server that sends NO.

No it's not, since the client cannot reliably determine the state of  
compression at any given moment.  And why the hell should the server  
even care?  Tracking the state is just extra useless code in the server.

--lyndon

---

From: Dave Cridland <[email-masked]>
Date: Wed, 12 Jul 2006 08:48:43 +0100

On Wed Jul 12 00:37:26 2006, Lyndon Nerenberg wrote:
>> second would break it. It'd be broken anyway, of course, in order 
>> to send the second COMPRESS, so realistically, I think we should 
>> say BAD here.
> 
> If your client can't tell what the TLS layer is doing then it 
> cannot know that the TLS layer didn't decide to turn compression 
> off (why is immaterial) after that first COMPRESS command was 
> issued.
> 
> 
This, and other cases, are all true, but not cases that I 
particularly care about optimizing for.

> COMPRESS is at best a hint, and could very well be a no-op.  
> Therefore the responses of OK and NO are equally valid (and content 
> free), and BAD should only be issued when the server does not 
> support the COMPRESS command at all.

Reading this and subsequent messages makes me think you've 
misunderstood the draft.

The client might not know about TLS level compression, and even the 
server might not. But both absolutely should know about application 
layer compression, because they're doing it.

If an application tries to insert two compression layers, this is 
obviously an error. It's an excusable error if the two compression 
layers are in different locations in the stack, although both ends 
should be trying to avoid this, but it's a programming error if the 
two layers are the same.

In particular, the COMPRESS command is never a no-op if it succeeds.

Dave.