Hi, > On Tue, 30 Dec 2003, Christof Drescher wrote: > > It is neither unilateral nor unexpected, if this information is given > > by the admins. If they do, everything is ok, if they don't, it is their > > fault, not the programmer's. > > When a user's client does not work the way the user expects, the user will > blame the client, not their system administrator. And the client authors > are going to lash out at any server which turns out to be the cause of the > problems.
.. something which the server author can explain very easily, because someone must have done a change deliberately. No one can blame a server which follows given commands (by client) of given config (by admins). This is not getting anywhere. There is no "imap-user" on its own, but always an imap-user in a given environment, which he and others define. If they agree to certain settings, why not? > > b) there is nothing as a "broken behavior". I do not propose a change > > which would "break" any client, since all rfc-conforming clients > > would not give any error message. > > Many widely-distributed clients do not handle unsolicited expunge > responses well. > > Furthermore, you have to defer EXPUNGE responses in the case of STORE (as > opposed to UID STORE). Have you considered what happens if the user > attempts to undelete a message prior to any command which permits an > EXPUNGE response? > > I doubt that you have really considered the implications of this on client > behavior. You are right, I have not. This is an argument I must follow. You win. [Gave me a hint that I need to fix something in my server :-(] I'm baffled why this rule exists in 7.4.1. I'd REALLY be interested to see an example which would cause a "loss in syncronization" if untagged expunge responses are sent at the end of any command. But for my idea, it's really bad, because it allows only for implementation if a client is really prepared for it, which might lead to a lot of clients not supporting it. Too bad. Christof
