Xref: utzoo comp.protocols.tcp-ip:16733 comp.protocols.tcp-ip.ibmpc:6266
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!milton!mrc
From: mrc@milton.u.washington.edu (Mark Crispin)
Newsgroups: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject: Re: Where Can I Get The IMAP Specification?
Message-ID: <1991Jun27.020134.17903@milton.u.washington.edu>
Date: 27 Jun 91 02:01:34 GMT
References: <1991Jun25.111426.16743@wimsey.bc.ca> <1991Jun26.040806.8764@milton.u.washington.edu> <43708@cup.portal.com>
Organization: University of Washington, Seattle
Lines: 72

In article <43708@cup.portal.com> Will@cup.portal.com (Will E Estes) writes:
>Can someone out there clarify the politics of this situation and
>give some solid reasons why one standard is likely to succeed
>over the other?

Sigh.  I've avoided discussing this because there has already been too
much airing of dirty laundry in public on this matter.  I hope I can
answer this question once and forget about it.  I would prefer to
ignore `IMAP3' and go about my work in building IMAP2 environments.

The story is that the author of the `IMAP3' specification wanted to
make several fundamental changes in the protocol to make his Lisp
machine implementation simpler.  He also felt that the IMAP2 model was
wrong; this is a religious argument more than anything.

Simply put, the religious difference goes like this: IMAP2 uses a
state-update model, in which clients access a local state that is
updated from a remote state as necessary.  IMAP2 also tries to work
well on networks where RTT's and/or throughput is bad.  Those of us
who use 2400 baud SLIP lines or Milnet know what I'm talking about.

IMAP3 is premised on always retrieving data from the network with no
local caching of state.  IMAP3 assumes RTT's are insignificant (that
is, you're on a high-speed LAN); it has operations (albeit not
specified well enough to implement) to fetch a single piece of a
message (e.g. to-list) at a micro-level.  The equivalents in IMAP2 are
at a higher-level; e.g. a single operation to fetch a structured
representation of all of the message envelope information in a single
transaction instead of separately fetching date, from, subject, to,
cc, etc. etc. in separate RTT's.

I wrote RFC-1176 as a replacement to my original RFC-1064, with the
sole intention of codifying reality and correcting bugs in RFC-1064.
I was not, at this stage, interested in making fundamental changes
that would break the entire installed base of IMAP users.  Everything
that is in RFC-1176 reflects IMAP software as it is actually
implemented, including at the site where the author of RFC-1203 works.

Because I had reservations about giving in to all of his demands, he
decided to get back at me by writing his RFC-1203 on `IMAP3'.  It
never should have been published; it accidentally slipped through the
cracks in the RFC review process.  When it was proposed that the
dispute be solved through the IETF, he asked "what's the IETF?"  I
don't think he or anyone else at that organization tracks what goes on
with Internet e-mail standards development; they have a lot of N.I.H.

The `IMAP3' protocol described in RFC-1203 has a number of operational
bugs which become apparent if anybody tries to implement it.  It does
not offer any greater asynchronity than IMAP2 (claims to the contrary
notwithstanding) and has a lot of poorly-thought-out ideas (for
example, the mechanism for binary mail).  Large chunks of `IMAP3' are
not specified at all (e.g. data base keys) other than as a concept.

I had written up a large document describing all the bugs in RFC-1203
that make it unimplementable without major changes.  After about 30K
of text I realized I was shooting fish in a barrel and put it aside.

The last I heard, the entire organization in which the author of
RFC-1203 works is going through some serious funding difficulties and
has had major staff cuts.  I don't know if any work has taken place at
all on RFC-1203; if it had I'm sure I would have heard something.  I
doubt it will ever see the light of day.

I am working on extensions in IMAP2 for the Borenstein/Freed Internet
Message Bodies extensions (the so-called `RFC-XXXX') and will be
releasing a major new release of IMAP2 which supports it.  As there
are no implementation of `IMAP3', and as IMAP2 is evolving to support
the new standards for typed/multipart e-mail, I don't believe that
`IMAP3' will do anything in the long-term other than to damage the
credibility of a lot of people who've worked on IMAP2.

Mark Crispin