MBOX-Line: From mrc+uw at Panda.COM  Tue Jun 16 13:44:24 2009
To: imap-protocol@u.washington.edu
From: Mark Crispin <mrc+uw@Panda.COM>
Date: Fri Jun  8 12:34:42 2018
Subject: [Imap-protocol] Changing capabilities
In-Reply-To: <1245183163.21624.814.camel@timo-desktop>
References: <1245181628.21624.808.camel@timo-desktop>
	<alpine.OSX.2.00.0906161258240.4967@hsinghsing.panda.com>
	<1245183163.21624.814.camel@timo-desktop>
Message-ID: <alpine.OSX.2.00.0906161341350.4967@hsinghsing.panda.com>

On Tue, 16 Jun 2009, Timo Sirainen wrote:
>> I've done this for a long time with implicit capabilities.
> You mean with those [CAPABILITY ..] response codes?

Yes.

> But do you also
> return reduced capabilities when replying to a CAPABILITY command before
> login?

No.

> That's the main change I'm hoping to make, because in some setups
> the list of capabilities isn't known before knowing the username.

I see no problem with doing that.  It has always been intended that 
capabilities can change at authentication (and STARTTLS) time.

>>> Note that in b) case it's sending untagged CAPABILITY reply. This seems
>>> to help a lot of clients.
>> I don't know if you care, but that would break an IMAP2 client.
>> Hopefully, nobody is still using Pine 3.xx ...
> I'd rather break Pine 3.xx than Thunderbird, Outlook and OE. :)

Indeed.  However, it's not clear that there won't be other clients that 
will toss their cookies at receiving an unsolicited CAPABILITY response; 
and as I said IMAP2 clients will definitely do so.  That's why the 
CAPABILITY response code exists.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

