Document: draft-ietf-lemonade-compress-07.txt
Reviewer: Miguel Garcia <miguel.an.garcia@nokia.com>
Review Date: 20-Jan-2007
IESG Telechat date: 25 January 2007

Summary: This draft is on the right track but has open issues, described 
in the review.

Comments: The document is almost ready for publication. I would like the 
authors to comment on the issue #2 (below), where I understand there is 
possibilities for an unrecoverable loop in the protocol. I am not sure 
if the WG is aware of it. Besides, there are some other nits that should 
be fixed.

1) In Section 2, 4th paragraph, the document mentions the LEMONADE WG. I 
  think this should be avoided, since WGs are temporary in nature, while 
RFCs are permanent. In a few years, when LEMONADE WG closes, readers 
will not be familiar with the LEMONADE WG, so better avoid the reference 
to it.

2) Section 3, paragraphs 5 and 7. I think there is some initial 
contradiction in the text, unless it is later clarified. The text here 
reads:

     "If the server
     response was BAD or NO, the client MUST NOT turn on compression."

The contradiction is that the BAD result may also indicate that 
compression is already active, in which case the text "the client MUST 
NOT turn on compression" could be understood as "the client MUST stop 
using compression", which obviously is not the intention.

I will leave a possible rewording up to you. I though something around 
"not changing the compression state". Perhaps:

"If the server response was BAD or NO, the client MUST not change its 
compression state, i.e., if compression was already active, it MUST 
continue using compression; if compression was not active, it MUST NOT 
turn on compression".

A more important side effect of this issue: I wonder now if there is a 
technical problem if, for some reason (e.g., software bug), the client 
thinks that compression is not active, but the server thinks that 
compression is active. The client sends COMPRESS and will get a BAD 
result. Reissuing the comment will have the same effect. There is no 
mechanism to recover from this loop: the client will not compress, the 
server will compress. Have the authors or WG thought about this problem?

3) IANA considerations section. A few tips:

- Usually links are not welcomed in this section (they may change with 
time).

- Accurately mention the registry IANA has to operate with. There isn't 
an "IMAP extensions" IANA registry, but instead, "IMAP4 Capabilities 
Registry".

- Is the new capability "COMPRESS", "COMPRESS=", or "COMPRESS=DEFLATE" ?
I think it shouldn't be "COMPRESS=DEFLATE", you may add the list of 
compression algorithms at a later stage by creating a new subregistry of 
the IMAP4 capabilities registry. By inspecting the current registry, I 
saw a value "RIGHTS=", which makes me think that "COMPRESS=" should be 
also valid. You must determine whether the capability is "COMPRESS" or 
"COMPRESS=" according to the current IMAP4 practices.

Suggested rewording for the first paragraph.

"IANA is requested to add "COMPRESS" as a new Capability Name in the 
IMAP4 Capabilities Registry.

- On the second paragraph, which starts "Note to IANA", I think the note 
is very valuable for the reader, but IANA does not necessarily 
understand/care about it. Perhaps you should just leave it as "Note", 
removing "to IANA".

4) It is not clear to me if the draft mandates the implementation of 
DEFLATE or not. In other words, if 10 years from now, someone comes and 
implement this RFC-to-be, but rather than DEFLATE it implements some 
other algorithm, can it say the implementation is compliant with this 
RFC? My opinion is that the intention is to guarantee interoperability 
while allowing extensibility. Thus, the draft should mandate the 
implementation of DEFLATE, which at the moment does not. I would suggest 
to add a sentence, somewhere, reading:

"Implementations according to this specification MUST implement the 
DEFLATE algorithm [RFC1951] and MAY implement other compression algorithms".

5) idnits tool reveals two nits:

- This document has ISOC Copyright according to RFC 3978, instead of the
  newer IETF Trust Copyright according to RFC 4748.  You should consider
  updating it; the new Copyright statement will be required from February
  1st, 2007
- This document has an original RFC 3978 Section 5.5 Disclaimer, instead
   of the newer disclaimer which includes the IETF Trust according to RFC
   4748. You should consider updating it; the new disclaimer will be
   required from February 1st, 2007