[Imap-protocol] Subscriptions in IMAP

Dave Cridland dave at cridland.net
Fri Jun 1 01:16:03 PDT 2007

On Thu May 31 21:45:42 2007, Mark Crispin wrote:

> On Thu, 31 May 2007, Dave Cridland wrote:

>> I'm not blaming Mark, or the others involved in RFC3501 here -

>> it's understandable that the semantics of a subscribed mailbox

>> weren't fully described in the original design, because the intent

>> was obvious - unfortunately, as time has moved on, it's less

>> obvious, and requires a certain degree of archeology to detirmine

>> what the intent was, and besides, we have multiple clients

>> gradually pulling the intent in different and contradictory

>> directions.


> There is a deeper problem. The idea of having a generic mechanism

> to support a common concept fails, more often than it succeeds,

> whenever it depends upon a cooperative use of that mechanism. All

> it needs is one bad actor to render the mechanism useless, and to

> cause all the other actors to flee back into a protected space that

> it controls.



In a lot of cases, even that's not too bad, as long as the protected
space is available. I think there's a general attitude toward trying
to use facilities and specifications interoperably, at least if at
all possible.

Witness keywords and flags, for instance - that's certainly a shared
configuration situation, yet for the most part IMAP clients have a
tendancy to either ignore the flags they don't recognise, or present
them fairly neutrally. And that's even with the distinctly unclear
usages, like $LabelX, as used by the Mozilla Mail/News clients.

> The bad actor problem afflicts many areas. Consider what happens

> when you install a media player to play a specific file. It

> doesn't just install that program. It also sets that program as

> the default media player for all your other media files; puts an

> extra icon on the desktop, the start menu, the quick launch

> taskbar; and adds a launcher to the notification area.



Actually, I've noticed a distinct change over the years. This used to
be the case, but increasingly, applications are designed toward
cooperation. It's not helped by the general design of the desktop
systems which push toward a single application for a single task, and
I don't think it's entirely fair to blame the applications in this
instance. (Desktops such as GNOME seem to promote the concept of a
default application for a media type, plus lots of alternatives, yet
as far as I can tell, there's still a single application granted
responsibility for each URI scheme).

> This, in my mind, is what doomed ACAP.

Like so many things, don't knock it until you've tried it. :-)

> It's easy to blame ACAP's overengineering (and it did have

> that!), but the more fundamental flaw was the notion that

> applications could share configuration without abusing it.

Actually, there's very little of that flaw in evidence amongst the
(admittedly small) deployments I've seen. The only instance I can
recall is where Mulberry changes addressbook entries by deleting and
recreating them, thus losing all attributes it doesn't understand
(including some standard ones, as well as any vendor-private ones). I
happen to think that's bad ACAP whichever way you cut it - it'd be
like removing all user-defined keywords on a message if you set the
\Seen flag - and it breaks inheritance chains as well.

In my opinion, ACAP is particularly well-designed in this respect, as
it provides the "protected space" that the applications can control
to handle their own requirements. (Of course, this also becomes
responsible for part of the over-engineering). Both ANNOTATE and
METADATA have this protected space too, of course, whereas
traditional IMAP flags are considerably more ad-hoc in this respect,
and there's only a one-size-fits-all subscription list - which is
perhaps why the latter suffers so much.

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Imap-protocol mailing list