MBOX-Line: From tss at iki.fi  Wed Jun 17 09:16:22 2009
To: imap-protocol@u.washington.edu
From: Timo Sirainen <tss@iki.fi>
Date: Fri Jun  8 12:34:42 2018
Subject: [Imap-protocol] Changing capabilities
In-Reply-To: <B4D8E3E4-A3B1-4F02-B2EA-7C2BE5A38AC2@sabahattin-gucukoglu.com>
References: <1245181628.21624.808.camel@timo-desktop>
	<B4D8E3E4-A3B1-4F02-B2EA-7C2BE5A38AC2@sabahattin-gucukoglu.com>
Message-ID: <1245255382.21624.854.camel@timo-desktop>

On Wed, 2009-06-17 at 09:30 +0100, Sabahattin Gucukoglu wrote:
> On 16 Jun 2009, at 20:47, Timo Sirainen wrote:
> > Has anyone tested how well clients support catching capabilities after
> > login? I was planning on having Dovecot v2.0 send only very minimal
> > capabilities before login.
> 
> Is it standard behaviour to even expect clients to understand  
> capabilities in untagged responses at all?  (Or has this just become  
> unspoken convention somehow?)

Well, RFC 3501 mentions automatically sent capabilities in a few places,
like:

> A server MAY send capabilities automatically, by using the
>       CAPABILITY response code in the initial PREAUTH or OK responses,
>       and by sending an updated CAPABILITY response code in the tagged
>       OK response as part of a successful authentication.  It is
>       unnecessary for a client to send a separate CAPABILITY command if
>       it recognizes these automatic capabilities.

So I guess it's preferred to send CAPABILITY response code in response
codes instead of untagged CAPABILITY, and this is also what Dovecot does
as long as client doesn't ignore them by requesting the CAPABILITY
again. The untagged CAPABILITY sending is only a workaround to many
commonly used clients.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20090617/98e1bf7c/attachment.sig>
