[Top] [All Lists]

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

2012-10-10 15:45:36
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

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

Right, and I've addressed this in my AD review of the MOVE extension document:
-- 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:
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.

sieve mailing list

<Prev in Thread] Current Thread [Next in Thread>