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

[Brian E Carpenter <[e-mail]>]

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

    Brian

On 2007-01-23 12:11, Arnt Gulbrandsen wrote:
> 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
> 

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