[Imap-protocol] SELECT/EXAMINE clarification of UNSEEN
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
> 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.
More information about the Imap-protocol