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

From: [email-masked]
Date: Mon, 02 Oct 2006 10:50:01 -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-05.txt
	Pages		: 9
	Date		: 2006-10-2
	
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-05.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-05.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-05.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: Tony Hansen <[email-masked]>
Date: Mon, 02 Oct 2006 12:02:45 -0400

> 	Title		: The IMAP COMPRESS Extension

This draft looks very good.

One nit in Section 7:

< and another compression is added
> and another compression mechanism is added
			  ^^^^^^^^^

Can we LC this now?

	Tony Hansen
	[email-masked]

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 2 Oct 2006 19:32:19 +0200

> This draft looks very good.

Thanks.

>>  and another compression mechanism is added

Fixed.

> Can we LC this now?

Yes, Eric will do that, probably tomorrow.

Arnt

---

From: <[email-masked]>
Date: Tue, 31 Oct 2006 16:22:08 +0200

I hope it's not too late.
1. Typo in section 2:
When a TLS librarly

2. Wording change suggestion in section 2:
all protocols that use TLS automatically are compressed
to:
all protocols that use TLS are automatically compressed

3. Wording change suggestion in section 3:
OK The server will compress its responses and expects the client to compress its commands.
to:
OK The server and the client will compress all data that it may send

4. Wording change suggestion in section 3:
The client MUST NOT send any further commands until it has seen the result of COMPRESS.
to:
After the client has sent the COMPRESS command, the client MUST NOT send any commands until it has seen the result of COMPRESS.

5. Clarification/wording change suggestion in section 3:
(Responses issued by the server before the OK response will, of course, still be uncompressed.)
to:
Therefore, responses issued by the server before the OK response will all be uncompressed, and delayed client requests that have been sent uncompressed (before turning compression on) may result in compressed responses.

6. Typo in section 4:
so any compression algorith

7. Wording change suggestion in section 4:
the same way as is recommended for servers
the same way as it is recommended for servers later

8. Question/suggestion in section 4:
Multiple occurances of "base-64" - this is BASE64 as in RFC4648, right? If so, I would suggest correction (base-64 -> BASE64) and adding a reference.

9. Question in section 5:
capability  =/ "COMPRESS=" algorithm
                      ;; multiple COMPRESS capabilities allowed
So, if I had multiple algorithms, would it be COMPRESS=1,2,3 or COMPRESS=1,COMPRESS=2,COMPRESS=3? I would guess the second.

10. Question in section 6:
Should we add ZLIB here? ZLIB already had some history...

11. Wording change suggestion in section 7:
The IANA is requested to add COMPRESS=DEFLATE the list
to:
The IANA is requested to add COMPRESS=DEFLATE to the list

12. Wording change suggestion in section 7:
and another compression is added at that time, it would then be appropriate to create a registry
to:
and any additional compression algorithms are introduced at that time, then the registry should be created

Thank You.

Best regards: Zoltán Ördögh
E-mail: zoltan dot ordogh at nokia dot com
Phone: +358 50 386 0566

>-----Original Message-----
>From: ext [email-masked] [mailto:[email-masked]] 
>Sent: 02 October, 2006 17:50
>To: [email-masked]
>Cc: [email-masked]
>Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-compress-05.txt 
>
>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.
>
>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. 
>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 
>http://www.ietf.org/shadow.html or 
>ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>Below is the data which will enable a MIME compliant mail 
>reader implementation to automatically retrieve the ASCII 
>version of the Internet-Draft.
>

---

From: Dave Cridland <[email-masked]>
Date: Tue, 31 Oct 2006 14:41:46 +0000

> OK The server and the client will compress all data that it may send
Most of these suggestions don't bother me either way, but this one 
strikes me as potentially misleading. One might read this as meaning 
that only literals and strings were compressed, rather than the 
entire protocol stream. It depends on what is meant by "data".

The current wording is less confusing than this, and I think it's 
fine.

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: <[email-masked]>
Date: Tue, 31 Oct 2006 16:59:30 +0200

Well, we can put anything You like there - the reason I changed it because I did not like "expects".
Once compression is on, it will be compressed, right? The word "expects" to me hints that this is not the case.

>From: ext Dave Cridland [mailto:[email-masked]] 
>Sent: 31 October, 2006 16:42
>To: Ordogh Zoltan (Nokia-TP-MSW/Tampere)
>Cc: Enhancements to Internet email to support diverse service 
>enivronments; Arnt Gulbrandsen
>Subject: RE: [lemonade] I-D 
>ACTION:draft-ietf-lemonade-compress-05.txt - comments
>
>Most of these suggestions don't bother me either way, but this 
>one strikes me as potentially misleading. One might read this 
>as meaning that only literals and strings were compressed, 
>rather than the entire protocol stream. It depends on what is 
>meant by "data".
>
>The current wording is less confusing than this, and I think it's fine.
>
>Dave.
>--

---

From: Randall Gellens <[email-masked]>
Date: Tue, 31 Oct 2006 12:20:51 -0800

>  OK The server and the client will compress all data that it may send

"data that it may send" sounds funny.  The original text is very 
clear about which side compresses what (commands versus responses). 
Is there something about it you don't like?

>  After the client has sent the COMPRESS command, the client MUST NOT 
> send any commands until it has seen the result of COMPRESS.

I think the original wording is better as it is more compact and says 
what it needs to.  But perhaps I'm missing something.  What about it 
don't you like?

