104 lines
4.6 KiB
Plaintext
104 lines
4.6 KiB
Plaintext
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.
|
|
|