On Thu, 11 Dec 2003, Marcel Crasmaru wrote: > Suppose that message of sequence number 1 is unseen. > The client issue the command: > C: tag fetch 1 body[] > and the server fetches the message but for some reasons > it can not flag the message as seen (e.g., rename of a file failes). > What should the server respond: > 0. whatever, the server is already broken; > 1. tagged OK without status of the flags; > 2. tagged OK with status of the flags but with flag \seen unset; > 3. tagged NO or > 4. other response?
(0) is the answer. :-) However, that doesn't help in deciding what to do for an internal error case. With that in mind, (2) is preferable to (1), and (1) is preferable to (3). The reason is that (2) unambiguously indicates what happened. It's bad behavior, but it's understandable behavior. (1) also indicates what happened, but some clients may find it ambiguous. It actually isn't, but (2) has the advantage of not leaving things to chance. This is why the specification wants servers to return the flags, rather than saying "set \Seen implicitly in the client." If you think about it, the specificaion could have had it set implicitly, and then in your case it would have have to explicitly unset and maybe clients wouldn't handle it right. So IMAP's design actually anticipated this problem! You're welcome. It would be better to prevent the situation from happening. If \Seen can't be changed for any message in that mailbox, then \Seen should not appear in PERMANENTFLAGS at SELECT time. Then you can say that \Seen is a session only flag; that way clients will graphically show \Seen status as the user reads the mail. If it turns out that \Seen can't be changed for any message in that mailbox, but you didn't find that out until when the FETCH was done, then you can issue a new PERMANENTFLAGS without \Seen before the untagged FETCH response. It's possible that some clients won't handle this well though, so I don't really recommend it... Hence we come back to (0). It would be best if you can avoid the situation entirely. Of course, it's not always possible to avoid implementation warts; we all have them. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
