[Imap-protocol] SELECT/EXAMINE clarification of UNSEEN
mrc+imap at panda.com
Tue Nov 15 14:45:38 PST 2011
On Tue, 15 Nov 2011, Bron Gondwana wrote:
> Or that it's talking to pre-rfc3501 server. Mark said that the wording
> about needing a search was added in response to a previous uncertainty
> about how to respond to this field. I'd like his comment on how best
> to handle that.
"A little bit of common sense goes a long way."
Any evolutionary process is going to have warts, resulting from changed
circumstances and requirements. The longer the evolution, the worse it
will get. A very large contributory factor to evolution is mutations
brought about from external influences.
Even if you were to draw a line, and declare that everything on the other
side is to be abolished, you can not stop evolution. New warts will
quickly be created on your side of the line.
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
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.
What you can do is apply common sense, such as:
 That interpretation is absurd, and it would cause complete
Example: "Since the [UNSEEN n] code is mandatory and n can not
be zero, it is impossible to SELECT a mailbox with no unseen
What to do: "That's nonsense. The only thing that makes sense
is to omit the [UNSEEN n] code in that case."
 It seems absurd that the specification requires this, but it makes no
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."
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.
Perhaps no client uses [UNSEEN n] any more. It was spawned by one of the
"IMAP will die if this isn't done" flamefests of the past that I was not
able to block. :(
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
> 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.
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.
"Babies" have a way of developing in ways that you do not intend, and
even in ways that you actively oppose.
-- Mark --
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
More information about the Imap-protocol