116 lines
3.9 KiB
Plaintext
116 lines
3.9 KiB
Plaintext
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.
|
|
|