🚀 go-pugleaf

> RFC 1203 (IMAP3), which claims to be a "counter proposal" to RFC 1176
> (IMAP2), came out in Feb 91.  What has happened since then?  Is there
> going to be an up-to-date generally accepted IMAP standard soon, or is
> the world sticking with POP3?

Some time ago Alasdair Grant asked about the status of the competing IMAP
"standards" -- defined in RFCs 1176 and 1203.  Rather than stoking the public
flames about this topic at the time, I have been working to find a resolution
and am pleased to report on our progress.  The following gives a summary of the
proposed solution first, and then more details for those who are interested.

1) We at Stanford/SUMEX-AIM (now called CAMIS) are as committed to the IMAP
   EMail architecture as ever.  We use its services extensively here, have
   invested heavily in increasing the number and improving the quality of
   clients (e.g., Mailstrom for the Macintosh, ximap for X-Windows servers, and
   YW for Common Lisp environments), and have tried to promote and support
   IMAP's wider adoption.

2) The core differences between the IMAP definitions in 1176 and 1203 come down
   to the University of Washington's desire to focus on a here-and-now, simple,
   operational protocol on the one hand, and our attempts on the other to build
   some degree of extensibility and adaptability into the protocol definition
   to anticipate the development of more sophisticated clients and to
   facilitate maintaining evolving distributed EMail services across diverse
   user communities (like most university settings).  Alas, both goals are
   important but there has not been any apparent way to reach compromise on
   these differences among the current players.  Meanwhile, much damage has
   come about -- work has progressed in diverging directions, confusion has
   arisen in the user community, and valuable R&D time has been drained into
   verbal battles (sometimes even addressing technical issues).  In the larger
   picture, this is not worth prolonging, so we have agreed with Mark Crispin
   to take the following steps.  We at Stanford/CAMIS will:

   a) Move immediately to adapt IMAP2bis-compatible servers and clients to
   provide routine email service for our laboratory and user community, and
   thereby push to have RFC 1176+ servers/clients adopted more widely at
   Stanford.  In the same vein, within our resources, we will attempt to make
   sure that the operational IMAP clients we have produced are compatible with
   IMAP2bis.

   b) Continue pursuing our RFC 1203-based server and enhanced client
   development work just in our own lab for now, and *not* try to promote 1203
   features further as part of the currently evolving IMAP2bis standards.  Many
   of us still feel that at least some of these features will prove desirable
   and necessary, but we will defer reopening the standards discussions until a
   more convincing demonstration of utility can be made to warrant this.

This is the end of the summary part for those who want to quit now and rush out
to get a copy of IMAP2bis software.  I hope we can get on with promoting what I
believe is an excellent (the best current) architecture for distributed email
services.  For those interested in more details on the status and direction of
our "1203" work, read on.

Tom Rindfleisch
Director, Stanford Knowledge Systems Laboratory

PS: One of the developments that would help promote IMAP services, at least
around Stanford, would be having an IMAP server implementation for IBM
mainframes.  Does anyone know of work on such a project?

                                 -------------
Appendix -- Future Work

It is our view that while EMail has come a very long way, it has raised as many
new development issues as it has solved.  In a nutshell, we believe that some
of the most important computer science problems of the 90s are related to
synthesizing more uniform user access to diverse information sources and
building much more effective tools to help users navigate through and select
only relevant material from the growing glut of information.  Most vendor work
focuses on making it possible to produce more and more email -- from every
application in sight.  We want to figure out how to help users filter,
organize, sort through, and make sense of the stuff coming to their screens.
There is lots more to say about this work at the appropriate time, but the
issue for this discussion is what does all this have to do with IMAP?

Put simply, mail client/server capabilities and relationships are sure to
change as new tools develop.  We wanted the IMAP standard to be a ready vehicle
for supporting and incorporating such new developments.  The guts of the RFC
1203/1176 differences we proposed for this purpose come down to:

1) Allowing client and server to negotiate what services each provides and
   wants.  In the simplest case this might just be "what version are you".
   Imagine a campus with thousands of mail clients working with tens or
   hundreds of servers.  If we want to make changes to the software to upgrade
   or extend services (e.g., consider trying to incorporate something like MIME
   capabilities to an operating client/server community), we will never be able
   to change all clients and servers simultaneously, yet we must keep services
   operating reliably.  In more sophisticated cases negotiations might involve
   deciding which services should be done on the server and which on the client
   (e.g., because of slow network and/or fast server).

2) Allowing a client to write back message content updates -- e.g., to add
   index terms in the header, to attach annotations (margin notes) that make a
   message more meaningful, to record pointers to connect groups of messages,
   etc.  Some of this could eventually be part of MIME subdocument parts.

3) Handling multiple outstanding service requests -- this primarily to
   facilitate more sophisticated multiprocessing clients or working over slow
   network links.

Despite conceding the current standards argument for the good of the community,
I want to add that RFC 1203 is not vaporware.  There has been a Lisp machine
(Explorer) implementation of 1203 running since the last half of 1990 and it
has been the basis for on-going experiments on user-customizable EMail
management tools -- particularly in the YesWay client Jim Rice has been
developing.  Kevin Brock and Bill Yeager have a UNIX implementation in the
debugging stages now and it will be available for use in our research work by
late summer.  This (with the ximap client) will be the new "laboratory" for our
development work.

Tom R.