Re: [imapext] Pete Resnick's Discuss on draft-ietf-imapmove-command-03: (with DISCUSS and COMMENT)

[Ned Freed <[e-mail]>]

> I'm adding the working group mailing list to this, because I think it
> needs to be aired there.

> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > I have not been following this WG, and I might have the Sieve bit wrong,
> > so I apologize in advance if this issue has been considered and addressed
> > by the WG; if so, I will remove this DISCUSS immediately. But this causes
> > me concern:
> >
> > Section 4.5:
> >
> >    Because MOVE does not cause flags
> >    to be changed, a MOVE command will not result in a script invocation
> >    with the imap.cause set to "FLAG".
> >
> > I think this is either wrong or needs more explanation. Section section
> > 3.3 is clear that doing a move "has the same effect for each message
> > as...[UID] STORE +FLAGS.SILENT \DELETED", which the above seems to
> > contradict. But even this is intended, I would think this would at the
> > very least cause significant user surprise: In a current client, if I
> > choose the "move" command in the UI, I'm going to get an invocation for
> > the COPY on the destination message *and* an invocation for the STORE
> > \DELETED on the source message. You are saying that an upgraded client
> > that starts using "MOVE" for it's "move" command will suddenly stop
> > invoking for the deletion. If you *don't* want Sieve to invoke for the
> > flag change, I think you're going to have to add a new imap.cause of
> > either MOVE or EXPUNGE, and folks will have to go rewrite their scripts.
> > But I would think the easier route would be to get a second invocation
> > from MOVE with imap.cause set to "FLAG".

> There appear to be two points here:

> 1. The MOVE spec is saying that in the end, the MOVE command has the
> same effect as the COPY/STORE/EXPUNGE sequence that clients are doing
> today.  It does NOT mean that the MOVE command is equivalent to that
> sequence in every way, including intermediate states.  It's precisely
> the purpose of making it a single command that we get away from the
> intermediate state problem, and allow servers to optimize a MOVE over
> a COPY/DELETE function.

Yes, and we've been struggling with how to present this from the start.
The fact that Pete misunderstood this suggests that the document still
isn't clear about some aspects of this. (See below for some suggested text.)

> We absolutely do NOT want to make servers present that "\Deleted flag
> is set" state in any context.

Absolutely. Perhaps we need to add something like this before the third
paragraph in section 3.3:

   Although the effect of MOVE is the same as the preceeding steps,
   the intermediate states produced by those steps do not occur. In
   particular, at no time will the \DELETED flag be seen to be set.

> 2. We did discuss, though only very briefly, whether to have a
> separate imapsieve cause for this, and decided that it wasn't worth
> the complexity.  No one has a use case for needing it.  If you do,
> we'd like to hear it..

Specifically, I brought up the idea of a "MOVE" cause. Nobody seemed interested
in it.

> Perhaps there might be a use case if, say, one wanted to use a Sieve
> script to take any message that was being removed from the inbox and
> do "fileinto Archive" on it.  That use case would be marginal now,
> because there's no imapsieve event for expunge (only for the flag
> change on \Deleted), and no way in Sieve to remove a message from
> Archive, so constantly setting and resetting the \Deleted flag,
> without ever expunging, would just cause the message to be repeatedly
> re-filed into Archive.  But anyway, if we accept some use case like
> that, we might need something here.

> But it gets complicated.

> The COPY cause is run against the target mailbox only.  We'd have to
> have a new cause that's run against the source mailbox in *addition*
> to that.  Say, a MOVE (out of) cause that's run against the source
> mailbox's script before the move, and then a COPY (into) cause that's
> run against the target mailbox's script after the move.  And then we'd
> have to ask whether there's a need for a new environment variable to
> name the other mailbox that's involved (we had no use case to do this
> for the COPY cause, so we didn't), because we might want to know where
> it was being moved TO, or where it's being copied FROM, for processing
> in the script.

> As I said, no one wanted the extra complication, and no one had a use
> case for needing it.

Agreed on all points. I'm not especially happy with this result, but I'm
nowhere near convinced that doing something like, say, applying a Sieve to the
source mailbox with a "movefrom" cause then applying a Sieve to the target
mailbox with a "moveto" cause is worth it. I am convinced, however, that
exposing intemediate state, which a "flags" cause absolutely would do, would be
very bad.

I'll also note that Sieve in IMAP has always been a tough nut semantically.
(And this really has little to do with Sieve; the semantics of IMAP weren't
designed with coherent generation of mailbox events in mind.) While I think
we've done a good job on Sieve in IMAP, if usage takes off I have a feeling
we'll need to revisit some of the choices we've made.

> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Section 1:
> >
> > Purely editorial nonsense:
> >
> >    clients have instead had to use a combination of the UID STORE, UID
> >    COPY and EXPUNGE commands to perform this very common operation.
> >
> > Seems to me that you should list the commands without the UID (since
> > they're not required) and in the right order. So instead:
> >
> >    clients have instead had to use a combination of the COPY, STORE,
> >    and EXPUNGE commands to perform this very common operation.
> >
> > And if you have any reason for keeping the original, do so. Just one AD's
> > OCD.

> That's probably an appropriate change -- the UID versions are a
> vestige of the original spec, which ONLY had UID MOVE, and did not
> define a non-UID version.

Agreed. I need to do another revision anyway; this will be in it.

				Ned