The IMAP COMPRESS Extension
draft-ietf-lemonade-compress-08
Yes
No Objection
Note: This ballot was opened for revision 08 and is now closed.
Lars Eggert (was Discuss) No Objection
(Chris Newman; former steering group member) Yes
(Sam Hartman; former steering group member) Yes
(Ted Hardie; former steering group member) Yes
(Bill Fenner; former steering group member) No Objection
(Brian Carpenter; former steering group member) No Objection
See dialogue with Gen-ART reviewer archived starting with http://www1.ietf.org/mail-archive/web/gen-art/current/msg01652.html Authors may suggest small changes as a result
(Cullen Jennings; former steering group member) (was Discuss) No Objection
(Dan Romascanu; former steering group member) No Objection
(David Kessens; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Jon Peterson; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Mark Townsley; former steering group member) (was No Record, No Objection) No Objection
Compared to PPP compression (see [RFC1962]) and modem-based compression (see [MNP] and [V42BIS]), COMPRESS offers much better compression efficiency. This is only true for IMAP data, of course. This is a bit like comparing apples and oranges given the different layers in the stack that these protocols operate. But, if you are going to bring it up, perhaps there should be some discussion about not running compression simultaneously at multiple layers? There is some discussion WRT TLS layering here, but nothing about PPP or L1 compression. For example, if PPP compression is running (perhaps because there is a lot of traffic on the link other than IMAP), should one run IMAP compression as well? Should the compression work differently in this case (e.g., focus on IMAP-specific compression vs. general algorithmic compression that could be covered by the lower layer).
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
From SecDir Review by Pat Cain: The last sentence of section 2 says that this document adds "a new command." I was expecting a "to <something>", maybe "IMAP" (?) to finish the sentence.