On Fri Sep 2 08:43:58 2005, Ingo Schurr wrote:
> Assume we are in selected state, the selected folder being foo. What
> would be the approriate behaviour for the commands
> c DELETE foo
> c RENAME foo bar
> (assuming they would succeed in authenticated state)?
>
>
A correct behaviour is to return "NO". That's certainly what some
implementations do.
> Should DELETE foo be read as
> c1 CLOSE
> c2 DELETE foo
> (meaning: Delete everything without untagged EXPUNGE respones and
> change into authenticated state)
>
>
No, it can't - DELETE does not change state.
> c1 STORE 1:* +FLAGS \Deleted
> c2 EXPUNGE
> c3 CLOSE
> c4 DELETE foo
> (meaning: Delete everything with untagged EXPUNGE responses for
> _all_
> mails and change into authenticated state)
>
>
Likewise here - DELETE doesn't change state, therefore it can't do
this.
> or as
> c1 STORE 1:* +FLAGS \Deleted
> c2 EXPUNGE
> (meaning: Delete everything with untagged EXPUNGE responses for
> _all_
> mails, but do _not_ delete folder and stay in selected state)
>
>
That would be legitimate. A subsequent SELECT (even in another
session) of the mailbox would presumably fail - the mailbox has
effectively been DELETEd. Any STORE would fail, because there are no
messages, and any APPEND would fail (because there's no mailbox).
The emulated STORE there could be +FLAGS.SILENT - there's no need to
notify the client of the flag change, or even to have one.
> or should one elete everything without untagged EXPUNGE responses,
> _not_ delete folder and stay in selected state?
>
>
After doing this, you're going to confuse the client, somewhat. The
client will believe there are messages. So many commands would have
to elicit an untagged NO with an ALERT response code to try to ensure
that the user could try to deal with the situation. I don't think
this is ideal.
Or, you can pretend the mailbox is deleted, but still allow all FETCH
operations, actually physically deleteing it when the last client
leaves the selected state on it. This is similar to the situation of
deleting an open file on UNIX, say - the file still exists, but has
no name anymore, no applications with it open can still use it, no no
new applications can open it.
One of the three above situations must occur if the mailbox is
deleted by another client, of course. I would personally opt for
either of the first [EXPUNGE all messages] or the third [Physical
deletion occurs after last client closes, but no new SELECT/APPEND
etc commands will operate].
> Or should we not allow it at all?
>
>
As I said, that's certainly done by some implementations, and would
seem quite sensible, but for DELETEs from other sessions, something
else needs to happen.
> Simillarly, RENAME foo bar could be read as:
> c1 EXAMINE foo
> c2 CLOSE
> c3 RENAME foo bar
> c4 SELECT bar
> or, altenatively c4 could be omitted. Or we could just rename
> folders
> without giving any untagged response, meaning, we would be in
> selected
> state on folder bar afterwards.
>
>
I'd assume either a NO, or else we would effectively be in SELECTed
state on the "new" mailbox afterward, entirely silently. Remember
that nothing in the selected state refers to the mailbox by name,
hence the mailbox can change name without having to tell the client.
What you can't do is change state for DELETE or RENAME. The only
commands which changed state from selected are SELECT (whether it
works or not), EXAMINE (likewise), CLOSE, and UNSELECT (if
available). Clients rely on this behaviour.
Dave.