mailing list archives

meli community discussions

⚠️ if something does not work as intended when interracting with the mailing lists,
reach out Github mirror Gitea repo @epilys:matrix.org

E-mail headers
From: Bill Janssen <janssen@parc.com>
To: imap-protocol@u.washington.edu
Date: Fri, 08 Jun 2018 12:34:38 -0000
Message-ID: 07Mar21.190015pst."57996"@synergy1.parc.xerox.com permalink / raw / eml / mbox
In-Reply-To: F37B003F-C418-4AD4-8579-09BC33D71505@goodserver.com
References: F37B003F-C418-4AD4-8579-09BC33D71505@goodserver.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
Reply