MBOX-Line: From guenther+imap at sendmail.com  Wed Mar 21 22:20:01 2007
To: imap-protocol@u.washington.edu
From: Philip Guenther <guenther+imap@sendmail.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: <07Mar21.190015pst."57996"@synergy1.parc.xerox.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>
	<07Mar21.190015pst."57996"@synergy1.parc.xerox.com>
Message-ID: <Pine.BSO.4.64.0703212224000.14907@vanye.mho.net>

On Wed, 21 Mar 2007, Bill Janssen wrote:
>> 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.

"Things Change."  Welcome to life with Internet protocols.

When Van Jacobsen and Mike Karels rewrote the book on congestion control 
for TCP, the protocol number for TCP wasn't changed, not even when RFC 
1122 came out just over a year later and said that "A TCP MUST implement" 
the various algorithms.  Boom, all implementations more than a year or so 
old were declared nonconforming with no number change.  Was that fair? 
No, but it saved the Internet from congestion collapse.

Where do you draw the line between "bait-and-switch" and "ouch, that's 
broken/harmful/insecure!  Now we know better"?

As for changing the version number on IMAP when STARTTLS was added, there 
are two possibilities: either you break backwards compatibility or you 
don't.  If "IMAP4rev2" is incompatible with "IMAP4rev1", then no one will 
want to upgrade their server, because none of their clients will work. 
No sane server vendor would do such an upgrade and no sane client author 
will add "IMAP4rev2" support until there's a server they can test against. 
If "IMAP4rev2" is compatible with "IMAP4rev1", then it's just "STARTTLS" 
with a different name.  Since STARTTLS was an option for *four years* 
before it became mandatory, changing it's name from "STARTTLS" to 
"IMAP4rev2" would only mean that servers would advertise both and newer 
clients would check for both.  Completely pointless.

Is "IMAP4rev1" a moving target?  Sure.  That's true of lots of stuff in 
the Real World too.  The standards for building codes change regularly: I 
had to add *five* smoke detectors to my house as part of a *one* room 
remodel.  Car manufacturers have to keep adding safety features and 
tweaking engines to meet changes in requirements.  Cities tighten up their 
water purification processes to meet tighter EPA standards on nitrate 
levels.  Change Happens.  Welcome to the IETF, and Life.


Philip Guenther

