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

[Mark Crispin <[e-mail]>]

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.