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

[Miguel Garcia <[e-mail]>]

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.

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

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

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

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.

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

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

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

Interesting... the fix should be done before IANA gets the draft, not in 
  auth48, which is post-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.

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

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.

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

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.



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

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

BR,

        Miguel


> Arnt

-- 
Miguel A. Garcia           tel:[phone]
sip:[e-mail]
Nokia Research Center      Helsinki, Finland

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