[Imap-protocol] SELECT/EXAMINE clarification of UNSEEN

Bron Gondwana brong at fastmail.fm
Tue Nov 15 21:08:34 PST 2011


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.



More information about the Imap-protocol mailing list