Subject: Re: [sieve] I-D Action: draft-ietf-sieve-imap-sieve-09.txt

From: Stephan Bosch <[email-masked]>
Date: Wed, 10 Oct 2012 22:19:23 +0200

On 9/15/2012 2:33 PM, Barry Leiba wrote:
> It looks like this is the final version that will go to the RFC
> Editor.

Just a question, how are we going to handle the approval of the 
following IMAP extension?

https://tools.ietf.org/html/draft-ietf-imapmove-command-01

Intuitively, I would say that adds a new imap.cause item called "MOVE" 
and I guess at some point this (or something else) would need to be 
documented. Would it still be possible for the editor to hammer it into 
the current yet-to-be-RFC imapsieve document if IMAP MOVE (somehow) 
makes it to RFC first?

Regards,

Stephan.

---

From: Aaron Stone <[email-masked]>
Date: Wed, 10 Oct 2012 13:33:31 -0700

On Wed, Oct 10, 2012 at 1:19 PM, Stephan Bosch <[email-masked]> wrote:
> Just a question, how are we going to handle the approval of the following
> IMAP extension?
>
> Intuitively, I would say that adds a new imap.cause item called "MOVE" and I
> guess at some point this (or something else) would need to be documented.
> Would it still be possible for the editor to hammer it into the current
> yet-to-be-RFC imapsieve document if IMAP MOVE (somehow) makes it to RFC
> first?

IMAP Sieve is already in the Editor's Queue, so it's surely ahead of IMAP MOVE.

IMAP MOVE itself says that the command is equivalent to:
"""
   The UID MOVE command has the same effect as a sequence of UID COPY,
   UID STORE +FLAGS.SILENT \DELETED and UID EXPUNGE ...
"""

One could argue that "copy" is a viable value for imap.cause.

Aaron

---

From: Barry Leiba <[email-masked]>
Date: Wed, 10 Oct 2012 16:45:29 -0400

> IMAP Sieve is already in the Editor's Queue, so it's surely ahead of IMAP MOVE.

Right, and I've addressed this in my AD review of the MOVE extension document:
http://www.ietf.org/mail-archive/web/imapext/current/msg04712.html
------------------------------
-- Section 4 --

Add a new Section:

   4.5.  IMAP Events in Sieve

   MOVE applies to IMAP events in Sieve [reference] in the same way
   as COPY does.  Therefore, MOVE can cause a Sieve script to be
   invoked with the imap.cause set to "COPY".  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".

The [reference] for IMAP Events in Sieve is
draft-ietf-sieve-imap-sieve-09, which should be in the RFC Editor
queue any day now (so it won't hold this document up).
------------------------------

...with follow-up here:
http://www.ietf.org/mail-archive/web/imapext/current/msg04714.html
------------------------------
Ned's comment:
> I think this is the right thing to do, but I have to ask: Given the timing
> of the Sieve in IMAP spec we could define a new "MOVE" cause in the base
> specification if we wanted to. Do we want to do this?

I thought about that when I wrote the above, and I can't find a good
reason to distinguish MOVE from COPY in imap-sieve.  It also wouldn't
be as simple as just defining a new cause: we'd have to decide whether
only the target-mailbox script is run, or whether the source-mailbox
script is run as well.  My sense is that it's not an important
distinction, and we don't want to go there.
------------------------------

Barry

---

From: Stephan Bosch <[email-masked]>
Date: Fri, 12 Oct 2012 13:47:15 +0200

> http://www.ietf.org/mail-archive/web/imapext/current/msg04712.html

I must have missed that one, because I am subscribed to that list.

> distinction, and we don't want to go there.
I agree.

Regards,

Stephan.