Re: [imap5] Designing a new replacement protocol for IMAP

Mark Crispin <mrc+ietf@panda.com> Wed, 15 February 2012 19:51 UTC

Return-Path: <mrc+ietf@panda.com>
X-Original-To: imap5@ietfa.amsl.com
Delivered-To: imap5@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D053721F85EA for <imap5@ietfa.amsl.com>; Wed, 15 Feb 2012 11:51:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzONsBXkdTNh for <imap5@ietfa.amsl.com>; Wed, 15 Feb 2012 11:51:44 -0800 (PST)
Received: from Panda.COM (panda.com [206.124.149.114]) by ietfa.amsl.com (Postfix) with ESMTP id 74A9F21E8032 for <imap5@ietf.org>; Wed, 15 Feb 2012 11:51:44 -0800 (PST)
Received: from hsinghsing.panda.com ([206.124.149.116]) by Panda.COM ([192.107.14.50]) with ESMTP via TCP; Wed, 15 Feb 2012 11:51:41 -0800
X-MailFrom: mrc+ietf@panda.com
Date: Wed, 15 Feb 2012 11:51:39 -0800
From: Mark Crispin <mrc+ietf@panda.com>
Sender: mrc@hsinghsing.panda.com
To: imap5@ietf.org
In-Reply-To: <20120215181047.GB13906@launde.brong.net>
Message-ID: <alpine.OSX.2.00.1202151020140.38441@hsinghsing.panda.com>
References: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <B764BD8C8B6047E659EABBE2@caldav.corp.apple.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <alpine.LSU.2.00.1202151405550.30682@hermes-2.csi.cam.ac.uk> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> <4F3BC7DA.5070803@gulbrandsen.priv.no> <20120215181047.GB13906@launde.brong.net>
User-Agent: Alpine 2.00 (OSX 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
Subject: Re: [imap5] Designing a new replacement protocol for IMAP
X-BeenThere: imap5@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion on drastically slimming-down IMAP." <imap5.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imap5>, <mailto:imap5-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imap5>
List-Post: <mailto:imap5@ietf.org>
List-Help: <mailto:imap5-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imap5>, <mailto:imap5-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Feb 2012 19:51:48 -0000

On Wed, 15 Feb 2012, Bron Gondwana wrote:
> No side effects.  No magic.

Your effort is doomed with that attitude.

Protocol designers do NOT drive the evolution of a protocol. Protocol
consumers do.

In order for a protocol to be used, the protocol designer must accomodate
everything that a protocol consumer identifies (whether correctly or
incorrectly) as a requirement. All too often, there is no way to do so
without adding magic and/or warts. If the designer refuses, the consumer
will go elsewhere.

In every protocol, every little wart, every bit of magic, happened for a
reason - and almost always over the protocol designer's objection. For
each of these, some consumer depends upon it.

In order to get a consumer to switch from an existing protocol, you must
accomodate ALL their dependencies, AND present a compelling reason why
they should invest in switching. Neither elegance, nor beauty, nor magic
and wart free are compelling.

It's VERY hard to accomodate all the requirements of protocol consumers,
especially when those requirements conflict (and they do conflict).

That is why you have a very small number of successful protocol designers,
and a much larger number of people who think that they can do a better
job. Every field of human endeavor demonstrates it.

The miraculous thing about IMAP is that, after nearly 25 years, it has a
surprisingly small amount of magic and warts. Even better, the majority of
magic and warts are in extensions that most people ignore.

Above all, IMAP works well enough for consumers. The older that any
protocol gets, the more difficult and expensive it becomes to deploy a new
solution within open standards. Nobody cares that an implementor may find
it to be hard work. Implementors are supposed to be Really Smart People
that are worth their exorbitant salaries; and some of the best IMAP
implementations I've seen were written by very smart people in Third World
countries that work for much less...

One last thought. The only likely "IMAP killer" is not a new open-source
protocol. It is Exchange.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.