Will@cup.portal.com (Will E Estes) (06/25/91)
Does anyone know where I can get the specification for IMAP?
IMAP is a mail server, basically an enhanced POP.
Thanks,
Will Estes Internet: Will@cup.portal.com
UUCP: apple!cup.portal.com!Willskl@wimsey.bc.ca (Samuel Lam) (06/25/91)
In article <43626@cup.portal.com>, Will@cup.portal.com (Will E Estes) wrote: >Does anyone know where I can get the specification for IMAP? IMAP3 is documented in RFC 1203, and IMAP2 is documented in RFC 1176. ...Sam -- <skl@wimsey.bc.ca>
mrc@milton.u.washington.edu (Mark Crispin) (06/26/91)
In article <43626@cup.portal.com> Will@cup.portal.com (Will E Estes) writes: >Does anyone know where I can get the specification for IMAP? >IMAP is a mail server, basically an enhanced POP. The specification for IMAP is RFC-1176. There will be a follow-up RFC to define the extensions for the new Internet Message Bodies standard. The April '91 IMAP distribution is on FTPHOST.CAC.WASHINGTON.EDU (IP address 128.95.112.1) as imap/imap.tar.Z via anonymous FTP. A major new revision is in the works and will be released later this summer.
mrc@milton.u.washington.edu (Mark Crispin) (06/26/91)
In article <1991Jun25.111426.16743@wimsey.bc.ca> skl@wimsey.bc.ca (Samuel Lam) writes: >IMAP3 is documented in RFC 1203, and IMAP2 is documented in RFC 1176. IMAP3 is vapor. All the existing (and future contemplated) software is RFC-1176 based.
Will@cup.portal.com (Will E Estes) (06/27/91)
<IMAP3 is vapor. All the existing (and future contemplated) software
<is RFC-1176 based.
Well, the conclusion that IMAP3 will not succeed as an eventual
standard does not follow from the premise that IMAP3 has no
reference implementation. That aside, after briefly scanning the
IMAP3 RFC it's clear that the IMAP3 and IMAP2 groups have some
bad blood between them and serious differences on how to implement
a mail server.
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?
Thanks,
Will Estes Internet: Will@cup.portal.com
UUCP: apple!cup.portal.com!Willmrc@milton.u.washington.edu (Mark Crispin) (06/27/91)
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
kdb@intercon.com (Kurt Baumann) (06/27/91)
In article <1991Jun26.040642.8535@milton.u.washington.edu>, mrc@milton.u.washington.edu (Mark Crispin) writes: > A major new revision is in the works and will be released later this > summer. Who is working on this? Kurt Baumann 703.709.9890 InterCon Systems Corp. Creators of fine TCP/IP products for the Macintosh
mrc@milton.u.washington.edu (Mark Crispin) (06/28/91)
In article <2869DA1E.614E@intercon.com> kdb@intercon.com (Kurt Baumann) writes: >In article <1991Jun26.040642.8535@milton.u.washington.edu>, >mrc@milton.u.washington.edu (Mark Crispin) writes: >> A major new revision is in the works and will be released later this >> summer. >Who is working on this? I am. It's a major update from our April 1991 release (which is still available on FTPHOST.CAC.WASHINGTON.EDU as imap/imap.tar.Z) and will incorporate full support for the Borenstein/Freed internet message bodies Internet Draft (the work of the IETF-822 group). I've been part of the development of the draft since its inception to be sure that the corresponding functions can be incorporated into IMAP. Once some of the dust settles there will also be an RFC describing the extensions to IMAP2 to support Borenstein/Freed message bodies. This new release will also include an IMAP-capable version of Pine, our local (and very popular!) Unix-based mail UA for novice users written by one of my colleagues. We've done some work in-house, but none of us are PC experts and it's been slow going. Various people and organizations have expressed interest in assisting to port Pine to the IBM PC, including at least one commercial organization. There's always room for more implementations though; to date I'm not aware of any finished version.
coates@UC780.UMD.EDU (06/29/91)
Wis IMAP? Please post. Thanks-
mrc@milton.u.washington.edu (Mark Crispin) (06/29/91)
In article <1991Jun28.224703.9915@socrates.umd.edu> coates@UC780.UMD.EDU writes: >Wis IMAP? Please post. IMAP is an Interactive Mail Access Protocol. It differs from the POP style of protocols in that IMAP focuses on maintaining a mailbox on a remote repository and not on a client. POP on the other hand is designed to fetch mail from a repository onto the client and remote it from the repository. In other words, they do fundamentally different things even though the idea (email on a personal machine but using a central machine as a maildrop) is the same in both. IMAP also has some fancy facilities to make it possible to do various things (e.g. remote searching) that would be prohibitively expensive with POP. IMAP was designed to scale well with very large mailboxes and with high latency/high RTT networks. I regularly read my mail from home on a NeXT using 2400 baud SLIP with IMAP. Another neat thing about IMAP is that it has the capability to parse the message remotely, so a client doesn't need to know about all the details of RFC-822 or of the new multi-part/typed mail body stuff. It's all converted into a easily machine-readable structure unaffected by the various perverse ideas of visual esthetics which inflict RFC-822 headers. IMAP was first conceived by me in 1985. That first version is now extinct. The modern version, called IMAP2, was originally documented in my RFC-1064. That RFC had a few typographic errors introduced in the RFC editing process and a few extensions to the protocol had become widely accepted. I issued a subsequent RFC-1176 to replace RFC-1064; it corrected those errors, documented the (minor) extensions, and clarified some aspects of the architecture that people had found confusing. IMAP2 has been implemented on a variety of client and server platforms; unfortunately for some reason a finished PC client has eluded us. A number of people are reportedly working on a PC client.
coates@UC780.UMD.EDU (06/29/91)
In article <1991Jun29.030833.9957@milton.u.washington.edu>, mrc@milton.u.washington.edu (Mark Crispin) writes: >In article <1991Jun28.224703.9915@socrates.umd.edu> coates@UC780.UMD.EDU writes: >>What is IMAP? Please post. > >IMAP is an Interactive Mail Access Protocol. It differs from the POP >style of protocols in that IMAP focuses on maintaining a mailbox on a >... Thanks for the information!