Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-compress-04.txt

From: [email-masked]
Date: Mon, 18 Sep 2006 10:50:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF.

	Title		: The IMAP COMPRESS Extension
	Author(s)	: A. Gulbrandsen
	Filename	: draft-ietf-lemonade-compress-04.txt
	Pages		: 9
	Date		: 2006-9-18
	
The COMPRESS extension allows an IMAP connection to be effectively
    and efficiently compressed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-compress-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-lemonade-compress-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-lemonade-compress-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Dave Cridland <[email-masked]>
Date: Mon, 18 Sep 2006 16:27:45 +0100

> http://www.ietf.org/internet-drafts/draft-ietf-lemonade-compress-04.txt

I've read through this, and I've found all my issues answered, and no 
new issues other than the following minor ones:

1) In Section 3, "The COMPRESS Command", third paragraph, I would 
personally change:

    If the server issues an OK response, the server MUST compress
    starting with the first response after the CRLF ending the OK
    response.

to:

If the server issues an OK response, the server SHALL compress 
starting with the first octet following the CRLF ending the reponse.

2) I would move the fourth paragraph "For DEFLATE (as for many other 
compression mechanisms)," to the normative section.

3) I would try to clarify the last paragraph, something like:

When COMPRESS is combined with TLS or SASL security layers, the order 
of processing data to be sent SHALL be to first COMPRESS, then SASL, 
and finally TLS. When receiving data, the processing order MUST be 
reversed. This ensures that data is compressed before it is 
encrypted, independent of the order in which the client issues 
COMPRESS, AUTHENTICATE, and STARTTLS.

My intention is to avoid any grey areas concerning whether, for 
example, TLS handshaking is compressed or not.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Randall Gellens <[email-masked]>
Date: Tue, 19 Sep 2006 14:15:08 -0700

This version looks terrific.

Two minor things:

(1) In Section 4 (Compression Efficiency), I'd suggest changing:

     clients which send many APPEND commands may want to
     surround large literals with flushes in the same way as is
     recommended for server below.

in two ways:

(1a) change "server" to "servers"
(1b) change "below" to "in Section 4, Compression Efficiency".

(2) In Section 7 (IANA Considerations), "another compression" should 
be "another compression mechanism".
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
They say that 90 per cent of TV is junk.  But 90 per cent
of *everything* is junk.
      --Gene Roddenberry, interview in TV Guide, Apr. 27, 1974
      (quoting Sturgeon's Revelation: "Ninety percent of
      everything is crap.")

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 19 Sep 2006 23:31:53 +0200

> starting with the first octet following the CRLF ending the reponse.

I'm a little bit unhappy about this. Haven't changed the text yet.

> compression mechanisms)," to the normative section.

It is in a normative section ;)

I see what you mean, but don't you think the document should say 
normatively that the sender isn't required to use any specific 
compression level?

> COMPRESS, AUTHENTICATE, and STARTTLS.

I struck the word security and used the rest.

> example, TLS handshaking is compressed or not.

TLS handshakes aren't a problem, since the server sends a response 
first. I could see that something else might be a problem.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 19 Sep 2006 23:40:59 +0200

> first. I could see that something else might be a problem.

If something else is a problem, IT is at fault and I shall gladly create 
problems for it.

No command should ever tell a server to send a non-response without a 
response to lead the way. It's just too difficult to differentiate 
between OK, NO and BAD otherwise.

Arnt

---

From: Randall Gellens <[email-masked]>
Date: Tue, 19 Sep 2006 14:59:40 -0700

At 11:22 PM +0200 9/19/06, Arnt Gulbrandsen wrote:

>  Really? It's the same section. Perhaps "in this section" or something?

Brain fade :-)

How about "later in this section"?
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
The most likely way for the world to be destroyed, most experts agree,
is by accident.  That's where we come in; we're computer professionals.
We cause accidents.                              --Nathaniel Borenstein

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 19 Sep 2006 23:22:16 +0200

> (1a) change "server" to "servers"

Of course.

> be "another compression mechanism".

Of course.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 20 Sep 2006 11:07:24 +0200

X-MailFrom [email-masked] Sun Sep 24 08:56:21 2006
Date: Tue, 19 Sep 2006 23:22:16 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Cc: Randall Gellens <[email-masked]>
Subject: [lemonade] Re: Comments on draft-ietf-lemonade-compress-04.txt

Of course.

Of course.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 20 Sep 2006 11:07:24 +0200

> How about "later in this section"?

Sounds good. Done.

Arnt

man-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

> How about "later in this section"?

Sounds good. Done.

Arnt