Re: [lemonade] draft-gulbrandsen-imap-enable-03

[Alexey Melnikov <[e-mail]>]

Arnt Gulbrandsen wrote:

>> I also don't like the fact that we're documenting that ENABLE can be 
>> used to probe for extensions (as per paragraph 2 in section 5).  We 
>> already have a command to list extensions.
>
> I'm perfectly happy taking that out, if that would be appropriate. I 
> thought this sort of thing was supposed to be listed in security 
> considerations.

Based on various off-list discussions I got impression that several 
people really disliked that.
So I am suggesting the following change:

Replace:
 The server MUST NOT change the CAPABILITY list as a result of
 executing ENABLE.

With:
 The server MUST NOT change the CAPABILITY list as a result of
 executing ENABLE, i.e. a CAPABILITY command issued right after
 an ENABLE command MUST list the same capabilities as a CAPABILITY
 command issued before the ENABLE command. The following example
 demonstrates that:
 
 C: t1 CAPABILITY
 S: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 ID LITERAL+ ENABLE
 S: t1 OK foo
 C: t2 ENABLE CONDSTORE X-GOOD-IDEA
 S: t2 OK foo
 C: t3 CAPABILITY
 S: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 ID LITERAL+ ENABLE
 S: t3 OK foo again
 
and also add:
 
 Note that according to [RFC3501] the list of advertised capabilities MAY
 change after a STARTTLS and/or AUTHENTICATE/LOGIN command. The ENABLE 
command
 doesn't change that.