< draft-ietf-lemonade-compress-06.txt		draft-ietf-lemonade-compress-07.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
	November 2006		January 2007
	The IMAP COMPRESS Extension		The IMAP COMPRESS Extension
	draft-ietf-lemonade-compress-06.txt		draft-ietf-lemonade-compress-07.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 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	at any time. It is inappropriate to use Internet-Drafts as		at any time. It is inappropriate to use Internet-Drafts as
	reference material or to cite them other than as "work in progress".		reference material or to cite them other than as "work in progress".
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-		http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-
	Draft Shadow Directories can be accessed at		Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society 2006.		Copyright (C) The Internet Society 2007.
	Abstract		Abstract
	The COMPRESS extension allows an IMAP connection to be effectively		The COMPRESS extension allows an IMAP connection to be effectively
	and efficiently compressed.		and efficiently compressed.
	Internet-draft November 2006		Internet-draft January 2007
	Table of Contents		Table of Contents
	1. Conventions Used in This Document . . . . . . . . . . . . . . 2		1. Conventions Used in This Document . . . . . . . . . . . . . . 2
	2. Introduction and Overview . . . . . . . . . . . . . . . . . . 2		2. Introduction and Overview . . . . . . . . . . . . . . . . . . 2
	3. The COMPRESS Command . . . . . . . . . . . . . . . . . . . . . 3		3. The COMPRESS Command . . . . . . . . . . . . . . . . . . . . . 3
	4. Compression Efficiency . . . . . . . . . . . . . . . . . . . . 5		4. Compression Efficiency . . . . . . . . . . . . . . . . . . . . 5
	5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7		5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 7		6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	skipping to change at page 2, line 41 ¶		skipping to change at page 2, line 41 ¶
	server respectively.		server respectively.
	2. Introduction and Overview		2. Introduction and Overview
	A server which supports the COMPRESS extension indicates this with		A server which supports the COMPRESS extension indicates this with
	one or more capability names consisting of "COMPRESS=" followed by a		one or more capability names consisting of "COMPRESS=" followed by a
	supported compression algorithm name as described in this document.		supported compression algorithm name as described in this document.
	The goal of COMPRESS is to reduce the bandwidth usage of IMAP.		The goal of COMPRESS is to reduce the bandwidth usage of IMAP.
	Compared to PPP/MNP compression, COMPRESS offers much better		Compared to PPP compression (see [RFC1962]) and modem-based
	compression efficiency, and can be used together with TLS [RFC4346],		compression (see [MNP] and [V42BIS]), COMPRESS offers much better
	SASL encryption, VPNs etc. Compared to TLS compression [RFC3749],		compression efficiency. COMPRESS can be used together with TLS
	COMPRESS has the following (dis)advantages:		[RFC4346], SASL encryption, VPNs etc. Compared to TLS compression
			[RFC3749], COMPRESS has the following (dis)advantages:
	- COMPRESS can be implemented easily by IMAP servers and clients.		- COMPRESS can be implemented easily by IMAP servers and clients.
	At present, TLS compression is not widely implemented. In the		At present, TLS compression is not widely implemented. In the
	LEMONADE WG, the general consent is that libraries implementing		LEMONADE WG, the general consensus is that libraries implementing
	TLS compression will not be available soon enough for LEMONADE.		TLS compression will not be available soon enough for LEMONADE.
	- IMAP compression efficiency benefits from an API that permits		Internet-draft January 2007
	flushing the compressor's dictionary at the right point. This is
	Internet-draft November 2006
	practical for COMPRESS, whereas typical TLS libraries don't		- IMAP COMPRESS benefits from an intimate knowledge of the IMAP
	currently allow that.		protocol's state machine, allowing for dynamic and aggressive
			optimization of the underlying compression algorithm's parameters.
	- When a TLS librarly implements compression, all protocols that use		- When the TLS layer implements compression, any protocol using that
	TLS automatically are compressed (in LEMONADE's case, SMTP, IMAP,		layer can transparently benefit from that compression (e.g. SMTP
	and some notification protocol), whereas COMPRESS is specific to		and IMAP). COMPRESS is specific to IMAP.
	IMAP.
	In order to increase interoperation, it is desirable to have as few		In order to increase interoperation, it is desirable to have as few
	different compression algorithms as possible, so this document		different compression algorithms as possible, so this document
	specifies only one. The DEFLATE algorithm (defined in [RFC1951]) is		specifies only one. The DEFLATE algorithm (defined in [RFC1951]) is
	standard, widely available, unencumbered by patents and fairly		standard, widely available, unencumbered by patents and fairly
	efficient, so it is the only algorithm defined by this document.		efficient, so it is the only algorithm defined by this document.
	The extension adds one new command (COMPRESS) and no new responses.		The extension adds one new command (COMPRESS) and no new responses.
	3. The COMPRESS Command		3. The COMPRESS Command
	Arguments: Name of compression mechanism: "DEFLATE".		Arguments: Name of compression mechanism: "DEFLATE".
	Responses: None		Responses: None
	Result: OK The server will compress its responses and expects the		Result: OK The server will compress its responses and expects the
	client to compress its commands.		client to compress its commands.
	NO The server doesn't support the requested mechanism, or		NO Compression is already active via another layer.
	the mechanism is already active,		BAD Command unknown, invalid or unknown argument, or COMPRESS
	BAD Command unknown, invalid argument, or COMPRESS already		already active.
	active.
	The COMPRESS command instructs the server to use the named		The COMPRESS command instructs the server to use the named
	compression mechanism ("DEFLATE" is the only one defined) for all		compression mechanism ("DEFLATE" is the only one defined) for all
	commands and/or responses after COMPRESS.		commands and/or responses after COMPRESS.
	The client MUST NOT send any further commands until it has seen the		The client MUST NOT send any further commands until it has seen the
	result of COMPRESS. If the response was OK, the client MUST compress		result of COMPRESS. If the response was OK, the client MUST compress
	starting with the first command after COMPRESS. If the server		starting with the first command after COMPRESS. If the server
	response was BAD or NO, the client MUST NOT turn on compression.		response was BAD or NO, the client MUST NOT turn on compression.
	If the server responds NO because it knows that the same mechanism		If the server responds NO because it knows that the same mechanism
	is active already (e.g. because TLS has negotiated the same		is active already (e.g. because TLS has negotiated the same
	mechanism), it MUST send COMPRESSIONACTIVE as resp-text-code (see		mechanism), it MUST send COMPRESSIONACTIVE as resp-text-code (see
	[RFC3501] section 7.1), and the resp-text SHOULD say which layer		[RFC3501] section 7.1), and the resp-text SHOULD say which layer
	compresses.		compresses.
	If the server issues an OK response, the server MUST compress		If the server issues an OK response, the server MUST compress
	starting with the first response after the CRLF ending the OK		starting immediately after the CRLF which ends the tagged OK
	response. (Responses issued by the server before the OK response		response. (Responses issued by the server before the OK response
	Internet-draft November 2006		Internet-draft January 2007
	will, of course, still be uncompressed.) If the server issues a BAD		will, of course, still be uncompressed.) If the server issues a BAD
	or NO respnose, the server MUST NOT turn on compression.		or NO respnose, the server MUST NOT turn on compression.
	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
	the data they send.		the data they send.
	skipping to change at page 5, line 5 ¶		skipping to change at page 5, line 5 ¶
	C: b compress deflate		C: b compress deflate
	S: b OK DEFLATE active		S: b OK DEFLATE active
	From this point on, everything is compressed before being		From this point on, everything is compressed before being
	encrypted.		encrypted.
	C: c login arnt tnra		C: c login arnt tnra
	S: c OK Logged in as arnt		S: c OK Logged in as arnt
	Internet-draft November 2006		Internet-draft January 2007
	The following example demonstrates how a server may refuse to		The following example demonstrates how a server may refuse to
	compress twice:		compress twice:
	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, and we assume		From this point on, everything is encrypted, and we assume
	that TLS negotiation has also enabled TLS compression (see		that TLS negotiation has also enabled TLS compression (see
	skipping to change at page 5, line 28 ¶		skipping to change at page 5, line 28 ¶
	C: b compress deflate		C: b compress deflate
	S: b NO [COMPRESSIONACTIVE] DEFLATE active via TLS		S: b NO [COMPRESSIONACTIVE] DEFLATE active via TLS
	4. Compression Efficiency		4. Compression Efficiency
	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 algorithm 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 servers later in this section.		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
	skipping to change at page 6, line 5 ¶		skipping to change at page 6, line 5 ¶
	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.
	Internet-draft November 2006		Internet-draft January 2007
	When attachments are retrieved in binary form, DEFLATE may be able		When attachments are retrieved in binary form, DEFLATE may be able
	to compress them, but the format of the attachment is usually not		to compress them, but the format of the attachment is usually not
	IMAP-like, so the dictionary built while compressing IMAP does not		IMAP-like, so the dictionary built while compressing IMAP does not
	help. The compressor has to adapt its dictionary from IMAP to the		help. The compressor has to adapt its dictionary from IMAP to the
	attachment's format, and then back. A few file formats aren't		attachment's format, and then back. A few file formats aren't
	compressible at all using deflate, e.g. .gz, .zip and .jpg files.		compressible at all using deflate, e.g. .gz, .zip and .jpg files.
	When attachments are retrieved in base-64 form, the same problems		When attachments are retrieved in base-64 form, the same problems
	apply, but the base-64 encoding adds another problem. 8-bit		apply, but the base-64 encoding adds another problem. 8-bit
	skipping to change at page 7, line 5 ¶		skipping to change at page 7, line 5 ¶
	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
	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.
	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.
	Internet-draft November 2006		Internet-draft January 2007
	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 [RFC4234]. [RFC4234] defines SP		Form (ABNF) notation as specified in [RFC4234]. This syntax augments
	and [RFC3501] defines command-any, capability and resp-text-code.		the grammar specified in [RFC3501]. [RFC4234] defines SP and
			[RFC3501] defines command-auth, capability and resp-text-code.
	Except as noted otherwise, all alphabetic characters are case-		Except as noted otherwise, all alphabetic characters are case-
	insensitive. The use of upper or lower case characters to define		insensitive. The use of upper or lower case characters to define
	token strings is for editorial clarity only. Implementations MUST		token strings is for editorial clarity only. Implementations MUST
	accept these strings in a case-insensitive fashion.		accept these strings in a case-insensitive fashion.
	command-any =/ compress		command-auth =/ compress
	compress = "COMPRESS" SP algorithm		compress = "COMPRESS" SP algorithm
	capability =/ "COMPRESS=" algorithm		capability =/ "COMPRESS=" algorithm
	;; multiple COMPRESS capabilities allowed		;; multiple COMPRESS capabilities allowed
	algorithm = "DEFLATE"		algorithm = "DEFLATE"
	resp-text-code =/ "COMPRESSIONACTIVE"		resp-text-code =/ "COMPRESSIONACTIVE"
	Note that due the syntax of capability names, future algorithm names		Note that due the syntax of capability names, future algorithm names
	must be atoms.		must be atoms.
	6. Security Considerations		6. Security Considerations
	As for TLS compression [RFC3749].		As for TLS compression [RFC3749].
	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, http://www.iana.org/assignments/imap4-capabilities.
	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 mechanism		community is that is is unlikely that another compression mechanism
	will be added in the future. However, if this RFC is extended in the		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		future by another RFC, and another compression mechanism is added at
	that time, it would then be appropriate to create a registry.		that time, it would then be appropriate to create a registry.
	Internet-draft November 2006		Internet-draft January 2007
	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, Stephane Maes, Alexey Melnikov, Lyndon		Randall Gellens, Tony Hansen, Stephane Maes, Alexey Melnikov, Lyndon
	Nerenberg and 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.
	skipping to change at page 8, line 37 ¶		skipping to change at page 8, line 37 ¶
	[RFC3501] Crispin, "Internet Message Access Protocol - Version		[RFC3501] Crispin, "Internet Message Access Protocol - Version
	4rev1", RFC 3501, University of Washington, June 2003.		4rev1", RFC 3501, University of Washington, June 2003.
	[RFC4234] Crocker, Overell, "Augmented BNF for Syntax		[RFC4234] Crocker, Overell, "Augmented BNF for Syntax
	Specifications: ABNF", RFC 4234, Brandenburg		Specifications: ABNF", RFC 4234, Brandenburg
	Internetworking, Demon Internet Ltd, October 2005.		Internetworking, Demon Internet Ltd, October 2005.
	9.2. Informative References		9.2. Informative References
			[RFC1962] Rand, "The PPP Compression Control Protocol (CCP)", RFC
			1962, June 1996.
	[RFC3516] Nerenberg, "IMAP4 Binary Content Extension", RFC 3516,		[RFC3516] Nerenberg, "IMAP4 Binary Content Extension", RFC 3516,
	Orthanc Systems, April 2003.		Orthanc Systems, April 2003.
	[RFC3749] Hollenbeck, "Transport Layer Security Protocol		[RFC3749] Hollenbeck, "Transport Layer Security Protocol
	Compression Methods", RFC 3749, VeriSign, May 2004.		Compression Methods", RFC 3749, VeriSign, May 2004.
	[RFC4346] Dierks, Rescorla, "The Transport Layer Security (TLS)		[RFC4346] Dierks, Rescorla, "The Transport Layer Security (TLS)
	Protocol, Version 1.1", RFC 4346, April 2006.		Protocol, Version 1.1", RFC 4346, April 2006.
	[RFC4422] Melnikov, Zeilenga, "Simple Authentication and Security		[RFC4422] Melnikov, Zeilenga, "Simple Authentication and Security
	Layer (SASL)", RFC 4422, Isode Limited, June 2006		Layer (SASL)", RFC 4422, Isode Limited, June 2006.
	Internet-draft November 2006		Internet-draft January 2007
			[V42BIS] ITU, "V.42bis: Data compression procedures for data
			circuit-terminating equipment (DCE) using error
			correction procedures", http://www.itu.int/rec/T-REC-
			V.42bis, January 1990.
			[MNP] Gilbert Held, "The Complete Modem Reference", Second
			Edition, Wiley Professional Computing, ISBN
			0-471-00852-4, May 1994.
	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
	skipping to change at page 9, line 43 ¶		skipping to change at page 10, line 5 ¶
	of such proprietary rights by implementers or users of this		of such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository		specification can be obtained from the IETF on-line IPR repository
	at http://www.ietf.org/ipr.		at http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at ietf-		this standard. Please address the information to the IETF at ietf-
	ipr@ietf.org.		ipr@ietf.org.
			Internet-draft January 2007
	Copyright Statement		Copyright Statement
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2007).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	Internet-draft November 2006
	Disclaimer of Validity		Disclaimer of Validity
	This document and the information contained herein are provided on		This document and the information contained herein are provided on
	an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE		an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE		REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
	INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR		INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
	IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
End of changes. 26 change blocks.
	39 lines changed or deleted		49 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/