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

[Alexey Melnikov <[e-mail]>]

Peter Coates wrote:

>What?  If Enabling an extension does not affect the CAPABILITY vector, and
>if the ENABLE command silenty ignores extensions the server does not want to
>allow or which it does 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
>  
>
Agreed, but this can (and I think should) be done in a way which doesn't 
contradict text I've suggested. See below.

>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
>  
>
I dislike that, because you now implicitly saying that there are magic 
extensions which don't work unless the client knows how to enable them. 
Really, the server should have advertised the CONDSTORE extension to 
begin with.

>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
>  
>
(Or just use the CAPABILITY response code: it serves the same purpose + 
can save a round trip in this case.)

So if you insist on being able to change the capability list, it is much 
better to return the updated list using the CAPABILITY response code. 
Clients should already be able to handle unsolicited updates, in 
particular because the CAPABILITY response code payload frequently 
changes after LOGIN/AUTHENTICATE.
This allows the client to figure out if an extension can be enabled 
after all.

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