MBOX-Line: From brong at fastmail.fm  Tue Nov 15 21:08:34 2011
To: imap-protocol@u.washington.edu
From: Bron Gondwana <brong@fastmail.fm>
Date: Fri Jun  8 12:34:47 2018
Subject: [Imap-protocol] SELECT/EXAMINE clarification of UNSEEN
In-Reply-To: <alpine.OSX.2.00.1111151543580.38075@hsinghsing.panda.com>
References: <C61A1BDF-03DD-4ED9-BFCA-C6183F07DD3E@mac.com>
	<alpine.OSX.1.10.1111141446070.8578@rastawifi.orthanc.ca>
	<1321311798.30750.140660998918417@webmail.messagingengine.com>
	<4EC1A0A5.8051.EFC2A39@David.Harris.pmail.gen.nz>
	<1321346922.6321.140660999083661@webmail.messagingengine.com>
	<4EC268D1.7010404@aol.com>
	<1321364880.3715.140660999182809@webmail.messagingengine.com>
	<alpine.OSX.2.00.1111151258420.38075@hsinghsing.panda.com>
	<20111115233902.GA1071@brong.net>
	<alpine.OSX.2.00.1111151543580.38075@hsinghsing.panda.com>
Message-ID: <20111116050834.GA12266@brong.net>

On Tue, Nov 15, 2011 at 05:21:35PM -0800, Mark Crispin wrote:
> On Wed, 16 Nov 2011, Bron Gondwana wrote:
> >It's not the first time this warty area of the specification has been
> >queried - and the fact that multiple implementors have asked exactly
> >the same questions suggests that the logicial inconsistency in that
> >part of the specification is a problem which impedes understanding.
> 
> That is why there is an errata and the concept of "frequently asked
> questions." This particular question is one that is simply answered; and
> is usually answered simply without making a federal case out of it.
> 
> These things happen. They always will happen. Should someone bother to
> make an erratum on this matter and get it posted to the errata, it will
> eventually get into a revision of the document. But there is no way that
> anyone can prevent it from happening in the future.
> 
> If you care so much, write the erratum and submit it.
> 
> Nobody cares that you think that you are smarter than me and know how to
> solve problems better than you.
> 
> Just write the freaking erratum, submit it, and move on.

% Intelligent and talented people, if they find that trivial matter to be
% annoying enough, will write an errata with proposed replacement wording,
% post it for review, and upon general concensus will submit it to the RFC
% 3501 errata for inclusion in a future revision.

So I did.

> Within hours after the revision is issued, there are new errata. At that
> point, everybody is too burned out to do anything more than start a new
> errata list.

And meanwhile whenever anyone asks the question, you can point at the
errata.  Problem solved.  No debate.

> >Fix it in ONE place, or explain it fresh to every new person
> >who trips over this nastily placed rock as if they're some sort of
> >idiot for not understanding the last time you explained it to someone
> >else.
> 
> The third alternative is simply to explain it and move on. "Yup, there's a
> rock there, just step around it." It doesn't imply that the newbie is an
> idiot. He wouldn't know that there is no deep dark secret, so he asked -
> which is absolutely and unquestionably the intelligent thing to do.
> 
> The only idiot in this entire foofaraw is you, for beating a dead horse.
> 
> If it's so important to you, write the erratum and move on.

Yeah, I did that first.

> >the reason we breed new people all the
> >time is because you sometimes have to throw everything away and start with
> >just bits of what you had before.  If you let the all the history build up
> >for ever you wind up with an old person living in their memories and unable
> >to adapt to the world.
> 
> If you think that you are smarter than me and can do a better job, then by
> all means go ahead and do it. I've watched at least four IMAP-replacement
> projects launch with great fanfare and bombast only to wither away into
> nothing. There were probably more; I haven't bothered to count but the
> four are the ones that I distinctly remember.

I don't know about "smarter" - but I think I probably will have a go at
a mail protocol at some point if I keep working with mail 100%.  It's
not fully baked yet though.

> Eventually one of these will succeed.
> 
> It will NOT be one that launches with fanfare and bombast. It will be
> something that nobody hears of for years. Its architect will be too busy
> DOING to boast about how much better a job he will do. His time is going
> to be spent, not in reacting to IMAP but rather in solving the completely
> new problems encountered in the process of his own design.
> 
> IMAP spent at least 5 years in that stage.

We're not that far yet.  We're still experimenting with a bunch of ajaxy
JSON nonsense which will probably go through plenty more revisions when
it has more than one user.  Middleware first.

Bron.

