Hi again (and again and again...) :-) > > 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. > [...] Noted. I agree with most of your explanation, thank you. I see you speak in favor of all the clients which cannot be changed and for a work to get everything interoperable, and you are willing to take the "less perfect" way to get this. I can understand, and I can accept that.
Sorry, but... > > 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. Agreed, but you (still) miss the core point: I want the implementation to have the message "be removed" instantly, this is the only thing I want. Neither 4.1.1 nor 4.1.4 give that result. THAT is the problem, and I seek a conforming solution. If you say "there is none to this problem", and this is agreed consensus here, I have to cope with it, but I think there should be and it only has to be "cleared", be it a "NO" to fetch or a NIL message. > > 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? > [...] > 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. Yes, yes, yes. I know it is a rare condition, and maybe this whole discussion is in vain because for the three times a year this happens worldwide, I could also just shutdown the server and the world would blame sun to have a bad JRE. :-) But the problem is, I'd like to have a solution which works even then, and I've seen clients which neither IDLE nor NOOP (at least "fast enough); the "dumb extension" would just tell them to NOOP like they should, be it explicitly with [NOOPFIRST] or implicitly when receiving a NIL message. > > 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. Never said so and never thought so. I think I know about the caching, and I also know that I cannot prevent the client from giving cached information, unless the expunge notifications have come through (- yes, I know I cannot even then -). The "security" thing was just an example, you know. Now just for the fun of 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." --BREAK HERE-- Server author says "those clients will be fixed since the client others will adopt to the new modern specs as they have to. You must weigh the advantage of this server handling you data in the way you requested it against the spurious client error message" System manager goes to all the client authors. Client authors say "OK, we see the point, and it will be done in a future release, sorry that it might take some time". System manager tells server author "ok, I can live with it - after all it's so seldom [because the great server author did a good job in making it as compliant as possible with the existing clients... :-))) ]". You say that's not likely? Agreed. But it depends more on the specs than on the client authors, because they will catch up if its recommended. Whatever... Christof
