Skip to main content

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
>                …
[Ballot discuss]
Section 9.1., paragraph 1:
>    [RFC1951]  Deutsch, "DEFLATE Compressed Data Format Specification
>                version 1.3", RFC 1951, Aladdin Enterprises, May 1996.

  DISCUSS: Is a DOWNREF (PS->Informational).
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