MBOX-Line: From janssen at parc.com  Wed Mar 21 20:00:14 2007
To: imap-protocol@u.washington.edu
From: Bill Janssen <janssen@parc.com>
Date: Fri Jun  8 12:34:38 2018
Subject: IMAP Wiki [was: Re: [Imap-protocol] IMAP features: which clients
	use them?] 
In-Reply-To: <F37B003F-C418-4AD4-8579-09BC33D71505@goodserver.com> 
References: <07Mar20.114847pst."57996"@synergy1.parc.xerox.com>
	<20070320133052.S8455@orthanc.ca>
	<07Mar20.133147pst."57996"@synergy1.parc.xerox.com>
	<1174428749.1318.94.camel@hurina>
	<07E59C2E-717C-4CD3-A668-6059C9F3AC0D@goodserver.com>
	<1174437211.1318.113.camel@hurina> <46008660.2040107@avaya.com>
	<07Mar20.174358pst."57996"@synergy1.parc.xerox.com>
	<F37B003F-C418-4AD4-8579-09BC33D71505@goodserver.com>
Message-ID: <07Mar21.190015pst."57996"@synergy1.parc.xerox.com>

> On a related note, I would not press the point too hard about saying  
> certain software is not IMAP4rev1 compatible. As I recall, a few  
> things became REQUIRED in RFC 3501 that were not in 2060, which was  
> done without bumping the rev # on the protocol, i.e. IMAP4rev2, which  
> would have given vendors a clear goal to work towards, without adding  
> confusion. If my memory has served me correctly on that note, then a  
> vendor could have been IMAP4rev1 compliant as of rfc2060 without  
> supporting STARTTLS or disabling LOGIN, and so it is not fair to bait- 
> and-switch by calling those two specs the same protocol rev.

Interesting.  I was wondering why the server would have to send
STARTTLS in the CAPABILITIES response if it was a required feature of
every server.  This seems to answer that question.

If Timo is starting a Wiki, perhaps an "Annotated RFC 3501", in the
spirit of Martin Gardner's THE ANNOTATED ALICE (see
http://www2.wwnorton.com/catalog/fall99/alice.htm), would be a good
thing to put up on it.  It could annotate the RFC to explain these
things.

Bill



