5 ms·

Well, you could look at the comments at the start of sup's client implementation at http://www.gitorious.org/~einars/sup/utf-sandbox/blobs/95e1f7e3fb05db7f313c4

Well, you could look at the comments at the start of sup's client implementation at http://www.gitorious.org/~einars/sup/utf-sandbox/blobs/95e1f7e3fb05db7f313c49e82040eb6b626fb10d/lib/sup/imap.rb http://www.gitorious.org/~einars/sup/utf-sandbox/blobs/95e1f... to start with. You could also look at http://www.courier-mta.org/fud/ http://www.courier-mta.org/fud/ as geofft mentioned earlier. 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.

saurik 14y ago
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/2007-March/000436.html 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).
- MichaelSalib 14y ago
  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?

saurik 14y ago

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/2007-March/000436.html 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).

MichaelSalib 14y ago
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?