[Imap-protocol] SELECT/EXAMINE clarification of UNSEEN

Bron Gondwana brong at fastmail.fm
Tue Nov 15 15:39:02 PST 2011

On Tue, Nov 15, 2011 at 02:45:38PM -0800, Mark Crispin wrote:

> Thus, it is better to apply triage to focus on those matters which are

> serious problems, and not worry overmuch about inconsequential warts. In

> this case, far more discussion has been made about a trivial wart than it

> was worth.

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.

It confused me when I first came across it too. It confuses EVERYONE
when they come across it.

> No matter how much you try, you can never abolish absurd interpretations

> of a specification. You can't even abolish absurd and harmful

> interpretations. Humans are incredibly creative in finding both.

In this case, there's a REQUIRED on one line, and then a logical
absurdity where it's impossible to create said REQUIRED line
a few lines later. It forces the reader to go "what were they
smoking" and then make a choice to do something which clearly
violates the words they see printed in front of them. This is
a congnative dissonance which doesn't help anyone.

> What you can do is apply common sense, such as:


> [1] That interpretation is absurd, and it would cause complete

> dysfunction.

> Example: "Since the [UNSEEN n] code is mandatory and n can not

> be zero, it is impossible to SELECT a mailbox with no unseen

> messages."

That's what we call a joke. Patently absurd, because the wording it
was responding to leaves no scope for a better answer which isn't
"ignore the spec, it's broken here".

> What to do: "That's nonsense. The only thing that makes sense

> is to omit the [UNSEEN n] code in that case."

It's obviously the only possible response. But there are two choices
here. 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. You might get some pleasure out of treating people like idiots,
but it doesn't actually help.

> [2] It seems absurd that the specification requires this, but it makes no

> real difference.

> Example: "The spec requires that there be a space and at least one

> character after a [xxx] response code."

> What to do: "That's stupid, but who cares. Just put in a space and

> an x and call it good."

I think that's how I responded to that one, yes. Though I think I said
"add another OK, so you don't confuse poor person reading the trace" - or
at least I would have if I'd been thinking straight at the time.

> It's a fool's dream to expect any specification to do the application of

> common sense for you in all cases. The attempt bloats the specification

> and, in the end, creates new warts and absurdities. At least half of the

> current IMAP specification is such bloat.

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.

> Now you know why I always dig in my heels in an attempt to block "simple

> little changes". I don't always succeed; and invariably end up regretting

> the failures.

Such is the way of all things. Things fail.

> >But then if I was starting from scratch, and it was my "baby", I wouldn't

> >do it like this anyway.


> Even if you start from scratch, nothing you do (anyone does) will be

> immune from evolutionary processes.

No, it's true. I had a boss at a previous job, he was a doctor by initial
training, and he said a very wise thing to me - I don't remember the exact
wording, but it was basically that 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.

A baby is a reset on some of the complexity. They will build new complexity,
and it may not be better than their parents - it's always steps backwards
and forwards. They don't always listen to their parents either (I have kids,
I know this bit very well!)

> Unless, that is, nobody ever uses your work. Then it will be pure and

> unsullied as you set it down. Only then can you be sure that your vision

> will be unaffected by external mutations.

Yeah, true that.

> "Babies" have a way of developing in ways that you do not intend, and

> even in ways that you actively oppose.

Indeed - I wrote the above having not even read down this far yet.


More information about the Imap-protocol mailing list