The IMAP COMPRESS Extension
draft-ietf-lemonade-compress-08
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2020-01-21
|
08 | (System) | Received changes through RFC Editor sync (added Verified Errata tag) |
|
2015-10-14
|
08 | (System) | Notify list changed from lemonade-chairs@ietf.org to (None) |
|
2012-08-22
|
08 | (System) | post-migration administrative database adjustment to the No Objection position for Cullen Jennings |
|
2012-08-22
|
08 | (System) | post-migration administrative database adjustment to the No Objection position for Lars Eggert |
|
2007-08-31
|
08 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
|
2007-08-31
|
08 | Amy Vezza | [Note]: 'RFC 4978' added by Amy Vezza |
|
2007-08-29
|
08 | (System) | RFC published |
|
2007-05-15
|
08 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
|
2007-05-14
|
08 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
|
2007-05-14
|
08 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
|
2007-05-14
|
08 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2007-05-02
|
08 | (System) | IANA Action state changed to In Progress |
|
2007-05-01
|
08 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
|
2007-05-01
|
08 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2007-05-01
|
08 | Amy Vezza | IESG has approved the document |
|
2007-05-01
|
08 | Amy Vezza | Closed "Approve" ballot |
|
2007-05-01
|
08 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza |
|
2007-04-30
|
08 | Cullen Jennings | [Ballot Position Update] Position for Cullen Jennings has been changed to No Objection from Discuss by Cullen Jennings |
|
2007-04-30
|
08 | Chris Newman | [Ballot Position Update] New position, Yes, has been recorded by Chris Newman |
|
2007-04-29
|
08 | Cullen Jennings | [Ballot comment] |
|
2007-04-29
|
08 | Cullen Jennings | [Ballot discuss] The latest version seem to capture what we discussed in Prague with one small exception. The draft says IMAP clients MAY … [Ballot discuss] The latest version seem to capture what we discussed in Prague with one small exception. The draft says IMAP clients MAY use either COMPRESS or TLS compression. But I thought it was going to say IMAP clients MAY use either COMPRESS or TLS compression however if they support both it is RECOMMENDED that they use TLS compression. |
|
2007-04-27
|
08 | (System) | New version available: draft-ietf-lemonade-compress-08.txt |
|
2007-03-24
|
08 | Chris Newman | Responsible AD has been changed to Chris Newman from Ted Hardie |
|
2007-02-12
|
08 | Cullen Jennings | [Ballot discuss] My largest problem with this work is around the applicability of when it should be used and when it should not and making … [Ballot discuss] My largest problem with this work is around the applicability of when it should be used and when it should not and making sure the specifying multiple approaches to compression does not reduce the number of clients/server pairs that actually interoperate. I note that in lemonade-profile-bis has the text The IETF has for some time generally agreed that compression is best handled at as low a level as possible, therefore Lemonade compliant IMAP servers SHOULD support the Deflate compression algorithm for TLS, as defined in [RFC3749]. However, the working group acknowledges that for many endpoints, this is a rarely deployed technology, as as such, Lemonade compliant IMAP servers MUST provide [I-D.ietf-lemonade-compress] support for fallback application-level stream compression, where TLS is not actively providing compression. My concerns would be dealt with by basically importing this text and saying that Servers that implement this specification SHOULD support the Deflate compression algorithm for TLS, as defined in [RFC3749] but MUST provide support for fallback application-level stream compression as defined in this specification, where TLS is not actively providing compression. Note that I am only asking for server not clients to do this and this seems to say the same thing as profile-bis. The reason I want something like this is that it ensures (at a SHOULD level) that servers support both and allows clients to support either and still get the benefits of compression. Can you just remove At present, TLS compression is not widely implemented. In the LEMONADE WG, the general consensus is that libraries implementing TLS compression will not be available soon enough for LEMONADE. It's fairly subjective and makes sense in a draft but makes less sense in an RFC that is around for a long time. You still keep what seems to be your key point that COMPRESS can be implemented easily by IMAP servers and clients. Can you just remove and encryption is generally more expensive than compression. (or convince me this is generally true) Typically IETF does not make statements about if patents apply to an algorithm or not - I agree we don't have any IPR statements made against this - it is less clear to me what the general patent position is. Can you just remove "unencumbered by patents" |
|
2007-02-12
|
08 | Cullen Jennings | [Ballot comment] Can you try to add some more specific advice that an implementor could follow to know when to call flush. It does not … [Ballot comment] Can you try to add some more specific advice that an implementor could follow to know when to call flush. It does not need to be normative but something like "Implementation would typically want to call flush after sending an attachment larger than XXX octets." |
|
2007-02-09
|
08 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert |
|
2007-01-26
|
08 | (System) | Removed from agenda for telechat - 2007-01-25 |
|
2007-01-25
|
08 | Amy Vezza | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza |
|
2007-01-25
|
08 | Lars Eggert | [Ballot discuss] Section 9.1., paragraph 1: > [RFC1951] Deutsch, "DEFLATE Compressed Data Format Specification > … |
|
2007-01-25
|
08 | Lars Eggert | [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert |
|
2007-01-25
|
08 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson |
|
2007-01-25
|
08 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
|
2007-01-25
|
08 | David Kessens | [Ballot Position Update] New position, No Objection, has been recorded by David Kessens |
|
2007-01-24
|
08 | Mark Townsley | [Ballot Position Update] Position for Mark Townsley has been changed to No Objection from Undefined by Mark Townsley |
|
2007-01-24
|
08 | Mark Townsley | [Ballot Position Update] Position for Mark Townsley has been changed to Undefined from No Objection by Mark Townsley |
|
2007-01-24
|
08 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley |
|
2007-01-24
|
08 | Mark Townsley | [Ballot comment] Compared to PPP compression (see [RFC1962]) and modem-based compression (see [MNP] and [V42BIS]), COMPRESS offers much better … [Ballot comment] 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). |
|
2007-01-24
|
08 | Bill Fenner | [Ballot Position Update] New position, No Objection, has been recorded by Bill Fenner |
|
2007-01-24
|
08 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
|
2007-01-24
|
08 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko |
|
2007-01-23
|
08 | Brian Carpenter | [Ballot comment] 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 |
|
2007-01-23
|
08 | Brian Carpenter | [Ballot Position Update] New position, No Objection, has been recorded by Brian Carpenter |
|
2007-01-22
|
08 | Russ Housley | [Ballot comment] From SecDir Review by Pat Cain: The last sentence of section 2 says that this document adds "a new command." I … [Ballot comment] 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. |
|
2007-01-22
|
08 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
|
2007-01-22
|
08 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
|
2007-01-21
|
08 | Sam Hartman | [Ballot Position Update] New position, Yes, has been recorded by Sam Hartman |
|
2007-01-20
|
08 | Cullen Jennings | [Ballot comment] The draft also say DEFLATE is unencumbered by patents. Is this really true? Have they expired? Is it only particular forms of DEFLATE? … [Ballot comment] The draft also say DEFLATE is unencumbered by patents. Is this really true? Have they expired? Is it only particular forms of DEFLATE? The draft says the encryption is generally faster than compression but I'm wonder if this is true - my lame experiment to create a sample point of one says that it is not [FluffyMac23:~] fluffy% cat id/draft-ietf-[sma]*.txt > foo.txt [FluffyMac23:~] fluffy% ls -l foo.txt -rw-r--r-- 1 fluffy fluffy 13688694 Jan 20 13:09 foo.txt [FluffyMac23:~] fluffy% time gzip < foo.txt > foo.txt.gz 1.063u 0.017s 0:01.20 89.1% 0+0k 0+2io 0pf+0w [FluffyMac23:~] fluffy% time openssl enc -des-cbc -e -in foo.txt -out foo.txt.des -k password 0.818u 0.097s 0:00.91 98.9% 0+0k 0+0io 0pf+0w |
|
2007-01-20
|
08 | Cullen Jennings | [Ballot discuss] So I'm a bit lost on this one and hoping someone can help me understand why we need this. Having two ways to … [Ballot discuss] So I'm a bit lost on this one and hoping someone can help me understand why we need this. Having two ways to do DEFLATE (tls based and this way) will simply reduce the interoperability of DEFLATE so I would like to make sure we need this before doing this. The draft says TLS compression is not widely implemented. I'm not sure when this draft was started but it seems to me that this is not true anymore. The draft also says that the compression ratios are improved by an API to flush the deflate stream - I assume you mean what zlib would call a Z_SYNC_FLUSH. It's not clear to me when the client or server should do this - I think advice is needed in the document on when to do it. It is also not clear to me that this will improve compression ratios - can you help me understand how it will? Now I don't know if the standard TLS APIs have a way to signal this flush to the compression layer but it seems to me that adding such an API is a better idea and defining a whole new standard to do it at a different layer and thus ham interoperability by having some people support it one place and other support it somewhere else. The documents lacks a meaningful security section. |
|
2007-01-20
|
08 | Cullen Jennings | [Ballot Position Update] New position, Discuss, has been recorded by Cullen Jennings |
|
2007-01-19
|
08 | Yoshiko Fong | IANA additional Comments: 7. IANA Considerations The IANA is requested to add COMPRESS=DEFLATE the list of IMAP extensions, http://www.iana.org/assignments/imap4-capabilities. … IANA additional Comments: 7. IANA Considerations The IANA is requested to add COMPRESS=DEFLATE the list of IMAP extensions, http://www.iana.org/assignments/imap4-capabilities. Note to IANA: This RFC does not specify the creation of a registry for compression mechanisms. The current feeling of the IMAP community is that is is unlikely that another compression mechanism will be added in the future. However, if this RFC is extended in the future by another RFC, and another compression mechanism is added at that time, it would then be appropriate to create a registry. |
|
2007-01-18
|
07 | (System) | New version available: draft-ietf-lemonade-compress-07.txt |
|
2007-01-18
|
08 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Patrick Cain. |
|
2007-01-15
|
08 | Yoshiko Fong | IANA Last Call Comments: Upon approval of this document, the IANA will make the following assignments in the "IMAP4 Capabilities Registry (RFC2060)" registry … IANA Last Call Comments: Upon approval of this document, the IANA will make the following assignments in the "IMAP4 Capabilities Registry (RFC2060)" registry located at http://www.iana.org/assignments/imap4-capabilities COMPRESS=DEFLATE [RFC-lemonade-compress-06] --- The IANA Consideration section did NOT state which registry the value should get in. PLEASE confirm the registry we mentioned above is correct. |
|
2007-01-11
|
08 | Ted Hardie | Placed on agenda for telechat - 2007-01-25 by Ted Hardie |
|
2007-01-11
|
08 | Ted Hardie | State Changes to IESG Evaluation from Waiting for Writeup by Ted Hardie |
|
2007-01-11
|
08 | Ted Hardie | [Ballot Position Update] New position, Yes, has been recorded for Ted Hardie |
|
2007-01-11
|
08 | Ted Hardie | Ballot has been issued by Ted Hardie |
|
2007-01-11
|
08 | Ted Hardie | Created "Approve" ballot |
|
2007-01-06
|
08 | (System) | State has been changed to Waiting for Writeup from In Last Call by system |
|
2006-12-24
|
08 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Patrick Cain |
|
2006-12-24
|
08 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Patrick Cain |
|
2006-12-18
|
08 | Dinara Suleymanova | PROTO Write-up (1.a) Document Shepherd: Eric Burger, eburger@alum.mit.edu; personally reviewed document. This document is ready for publication. (1.b) Work group review: The lemonade work … PROTO Write-up (1.a) Document Shepherd: Eric Burger, eburger@alum.mit.edu; personally reviewed document. This document is ready for publication. (1.b) Work group review: The lemonade work group provided extensive review of this document. In addition, the document received extra-WG review in the security area. (1.c, 1.d) Further review: This document does not need further specialized review, beyond GEN-ART. (1.e, 1.f) WG Consensus: There are no open issues or internal discussion remaining. There are no members with objections or concerns. There are no threats of appeal or process issues. (1.g) ID-nits: Check and verified with idnits 1.118 (1.h) References: All references (normative and informative) are current RFCs (1.i) IANA Considerations: Exist and internally consistent (1.j) ABNF: Internally consistent and manually verified (1.k) Document Announcement: Technical Summary This document specifies an IMAP extension to compress IMAP commands and responses and gives some advice on how to implement that to the best possible effect. It does not create any IANA registry or define several compression mechanisms: The WG believes that in the long term, TLS compression availability will make this extension obsolete. However, if that should be wrong, the document leaves an option to define more mechanisms and a registry later. Working Group Summary There is consensus in the WG to publish this document. Document Quality Many members of the Lemonade WG, including Dave Criland, Ned Freed, Philip Guenther, Randy Gellens and Tony Hansen, have reviewed the document. Eric Rescorla (non-work group) has provided a security review and also gave valuable feed back. The protocol has been implemented by three servers and two clients and was shown to interoperate. The document has been checked manually and using idnits 1.118, and passed both checks. The IANA Considerations section is sensible and consistent. The (four-line) ABNF has been manually checked. Eric Burger shepherds this document. He has reviewed this document and believes the -06 version is ready for publication. |
|
2006-12-15
|
08 | Amy Vezza | Last call sent |
|
2006-12-15
|
08 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
|
2006-12-14
|
08 | Ted Hardie | Last Call was requested by Ted Hardie |
|
2006-12-14
|
08 | Ted Hardie | State Changes to Last Call Requested from Publication Requested by Ted Hardie |
|
2006-12-14
|
08 | (System) | Ballot writeup text was added |
|
2006-12-14
|
08 | (System) | Last call text was added |
|
2006-12-14
|
08 | (System) | Ballot approval text was added |
|
2006-12-14
|
08 | Ted Hardie | 1.a) Document Shepherd: Eric Burger, eburger@alum.mit.edu; personally reviewed document. This document is ready for publication. (1.b) Work group review: The lemonade work group provided … 1.a) Document Shepherd: Eric Burger, eburger@alum.mit.edu; personally reviewed document. This document is ready for publication. (1.b) Work group review: The lemonade work group provided extensive review of this document. In addition, the document received extra-WG review in the security area. (1.c, 1.d) Further review: This document does not need further specialized review, beyond GEN-ART. (1.e, 1.f) WG Consensus: There are no open issues or internal discussion remaining. There are no members with objections or concerns. There are no threats of appeal or process issues. (1.g) ID-nits: Check and verified with idnits 1.118 (1.h) References: All references (normative and informative) are current RFCs (1.i) IANA Considerations: Exist and internally consistent (1.j) ABNF: Internally consistent and manually verified (1.k) Document Announcement: Technical Summary This document specifies an IMAP extension to compress IMAP commands and responses and gives some advice on how to implement that to the best possible effect. It does not create any IANA registry or define several compression mechanisms: The WG believes that in the long term, TLS compression availability will make this extension obsolete. However, if that should be wrong, the document leaves an option to define more mechanisms and a registry later. Working Group Summary There is consensus in the WG to publish this document. Document Quality Many members of the Lemonade WG, including Dave Criland, Ned Freed, Philip Guenther, Randy Gellens and Tony Hansen, have reviewed the document. Eric Rescorla (non-work group) has provided a security review and also gave valuable feed back. The protocol has been implemented by three servers and two clients and was shown to interoperate. The document has been checked manually and using idnits 1.118, and passed both checks. The IANA Considerations section is sensible and consistent. The (four-line) ABNF has been manually checked. Eric Burger shepherds this document. He has reviewed this document and believes the -06 version is ready for publication. |
|
2006-12-14
|
08 | Ted Hardie | Draft Added by Ted Hardie in state Publication Requested |
|
2006-12-14
|
08 | Ted Hardie | [Note]: 'Eric Burger is the Shepherd for this document.' added by Ted Hardie |
|
2006-11-27
|
06 | (System) | New version available: draft-ietf-lemonade-compress-06.txt |
|
2006-10-02
|
05 | (System) | New version available: draft-ietf-lemonade-compress-05.txt |
|
2006-09-18
|
04 | (System) | New version available: draft-ietf-lemonade-compress-04.txt |
|
2006-08-01
|
03 | (System) | New version available: draft-ietf-lemonade-compress-03.txt |
|
2006-07-17
|
02 | (System) | New version available: draft-ietf-lemonade-compress-02.txt |
|
2006-06-22
|
01 | (System) | New version available: draft-ietf-lemonade-compress-01.txt |
|
2006-03-02
|
00 | (System) | New version available: draft-ietf-lemonade-compress-00.txt |