On Fri, 2 Jan 2004, Christof Drescher wrote: > IMHO, RFC abc, subparagraph x.y with alternative this-and-that is not going > to make implementors really give anything on it. A clearly stated paragraph > in IMAP4rev2 would most probably do so, and clarify the issue - so a tagged > no would not be "bad server juju", but an accepted way of dealing with > the issue.
I'm afraid that you are going to lose this argument. >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. I agree with that perception. The broken server should be fixed instead of expecting clients to deal with a server's internal implementation problem. Nor am I convinced by the notion that burdening clients is somehow necessary for "security". EXPUNGE is not part of the access control model. EXPUNGE is a housekeeping operation. You seem to think that "IMAP4rev2" or "IMAP5" is a trivial undertaking. It is not. Most people who have been through this process for years hope that there will never be another version of IMAP. 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. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
