199 lines
8.2 KiB
Plaintext
199 lines
8.2 KiB
Plaintext
MBOX-Line: From snowjn at aol.com Mon Jun 14 21:28:42 2010
|
|
To: imap-protocol@u.washington.edu
|
|
From: John Snow <snowjn@aol.com>
|
|
Date: Fri Jun 8 12:34:44 2018
|
|
Subject: [Imap-protocol] MOVE is a pipeline
|
|
In-Reply-To: <alpine.OSX.2.00.1006141713260.662@hsinghsing.panda.com>
|
|
References: <201006110854.37969.witold.krecicki@firma.o2.pl>
|
|
<201006150012.43889.witold.krecicki@firma.o2.pl>
|
|
<alpine.OSX.2.00.1006141528400.662@hsinghsing.panda.com>
|
|
<201006150103.52513.witold.krecicki@firma.o2.pl>
|
|
<alpine.OSX.2.00.1006141604420.662@hsinghsing.panda.com>
|
|
<4C16C4E8.7010008@aol.com>
|
|
<alpine.OSX.2.00.1006141713260.662@hsinghsing.panda.com>
|
|
Message-ID: <4C17017A.2090305@aol.com>
|
|
|
|
|
|
|
|
Mark Crispin wrote:
|
|
> On Mon, 14 Jun 2010, John Snow wrote:
|
|
>>> No. MOVE takes a message set argument. That makes its behavior
|
|
>>> client-deterministic.
|
|
>> How is that different than a UID expunge? A client specifies which
|
|
>> specific message it wants expunged.
|
|
>
|
|
> That's not what UID EXPUNGE does.
|
|
>
|
|
> UID EXPUNGE indicates the message ranges that MAY be expunged as a result
|
|
> of that command (or, alternatively, indicates that messages outside that
|
|
> range should not be expunged as a result of that command).
|
|
>
|
|
> It does not require that the server expunge any of those messages. It
|
|
> won't expunge messages that aren't deleted (read RFC 4315) or were
|
|
> undeleted in another session just before the UID EXPUNGE was issued (so
|
|
> there was no opportunity for an untagged FETCH to report the undeletion).
|
|
>
|
|
> Nor does it forbid an expunge that happened in some other session from
|
|
> being reported.
|
|
>
|
|
> These are all significant differences from "[in UID EXPUNGE] a client
|
|
> specified which specific message it wants expunged."
|
|
>
|
|
> There is no command in IMAP to say "expunge these, and precisely these,
|
|
> messages". I would find such a command to be utterly appalling, but I
|
|
> would have no argument against it.
|
|
>
|
|
> I do not find MOVE to be appalling. MOVE is a desirable functionality.
|
|
> The problem with MOVE are technical objections which have been known for
|
|
> 25 years.
|
|
>
|
|
> My judgement is not based upon what I find to be desirable or appalling.
|
|
> They are based upon technical matters.
|
|
>
|
|
> So ideas are appalling and technically flawed. They are the easiest to
|
|
> oppose, although some people argue for them anyway.
|
|
>
|
|
> MOVE is desirable, but not as a chatty kludge with unpredictable
|
|
> behavior.
|
|
> MOVE must either fully succeed, or fully fail. If it succeeds, then ALL
|
|
> messages MUST be inserted in the target and MUST be removed from the
|
|
> source. If it fails, then messages MUST NOT be inserted in the target
|
|
> and
|
|
> MUST NOT be removed from the source. This also obviates the need for an
|
|
> untagged expunge or any other response other than a MULTIAPPEND-form
|
|
> APPENDUID (not COPYUID) data.
|
|
>
|
|
|
|
I don't think anyone is arguing against the requirement that ALL must
|
|
succeed or
|
|
ALL must fail, but I don't see how you can guarantee that's true for
|
|
even existing
|
|
commands. If the client sends a copy 1:100 saved and the server crashes
|
|
when
|
|
only 50 have been copied what happens? The server managed to copy 50, but
|
|
didn't finish so the client doesn't know any were copied yet. In this
|
|
case I 'd
|
|
expect that the client reconnected and retried the copy resulting in the
|
|
first
|
|
50 being duplicated in the saved folder.
|
|
|
|
Stuart's proposed per message status would give the client an indication
|
|
of move progress
|
|
leaving the client in a better position to recover from such a failure.
|
|
|
|
>> Why doesn't a move have the same option?
|
|
>
|
|
> So you are saying that the sequence set argument to MOVE ought to be a
|
|
> guideline, like UID EXPUNGE; and not a specific client request for a
|
|
> precise set of messages, as in FETCH, STORE, COPY, SEARCH?
|
|
>
|
|
> Do you think that client implementors will be comfortable with that? "It
|
|
> may or may not move all the requested messages, and it may leave you in a
|
|
> state where you can't move forward (complete the operation) or backward
|
|
> (undo it)."
|
|
>
|
|
As noted above, I think this can already happen.
|
|
|
|
> As I noted earlier, the requirement for atomicity in COPY did not
|
|
> originate with me. Both the original IMAP and IMAP2 had an untagged COPY
|
|
> response for partial success. Client implementors rejected those
|
|
> semantics circa 1991. As a result, the COPY response was deprecated in
|
|
> RFC 1730, and removed entirely in RFC 2060 (see RFC 2062).
|
|
>
|
|
> Non-atomic MOVE violates that precedent for COPY, and with a far more
|
|
> dangerous operation that destroys data.
|
|
>
|
|
> This will be the first operation in IMAP that may fail irreversibly.
|
|
With the per message response, a failure is not irreversible
|
|
>
|
|
>
|
|
> The only definition of MOVE that I consider acceptable is:
|
|
>
|
|
> MOVE and UID MOVE must either fully succeed, or fully
|
|
> fail. If it succeeds, then ALL requested messages MUST
|
|
> be inserted in the target and MUST simultaneously be
|
|
> removed from the source.
|
|
>
|
|
> If it fails, messages MUST NOT be inserted in the target
|
|
> and MUST NOT be removed from the source.
|
|
>
|
|
> There MUST NOT be any intermediate state in which some,
|
|
> but not all, messages appear in the target.
|
|
>
|
|
> There MUST NOT be any intermediate state in which some,
|
|
> but not all, messages are removed from the source.
|
|
>
|
|
I can agree these are a good goal, but in practice I don't think you
|
|
can guarantee it.
|
|
|
|
> A successful MOVE and UID MOVE returns data equivalent
|
|
> to the APPENDUID response for a MULTIAPPEND. There is
|
|
> no untagged EXPUNGE or any other indication of the
|
|
> messages that were removed from the source. This means
|
|
> that a client which does UID MOVE must either have the
|
|
> UID/sequence map in advance to calculate the affected
|
|
> messages or it can not use message sequence numbers.
|
|
>
|
|
Isn't that true for all commands?
|
|
|
|
> An untagged EXPUNGE response resulting from some activity
|
|
> in another session MAY occur with a MOVE and UID MOVE
|
|
> command. The message sequence number in such responses
|
|
> reflects the source mailbox after the effect of the MOVE
|
|
> or UID MOVE. Example:
|
|
> tag MOVE 2:5 test
|
|
> * 2 EXPUNGE
|
|
> tag OK [MOVEUID 48394733 3345:3348] all moved
|
|
> The message that was expunged was the former message 6.
|
|
> If this was a UID MOVE command, the client would not know
|
|
> what message got expunged without having a UID/sequence
|
|
> map.
|
|
If you look at a move as a macro form of copy/store/delete, then I think
|
|
that an untagged expunge response should fall under the ambiguity rule
|
|
of RFC3501 section 5.5. and should not be allowed.
|
|
|
|
A per message response would remove the ambiguity.
|
|
|
|
>
|
|
> All other sessions which have the source mailbox open
|
|
> will receive untagged EXPUNGE responses at the next
|
|
> permitted point in the session (RFC 3501, section 7.4.1).
|
|
> This means that there is an intermediate state in which
|
|
> the messages exist in both source and target, that exists
|
|
> only in sessions which have the source mailbox open at
|
|
> the time of the MOVE.
|
|
>
|
|
No argument.
|
|
> This all creates quite a few requirements on a server. But the point is
|
|
> the benefit to the client: the saving of RTTs. It is not to create a
|
|
> chatty kludge for certain mail stores that presupposes that the client
|
|
> doesn't care that it can get halfway and be unable to move forward or
|
|
> back.
|
|
>
|
|
I don't think it's a kludge, and I don't think it's only a benefit to a
|
|
client by
|
|
saving RTTs. I think it puts message management more in
|
|
line with the way a user would think it should work.
|
|
|
|
Most clients I've tried have a Move command. When I move a message
|
|
to a new folder, the client does a copy and store, leaving the expunge for
|
|
later. The result is I still have the message in the folder I just
|
|
tried to
|
|
"move" it out of. The client indicates that it's deleted in some
|
|
fashion, but
|
|
it's still noise in my message list. When I tell the client to move a
|
|
message
|
|
I want it moved now, not partially moved and finished later.
|
|
|
|
> If you agree to ALL of the above conditions, then I will drop my
|
|
> objections.
|
|
>
|
|
> -- 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.
|
|
-------------- next part --------------
|
|
An HTML attachment was scrubbed...
|
|
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20100615/2697b137/attachment.html>
|