[prev in list] [next in list] [prev in thread] [next in thread] 

List:       imap
Subject:    RE: [Imap-protocol] SELECT of same mailbox
From:       Mark Crispin <mrc () CAC ! Washington ! EDU>
Date:       2005-09-13 15:01:07
Message-ID: Pine.OSX.4.63.0509130752100.1609 () pangtzu ! panda ! com
[Download RAW message or body]

On Tue, 13 Sep 2005, Corby.Wilson@nokia.com wrote:
> This is confusing the heck out of me.
> There should not be this level of ambiguity anywhere in any RFC.

I don't think that there is any ambiguity.

Cyrus expanded the meaning of the word "failed" to incorporate the BAD 
response, and arrived at an absurd conclusion.

The entire point of the BAD response is to have a third state other than 
success and failure.  BAD means, in effect, "huh?".

> The way I interpreted the statements:
>
> OK - Command Successfully Executed
> BAD - Command failed and the state of any part of the server is exactly
> the same as it was before the command was submitted (except for maybe
> the Z flag).  This can be a syntax error, a hardware failure on the
> server side, or executing two commands at the same time that collide
> with each other (no proper atomicity).
> NO - The command was executed but something prevented successful
> completion.  State may have changed meaning the client should do
> appropriate cleanup if necessary.

This is basically the correct interpretation, with one exception.

You say:
   the Z flag).  This can be a syntax error, a hardware failure on the
   server side, or executing two commands at the same time that collide
   with each other (no proper atomicity).

What is "the Z flag"?

Why would a hardware failure on the server side cause a BAD?  Are you 
thinking about untagged BAD?

It's a stretch to say that "executing two commands at the same time that 
collide with each other (no proper atomicity)" causes a BAD.  It could, on 
the grounds that the command is not recognized in the state machine, but 
that assumes an FSM parser.  Many IMAP FSM parsers just recognize the 
states outlined in the specification (Not Authenticated, Authenticated, 
Selected), and do not try to have states to prevent command collisions.

> I had assumed this was the case, but now I see that the meaning of these
> changes throughout the document and I will need to revisit each command.

Why do you say that?

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
_______________________________________________
Imap-protocol mailing list
Imap-protocol@u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-protocol
[prev in list] [next in list] [prev in thread] [next in thread]