home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / mail / misc / 2478 < prev    next >
Encoding:
Text File  |  1992-07-25  |  6.9 KB  |  122 lines
  1. Newsgroups: comp.mail.misc
  2. Path: sparky!uunet!stanford.edu!morrow.stanford.edu!sumex-aim.Stanford.EDU!tcr
  3. From: tcr@sumex-aim.Stanford.EDU (Thomas C. Rindfleisch)
  4. Subject: Re: IMAP2 vs. IMAP3 - who won?
  5. Message-ID: <1992Jul25.010035.1104@morrow.stanford.edu>
  6. Sender: news@morrow.stanford.edu (News Service)
  7. Organization: KSL, Stanford University, CA 94305, USA
  8. Date: Sat, 25 Jul 1992 01:00:35 GMT
  9. Lines: 111
  10.  
  11. > RFC 1203 (IMAP3), which claims to be a "counter proposal" to RFC 1176
  12. > (IMAP2), came out in Feb 91.  What has happened since then?  Is there
  13. > going to be an up-to-date generally accepted IMAP standard soon, or is
  14. > the world sticking with POP3?
  15.  
  16. Some time ago Alasdair Grant asked about the status of the competing IMAP
  17. "standards" -- defined in RFCs 1176 and 1203.  Rather than stoking the public
  18. flames about this topic at the time, I have been working to find a resolution
  19. and am pleased to report on our progress.  The following gives a summary of the
  20. proposed solution first, and then more details for those who are interested.
  21.  
  22. 1) We at Stanford/SUMEX-AIM (now called CAMIS) are as committed to the IMAP
  23.    EMail architecture as ever.  We use its services extensively here, have
  24.    invested heavily in increasing the number and improving the quality of
  25.    clients (e.g., Mailstrom for the Macintosh, ximap for X-Windows servers, and
  26.    YW for Common Lisp environments), and have tried to promote and support
  27.    IMAP's wider adoption.
  28.  
  29. 2) The core differences between the IMAP definitions in 1176 and 1203 come down
  30.    to the University of Washington's desire to focus on a here-and-now, simple,
  31.    operational protocol on the one hand, and our attempts on the other to build
  32.    some degree of extensibility and adaptability into the protocol definition
  33.    to anticipate the development of more sophisticated clients and to
  34.    facilitate maintaining evolving distributed EMail services across diverse
  35.    user communities (like most university settings).  Alas, both goals are
  36.    important but there has not been any apparent way to reach compromise on
  37.    these differences among the current players.  Meanwhile, much damage has
  38.    come about -- work has progressed in diverging directions, confusion has
  39.    arisen in the user community, and valuable R&D time has been drained into
  40.    verbal battles (sometimes even addressing technical issues).  In the larger
  41.    picture, this is not worth prolonging, so we have agreed with Mark Crispin
  42.    to take the following steps.  We at Stanford/CAMIS will:
  43.  
  44.    a) Move immediately to adapt IMAP2bis-compatible servers and clients to
  45.    provide routine email service for our laboratory and user community, and
  46.    thereby push to have RFC 1176+ servers/clients adopted more widely at
  47.    Stanford.  In the same vein, within our resources, we will attempt to make
  48.    sure that the operational IMAP clients we have produced are compatible with
  49.    IMAP2bis.
  50.  
  51.    b) Continue pursuing our RFC 1203-based server and enhanced client
  52.    development work just in our own lab for now, and *not* try to promote 1203
  53.    features further as part of the currently evolving IMAP2bis standards.  Many
  54.    of us still feel that at least some of these features will prove desirable
  55.    and necessary, but we will defer reopening the standards discussions until a
  56.    more convincing demonstration of utility can be made to warrant this.
  57.  
  58. This is the end of the summary part for those who want to quit now and rush out
  59. to get a copy of IMAP2bis software.  I hope we can get on with promoting what I
  60. believe is an excellent (the best current) architecture for distributed email
  61. services.  For those interested in more details on the status and direction of
  62. our "1203" work, read on.
  63.  
  64. Tom Rindfleisch
  65. Director, Stanford Knowledge Systems Laboratory
  66.  
  67. PS: One of the developments that would help promote IMAP services, at least
  68. around Stanford, would be having an IMAP server implementation for IBM
  69. mainframes.  Does anyone know of work on such a project?
  70.  
  71.                                  -------------
  72. Appendix -- Future Work
  73.  
  74. It is our view that while EMail has come a very long way, it has raised as many
  75. new development issues as it has solved.  In a nutshell, we believe that some
  76. of the most important computer science problems of the 90s are related to
  77. synthesizing more uniform user access to diverse information sources and
  78. building much more effective tools to help users navigate through and select
  79. only relevant material from the growing glut of information.  Most vendor work
  80. focuses on making it possible to produce more and more email -- from every
  81. application in sight.  We want to figure out how to help users filter,
  82. organize, sort through, and make sense of the stuff coming to their screens.
  83. There is lots more to say about this work at the appropriate time, but the
  84. issue for this discussion is what does all this have to do with IMAP?
  85.  
  86. Put simply, mail client/server capabilities and relationships are sure to
  87. change as new tools develop.  We wanted the IMAP standard to be a ready vehicle
  88. for supporting and incorporating such new developments.  The guts of the RFC
  89. 1203/1176 differences we proposed for this purpose come down to:
  90.  
  91. 1) Allowing client and server to negotiate what services each provides and
  92.    wants.  In the simplest case this might just be "what version are you".
  93.    Imagine a campus with thousands of mail clients working with tens or
  94.    hundreds of servers.  If we want to make changes to the software to upgrade
  95.    or extend services (e.g., consider trying to incorporate something like MIME
  96.    capabilities to an operating client/server community), we will never be able
  97.    to change all clients and servers simultaneously, yet we must keep services
  98.    operating reliably.  In more sophisticated cases negotiations might involve
  99.    deciding which services should be done on the server and which on the client
  100.    (e.g., because of slow network and/or fast server).
  101.  
  102. 2) Allowing a client to write back message content updates -- e.g., to add
  103.    index terms in the header, to attach annotations (margin notes) that make a
  104.    message more meaningful, to record pointers to connect groups of messages,
  105.    etc.  Some of this could eventually be part of MIME subdocument parts.
  106.  
  107. 3) Handling multiple outstanding service requests -- this primarily to
  108.    facilitate more sophisticated multiprocessing clients or working over slow
  109.    network links.
  110.  
  111. Despite conceding the current standards argument for the good of the community,
  112. I want to add that RFC 1203 is not vaporware.  There has been a Lisp machine
  113. (Explorer) implementation of 1203 running since the last half of 1990 and it
  114. has been the basis for on-going experiments on user-customizable EMail
  115. management tools -- particularly in the YesWay client Jim Rice has been
  116. developing.  Kevin Brock and Bill Yeager have a UNIX implementation in the
  117. debugging stages now and it will be available for use in our research work by
  118. late summer.  This (with the ximap client) will be the new "laboratory" for our
  119. development work.
  120.  
  121. Tom R.
  122.