Re: [MORG] POP3 LIST+ Extension: Monitoring for mailbox changes

[Mark Crispin <[e-mail]>]

On Sun, 6 Feb 2011, Steffen Lehmann wrote:
> About 80% our customers are using POP3, 20% IMAP. The decision, whether
> to use POP3 or IMAP, is not ours.

You are making a staggering assumption: that your customers' decision is
one to use POP3 vs. IMAP.

I submit that the vast majority of your customers don't decide in those
terms at all.  Rather, their decision is to use certain software, whether
due to comfort or inertia.  Often, other than to getting it to function,
they haven't spent much time in configurating their software.

Put another way: most of your customers don't know a POP3 from an IMAP
from a Bombastic Blurdybloop; and even if you told them they wouldn't
care.

You may be able to get some your customers to change the POP3/IMAP
checkbook in their software on the grounds that it will "improve
performance".  Your odds of success increase if you give them specific
instructions, with screen shots, on how to do it in their specific
software.

> I think you have never seen a customer using POP3 tryig desperately
> regain control over his mailbox

You are making a second staggering assumption: that a person who has been
a professional in the email industry for over 30 years is somehow ignorant
of such matters.

> As long as customers use POP3, for whatever reasons, we should try to
> improve it, if possible.

This is the third staggering assumption: that by having IETF produce a
document, you will somehow achieve technological progress for your users.

It assumes that the vendors of client used by your users, and the vendor
of your server, all implement this extension; that these implementations
all interoperate; and that your users promptly upgrade to the new version
of their client software.

There are huge barriers in the way.  The greatest of these is that there
is no particular incentive for vendors to do it; and there are severe
disincentives to vendors.

Any extension to POP3 (or IMAP), no matter how trivial, requires hundreds
of hours of time in R&D and testing.  We're talking a great deal of money;
and a compelling business case has to be made for it.

Perhaps unlike you, I have dealt with getting engineering changes through
the likes of Microsoft, Google, and Apple.  The timeframe for getting
things through these guys is measured in years; and that is when there is
a compelling business case.  There is none here.

Nor do you particularly want them implementing your extension.  It is
virtually guaranteed that if they do it, it will be in a way that breaks
your other implementations.  Microsoft and Google especially are of the
attitude that their software constitutes the "standard"; and that if some
RFC disagrees it's a bug in the RFC.

You may get a "free software" implementation or two to implements it.
Even these are impacted by "it works fine with the competition"
bug/regression report caused by implementation incompatibilities.

> I (carefully) agree. But this can be avoided by well-engeneered
> extensions and well-tested implementations.

Any talk about new POP3 extensions (and arguably also IMAP extensions) is
mental masturbation.

The only business case that exists for extensions any more is to foil an
attempt to bias competitive procurement in government purchases that
writes in a requirement for some obscure RFC.  I've seen RFPs that
stipulated RFC 748 compliance!

The end result of work on a POP3 extension is an obscure document, that
may make it to an RFC, that hardly anyone ever implemented and is
consigned to the scrap heap of history.  There is a large pile of such
documents in the IETF.  I wrote some, long ago.  The pile is growing.

Adding to the pile will not solve your problem.  You will presently be
forced to seek another (hopefully more effective) solution, and come to
realize that your work on this beautiful POP3 extension was a complete
waste of your time.

I am doing you a favor.  Feel free to disregard it.  You will learn either
sooner, or later.  The choice is yours.

-- Mark --

http://panda.com/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.