A few months ago, I started working on an IMAP server, and as part of that process I decided to read, as best I could, "the collected works of Mark Crispin". Of course this meant that I read through the latest IMAP specification (in its entirety, "cover to cover") but it also meant that I read through all of the old ones as well (if nothing else: Mark actually often stated one should).
However, I honestly found this person fascinating: the more I read, the more I wanted to read; I thereby continued from the specifications, and have been reading everything I could get my hands on, scouring mailing lists old and new. I imagine that this is similar to how many might feel about their favorite author, only for me my favorite author is not Tolstoy, Dickens, or Shakespeare: it is Mark Crispin.
Obviously, like with most authors, I don't pretend to know anything about him as a person, but I look up to him as a writer. I thereby don't really know what I would say to him (nor even feel it terribly appropriate to do so at all); I do think, however, I can at least help some people here on Hacker News who might not know much about him appreciate what Mark Crispin has been doing for us in his life.
This man has been working, nearly constantly, on the IMAP protocol specification now for decades of his life; he has seen numerous challenges to compatibility and has had to make countless tradeoffs and compromises to both his vision for the protocol and his wording in specifications to keep making forward progress. Much of this is actually documented in years of mailing list archives.
"""This was a mistake. We all acknowledge it to have been a mistake. However, the discussion about naming that took place in the early 1990s wasted at least 18 months of everybody's time (and probably reduced all of our lifespans by a few years due to high blood pressure). What came up was a wretched compromise, but at least it let us do our work.""" -- http://mailman2.u.washington.edu/pipermail/imap-protocol/200...
From all of this, I would like to say: I believe he was actually a visionary. Many people who use IMAP do not realize this, but Mark did not (from my reading) ever believe in the offline e-mail that Google and Microsoft are slowly obsoleting, even at the benign level of IMAP synchronization; in fact, his own client (alpine) doesn't even support that mode of operation: it is purely on "online" IMAP client with a tiny memory cache.
"""Email synchronization is a fool's errand; but there seem to be an abundant supply of fools that undertake it. Thus we have miserable mobile device email clients such as Mail.app on the iToy, BlackBerry, and the default Mail app on Android. At least Android has k9mail which - just barely - steps over the line into "usability".""" -- http://mailman2.u.washington.edu/pipermail/imap-protocol/201...
If you go back to the early IMAP specifications, this is actually laid out in the rationale section: the argument is that in an age where users have too many devices to easily manage and network connectivity is nearly universal--or as I will call it, "Mark Crispin's 1988" (yes: 1988, and this is already IMAP2)--it no longer makes sense to store e-mail on the client; he then lays out a strategy for an efficient mail-specific thin-client protocol, with everything from server-side search to server-side parsing.
"""Consequently, while the workstation may be viewed as an Internet host in the sense that it implements IP, it should not be viewed as the entity which contains the user's mailbox. Rather, a mail server machine (sometimes called a "repository") should hold the mailbox, and the workstation (hereafter referred to as a "client") should access the mailbox via mail transactions.""" -- http://tools.ietf.org/html/rfc1064
It is only, however, when one delves into the mailing lists where you truly get a sense for this: on various occasions, Mark has even looked at modern webmail systems as having more in common with IMAP than the alternatives people normally compare IMAP to (such as POP).
"""It's easy to dismiss all this, because only a few IMAP clients are sophisticated enough to take advantage of this state. The vast majority are glorified POP clients that babble IMAP protocol. This came about because of the long-obsolete notion that Internet access is a difficult and expensive commodity that requires that the client must keep a mirror of what's on the server. The success of webmail (which transforms the browser into the ultimate thin client) proves that this notion is complete nonsense today. Yet people persist in claiming it. Webmail won the war for the hearts and minds of users, not because webmail is so much better than IMAP, but rather because webmail is so much better than POP.""" -- http://mailman2.u.washington.edu/pipermail/imap-protocol/200...
What struck me the most, though, is just how often people refused to see this: assuming that IMAP was something that it was not, or simply not giving Mark the respect he deserved from the history he has thinking about this problem; people oft would approach claiming they knew better, and wanted to start over. This meant that he often had to spend his time attempting to herd people towards a common goal, and defending what existed against misconceptions; even having to teach people what it meant to have a protocol at all.
He didn't just sit back and heckle, though: he provided long and detailed critiques; he imparted his knowledge to others, even as he saw people often ignore what he had learned. His explanations usually also gave you a history lesson, illuminating part of the process and showing not only why something works the way it does, but why it worked the way it did, and how that notion had to be stretched into what we are currently using today: you can learn a lot about not just IMAP, but protocols in general, from his writings.
"""Furthermore, if you design for the stupid, you must also design for the defiant. If you fail to do that, you have learned absolutely nothing from my experience in the past 22 years.""" -- http://www.ietf.org/mail-archive/web/imap5/current/msg00005....
There was a continual sobering undercurrent, however, with relation to how long it has taken IMAP to come to fruition (technically, it is still only a proposal). Hearing today's news brings back to mind one e-mail in particular from 2007, which I will now end this comment with (its a long one, but I consider it quite powerful, and in this context, I think it is important to include in its entirety).
"""
RFC 3501, like all human endeavors, is not perfect. We have spent about 20 years in trying to get IMAP beyond Proposed Standard status. We are probably going to fall back yet again with another Proposed Standard RFC for IMAP.
You can't assume that the specification is going to tell you everything that you need to know. It will never happen. We can address this particular question, but I can guarantee that someone will find another one after the publication of the new RFC.
Each IMAP specification update consumes a couple of years of my time. Invariably, there are months of "last calls" and inactivity, only to have someone call a "wait, we need to do this" at the last minute that pulls everything back. Requests to review drafts don't work.
And, with the addition of more expository text to say (what is obvious to some people), we get a larger and more bloated document that people won't read. There are already many IMAP implementations written by people who looked at the examples but never the formal syntax or the expository text, because their implementations blatantly violate both.
I understand -- and sympathize -- with the desire to remove reliance upon folklore and common sense. I see no hope of that ever being accomplished.
The sad fact is that we are running out of time. Given past history, there is little hope that it will reach full standard status under my tenure.
I don't think that it's a good use of the next decade or so to make a futile attempt to perfect the base specification. It needs to be made good enough, and there needs to be general understanding of the architecture so that people don't blame their silly decisions on the base specification.
While there's a lot there that's true, we should be careful to note that Mark Crispin isn't universally correct on how email should work, and has, occasionally, some fundamental misunderstandings. Here's why IDLE support was never implemented for pine:
"I think that you misinterpret the purpose of IDLE. There is no reason to believe that IDLE gets you new mail notifications any faster. It may, but only if the server's new mail announce interval through IDLE is faster than the client's polling interval when not using IDLE."
Somehow he completely fails to grasp the concept of event-based notification and assumes that a server that supports IDLE must do so via polling -- a reasonable assumption for the traditional MDA/mail repository split on aging UNIX boxes, but not a correct one on UNIX boxes with push-based notification of modifications to files, and definitely not a correct one if the mail store and the mail delivery agent are connected. SMTP is real-time and event-based, and there's no reason for IMAP to assume that it can't be.
This is symptomatic of a more general assumption that the way that UW imapd handles things is the only correct way of doing things, and a bias against newer, larger-scale email servers like Gmail and Exchange -- servers that, I'm sure, would happily support IMAP in a conformant way if it were at all possible for them to do so. IMAP is a great standard for something like UW imapd and the assumptions it embeds, and a terrible standard for something like Gmail or Exchange, and the extent to which they do support IMAP is a credit to them and a sign of how terrible the protocol is. You might want to see Courier's documentation of Mark Crispin's FUD:
I have no stake in that particular debate either way. I'm a heavy user of alpine, and I love it, but I've come to see that the incompatibilities between it and Exchange are as much the fault of alpine as they are of Exchange, and in reading the IMAP protocol, I'm impressed anyone other than the reference implementation is able to comply as well as they do. It's true there's a lot that Mark Crispin did for the state of the Internet -- but there's a lot more that could have been done if he were a little more gracious about understanding how other people besides him want to use email and want to implement mail clients.
I did not realize he had written UW imapd. All I knew about that was that it was full of holes, and it's the number one reason I avoided IMAP for as long as I did. When running servers for my users, I only offered POP3 for as long as possible since someone (Solar Designer) had gone to the trouble of designing popa3d with security as a first-class requirement.
Perhaps these holes were related to what you said about failing to grasp the event-based notification scheme. It assumes a certain level of knowledge about how the underlying system works. Maybe his talents were elsewhere.
> ...and a bias against newer, larger-scale email servers like Gmail and Exchange -- servers that, I'm sure, would happily support IMAP in a conformant way if it were at all possible for them to do so...
I do not know of anything in IMAP that would be difficult for Gmail to theoretically implement efficiently except for how EXPUNGE interacts with message sequence numbers (which actually came up on the imap-protocol mailing list a few days ago, although I had seen the problem myself with my server a few months ago; I even came up with something that might be a good solution to it for a Gmail-style infrastructure, although I haven't implemented this evil magic yet and if I do will probably not tell anyone how I did it for a while).
Can you thereby please explain what it is that is so difficult about IMAP to implement that is holding back these companies? It seems much easier to fathom that they simply don't care much, as there are very few real IMAP clients out there other than Thunderbird; Microsoft managed to get everyone to just let them implement ActiveSync into their clients (even the iPhone comes with an ActiveSync implementation by default), and Google has gone on record as saying they only care about what Thunderbird and Outlook bother doing with the protocol.
That said, though, as far as I understand (from having read all of the related discussions I could get my hands on a few months ago), the primary (and totally benign) reason that Gmail doesn't support IMAP terribly well is actually an even simpler reason than even that: it is just because they don't want to spend the resources to go back through old e-mail and fix weird mistakes and old decisions in how various e-mails were parsed (there was a good quote about this somewhere, but I'm having a difficult time finding it :(); though, these are kind of inane details that I'm not even certain you are complaining about.
As some examples, they did weird LF->CRLF conversions only some of the time that cause their "how many bytes is this part of the message" to be inaccurate and they didn't parse through RFC822 attachments and so cannot return envelope structures for them. Otherwise, they are actually pretty good: their known incompatibilities list is actually very short. The one everyone pokes them about are things involving not supporting IMAP flags, but they aren't even really incompatible with their implementation: just "strange" for people who like older clients.
Now, yes: it would be nice if they supported CONDSTORE/QRESYNC, but that would require storing more data per message, keeping an extra secondary index, and changing some of the transaction management code for how they store flags, and they don't seem prepared to do that: however, IMAP works fine without those extensions, and those extensions surround offline synchronization (something that one can appreciate Gmail not having been designed from the beginning to ever support).
Ok, and I guess also combined with some amount of "dunno" on behalf of the Gmail team. ;P
As for pine+IDLE, while Mark often has expansive explanations for what people are trying to with IDLE and how it caused interactions and problems with other systems over the years, I think you totally mischaracterize the "why IDLE was never implemented for pine" situation... as far as I could ever tell it always, in the end, came down to a technical detail of his existing codebase and API; his server, certainly, supported it, and even worked around bugs he found quite irritating in the Outlook implementation of the feature.
"""I'll look at it, but I can't promise that I would adopt it. Nor can I promise that if I adopt it, that it wouldn't have a different interface. c-client is fundamentally synchronous in its implementation of IMAP, and
IDLE is very much asynchronous. It'll need careful consideration.""" -- http://mailman2.u.washington.edu/pipermail/imap-uw/2005-Dece...
Please give this guy the benefit of the doubt here: he's been doing this very long, and seems to actually be quite intelligent with regards to not just how these features were planned to be used but how they ended up being used in practice. The IMAP protocol isn't actually that difficult to implement: it might seem daunting if you don't know much about implementing parsers, but it took about two quick days for me to, entirely from scratch, write a parser combinator library implementation and IMAP->structure parser; everything else was just mapping inputs to outputs.
If nothing else, this seems like a mean time to be disparaging about someone over such little things. :(
If nothing else, this seems like a mean time to be disparaging about someone over such little things. :(
Look, I'm sad that this guy is dying because that sucks.
If you want to have a thread commiserating with Crispin and his family and friends over how awful it is to die at 56, that's fine. It is awful. But if you want to have a thread lamenting how awesome a protocol designer we're losing, then you need to accept the fact that some people think Crispin is a bad protocol designer.
I haven't spent a lot of time working with IMAP implementations but I have friends who have and they describe pretty serious problems. Perhaps not all of those problems are obvious if you've only implemented a protocol parser and haven't built a working product that's successfully interoperated with popular clients and servers.
(My implementation, which includes my own implementation of Sieve and has a fully-transactional mail storage backend with full-text indexing, keyword flags, and attachment analysis, works fine with all of the clients I have tried it with, including Outlook, alpine, Mail.app, MobileMail, and Thunderbird... look, if you have specific issues to address or evidence from some mailing lists you should bring them up, but now you are just being needlessly insulting entirely based on "my friend said something".)
I'm wracking my brains trying to think of a good reason why a protocol would allow the server to send arbitrary command responses to the client at any time. Or why you'd introduce UIDs but then make them revocable...what possible reason could there be for that?
Also, I can understand building a mail protocol that uses UIDs. I can understand building a mail protocol that uses message sequence numbers. I cannot understand building a protocol that uses both and in fact requires both because some protocol operations use UIDs and some use MSNs. Actually, I lied. I cannot fathom why anyone would make a protocol that uses MSNs (they change whenever any client deletes anything! whee!) unless they were mentally trapped in a world where the only message stores were MBOX.
That Courier FUD article does not list a single specific complaint with the specification (well, other than the version number ;P): it just goes over a bunch of personal arguments back/forth and then concludes that it is the fault of the specification that interoperability was poor because interoperability seems poor.
As for the UID issue, there are some backends that simply cannot support maintaining a UID as that was not a concept that existed in legacy mail stores. However, it is only an implementation "of inferior quality" that does not maintain them: it's in the category of "SHOULD".
"""UIDNOTSTICKY is an admission by the server that either the server or the mail store is of inferior quality that can not comply with the design requirements of IMAP UIDs. Not announcing UIDNOTSTICKY, but changing the UIDVALIDITY on a mailbox is an admission by the server that either it or the mail store has an defect that caused it to fail to comply with the design requirements of IMAP UIDs.""" -- http://mailman2.u.washington.edu/pipermail/imap-protocol/200...
The protocol thereby provides a means by which you can tell if you have an inferior server; but yes: it technically allows a server to be inferior because at the time the protocol was released there were no existing mail storage systems that did not have this inferiority. If you still insist on using an inferior server, the result will be weird and will be, well, inferior ;P, but at least it will work.
And yes: I've seen that specific block of source code before, because people paste it around all the time as it is fun to complain about things with foul language and insult the things that people do; that doesn't make it an accurate description of the state of affairs, nor certainly does it indicate anything about the design constraints of the protocol.
As for why the server is allowed to send arbitrary command responses at any time, most people consider that a feature for the same reason they considered IDLE a feature: the original IMAP protocol was highly asynchronous, and simply streamed protocol state to the client whenever things were updated so that the local client would have a live-updated display.
The result is that the protocol, to a very real extent, doesn't even have "command responses": they are kind of a specification concept; instead, it simply has state update messages, and some commands are guaranteed to flush caches and force state updates (which then have timing constraints in when they can be sent, which as a client are mostly irrelevant and for a server are trivially implemented if you do so conservatively).
That Courier FUD article does not list a single specific complaint with the specification (well, other than the version number ;P):
Um, that version number issue is pretty significant I think, and it really calls into question the competence of the IMAP committee at the most basic level:
In 2003, Appendix B of RFC 3501 identified over a hundred corrections to RFC 2060. Observe that RFC 3501 does not define a new version of the IMAP protocol. It's the same version. This is a “revised” document, which attempts to clarify and address numerous issues and inaccuracies in the original specification (some of which I noted publicly).
And, to make things even more interesting, as of this date there are already several reported errata to 3501. Furthermore, RFC 3501 actually changed the IMAP protocol, adding several new requirements, but it kept the IMAP4rev1 version. In other words: the protocol has changed, but it's still the same protocol, officially. Figure that one out.
Isn't updating version numbers when you change the protocol the most basic job of any standards organization? Is this really the sort of thing that we should be failing at?
If you still insist on using an inferior server, the result will be weird and will be, well, inferior ;P, but at least it will work.
All compliant client implementations have to be designed to deal with these "inferior servers" because they still exist. So client implementers cannot rely on usable persistent UIDs (if they want to be standards compliant, which is apparently very important to Crispin). And I'll note that you still haven't given me an explanation for why this feature exists in the spec at all: was the IMAP team really so shortsighted that they believed that no one would ever make a real IMAP server datastore?
that doesn't make it an accurate description of the state of affairs, nor certainly does it indicate anything about the design constraints of the protocol.
OK, what is inaccurate about it? And what are these mythical design constraints? Shouldn't they be written down somewhere?
the original IMAP protocol was highly asynchronous, and simply streamed protocol state to the client whenever things were updated so that the local client would have a live-updated display.
This seems insane to me. Live updates are all well and good, but why on Earth do we need live updates WHILE THE CLIENT HAS AN OUTSTANDING REQUEST?
Can you name other protocols that adopt this gloriously unstructured style? I mean, lots of protocols could in theory benefit from this 'ultra low latency' trick, right?
The result is that the protocol, to a very real extent, doesn't even have "command responses"
Then describing the protocol in terms of commands and command responses seems a bit absurd, right?
> Um, that version number issue is pretty significant I think, and it really calls into question the competence of the IMAP committee at the most basic level: ... Isn't updating version numbers when you change the protocol the most basic job of any standards organization? Is this really the sort of thing that we should be failing at?
Actually, no: these are all protocol drafts; the official RFC for HTTP/1.1 is RFC2616, but RFC2068 also documents a protocol that happens to be called HTTP/1.1. RFC2616 "is an update to RFC 2068". There were actually protocol-requirement changes (the addition of new status codes, changes to existing ones to fit what actually got implemented, modifications to compatibility modes for proxies, etc.) between RFC2068 and RFC2616: if you disagree with this practice, it is either the fault of using a "request for comment" as if it were standard or a bug in the IETF itself, not an issue specific to IMAP.
> All compliant client implementations have to be designed to deal with these "inferior servers" because they still exist.
Doing so is trivial, because if the UIDVALIDITY changes you simply delete all the data and redownload it as if it were a new folder; you would need this functionality anyway if the user deleted the folder and created a new one in its place: it just so happens that some servers are so inferior that their notion of the IMAP mail store is transient and in memory while the client is connected and is deleted when they disconnect. With such a server it is only reasonable to have a fully online client, and with the naive way to implement this that just works, easily, and for free.
> OK, what is inaccurate about it? And what are these mythical design constraints? Shouldn't they be written down somewhere?
They are, actually: mbox is an example mail store that existing systems had, and which IMAP should be able to support as a protocol. In essence, any server that previously had been supporting only POP--or even hell: a POP server being proxied to clients as if it were IMAP--isn't going to have anywhere to store UIDs lying around, and so is going to be forced to simulate the entire notion of IMAP transiently in memory. A good client will work against this server, and it doesn't require you to code specially around it or anything: it will just be inefficient, as it will delete the data and redownload it often.
IMAP simply does not standardize the mail store: it is more similar to a generic protocol like HTTP. To demonstrate, HTTP doesn't require the server have a specific filesystem to store the files that it serves; if the server's filesystem doesn't have the a concept of "last modified date", then it isn't going to be able to return a Last-Modified header; if it doesn't do so, the client's caching algorithms are going to suck, and it is going to end up redownloading files many more times than it otherwise should have to... this is actually the exact same behavior that will happen with broken UIDVALIDITY.
This really isn't a protocol issue: as I said, the protocol needs this feature even if the server works because of the concept of folder names. Yes: you could replace folder names with folder UIDs, but that's just equivalent to concatenating the folder name with the UIDVALIDITY and calling that the UID. If the UIDVALIDITY changes, it is a new folder. The guy who wrote that imap.rb really really wanted to support a good feature (stable folders) on a server that was fundamentally incapable of it with any protocol: that's not IMAP's fault.
> This seems insane to me. Live updates are all well and good, but why on Earth do we need live updates WHILE THE CLIENT HAS AN OUTSTANDING REQUEST?
Yes: IRC (RFC1459). With IRC you can send commands and get responses, and you can send a bunch of commands and get a bunch of responses. Interleaved with those responses (which from your perspective is going to look like "in the middle of a request/response") you will also be getting incoming private messages, because that's just what the protocol does: it streams data to you while also accepting commands and providing responses. You could even argue that that makes IRC two separate protocols combined on a single socket, which is actually how Mark Crispin described IMAP.
"""IMAP is two protocols; a command/response protocol that is client initiated (section 6, and tagged 7.1.1 - 7.1.3), and a data-transmission protocol that is server initiated (section 7).""" -- http://mailman2.u.washington.edu/pipermail/imap-protocol/200...
> Then describing the protocol in terms of commands and command responses seems a bit absurd, right?
Yes, it is; in fact, I believe (but could never say for certain, and am finding this exceedingly awkward that I am needing to defend a dying guy I don't even know against silly tiny complaints that could easily have waited a little while longer) that Mark agrees with you: he at least explicitly said as much on the imap-protocol mailing list, and his disappointment with how he was forced to change the way the spec was written into that "absurd" way of description was a compromise to get buy-in. It is actually one of the reasons he asks people to go back and read IMAP2.
"""This is one of the reasons why I did NOT want to say "such-and-such response occurs as a result of such-and-such command" (I was forced to do so against my wishes); I knew that people would falsely presume that
stating such implies that such-and-such response only occurs as a result of such-and-such command. The fact that the text says "this response occurs as a result of that command" does NOT mean that the response can not occur at another time.""" -- http://mailman2.u.washington.edu/pipermail/imap-protocol/200...
Before today, I never heard of Mark Crispin. After reading your post and the e-mails sent for him, I wish that I had. Like whitewhim, thank you for enlightening me for a man I will never know.
"""It's instructive to read the IMAP3 document (RFC 1203), if only to see a dead-end branch in IMAP's evolution.""" -- http://mailman2.u.washington.edu/pipermail/imap-protocol/200...
However, I honestly found this person fascinating: the more I read, the more I wanted to read; I thereby continued from the specifications, and have been reading everything I could get my hands on, scouring mailing lists old and new. I imagine that this is similar to how many might feel about their favorite author, only for me my favorite author is not Tolstoy, Dickens, or Shakespeare: it is Mark Crispin.
Obviously, like with most authors, I don't pretend to know anything about him as a person, but I look up to him as a writer. I thereby don't really know what I would say to him (nor even feel it terribly appropriate to do so at all); I do think, however, I can at least help some people here on Hacker News who might not know much about him appreciate what Mark Crispin has been doing for us in his life.
This man has been working, nearly constantly, on the IMAP protocol specification now for decades of his life; he has seen numerous challenges to compatibility and has had to make countless tradeoffs and compromises to both his vision for the protocol and his wording in specifications to keep making forward progress. Much of this is actually documented in years of mailing list archives.
"""This was a mistake. We all acknowledge it to have been a mistake. However, the discussion about naming that took place in the early 1990s wasted at least 18 months of everybody's time (and probably reduced all of our lifespans by a few years due to high blood pressure). What came up was a wretched compromise, but at least it let us do our work.""" -- http://mailman2.u.washington.edu/pipermail/imap-protocol/200...
From all of this, I would like to say: I believe he was actually a visionary. Many people who use IMAP do not realize this, but Mark did not (from my reading) ever believe in the offline e-mail that Google and Microsoft are slowly obsoleting, even at the benign level of IMAP synchronization; in fact, his own client (alpine) doesn't even support that mode of operation: it is purely on "online" IMAP client with a tiny memory cache.
"""Email synchronization is a fool's errand; but there seem to be an abundant supply of fools that undertake it. Thus we have miserable mobile device email clients such as Mail.app on the iToy, BlackBerry, and the default Mail app on Android. At least Android has k9mail which - just barely - steps over the line into "usability".""" -- http://mailman2.u.washington.edu/pipermail/imap-protocol/201...
If you go back to the early IMAP specifications, this is actually laid out in the rationale section: the argument is that in an age where users have too many devices to easily manage and network connectivity is nearly universal--or as I will call it, "Mark Crispin's 1988" (yes: 1988, and this is already IMAP2)--it no longer makes sense to store e-mail on the client; he then lays out a strategy for an efficient mail-specific thin-client protocol, with everything from server-side search to server-side parsing.
"""Consequently, while the workstation may be viewed as an Internet host in the sense that it implements IP, it should not be viewed as the entity which contains the user's mailbox. Rather, a mail server machine (sometimes called a "repository") should hold the mailbox, and the workstation (hereafter referred to as a "client") should access the mailbox via mail transactions.""" -- http://tools.ietf.org/html/rfc1064
It is only, however, when one delves into the mailing lists where you truly get a sense for this: on various occasions, Mark has even looked at modern webmail systems as having more in common with IMAP than the alternatives people normally compare IMAP to (such as POP).
"""It's easy to dismiss all this, because only a few IMAP clients are sophisticated enough to take advantage of this state. The vast majority are glorified POP clients that babble IMAP protocol. This came about because of the long-obsolete notion that Internet access is a difficult and expensive commodity that requires that the client must keep a mirror of what's on the server. The success of webmail (which transforms the browser into the ultimate thin client) proves that this notion is complete nonsense today. Yet people persist in claiming it. Webmail won the war for the hearts and minds of users, not because webmail is so much better than IMAP, but rather because webmail is so much better than POP.""" -- http://mailman2.u.washington.edu/pipermail/imap-protocol/200...
What struck me the most, though, is just how often people refused to see this: assuming that IMAP was something that it was not, or simply not giving Mark the respect he deserved from the history he has thinking about this problem; people oft would approach claiming they knew better, and wanted to start over. This meant that he often had to spend his time attempting to herd people towards a common goal, and defending what existed against misconceptions; even having to teach people what it meant to have a protocol at all.
"""Before assuming that you are smarter than the old guy, you ought to make sure that you really understand the problem.""" -- http://mailman2.u.washington.edu/pipermail/imap-protocol/200...
He didn't just sit back and heckle, though: he provided long and detailed critiques; he imparted his knowledge to others, even as he saw people often ignore what he had learned. His explanations usually also gave you a history lesson, illuminating part of the process and showing not only why something works the way it does, but why it worked the way it did, and how that notion had to be stretched into what we are currently using today: you can learn a lot about not just IMAP, but protocols in general, from his writings.
"""Furthermore, if you design for the stupid, you must also design for the defiant. If you fail to do that, you have learned absolutely nothing from my experience in the past 22 years.""" -- http://www.ietf.org/mail-archive/web/imap5/current/msg00005....
There was a continual sobering undercurrent, however, with relation to how long it has taken IMAP to come to fruition (technically, it is still only a proposal). Hearing today's news brings back to mind one e-mail in particular from 2007, which I will now end this comment with (its a long one, but I consider it quite powerful, and in this context, I think it is important to include in its entirety).
"""
RFC 3501, like all human endeavors, is not perfect. We have spent about 20 years in trying to get IMAP beyond Proposed Standard status. We are probably going to fall back yet again with another Proposed Standard RFC for IMAP.
You can't assume that the specification is going to tell you everything that you need to know. It will never happen. We can address this particular question, but I can guarantee that someone will find another one after the publication of the new RFC.
Each IMAP specification update consumes a couple of years of my time. Invariably, there are months of "last calls" and inactivity, only to have someone call a "wait, we need to do this" at the last minute that pulls everything back. Requests to review drafts don't work.
And, with the addition of more expository text to say (what is obvious to some people), we get a larger and more bloated document that people won't read. There are already many IMAP implementations written by people who looked at the examples but never the formal syntax or the expository text, because their implementations blatantly violate both.
I understand -- and sympathize -- with the desire to remove reliance upon folklore and common sense. I see no hope of that ever being accomplished.
The sad fact is that we are running out of time. Given past history, there is little hope that it will reach full standard status under my tenure.
I don't think that it's a good use of the next decade or so to make a futile attempt to perfect the base specification. It needs to be made good enough, and there needs to be general understanding of the architecture so that people don't blame their silly decisions on the base specification.
-- Mark --
""" -- http://mailman2.u.washington.edu/pipermail/imap-protocol/200...