> << 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
[email protected]
https://www.ietf.org/mailman/listinfo/sieve
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.