MBOX-Line: From mrc+imap at panda.com  Tue Nov 15 17:21:35 2011
To: imap-protocol@u.washington.edu
From: Mark Crispin <mrc+imap@panda.com>
Date: Fri Jun  8 12:34:47 2018
Subject: [Imap-protocol] SELECT/EXAMINE clarification of UNSEEN
In-Reply-To: <20111115233902.GA1071@brong.net>
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>
Message-ID: <alpine.OSX.2.00.1111151543580.38075@hsinghsing.panda.com>

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.

Nobody will to issue a new version of the document just for this one
stupid dinky ambiguity. It takes approximately one man-year(!) to produce
a revised version of the IMAP specification. Multiple drafts, reviews,
updates, re-reviews, reformats, compliance, ... that all take place as
part of a revision.

Errata collect for a while before such a task is launched.

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.

> It's obviously the only possible response.

The fact that it is obvious makes it of lower priority.

As annoying as it is, there is only one answer. When resources are
limited (and resources are ALWAYS limited), they are focused on the
problems that are less easily resolved.

> 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.

> You might get some pleasure out of treating people like idiots,
> but it doesn't actually help.

I don't treat newbies like idiots.

I do get a teacher's pleasure in helping newbies learn. As time goes on, I
see ways to improve the text; but there will always be a need to help
newbies.

> It's an arsehole's approach to leave known stones which have tripped many
> others - then point and laugh at the clumsiness of those walking the same
> well trodden path as they trip there.

Maybe you should stop name-calling and accusations.

I don't laugh at anyone who trips over the stone. I say "yup, there's a
rock there, just step around it."

There's lots of other rocks to get rid of during the next repaving. Until
the repaving, we're stuck with telling people about the rocks. At least
this rock is visible with bright paint on it. Some rocks, not to mention
all the holes, are less obvious and more dangerous; and consequently get
more attention.

If you care, write the erratum. That way, when the repaving is done,
people will remember to get rid of that rock.

It's going to be a while before the repaving is done. Repaving is very
costly. We don't repave for one rock. On top of that, the paving
regulations keep on changing, so besides all the rock and hole removals,
there's also new regulatory compliance.

Just don't be surprised when, after the repaving, brand new rocks and
holes show up. Some will be in text was that supposed to fix the previous
set of errata [*]. Others show up in the new regulatory compliance work
(intake of breath here) that was not required before. Still more is made
by the crew that comes in AFTER you're done to "proof" and "standardize"
it. God help you if you have the temerity to CHANGE the specification!

[*] Such is the particular text that you are beating me over the head
about. Another person (I remember who, but won't say) wrote it. It's easy
to identify errata. It is much harder to write a replacement that doesn't
create new errata. A great source of this is unintended interactions with
some text in a completely different part of the document.

> 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.

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.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

