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

[Peter Coates <[e-mail]>]

What?  If Enabling an extension does not affect the CAPABILITY vector, and
if the ENABLE command silenty ignores extensions the server does not wan to
allow or which it doe not know, then after the sequence

 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

the client does not know whether CONDSTORE is enabled or not.  I assert that
either the enable command has to tell the client which things worked (or
which things didn't), or the capability vector has to change

Thus the sequence should be either
 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
CONDSTORE
 S: t3 OK foo again

Or
 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: * OK [ENABLED CONDSTORE] or some variant of this
 S: t2 OK foo
 C: t3 CAPABILITY
 S: * CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 AUTH=DIGEST-MD5 ID LITERAL+ ENABLE
 S: t3 OK foo again

Peter


-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Alexey Melnikov
Sent: November 9, 2007 08:16
To: Arnt Gulbrandsen
Cc: [e-mail]; [e-mail]
Subject: Re: [lemonade] draft-gulbrandsen-imap-enable-03


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.