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. > 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. > 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. > 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"? My only motivation is to give advice to people who want to write good servers that will not be perceived as garbage. If you write a garbage server, either you will end up fixing it or it will eventually die of its own stink. Perhaps you will inflict the stink on others for a while, but over time the world has a way of getting rid of stinking garbage. Not even Microsoft is immune from this. 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. Maybe I've become old and foolish enough that I'm no longer an authority and have instead become a crank. I can't judge that; by definition cranks do not consider themselves to be cranks. It is my fervent hope that I will be either retired or dead before I turn into a crank, but not all hopes come true. > 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. 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. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
