--On Thursday, July 10, 2003 04:16:49 PM +0200 Andreas Aardal Hanssen <[EMAIL PROTECTED]> wrote:
|> it shouldn't know about yet, it's clearly an error. |> How is keeping client state in mind with SEARCH any different than with |> FETCH? | | If you FETCH message 1000:1050 and there are no messages there, then that | is an error. If you search for messages with msn 1000:1050 and there are | none, then the search result is empty. | | There is no _error_ in searching for message number 1000:1050 even if | that doesn't match anything. Error <=> BAD.
As the author of the client that generated the wrong sequence number I have to say that I think servers MUST flag sequence number range errors as BAD responses. Sequence number (as opposed to UID) errors are critical errors as using the wrong sequence number can result in unwanted message loss (in the worst case). I think both servers and client should immediately flag sequence number errors as BAD to ensure things don't go wrong and to provide useful feedback that some kind of error has taken place that needs to be tracked done and fixed (which I'm now doing).
In this particular instance the error might appear not to be harmful at first glance, but what if a new message arrived at the same time as the last one was expunged? In that case, the expunged message's sequence number would have been assigned to the new message and the client might have gone on to operate on that, which would be a serious mistake. Thus the original 'anomaly' was symptomatic of a much more serious problem and anything that can be done to expose what might appear to be trivial 'anomalies' is useful in helping tackle such issues.
-- Cyrus Daboo
