MBOX-Line: From tjs at psaux.com  Mon Oct 29 14:43:10 2007
To: imap-protocol@u.washington.edu
From: Tim Showalter <tjs@psaux.com>
Date: Fri Jun  8 12:34:40 2018
Subject: [Imap-protocol] re: GMail
In-Reply-To: <1193689139.25921.618.camel@hurina>
References: <alpine.WNT.0.9999.0710241938220.520@Shimo-Tomobiki.Panda.COM>	
	<fc2c80ae0710270911o23f0b366g942b2956ac3fa@mail.gmail.com>	
	<alpine.WNT.0.9999.0710270924180.4788@Shimo-Tomobiki.Panda.COM>	
	<5202.1193523708.069559@peirce.dave.cridland.net>	
	<alpine.OSX.0.9999.0710271708460.11181@pangtzu.panda.com>	
	<1193531029.25921.561.camel@hurina>	
	<alpine.WNT.0.9999.0710271748490.204456@Ningyo-no-Mori.Panda.COM>	
	<RMRLrFbL0dA92HCVkk6Cgw.md5@libertango.oryx.com>	
	<alpine.OSX.0.9999.0710280923190.11181@pangtzu.panda.com>	
	<d1klUHoFkFbXOtQmbn1Bww.md5@libertango.oryx.com>	
	<47263322.7040702@psaux.com> <1193689139.25921.618.camel@hurina>
Message-ID: <472653EE.9080102@psaux.com>

Timo Sirainen wrote:
> Client-side capabilities come to my mind. Has something like this been
> discussed already?
> 
> 1 ENABLE UTF-8 UNSOLICITED-RESPONSES-WITHOUT-IDLE ETC

IMAP lore says this is what killed IMAP 3.

I'm not opposed to client-side capabilities, as I think we need a way to 
get rid of some of the cruft of the protocol eventually.  But I do think 
we ought to be able to specify a strict, increasing order for such 
extensions.

Tim

