Hi, > On Fri, 2 Jan 2004, Christof Drescher wrote: > > This is definitely arguable, and I personally think you are wrong. So > > is RFC2180, which allows it for purpose. > > 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? > > 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. > > I do not know of a single *client* implementor who says that it is right > to surprise the client. This goes to a point like: Client implementors ignored this or that (namely RFC2180), so now you have to live with it. 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. > > Bad argumentation. The server is not broken at all, and it is not an > > implementation problem either. > > Whether or not a server implementor thinks that his server is broken is > irrelevant to the question of whether or not a client implementor and the > users of that client think that the server is broken. Do they think so? I belive you think so, which is of course up to you. But the user in general? I doubt it. 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? Just because the client does NOT give an error message, I would not say "the client is not broken". > > 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. > > What are you talking about when you say "my preferred behavior"? 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 This handling is your choice, ok. This handling seems wrong to me. My view (not allowing access anymore) seems to make sense to me and to others, even if it does not to you. However, you seem to ignore this view for the sake of "client compatibility", which I think is not ok. > If you don't want my advice, then you are free to ignore it. If you then > spend a lot of time and effort, and the result is widely reviled as > garbage, then it's not my fault because I tried to warn you. Advice taken, thanks. Maybe you are right, maybe not. > > 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 argued against 4.1.2 and 4.1.3 when they were first put in RFC 2180. > You'll notice that 4.1.1 is what I say should be done and is listed first. Seems some others did not go with you at that time either...so forgive a newbie like me to do the same "mistake". Let me learn... > As it turns out, the subsequent 6.5 years of history showed that 4.1.1 is > the way to go. Of course, 4.1.4 (the "don't let it happen in the first > place") also works; punting is always an option. It sure is, not writing a server is also an option. Both of which I won't take. Again: What events showed this was not ok? If the only thing is that clients show error messages, so be it. I can handle that. But I'd like clients to evolve and to cope with it even better in the future. Then both ways (keeping mails or not) would be ok and it would not cause any harm. Only saying "my way works, so make it my way" cannot be a solution for everything, especially if another way has good reasons for using too. Please explain. Christof
