< draft-gulbrandsen-imap-deflate-01.txt		draft-gulbrandsen-imap-deflate-02.txt >
	Network Working Group Arnt Gulbrandsen		Network Working Group Arnt Gulbrandsen
	Request for Comments: DRAFT Oryx		Request for Comments: DRAFT Oryx Mail Systems GmbH
	draft-gulbrandsen-imap-deflate-01.txt August 2005		draft-gulbrandsen-imap-deflate-02.txt February 2006
	The IMAP COMPRESS=DEFLATE extension		The IMAP COMPRESS=DEFLATE extension
	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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other documents		months and may be updated, replaced, or obsoleted by other documents
	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 2005. All Rights Reserved.		Copyright (C) The Internet Society 2006.
	Abstract		Abstract
	The COMPRESS=DEFLATE extension allows an IMAP connection to be		The COMPRESS=DEFLATE extension allows an IMAP connection to be
	compressed using the DEFLATE algorithm, such that effective		compressed using the DEFLATE algorithm, such that effective
	compression is available even when TLS is used.		compression is available even when TLS is used.
	Conventions Used in This Document		Conventions Used in This Document
	The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD		The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD
	NOT", and "MAY" in this document are to be interpreted as described		NOT", and "MAY" in this document are to be interpreted as described
	in "Key words for use in RFCs to Indicate Requirement Levels"		in "Key words for use in RFCs to Indicate Requirement Levels"
	Internet-draft August 2005		Internet-draft February 2006
	[KEYWORDS]. Formal syntax is defined by [ABNF] as modified by		[KEYWORDS]. Formal syntax is defined by [ABNF] as modified by
	[IMAP].		[IMAP].
	In the example, "C:" and "S:" indicate lines sent by the client and		In the example, "C:" and "S:" indicate lines sent by the client and
	server respectively.		server respectively.
	Introduction and Overview		Introduction and Overview
	An IMAP server that supports this extension announces		An IMAP server that supports this extension announces
	"COMPRESS=DEFLATE" as one of its capabilities.		"COMPRESS=DEFLATE" as one of its capabilities.
	The goal of COMPRESS=DEFLATE is to reduce the bandwidth usage of		The goal of COMPRESS=DEFLATE is to reduce the bandwidth usage of
	IMAP. On regular IMAP connections, the PPP or MNP compression used		IMAP. On regular IMAP connections, the PPP or MNP compression used
	with many low-bandwidth links compresses IMAP well. However, when		with many low-bandwidth links compresses IMAP well. However, when
	TLS is used, PPP/MNP compression is ineffective. TLS too can provide		TLS is used, PPP/MNP compression is ineffective. TLS too may provide
	compression, but currently few or no implementations do so in		compression, but few or no implementations do so in practice
	practice.		(perhaps for patent reasons).
	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 is standard, widely		specifies only one. The DEFLATE algorithm is standard, widely
	available, unencumbered by patents and fairly efficient. Hopefully		available, unencumbered by patents and fairly efficient. Hopefully
	it will not be necessary to define additional algorithms.		it will not be necessary to define additional algorithms.
	The extension adds one new command (COMPRESS) and no new responses.		The extension adds one new command (COMPRESS) and no new responses.
	The COMPRESS Command		The COMPRESS Command
	skipping to change at page 3, line 5 ¶		skipping to change at page 3, line 5 ¶
	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 future		compression mechanism ("DEFLATE" is the only one defined) for future
	commands and responses.		commands and responses.
	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 2005		Internet-draft February 2006
	the data they send.		the data they send.
	The client MUST NOT send additional commands until it has seen the		The client MUST NOT send additional commands until it has seen the
	result of COMPRESS.		result of COMPRESS.
	If the client wants to use both TLS and compression, it SHOULD send		If both TLS and COMPRESS are in use, the data should be compressed
	STARTTLS before COMPRESS.		before it is encrypted (and decrypted before it is decompressed).
	Example		Example
	This example shows a simple login sequence. The client uses TLS for		This example shows a simple login sequence. The client uses TLS for
	privacy and DEFLATE for compression.		privacy and [DEFLATE] for compression.
	S: * OK [CAPABILITY IMAP4REV1 STARTTLS COMPRESS=DEFLATE]		S: * OK [CAPABILITY IMAP4REV1 STARTTLS COMPRESS=DEFLATE]
	C: a starttls		C: a starttls
	S: a OK		S: a OK
	C: b compress deflate		C: b compress deflate
	S: b OK		S: b OK
	C: c login arnt tnra		C: c login arnt tnra
	S: c OK		S: c OK
	Implementation Notes		Implementation Notes
	skipping to change at page 4, line 5 ¶		skipping to change at page 4, line 5 ¶
	referenced but not defined below are as defined by [ABNF] (SP, CRLF)		referenced but not defined below are as defined by [ABNF] (SP, CRLF)
	or [IMAP] (all others).		or [IMAP] (all others).
	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-any =/ compress
	Internet-draft August 2005		Internet-draft February 2006
	compress = "COMPRESS" SP astring		compress = "COMPRESS" SP astring
	Security considerations		Security considerations
	The proposed extension does not cause any security problems. It may		(As for [TLSCOMP] RFC 3749.)
	marginally reduce the scope for plaintext attacks when used together
	with [TLS].		IANA considerations
			The IANA is requested to add COMPRESS=DEFLATE to the list of IMAP
			extensions.
	Credits		Credits
	(Your name here :)		(Your name here :)
	References		Normative References
	[ABNF] Crocker, Overell, "Augmented BNF for Syntax		[ABNF] Crocker, Overell, "Augmented BNF for Syntax
	Specifications: ABNF", RFC 2234, Internet Mail		Specifications: ABNF", RFC 2234, Internet Mail
	Consortium, Demon Internet Ltd, November 1997.		Consortium, Demon Internet Ltd, November 1997.
	[IMAP] Crispin, M., "Internet Message Access Protocol - Version		[IMAP] Crispin, "Internet Message Access Protocol - Version
	4rev1", RFC 3501, University of Washington, June 2003.		4rev1", RFC 3501, University of Washington, June 2003.
	[KEYWORDS] Bradner, "Key words for use in RFCs to Indicate		[KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, Harvard University, March		Requirement Levels", RFC 2119, Harvard University, March
	1997.		1997.
	[DEFLATE] Deutsch, P., "DEFLATE Compressed Data Format		[DEFLATE] Deutsch, "DEFLATE Compressed Data Format Specification
	Specification version 1.3", RFC 1951, Aladdin		version 1.3", RFC 1951, Aladdin Enterprises, May 1996.
	Enterprises, May 1996.
	[STARTTLS] Newman, C. "Using TLS with IMAP, POP3 and ACAP", RFC		[STARTTLS] Newman, C. "Using TLS with IMAP, POP3 and ACAP", RFC
	2595, June 1999.		2595, June 1999.
			Informative References
			[TLSCOMP] Hollenbeck, "Transport Layer Security Protocol
			Compression Methods", RFC 3749, VeriSign, May 2004.
			Internet-draft February 2006
	Author's Address		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
	Phone: +49 89 45029757		Fax: +49 89 4502 9758
	Fax: +49 89 45029758
	Email: arnt@oryx.com		Email: arnt@oryx.com
	Internet-draft August 2005
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in this
	this document or the extent to which any license under such rights		document or the extent to which any license under such rights might or
	might or might not be available; nor does it represent that it has		might not be available; nor does it represent that it has made any
	made any independent effort to identify any such rights. Information		independent effort to identify any such rights. Information on the
	on the procedures with respect to rights in RFC documents can be		procedures with respect to rights in RFC documents can be found in BCP 78
	found in BCP 78 and BCP 79.		and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any		Copies of IPR disclosures made to the IETF Secretariat and any assurances
	assurances of licenses to be made available, or the result of an		of licenses to be made available, or the result of an attempt made to
	attempt made to obtain a general license or permission for the use of		obtain a general license or permission for the use of such proprietary
	such proprietary rights by implementers or users of this		rights by implementers or users of this specification can be obtained from
	specification can be obtained from the IETF on-line IPR repository at		the IETF on-line IPR repository at http://www.ietf.org/ipr.
	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
	rights that may cover technology that may be required to implement		that may cover technology that may be required to implement this standard.
	this standard. Please address the information to the IETF at		Please address the information to the IETF at ietf-ipr@ietf.org.
	ietf-ipr@ietf.org.
	Disclaimer of Validity		Copyright Statement
	This document and the information contained herein are provided on an		Copyright (C) The Internet Society (2006).
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement		This document is subject to the rights, licenses and restrictions
			contained in BCP 78, and except as set forth therein, the authors retain
			all their rights.
	Copyright (C) The Internet Society (2005). This document is subject		Internet-draft February 2006
	to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		Disclaimer of Validity
			This document and the information contained herein are provided on an "AS
			IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS
			SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
			TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
			LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
			INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
			FITNESS FOR A PARTICULAR PURPOSE.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the Internet
	Internet Society.		Society.
End of changes. 24 change blocks.
	53 lines changed or deleted		61 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/