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

From: Miguel Garcia <[email-masked]>
Date: Sat, 20 Jan 2007 14:18:13 +0200

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 <[email-masked]>
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

BR,

       Miguel
-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 23 Jan 2007 12:11:25 +0100

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

Miguel Garcia writes:
> 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,"?

> contradiction in the text, unless it is later clarified. The text 
> here reads:
>
>     "If the server
> 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.
>
> continue using compression; if compression was not active, it MUST 
> NOT turn on compression".
>
> 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.

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

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

> - On the second paragraph, which starts "Note to IANA", I think the 
> note is very valuable for the reader, but IANA does not necessarily 
> 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 
> implementation of DEFLATE, which at the moment does not. I would 
> suggest to add a sentence, somewhere, reading:
>

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

>   required from February 1st, 2007

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

Arnt

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Jan 2007 13:34:03 +0100

My ballot is No Objection, so please follow Ted's direction
on this.

    Brian

On 2007-01-23 12:11, Arnt Gulbrandsen wrote:
>> 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.
>>
>> compression is active.
> 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 
> COMPRESSIONACTIVE response code so the client can learn what's going on.
> 
>> capability is "COMPRESS" or "COMPRESS=" according to the current IMAP4 
>> practices.
> 
> 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.
> 
>> 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:
>>

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 23 Jan 2007 17:53:04 +0200

Hi Arnt:

In general, you should wait for instructions from Ted Hardie with 
respect my comments. At the end of the day, these are just suggestions.

I would also like to have some further comments on a few issues. I 
delete the rest of the message where there is no need for further 
discussion.

> COMPRESSIONACTIVE response code so the client can learn what's going on.

I wasn't worried about this case, for which I assumed what you just 
mentioned about the different TLS APIs. I was worried about the 
COMPRESSion at IMAP level.
> 
> In the case of IMAP-level compression it cannot happen. 

Are you sure that software bugs will prevent the case?

> If it does 

I think the connection will still be usable, because the assumption is 
that the COMPRESS command successfully reached the IMAP server, so I 
don't think we have an unusable connection
> so I didn't try to add a specific fix.

Ok, I am not so familiar with IMAP, so I didn't now this was a general 
problem. Well, as I said, these are non-binding comments, so you should 
consult Ted.

> Uh? IANA asked me to clarify when the previous revision of the draft did 

Weird, really weird. At least I know that the IESG members don't like 
these URLs in the IANA considerations section.

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

Interesting... the fix should be done before IANA gets the draft, not in 
  auth48, which is post-IANA.

> order to use that argument.

Well, the thing I don't like is the "implicitly". I think the aim of the 
draft is to mandate DEFLATE and leave the door open for future 
algorithms, so I was trying to capture this sentiment with the suggested 
wording.
> reason not to, so we think it's better to defer the choice of M-T-I to 

I disagree again. DEFLATE is always mandatory to implement, because the 
only way to achieve interoperability is through the definition of at 
least one mandatory compression algorithm.

> will be improved until it eventually supersedes this extension.)

Again I disagree here. I have seen many RFCs that define a protocol 
capability (such as COMPRESS) and one instantiation of that capability 
(such as DEFLATE), and at the same time the open or not the registry for 
other instantiations. Just to mention a document that does the same: RFC 
3486, which defines the "comp" capability for SIP and the "sigcomp" 
value for such capability.

> Ah, I must upgrade idnits again. (I think the version I use is all of 

Or you can use the online version at http://tools.ietf.org/

BR,

        Miguel