>  Therefore, responses issued by the server before the OK response 
> will all be uncompressed, and delayed client requests that have 
> been sent uncompressed (before turning compression on) may result 
> in compressed responses.

What are "delayed client requests"?  Do you mean commands sent by the 
client before it sent COMPRESS that were delayed by underlying 
network (perhaps routed differently)?  Or do you mean something else? 
If the server receives uncompressed commands after it has sent the OK 
to COMPRESS, will it interpret them correctly?  The original text 
implies no, but your suggested text states yes.

>  the same way as it is recommended for servers later

Why do you want to change "as is" to "as it is"?  The suggested 
wording sounds awkward to me, and implies that a source other than 
this draft is doing the recommending.

>  So, if I had multiple algorithms, would it be COMPRESS=1,2,3 or 
> COMPRESS=1,COMPRESS=2,COMPRESS=3? I would guess the second.

That's correct, and matches what has been done for some other extensions.

Note that the ABNF for your first alternate would be
	"COMPRESS=" algorithm *( "," algorithm )

>  and any additional compression algorithms are introduced at that 
> time, then the registry should be created

This looks good to me.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
If you don't care where you are, then you ain't lost.

---

From: Philip Guenther <[email-masked]>
Date: Tue, 31 Oct 2006 14:23:50 -0700

> At 4:22 PM +0200 10/31/06, <[email-masked]> wrote:
...
>>  Therefore, responses issued by the server before the OK response will all 
>> be uncompressed, and delayed client requests that have been sent 
>> uncompressed (before turning compression on) may result in compressed 
>> responses.
>
> What are "delayed client requests"?  Do you mean commands sent by the client 
> before it sent COMPRESS that were delayed by underlying network (perhaps 
> routed differently)?  Or do you mean something else? If the server receives 
> uncompressed commands after it has sent the OK to COMPRESS, will it interpret 
> them correctly?  The original text implies no, but your suggested text states 
> yes.

I think he's referring to commands that were sent before the COMPRESS 
command but that the server decided to process after the COMPRESS command. 
I suppose the client could pipeline CAPABILITY and COMPRESS commands 
together, in that order, and the server could handle them out of order. 
But I don't see why specific text is needed for this.  For the server to 
client directory, everything received before a tagged OK response to the 
COMPRESS command is uncompressed.  Everything after that is uncompressed. 
There are no exceptions.  The more text we use here the more likely 
someone will think an exception is being described.

...
>> COMPRESS=1,COMPRESS=2,COMPRESS=3? I would guess the second.

It would be COMPRESS=1 COMPRESS=2 COMPRESS=3.  Capabilities are separated 
by spaces, not commas.  c.f. RFC 3501 page 25 for an example involving 
multiple AUTH= capabilities.

Philip Guenther

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 31 Oct 2006 22:40:22 +0100

Philip Guenther writes:
>> network (perhaps routed differently)?  Or do you mean something 
>> else? If the server receives uncompressed commands after it has sent 
>> the OK to COMPRESS, will it interpret them correctly?  The original 
>> text implies no, but your suggested text states yes.
>

Or to commands/responses that the client/server has sent, but whose TCP 
segments were delayed en route. Since the receiver's TCP layer sorts 
that out I don't want to add text about it.

Arnt

---

From: Randall Gellens <[email-masked]>
Date: Tue, 31 Oct 2006 14:49:23 -0800

At 2:23 PM -0700 10/31/06, Philip Guenther wrote:

>>  What are "delayed client requests"?  Do you mean commands sent by 
>> the client before it sent COMPRESS that were delayed by underlying 
>> else? If the server receives uncompressed commands after it has 
>> sent the OK to COMPRESS, will it interpret them correctly?  The 
>> original text implies no, but your suggested text states yes.
>
>  I think he's referring to commands that were sent before the 
> COMPRESS command but that the server decided to process after the 
> COMPRESS command. I suppose the client could pipeline CAPABILITY 
> and COMPRESS commands together, in that order, and the server could 
> handle them out of order. But I don't see why specific text is 
> needed for this.  For the server to client directory, everything 
> received before a tagged OK response to the COMPRESS command is 
> uncompressed.  Everything after that is uncompressed. There are no 
> exceptions.  The more text we use here the more likely someone will 
> think an exception is being described.

I agree.
-------------- Randomly-selected tag: ---------------
Sorry, please try again. Thank you for taking the Turing test.

---

From: Randall Gellens <[email-masked]>
Date: Tue, 31 Oct 2006 14:49:15 -0800

At 4:59 PM +0200 10/31/06, <[email-masked]> wrote:

>  Well, we can put anything You like there - the 
> reason I changed it because I did not like 
> "expects".
>  Once compression is on, it will be compressed, 
> right? The word "expects" to me hints that this 
> is not the case.

Good point.  I read the use of "expects" as being 
literally true: since the server expects that all 
subsequent client commands are compressed, it 
will decompress them before reading them.

Keep in mind that the text we are discussing is 
comment text in a server response, as opposed to 
normative statements in the draft.  As such, it 
makes sense that it is written from the server's 
point of view.  A server could just as validly 
say "OK foo bar gork" or "OK All my responses 
will be compressed and you better compress all 
your commands".

-------------- Randomly-selected tag: ---------------
Program complexity grows until it exceeds the capability of
the programmer who must maintain it.