Mark Crispin <[EMAIL PROTECTED]> wrote:If a server could send an tagged NO to a FETCH, then there would be no need for a serverto implement ENVELOPE, BODYSTRUCTURE, etc. -- just send a tagged NO and force the client to FETCH RFC822 and parse the message itself.I don't see why you would take it that far. Wouldn't it be reasonable to say "the server can give a NO response in these conditions, but still must support these features"?
Decades of unfortunate experience with cretins who think that they can implement whatever they damn well please suggests otherwise.
It is unfortunate that the IMAP base specification ever suggested that NO was a reasonable response to a FETCH command. There is no reason to believe that any client will ever do anything reasonable with a NO response to a FETCH command.
Why would a client interpret NO as a signal that it should do the parsing itself?
That was the very thing that the original message in this thread suggested!
If the server can't parse the message at least as well as the client (and preferably better), then the server is broken.Sure. But how do you get from there to "the server must never send NO to FETCH"?
If the server says that the message is there, then the client has a reasonable expectation that it can fetch it.
It is not IMAP's fault if some servers choose to implement mailboxes as multiple files in which some can be read-protected against the server. That is an implementation detail which must be hidden from the client. The lowest level of protection granularity in IMAP is the mailbox, not the message.
-- Mark --
http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
