On Fri, 2 Jan 2004, Christof Drescher wrote: > > RFC 2180 is informational. It is not standards-track. In part, RFC 2180 > > has been overtaken by events. > I'm willing to learn. What events?
The past 6.5 years of implementation history. > This goes to a point like: Client implementors ignored this or that > (namely RFC2180), so now you have to live with it. Please remember that RFC 2180 was only informational, not standards-track, and it reflected the collective wisdom of 6 1/2 years ago. The fact that it prevaricates on certain issues should indicate to you that these issues were just as hotly debated then as now. Certain of its recommendations have ceased to be good ideas (in fact, I believe that those were never good ideas) since client implementors ignored the possibility and server implementors choose to oblige those clients. In other words, the market decided the issue. This doesn't affect the standards-track specification, since it did not rule on this issue. Perhaps a future standard will; but if it does I predict that it will be on the side of least-surprise to the client. > I'd say the opposite: Try to educate the client implementors > to handle it correctly, since it's a valid way to cope with this > case. I don't think that it's sensible. It's a surprise for clients, especially since it's an uncommon case. It's easy for the server to implement in a different way that doesn't cause the problem. In terms of deployment, it's much easier to fix servers than it is to fix clients. Historically, when I first designed IMAP, I never intended for it to be valid that a FETCH of any of the existing data items, on an non-zero message number less than or equal to the EXISTS count, would return anything other than an OK. I left open the possibility of a NO in order to leave a hook for future annotations. 15 years later, it is clear that annotations use a different design. STORE is similar. I considered a NO for the read-only case, and decided against it when I discovered that it caused all sorts of client confusion when reading a read-only mailbox. Users were irritated about getting the error messages, and wanted \Seen, \Answered, etc. flags to get lit at their client's behest even after they were told that such flags would get lost when their session ended. Nobody likes the idea of session flags, but they make clients behave nicer for the users. Now, none of this says that returning NO to a FETCH or STORE is "not valid" in terms of strict compliance with the protocol. But if you want to have an interoperable server which works well with the majority of clients, you shouldn't do that. > Me, as a user, would not. Lets say I have a few computers in my office, > both have the same mailbox open, I expunge on one of them, see the > mails removed, and I go to the other box and see them NOT expunged. > Especially, I can retrieve a message which I deliberately deleted. > I'd say "there's something broken here". Wouldn't you? What is the second client doing? Is it sitting idle? Did it do an IDLE command, or does it just do periodic NOOPs? If it did an IDLE command, the state would not have happened since it would have gotten the expunge. If it did a periodic NOOP command, the state only happens if you get to the second client fast enough before it has a chance to do its periodic NOOP. If the second client had earlier fetched the data into its cache and thus translated your request to "retrieve the message" into a "show what is in the cache", then it never does any IMAP commands to fetch the message; thus your server's effort to respond with NO is in vain. In any case, the situation clears itself up the instant the second client does a NOOP (or any command other than FETCH, STORE, SEARCH); it gets the untagged EXPUNGE and the messages vanish. Hence, what we are talking about is a brief interval, in between the periodic NOOPs. And either the client works the way it expects (and presently the expunged messages vanish), or it gets this utterly bizarre NO which leads it to spit "horrible error 69" on the user's screen. > Just because the client does NOT give an error message, I would > not say "the client is not broken". Review the cache case. If you tell me that caching clients are broken, then I suggest that you study the IMAP protocol and do some careful thinking because caching is what IMAP is all about. > I think your preferred behavior is to keep message content to be > delivered although they are meant to be expunged, as in RFC2180 4.1.1 My preferred behavior is that a wide variety of clients and servers interoperate without "horrible error 69". That leads to RFC 2180 4.1.1 and 4.1.4, and eschews 4.1.2 (and to a lesser degree 4.1.3). > Again: What events showed this was not ok? If the only thing is that clients > show error messages, so be it. Consider the following little comedy, which is not much different from what actually happened over a period of years: Clients spit forth unpleasant error messages. Users complain to client authors. Client authors say "the server sucks. No other server does that." Users complain to system manager. System manager talks to server author. Server author says "no, all those clients should be fixed." System manager goes to all the client authors. Client authors say "We will accomodate the broken server when monkeys fly out of our butts, and even then it won't be for three or more years." System manager tells server author "fix it or I'll replace your server." Server author fixes problem or system manager replaces server. The end. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
