MBOX-Line: From dave at cridland.net  Fri Sep  2 02:04:39 2005
To: imap-protocol@u.washington.edu
From: Dave Cridland <dave@cridland.net>
Date: Fri Jun  8 12:34:36 2018
Subject: [Imap-protocol] Req. for clarification: RENAME and DELETE in
	selected state
In-Reply-To: <20050902074358.GJ1330@fone>
References: <20050902074358.GJ1330@fone>
Message-ID: <13633.1125651879.236369@peirce.dave.cridland.net>

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.

