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

From: [email-masked]
Date: Mon, 10 Sep 2012 14:16:13 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title           : Support for Internet Message Access Protocol (IMAP) Events in Sieve
	Author(s)       : Barry Leiba
	Filename        : draft-ietf-sieve-imap-sieve-08.txt
	Pages           : 23
	Date            : 2012-09-10

Abstract:
   Sieve defines an email filtering language that can, in principle,
   plug into any point in the processing of an email message.  As
   defined in the base specification, it plugs into mail delivery.  This
   document defines how Sieve can plug into points in the IMAP protocol
   where messages are created or changed, adding the option of user-
   defined or installation-defined filtering (or, with Sieve extensions,
   features such as notifications).  Because this requires future Sieve
   extensions to specify their interactions with this one, this document
   updates the base Sieve specification, RFC 5228.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sieve-imap-sieve

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-sieve-imap-sieve-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-sieve-imap-sieve-08

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Stephan Bosch <[email-masked]>
Date: Tue, 11 Sep 2012 10:51:27 +0200

>     updates the base Sieve specification, RFC 5228.

There is no changelog in the document, so I wondered what changed and 
therefore I read it again. Rather than finding out what had changed, I 
noticed a few other things:

#1) The final paragraph of Section 2.1 lists a few IMAP and Sieve 
capabilities for which support is required: IMAP "METADATA" and Sieve 
"environment". I would expect this Section to list all such 
dependencies, but apparently it does not. Section 3.8 adds the Sieve 
imap4flags extension as a requirement. Yet, section 4.5 suggests that it 
is optional again. So what is it?

#2) Section 2.2.2 suggests that there is a MULTIAPPEND command for IMAP. 
There is no such thing: it is an IMAP capability that extends APPEND to 
accept multiple messages at once. I would merge this with the previous 
section:

--
2.2.1. The IMAP APPEND Command

    A message may be added to a mailbox through the IMAP APPEND command.
    In a server that advertises "imapsieve", new messages added in this
    way MUST trigger the execution of a Sieve script, subject to the
    settings defined through Metadata (see Section 2.3.1).

    If the IMAP server supports the IMAP MultiAppend extension [RFC3502],
    multiple messages may be added to a mailbox through a single APPEND
    command.  In a server that advertises "imapsieve", new messages added
    in this way MUST each individually trigger the execution of a Sieve 
script.
--

This also stresses the fact that each individual message triggers the 
Sieve script. At other places in the document MULTIAPPEND is listed as a 
separate command, but there it would suffice to just remove it.

I also gave the issue of useless script triggers, i.e. events that are 
never of interest for the script involved, some more thought. For 
example, I would hate to have my Sieve script executed for each message 
that I read (added \Seen flag) while it doesn't do anything useful with 
that event. Wouldn't it be useful to have a `/shared/imapsieve/cause' 
Metadata item that indicates which causes (the items from Section 7.3.1 
in a space-separated list) should trigger the Sieve script? More 
detailed control could be used to select specific flags that are 
relevant (e.g. in a '/share/imapsieve/changedflags' Metatada item).

Regards,

Stephan.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 13 Sep 2012 15:05:53 -0400

Oy.
These comments are VERY late, and the document has already gone
through IESG approval.  I'll look at them and see what I think we can
address now.

I also have a question for the working group:
In his IESG evaluation review, Robert Sparks has this comment:

<< The environment names live in a global space - other extensions might want to
put a cause into the environment. Would it be worth the pain to scope the name
_this_ extension is adding to this extension ("imapcause" or something like
that)? >>

I think that's a reasonable change, and will change "cause" to
"imapcause", unless there's objection from the WG (and one or two
"That sounds fine." comments would be good).

On Tue, Sep 11, 2012 at 4:51 AM, Stephan Bosch <[email-masked]> wrote:
> There is no changelog in the document, so I wondered what changed

That's why &deity made diffs.  When you go to the tools page:
   http://tools.ietf.org/html/draft-ietf-sieve-imap-sieve
...you can click on "Diff1" if you like strike-out diffs or "Diff2" if
you like side-by-side diffs.  Tools are your friends.

