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

Mark Crispin <mrc+ietf@panda.com> Mon, 13 February 2012 21:37 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 F0CCB21E8049 for <imap5@ietfa.amsl.com>; Mon, 13 Feb 2012 13:37:23 -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=[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 OB2VBMjBgMRV for <imap5@ietfa.amsl.com>; Mon, 13 Feb 2012 13:37:23 -0800 (PST)
Received: from Panda.COM (panda.com [206.124.149.114]) by ietfa.amsl.com (Postfix) with ESMTP id A111D21E8044 for <imap5@ietf.org>; Mon, 13 Feb 2012 13:37:22 -0800 (PST)
Received: from hsinghsing.panda.com ([206.124.149.116]) by Panda.COM ([192.107.14.50]) with ESMTP via TCP; Mon, 13 Feb 2012 13:37:15 -0800
X-MailFrom: mrc+ietf@panda.com
Date: Mon, 13 Feb 2012 13:37:14 -0800 (PST)
From: Mark Crispin <mrc+ietf@panda.com>
Sender: mrc@hsinghsing.panda.com
To: Bron Gondwana <brong@fastmail.fm>
In-Reply-To: <20120213203757.GA13029@launde.brong.net>
Message-ID: <alpine.OSX.2.00.1202131243200.38441@hsinghsing.panda.com>
References: <201202090820.28260.thomas@koch.ro> <4F337E61.5040702@qbik.com> <201202101544.51364.thomas@koch.ro> <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <B764BD8C8B6047E659EABBE2@caldav.corp.apple.com> <4F394F0A.2080506@oracle.com> <alpine.OSX.2.00.1202131015200.38441@hsinghsing.panda.com> <20120213195253.GB11806@launde.brong.net> <alpine.OSX.2.00.1202131154240.38441@hsinghsing.panda.com> <20120213203757.GA13029@launde.brong.net>
User-Agent: Alpine 2.00 (OSX 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: imap5@ietf.org
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: Mon, 13 Feb 2012 21:37:24 -0000

On Mon, 13 Feb 2012, Bron Gondwana wrote:
> And I'd rather do it in public than
> in secret right up until the IETF process bit.

You will never make much progress as long as the initial design process is
burdened with that monkey on its back. The best way to destroy any project
is to subject it to review at that stage.

> Do you still have your un-"improved" specification and interoperable
> code sitting around somewhere that you can show us all how nice it was
> before the grandmothers improved it?  I'd be interested to see so I
> can tell what I'm in for.

Knowledge of the original IMAP (before IMAP2) exists primarily in my mind
as all the original IMAP specifications and implementations were replaced
with IMAP2.

The only substantial difference between original IMAP and IMAP2 was the
introduction of tags in IMAP2. In original IMAP, a response started with
one of "OK", "NO", "BAD", "BYE", or "*".

That incompatibility is caused the "2". Since it was still possible to
replace all the "old protocol" implementations, there was no attempt at
IMAP/IMAP2 compatibility.

A secondary effect was the much-maligned advent of untagged OK/NO/BAD
responses.

As it turned out, tags never were as important for pipelining as its
advocates claimed. The vast majority of Internet protocols pipeline do
just fine without tags, although I admit ManageSieve did it in a cool way.

The motivation for tags was the quaint idea (which I never believed back
then) that an IMAP server will routinely have requests blocked while
waiting for the computer operator to mount a 9-track tape or optical disk.
Thus it was purportedly important for responses to arrive out of order for
the request, and all clients must be completely asynchronous. Of course,
that never happened...

Post-IMAP2, there are all the past IMAP RFCs. The ftp.cac.washington.edu
FTP site still has many of the IMAP2bis drafts on the mail/old/ directory,
as well as the RFC drafts. There is quite a lot to review there.

The history of IMAP2bis is particularly important, as it explains a great
deal of the process from RFC 1176 to RFC 1730 which would otherwise be an
unbridgeable gap.

In turn, RFC 1730 to RFC 2060 shows what happens when a set of last-minute
additions (to RFC 1730) are put in without adequate thought and
consideration. There is a BIG lesson to learn from that abortion.

RFC 2060 is the RFC 1176 replacement protocol in more or less final form.

-- 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.