Re: [lemonade] WGLC draft-ietf-lemonade-compress-02.txt

[Alexey Melnikov <alexey.melnikov at isode.com>]

Burger, Eric wrote:

> The Work Group Last Call for draft-ietf-lemonade-compress-02.txt will
> close 5 August 2006.  Please prepend the string "WGLC compress-02" to
> the subject line of your comments.
>
> Thank you.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-lemonade-compress-02.txt
>  
I think the document is in a good shape, but at least one more revision 
is needed.
(Also, Dave has a real implementation issue with this extension, but I 
let him report it.)

>2.  Introduction and Overview
[...]
>    The goal of COMPRESS=DEFLATE is to reduce the bandwidth usage of
>    IMAP.  On regular IMAP connections, the PPP or MNP compression used
>    with many low-bandwidth links compresses IMAP well. However, when
>    TLS is used, PPP/MNP compression is ineffective. TLS too may provide
>    compression, but a careful IMAP implementation can do much better.

I don't like the last sentence. It doesn't provide any explanation on 
why TLS compression is worse.

>    In order to increase interoperation, it is desirable to have as few
>    different compression algorithms as possible, so this document
>    specifies only one.  The DEFLATE algorithm is standard, widely
>    available, unencumbered by patents and fairly efficient.  Hopefully
>    it will not be necessary to define additional algorithms.

I think a reference to the DEFLATE algorithm description is needed the 
first time it is mentioned.

>3.  The COMPRESS Command
[...]
>    If both [STARTTLS] and COMPRESS are in use, the data should be

SASL is not listed here, but listed below. I suggest to change the 
beginning of the first sentence to read:

>    If both [STARTTLS]/SASL security layer [SASL][IMAP] and COMPRESS 
are in use, the data should be

>    compressed before it is encrypted (and decrypted before it is
>    decompressed), independent of the order in which the client issues
>    COMPRESS, AUTHENTICATE and STARTTLS.

Section 3 doesn't describe when exactly compression starts in both 
directions. Suggested text:

     Compression takes effect immediately following the
     CRLF that concludes the COMPRESS command for the client,
     and the CRLF of the tagged OK response for the server.

>4.  Compression Efficiency

This is not a big deal, but I would recommend moving this into 
Informative Appendix.

>5.  Formal Syntax
[...]
>        command-any =/ compress
>
>        compress    = "COMPRESS" SP algorithm
>
>        algorithm   = "DEFLATE"

Does this mean that sending DEFLATE as quoted string (or literal) is not 
allowed?

I would rather see the following:

       algorithm   = astring
                           ;; Only "DEFLATE" is registered by this document

Or if you really want to use atom:

       algorithm   = atom
                           ;; Only "DEFLATE" is registered by this document

BTW, be prepared to answer IESG why you don't want an IANA registry.

>6.  Security Considerations
>
>    As for [TLSCOMP] RFC 3749.

That is probably Ok, but wouldn't it be better to cut&paster Security 
Considerations from RFC 3749 and do explicit acknowledgment of the 
copied text?

>9.1. Normative References
>
>    [IMAP]     Crispin, "Internet Message Access Protocol - Version
>               4rev1", RFC 3501, University of Washington, June 2003.

[...]

>    [STARTTLS] Newman, C. "Using TLS with IMAP, POP3 and ACAP", RFC
>               2595, June 1999.

This reference got replaced by RFC 3501, drop it.
*
*


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