Mark Crispin <[EMAIL PROTECTED]> wrote: > It is not necessary to cater to cretins. > > It is, however, necessary to avoid giving them wiggle room where they > can point to the specification and claim that they are right and > everybody else is wrong.
Ok. AFAICS, then, there is no wiggle room - NO is listed as a valid response to FETCH, and any client that can't handle it is in violation. Servers are entirely within their rights if they send NO, though of course it's preferable to prevent the problem if possible. > You are in your favorite text editor. You now give the command to go > to the next screenful. The editor gets an I/O error. > > Is it reasonable to say "no, you can't read that data, but you can > read the rest of the file, and when you save I'll save it without that > data"? > > Or do you say "an impossible error has occurred, I'm giving up now, > have the sysadmin fix it." Why should those be the only two choices? Certainly the error should be reported. Allowing the user to see the rest of the file, in itself, doesn't do any harm. Further clobbering an already clobbered file would be bad, and it should not be possible to do it by accident, so a noisy warning and confirmation request would be in order if the user tries that. I hesitate to say that it should be completely prohibited - protecting users from themselves is often a losing battle, and the user may know better than you, being in the thick of it. But you seem to think that reporting the error instead of dropping the connection will also cause further data corruption for an IMAP mailbox too. How, exactly? > I vote -- strongly -- for the latter. If can open a mailbox, then I > expect to be able to read what's in it, without having some fool > server say "you can read messages 1 and 3 but not 2 because of some > internal implementation consideration that is invisible to you." You prefer not being able to read any of it? >> Isn't it also reasonable to expect that things might change over time? > > Why? > > Why would you consider this to be a good thing? Are you saying that you'd prefer for the mailbox contents to be entirely static? As you know, regardless of what you prefer, new messages show up, old ones get deleted, and resources that were available a second ago may be allocated now. paul
