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

[[e-mail]]

> << 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).

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".

> > #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?

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

>     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.

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

				Ned