[Gen-art] Re: Gen-ART Proto-WG review of draft-ietf-lemonade-compress-07.txt

[Arnt Gulbrandsen <[e-mail]>]

Thanks! I'm sorry my reply is so late.

Miguel Garcia writes:
> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
> Please wait for direction from your document shepherd
> or AD before posting a new version of the draft.
>
> Document: draft-ietf-lemonade-compress-07.txt
> Reviewer: Miguel Garcia <[e-mail]>
> 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.

I see the point, but I've thought about other ways to put it, and like 
them less. Would you be happy if I were to insert ", which developed 
this document,"?

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

You say compression, with lower case, so yes ;) The MUA with which I 
type these words can negotiate TLS compression, but it doesn't know so. 
It happens to be linked with a TLS implementation that negotiates 
compression, but has no API to tell the application about it. One of 
the IMAP servers I'm connected to uses a different TLS toolkit and API, 
and _does_ know that TLS compression has been negotiated. One of the 
implementers found the problem a few months ago, and I added the 
COMPRESSIONACTIVE response code so the client can learn what's going 
on.

In the case of IMAP-level compression it cannot happen. If it does 
happen the connection instantly becomes unusable (due to byte-level 
syntax differences between DEFLATE and IMAP) and in general either the 
client or server will close the connection after a few bytes. In the 
worst case it takes half an hour, then RFC3501's inactivity timeout 
strikes and the connection is closed.

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

Yes.

That's a general IMAP problem. The same problem occurs in a slightly 
different form if you try to select a mailbox for which you don't have 
read access. Some clients will send 'select name.of.mailbox', get a 'NO 
insufficient rights' response, and try the same command again 
immediately. That's just one example, there are many other forms of the 
problem. At a guess, I'd say around 50% of the IMAP commands can be 
affected by such bugs, and the three most-used commands can all be 
affected.

The problem is less severe in this case than for many existing commands, 
so I didn't try to add a specific fix.

> 3) IANA considerations section. A few tips:
>
> - Usually links are not welcomed in this section (they may change with time).

Uh? IANA asked me to clarify when the previous revision of the draft did 
NOT name the URL.

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

Good point. I can fix this in auth48 or (preferably) in an rfc-editor note.

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

RIGHTS is odd and strange.

This has been a bit of a mess over the past years. COMPRESS=DEFLATE 
seems to me to be the alternative that's most in tune with tradition 
and current practice. We discussed this a couple of years ago on the 
imapext mailing list, in the context of another extension.

I wonder why AUTH=... isn't listed on the IANA page.

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

It implicitly does. The COMPRESS command has one mandatory argument, and 
that argument has exactly one legal value. Servers must implement 
DEFLATE in order to support the legal argument, and clients must in 
order to use that argument.

If the extension is later widened to allow other compression algorithms, 
DEFLATE may or may not be mandatory to implement. IMO that's desirable. 
We don't know any reason why we'd want to widen it, and we know a good 
reason not to, so we think it's better to defer the choice of M-T-I to 
when there is a choice.

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

IMO, out of place in this document. Should be in the document that 
defines a registry and more compression methods, if such a document is 
ever published. (At the moment, there's general consensus among the 
reviewers and myself that this won't happen. Instead TLS compression 
will be improved until it eventually supersedes this extension.)

> 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

Ah, I must upgrade idnits again. (I think the version I use is all of 
four months old.)

Arnt

_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art