Subject: [lemonade] COMPRESS - NO vs BAD

From: Ken Murchison <[email-masked]>
Date: Mon, 04 Dec 2006 12:11:03 -0500

Is a server implementation supposed to use one of these responses when 
COMPRESS is already active and the other one when compression is active 
in TLS?  It seems like the draft hints that this is the case, but I'm 
not sure.  If only one response is used for both cases, which one is 
correct?  I'm thinking "NO".

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 4 Dec 2006 18:52:16 +0100

Ken Murchison writes:
> COMPRESS is already active and the other one when compression is 
> active in TLS?  It seems like the draft hints that this is the case, 
> but I'm not sure.  If only one response is used for both cases, which 
> one is correct?  I'm thinking "NO".

Or BAD?

As I understand it, BAD is used for the cases where the client shouldn't 
have sent that command, and NO for the cases where the server cannot or 
will not execute the command (entirely), but the client might not know 
that ahead of time.

If that understanding is correct, negotiating compression in TLS and 
then using COMPRESS is a NO thing (the client could reasonably be 
ignorant of what its TLS library negotiated), and when the client sends 
three COMPRESS commands in a row, the last two are BAD.

Personally I lean more towards NO than BAD, but I can see that others 
might reasonably think BAD is the right thing to send in at least some 
cases. I'm entirely willing to tweak the wording in the draft.

(Dave sent you a patch?)

Arnt

---

From: Ken Murchison <[email-masked]>
Date: Mon, 04 Dec 2006 15:23:25 -0500

> three COMPRESS commands in a row, the last two are BAD.

OK.  FWIW, Cyrus IMAP return BAD when the client tries to issue STARTTLS 
more than once.

> cases. I'm entirely willing to tweak the wording in the draft.

It looks like the wording for BAD is OK.  Perhaps the wording for NO 
should read something like:

"..., or compression is already active via another layer"

> (Dave sent you a patch?)

He did, but I was already most of the way there with my own code.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 18 Dec 2006 21:05:54 +0000

Ken Murchison wrote:

>> might reasonably think BAD is the right thing to send in at least 
>> some cases. I'm entirely willing to tweak the wording in the draft.
>

I've just checked -06 and it contains the following text:

> 3.  The COMPRESS Command
>
>     Arguments: Name of compression mechanism: "DEFLATE".
>
>     Responses: None
>
>     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, or
>                the mechanism is already active,

I think "mechanism is already active" is ambiguos. I thought mechanism = 
COMPRESS command here.

So I suggest changing this to:

            NO The server doesn't support the requested mechanism, or
               the compression mechanism is already active via another 
layer (e.g. TLS),

>            BAD Command unknown, invalid argument, or COMPRESS already
>                active.

---

From: Lyndon Nerenberg <[email-masked]>
Date: Mon, 18 Dec 2006 13:18:42 -0800 (PST)

>           NO The server doesn't support the requested mechanism,

If the server doesn't advertise Compress=mumble the client should never 
have issued a Compress command in the first place.  This is a clear 
protocol violation, and merits a BAD response. (This would also be the 
case where Compress=Foo is advertised and the client asks Compress Bar.)

--lyndon

   Always Mount a Scratch Monkey

---

From: Lyndon Nerenberg <[email-masked]>
Date: Mon, 18 Dec 2006 14:35:09 -0800 (PST)

More last call comments on compress.  This are almost all editorial.

-------------------------------------------------------
Section 2:

     Compared to PPP/MNP compression, COMPRESS offers much better
     compression efficiency, and can be used together with TLS [RFC4346],
     SASL encryption, VPNs etc. Compared to TLS compression [RFC3749],
     COMPRESS has the following (dis)advantages:

The text is ambiguous.  It implies PPP/MNP cannot be used with TLS, SASL, etc.
I suggest something like:

     Compared to PPP and MNP compression, COMPRESS offers greater
     compression efficiency. COMPRESS can be used in the presence of
     TLS, SASL encryption, virtual private networks, etc.

     Compared to TLS compression, COMPRESS has the following advantages:

     ...

     and the following disadvantages:

     ...

PPP and MNP should have informative references.

-------------------------------------------------------
Page 1:

The last bullet item speaks of API benefits.  This document can't speak
to the specifics of any particular TLS implementation.  Hell, we can't
even mandate that a COMPRESS implementation support a direct call to flush
the dictionary.  How about:

 	- IMAP COMPRESS benefits from an intimate knowledge of the
 	  IMAP protocol's state machine, allowing for dynamic and
 	  aggressive optimization of the underlying compression
 	  algorithm's parameters.
-------------------------------------------------------
Page 2:

     - When a TLS librarly implements compression, all protocols that use
       TLS automatically are compressed (in LEMONADE's case, SMTP, IMAP,
       and some notification protocol), whereas COMPRESS is specific to
       IMAP.

This sentence is awkward to read, and the last fragment
is redundant.  How about:

 	- When the TLS layer implements compression, any protocol
 	  using that layer can transparently benefit from that compression
 	  (e.g. SMTP and IMAP).
-------------------------------------------------------
Page 2:

     In order to increase interoperation, it is desirable to have as few
     different compression algorithms as possible, so this document
     specifies only one.  The DEFLATE algorithm (defined in [RFC1951]) is
     standard, widely available, unencumbered by patents and fairly
     efficient, so it is the only algorithm defined by this document.

More word-smithing :-)

 	To ensure interoperability, every IMAP client and server
 	supporting COMPRESS MUST support the DEFLATE [RFC1951]
 	compression mechanism.

We could add some rationale, but I prefer keeping it simple.  We don't
need to make excuses for the choice, although it might be worth adding
something to discourage adoption of other mechanisms, citing the
pending deployment of TLS compression.
-------------------------------------------------------
Section 3:

I'm uneasy about the wording of where, exactly, in the protocol data 
stream, compression is to be turned on.  We must call this out at the 
octet level.  ISTR the SASL/STARTTLS documents have good wording for this 
(in relation to where encryption starts) that could be lifted. It is 
imperative that there be no ambiguity here.

And could we move the examples into a separate, informative, section?
-------------------------------------------------------
Section 4:

     This section is informative, not normative.

And that sentence is redundant :-)  s/,.*$/./
-------------------------------------------------------
Section 5:

The text in this section does not extend the IMAP protocol grammar. We
need to add:

    This syntax augments the grammar specified in [RFC3501].

--lyndon

   /* Pre-C-Preprocessor to translate ANSI trigraph idiocy in BUF
      before main CCCP processing.  Name `pcp' is also in honor of the
      drugs the trigraph designers must have been on. */

---

From: Lyndon Nerenberg <[email-masked]>
Date: Mon, 18 Dec 2006 15:27:05 -0800 (PST)

Let me clarify.

> I'm uneasy about the wording of where, exactly, in the protocol data stream, 
> compression is to be turned on.  We must call this out at the octet level.

My problem is with this:

     If the server issues an OK response, the server MUST compress
     starting with the first response after the CRLF ending the OK
     response.

and in particular '... with the first response'.  If that was changed to 
'... with the octet immediately following the CRLF terminating the OK 
response.' that eliminates any ambiguity.

--lyndon

   I think 3B2 code deserves its own place in hell.  Poring over the ESS#5 code,
   someone found that there were lots of strcmp(p, "f(") == 0 checks (I may have
   gotten the exact string wrong but it's close).  It took us a while to figure
   out why.  Apparently, location 0 on the 3b had the 3 bytes 'f' '(' '\0',
   someone noticed that when programs blew up they were pointing to "f(", and
   the worlds most amazing kludge for detecting nil pointers was born.
   			-- Dave Presotto