On Fri, 2 Jan 2004, Christian Kratzer wrote: > can you perhaps further elaborate on your thoughts on why exactly you > feel that an untagged NO FETCH response is evil.
Clients don't handle it the way that you think they do. They expect that if they issue a proper FETCH, that it will work work; and if it doesn't work then it's "horrible error 69." > Rfc2060 and 3501 seem > to leave this option open and I cannot see how they would forbid such > behaviour. Yes, it is a flaw of the IMAP specification that its author does not have enough clairvoyance to imagine every possible way in which some implementation will make a silly choice, and write specific text forbidding the choice. The IMAP specification has quite a bit of company in this regard. When implementing a specification, it is necessary not only to comply with the specification, but also to make sensible choices. Sometimes, it isn't always obvious what constitute a "sensible" choice. That's why there are mailing lists and newsgroups; so that you can get guidance on such matters. Often the question isn't anticipated until someone asks it. This isn't the first time that someone has rejected being told "that is not a sensible path" and instead has argued (or even demanded) that that choice be formally declared sensible. Sooner or later, after long heated discussions, market realities will crush the argument. The choice is stark: either accept when you're told "it's not going to work, don't do it" and implement based on that advice, or ignore the advice and be forced to fix it later when you are flooded with complaints. > For me the best common practice promoted by rfc2180 seems quite logical and > it also seems several server vendors seem to have implemented "no fetch" > responses for expunged messages. RFC 2180 is an informational (*not* standards track) RFC that came out only half a year after IMAP4rev1 entered standards track. Most of what it has to say is still good advice; some has been overtaken by events in the subsequent six and a half years. You'll notice that my recommendation is listed first (4.1.1), and the untagged NO or dummy data options are listed second and third (4.1.2 and 4.1.3). As it turns out, 4.1.1 and 4.1.4 (avoid the problem entirely) turned out to be the only successful strategies. This is because the client never encounters an unexpected situation with these strategies. Not surprising clients is always the winning strategy. > The discussion so far has been much heated as usual for this kind of stuff. > Everybody seems to think they want it their way and makes up arguments why it > is logical this way or the other. It seems that people like to implement this > the way it's least painfull for the kind of mailstore they have. The reality is that users and client authors don't care about the kind of mailstore at the server. This is a matter in which a server implementation can choose not to inflict the problem upon unsuspecting clients. I consider that fact to be the razor in which client preferences override server preferences. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
