<< 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
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve