< draft-ietf-lemonade-compress-04.txt		draft-ietf-lemonade-compress-05.txt >
	Network Working Group Arnt Gulbrandsen		Network Working Group Arnt Gulbrandsen
	Request for Comments: DRAFT Oryx Mail Systems GmbH		Request for Comments: DRAFT Oryx Mail Systems GmbH
	September 2006		October 2006
	The IMAP COMPRESS Extension		The IMAP COMPRESS Extension
	draft-ietf-lemonade-compress-04.txt		draft-ietf-lemonade-compress-05.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 4, line 9 ¶		skipping to change at page 4, line 9 ¶
	For DEFLATE (as for many other compression mechanisms), the		For DEFLATE (as for many other compression mechanisms), the
	compressor can trade speed against quality. When decompressing		compressor can trade speed against quality. When decompressing
	there isn't much of a tradeoff. Consequently, the client and server		there isn't much of a tradeoff. Consequently, the client and server
	are both free to pick the best reasonable rate of compression for		are both free to pick the best reasonable rate of compression for
	Internet-draft August 2006		Internet-draft August 2006
	the data they send.		the data they send.
	If both COMPRESS and STARTTLS and/or a [SASL] security layer are in		When COMPRESS is combined with TLS or [SASL] layers, the order of
	use, the data should be compressed before it is encrypted (and		processing data to be sent SHALL be to first COMPRESS, then SASL,
	decrypted before it is decompressed), independent of the order in		and finally TLS. When receiving data, the processing order MUST be
	which the client issues COMPRESS, AUTHENTICATE and STARTTLS.		reversed. This ensures that data is compressed before it is
			encrypted, independent of the order in which the client issues
			COMPRESS, AUTHENTICATE, and STARTTLS.
	The following example illustrates how commands and responses are		The following example illustrates how commands and responses are
	compressed during a simple login sequence:		compressed during a simple login sequence:
	S: * OK [CAPABILITY IMAP4REV1 STARTTLS COMPRESS=DEFLATE]		S: * OK [CAPABILITY IMAP4REV1 STARTTLS COMPRESS=DEFLATE]
	C: a starttls		C: a starttls
	S: a OK TLS active		S: a OK TLS active
	From this point on, everything is encrypted.		From this point on, everything is encrypted.
	skipping to change at page 4, line 43 ¶		skipping to change at page 4, line 45 ¶
	This section is informative, not normative.		This section is informative, not normative.
	IMAP poses some unusual problems for a compression layer.		IMAP poses some unusual problems for a compression layer.
	Upstream is fairly simple. Most IMAP clients send the same few		Upstream is fairly simple. Most IMAP clients send the same few
	commands again and again, so any compression algorith which can		commands again and again, so any compression algorith which can
	exploit repetition works efficiently. The APPEND command is an		exploit repetition works efficiently. The APPEND command is an
	exception; clients which send many APPEND commands may want to		exception; clients which send many APPEND commands may want to
	surround large literals with flushes in the same way as is		surround large literals with flushes in the same way as is
	recommended for server below.		recommended for servers later in this section.
	Downstream has the unusual property that several kinds of data are		Downstream has the unusual property that several kinds of data are
	sent, confusing all dictionary-based compression algorithms.		sent, confusing all dictionary-based compression algorithms.
	One type is IMAP responses. These are highly compressible; zlib		One type is IMAP responses. These are highly compressible; zlib
	using its least CPU-intensive setting compresses typical responses		using its least CPU-intensive setting compresses typical responses
	to 25-40% of their original size.		to 25-40% of their original size.
			Internet-draft August 2006
	Another is email headers. These are equally compressible, and		Another is email headers. These are equally compressible, and
	benefit from using the same dictionary as the IMAP responses.		benefit from using the same dictionary as the IMAP responses.
	Internet-draft August 2006
	A third is email body text. Text is usually fairly short and		A third is email body text. Text is usually fairly short and
	includes much ASCII, so the same compression dictionary will do a		includes much ASCII, so the same compression dictionary will do a
	good job here, too. When multiple messages in the same thread are		good job here, too. When multiple messages in the same thread are
	read at the same time, quoted lines etc. can often be compressed		read at the same time, quoted lines etc. can often be compressed
	almost to zero.		almost to zero.
	Finally, attachments (non-text email bodies) are transmitted, either		Finally, attachments (non-text email bodies) are transmitted, either
	in [BINARY] form or encoded with base-64.		in [BINARY] form or encoded with base-64.
	When attachments are retrieved in [BINARY] form, DEFLATE may be able		When attachments are retrieved in [BINARY] form, DEFLATE may be able
	skipping to change at page 5, line 52 ¶		skipping to change at page 6, line 4 ¶
	A server can improve downstream compression if it hints to the		A server can improve downstream compression if it hints to the
	compressor that the data type is about to change strongly, e.g. by		compressor that the data type is about to change strongly, e.g. by
	sending a Z_FULL_FLUSH at the start and end of large non-text		sending a Z_FULL_FLUSH at the start and end of large non-text
	literals (before and after '*CHAR8' in the definition of literal in		literals (before and after '*CHAR8' in the definition of literal in
	RFC 3501, page 86). Small literals are best left alone.		RFC 3501, page 86). Small literals are best left alone.
	A server can improve the CPU efficiency both of the server and the		A server can improve the CPU efficiency both of the server and the
	client if it adjusts the compression level (e.g. using the		client if it adjusts the compression level (e.g. using the
	deflateParams() function in zlib) at these points. A very simple		deflateParams() function in zlib) at these points. A very simple
	strategy is to change the level to 0 to at the start of a literal		strategy is to change the level to 0 to at the start of a literal
			Internet-draft August 2006
	provided the first two bytes are either 0x1F 0x8B (as in deflate-		provided the first two bytes are either 0x1F 0x8B (as in deflate-
	compressed files) or 0xFF 0xD8 (JPEG), and to keep it at 1-5 the		compressed files) or 0xFF 0xD8 (JPEG), and to keep it at 1-5 the
	rest of the time.		rest of the time.
	Internet-draft August 2006
	Note that when using TLS, compression may actually decrease the CPU		Note that when using TLS, compression may actually decrease the CPU
	usage, depending on which algorithms are used in TLS. This is		usage, depending on which algorithms are used in TLS. This is
	because fewer bytes need to be encrypted, and encryption is		because fewer bytes need to be encrypted, and encryption is
	generally more expensive than compression.		generally more expensive than compression.
	5. Formal Syntax		5. Formal Syntax
	The following syntax specification uses the Augmented Backus-Naur		The following syntax specification uses the Augmented Backus-Naur
	Form (ABNF) notation as specified in [ABNF]. Non-terminals		Form (ABNF) notation as specified in [ABNF]. Non-terminals
	referenced but not defined below are as defined by [ABNF] (SP, CRLF)		referenced but not defined below are as defined by [ABNF] (SP, CRLF)
	skipping to change at page 6, line 47 ¶		skipping to change at page 6, line 51 ¶
	As for [TLSCOMP] RFC 3749.		As for [TLSCOMP] RFC 3749.
	7. IANA Considerations		7. IANA Considerations
	The IANA is requested to add COMPRESS=DEFLATE the list of IMAP		The IANA is requested to add COMPRESS=DEFLATE the list of IMAP
	extensions.		extensions.
	Note to IANA: This RFC does not specify the creation of a registry		Note to IANA: This RFC does not specify the creation of a registry
	for compression mechanisms. The current feeling of the IMAP		for compression mechanisms. The current feeling of the IMAP
	community is that is is unlikely that another compression algorithm		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 is added at that
	time, it would then be appropriate to create a registry.
	Internet-draft August 2006		Internet-draft August 2006
			algorithm will be added in the future. However, if this RFC is
			extended in the future by another RFC, and another compression is
			added at that time, it would then be appropriate to create a
			registry.
	8. Acknowledgements		8. Acknowledgements
	Eric Burger, Dave Cridland, Tony Finch, Ned Freed, Philip Guenther,		Eric Burger, Dave Cridland, Tony Finch, Ned Freed, Philip Guenther,
	Randall Gellens, Tony Hansen, Alexey Melnikov, Lyndon Nerenberg and		Randall Gellens, Tony Hansen, Stephane Maes, Alexey Melnikov, Lyndon
	Zoltan Ordogh have all helped with this document.		Nerenberg and Zoltan Ordogh have all helped with this document.
	The author would also like to thank various people in the rooms at		The author would also like to thank various people in the rooms at
	meetings, whose help is real, but not reflected in the author's		meetings, whose help is real, but not reflected in the author's
	mailbox.		mailbox.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[ABNF] Crocker, Overell, "Augmented BNF for Syntax		[ABNF] Crocker, Overell, "Augmented BNF for Syntax
	skipping to change at page 7, line 44 ¶		skipping to change at page 8, line 4 ¶
	9.2. Informative References		9.2. Informative References
	[TLSCOMP] Hollenbeck, "Transport Layer Security Protocol		[TLSCOMP] Hollenbeck, "Transport Layer Security Protocol
	Compression Methods", RFC 3749, VeriSign, May 2004.		Compression Methods", RFC 3749, VeriSign, May 2004.
	[SASL] Melnikov, Zeilenga, "Simple Authentication and Security		[SASL] Melnikov, Zeilenga, "Simple Authentication and Security
	Layer (SASL)", RFC 4422, Isode Limited, June 2006		Layer (SASL)", RFC 4422, Isode Limited, June 2006
	[BINARY] Nerenberg, "IMAP4 Binary Content Extension", Orthanc		[BINARY] Nerenberg, "IMAP4 Binary Content Extension", Orthanc
	Systems, April 2003.
	Internet-draft August 2006		Internet-draft August 2006
			Systems, April 2003.
	10. Author's Address		10. Author's Address
	Arnt Gulbrandsen		Arnt Gulbrandsen
	Oryx Mail Systems GmbH		Oryx Mail Systems GmbH
	Schweppermannstr. 8		Schweppermannstr. 8
	D-81671 Muenchen		D-81671 Muenchen
	Germany		Germany
	Fax: +49 89 4502 9758		Fax: +49 89 4502 9758
End of changes. 13 change blocks.
	18 lines changed or deleted		24 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/