> "environment". I would expect this Section to list all such dependencies,
> but apparently it does not. Section 3.8 adds the Sieve imap4flags extension
> as a requirement. Yet, section 4.5 suggests that it is optional again. So
> what is it?

We made imap4flags required at a fairly late date, and I didn't get
everything changed consistently.  I've fixed that for -09; thanks.

> accept multiple messages at once. I would merge this with the previous

I have added this second paragraph to 2.2.1, eliminated 2.2.2, and
eliminated the other references to a MULTIAPPEND command:

    If the IMAP server also supports the IMAP MultiAppend extension
    <xref target="RFC3502"/>, the APPEND command can create more
    than one message at a time.
    In that case, each message creation is considered a separate
    event, and any applicable Sieve script is called once for each
    message.

> I also gave the issue of useless script triggers, i.e. events that are never
> of interest for the script involved, some more thought. For example, I would
> hate to have my Sieve script executed for each message that I read (added
> \Seen flag) while it doesn't do anything useful with that event. Wouldn't it
> be useful to have a `/shared/imapsieve/cause' Metadata item that indicates
> which causes (the items from Section 7.3.1 in a space-separated list) should
> trigger the Sieve script? More detailed control could be used to select
> specific flags that are relevant (e.g. in a '/share/imapsieve/changedflags'
> Metatada item).

It might, and we considered this, but rejected the complexity.  I
don't think this is the time to reconsider it.

Barry

---

From: Stephan Bosch <[email-masked]>
Date: Thu, 13 Sep 2012 21:25:35 +0200

> through IESG approval.  I'll look at them and see what I think we can

My previous comments were late already and I wonder why I missed these ones.

> "That sounds fine." comments would be good).

That sounds fine.

> you like side-by-side diffs.  Tools are your friends.

Indeed they are; good to know. It's good that I didn't use that though, 
otherwise I would not have made these comments. :)

>      event, and any applicable Sieve script is called once for each

Agreed.

> don't think this is the time to reconsider it.

Yes, I agree. This document is too far along. I'll remember this for a 
future revision/extension.

Regards,

Stephan.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 13 Sep 2012 15:32:34 -0400

> My previous comments were late already and I wonder why I missed these ones.

It happens.  I'll add, for the public record, that your reviews are
always useful, and I'm very happy that you're taking the time to do
them.  Thanks.

Barry

---

From: Aaron Stone <[email-masked]>
Date: Thu, 13 Sep 2012 13:31:03 -0700

> "That sounds fine." comments would be good).

I don't think we're going to impact any existing implementations with
this change, so it sounds fine to me.

> _______________________________________________
> sieve mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sieve

---

From: [email-masked]
Date: Thu, 13 Sep 2012 19:13:42 -0700 (PDT)

> "That sounds fine." comments would be good).

I agree it's a reasonable change. However, RFC 5183 states:

4.3. IANA Registration of Environment Items

   A registry of environment items is provided by IANA.  Item names may
   be registered on a first-come, first-served basis.

   Groups of items defined in a standards track or experimental RFC MAY
   choose to use a common name prefix of the form "name.", where "name"
   is a string that identifies the group of related items.

I would therefore suggest "imap.cause".

> don't think this is the time to reconsider it.

Although I still like the general idea, I agree now is not the time to
reconsider.

				Ned

---

From: [email-masked]
Date: Thu, 13 Sep 2012 19:42:59 -0700 (PDT)

> always useful, and I'm very happy that you're taking the time to do

I emphatically agree.

				Ned

---

From: Stephan Bosch <[email-masked]>
Date: Fri, 14 Sep 2012 09:22:52 +0200

> I would therefore suggest "imap.cause".

Good point.

Two others have an "imap" prefix too, so those should then become 
"imap.user" and "imap.email". For consistency, I'd also make 
"imap.changedflags" and "imap.mailbox".

Regards,

Stephan.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 14 Sep 2012 08:48:54 -0400

Ned says...
> I would therefore suggest "imap.cause".

Stephan says...
> "imap.changedflags" and "imap.mailbox".

So let it be written; so let it be done!

Barry