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

Dave Cridland writes:
> On Mon Sep 18 15:50:02 2006, Internet-Drafts@ietf.org wrote:
>> A URL for this Internet-Draft is:
>> 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.

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

> 2) I would move the fourth paragraph "For DEFLATE (as for many other 
> 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?

> 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.

I struck the word security and used the rest.

> My intention is to avoid any grey areas concerning whether, for 
> 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

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade