Hi, I have agreed with Mark's positions the last few month's almost all the time, but this time... :-(
> >From the point of view of users and client authors, the other servers get > it right. The other servers do not respond with NO to a valid FETCH. > Therefore, a server that sends NO to a valid FETCH will be seen as broken > by users and client authors. No. Absolutely no. You argue that a server which does not keep messages for delivery after a session has sucessfully expunged to be broken. This is definitely arguable, and I personally think you are wrong. So is RFC2180, which allows it for purpose. If it had been stated in the IMAP specs to still deliver mails already expunged, I'd say ok, it's in the specs. But it is not - it has been left open to the implementators. And some implementors, not only me, think another way than yours is correct and meaningful. Simply to say "I don't like it, so it's broken" is no good at all. > I agree with that perception. The broken server should be fixed instead > of expecting clients to deal with a server's internal implementation > problem. Bad argumentation. The server is not broken at all, and it is not an implementation problem either. You can be sure me and others would be well capable to implement your "preferred" behavior, but I do not think it's good behavior. > You seem to think that "IMAP4rev2" or "IMAP5" is a trivial undertaking. Have I ever said so? No. Far from it. > It is not. Most people who have been through this process for years hope > that there will never be another version of IMAP. I bow my head before thee, master of IMAP, and I respect any and all who helped creating this protocol. Nonetheless, I thought we could talk about open issues on this list, maybe to make IMAP even better. I personally do not think there are too many issues with IMAP4rev1, it's complex though very well defined and documented. If there are one or two arguable things here and there, so be it. This is - in my opinion - one of it. It's been halfway cleared in RFC2180, but now you say RFC2180 4.1.2 is nonsense, this is broken behavior and I don't like it. Great. :-( > I can, however, assure you that if there is a new version of IMAP, it will > be much harsher in its server requirements than any of its predecessors. > Too much in IMAP is left to server discretion, and this has caused ongoing > problems. So be it. Don't get me wrong: I can live with a decision to say "this is required behavior in IMAP" if it is in an RFC after discussion on a broad basis. I accept such things, even if I disagree, and I will not go mad about it. But currently, a couple of people seem to see it like I do, RFC2180 sees it like I do, and I requested some clarification, mainly "formalising" what RFC2180 already requests (to NOOP after a NO to a fetch). It is even still there! You keep your point? OK. But your argumentation is far from convincing. Christof
