For the former: the lemonade extension adds a reserved variable which
I'm currently calling "IMAPSieve.cause". Its value is the action
that caused the script to be run ("APPEND", "COPY", and so on). It
occurs to me that it'll be awkward for scripts to have to wonder
what the absence of that variable means. Wouldn't it be a good idea
to have a reserved namespace called "Sieve.", and to have a variable
called "Sieve.cause" that's ALWAYS available if variables are
supported? In the normal case, its value would be "DELIVERY", and
extensions like mine can specify other values. (This might also add
an IANA item....)
okay, so you think this namespace should be defined in the variables
draft? I'm not too wild with the idea, since I really wanted -08
which I submitted yesterday to finally reach RFC status.
Oh, well. So it can be the -09 version that does; is that such a big
deal?
Frankly, yes. We need to finish up this spec and get it out the door. The list
of potential additions of this general sort is for all intents and purposes
infinite.
I would expect the
extension to be required by anyone wanting to inspect that variable,
and so I don't see much benefit to making it a globally available
variable.
The problem is that when a script is written to ask "Why did I get
called?", it will have to assume that if it doesn't know, it's because
it got called by "mail delivery". Since we're at a point where we
could get that modified in the variables draft now, I think we should.
I'm dubious about the notion that there will be lots of scripts intended to be
run in a variety of different contexts that need to test this sort of thing.
However, I have no objection to making such a test available, although I think
the right way to do it is as a separate extension and test, not as a magic
variable. For one thing, this means that in order for such a test to work you
have to have the variables extension, and I worry that variables may not be
implemented or enabled in some performance-sensitive environments.
So I'm suggesting that the variables spec define a base namespace (I'm
suggesting "Sieve."). And I'm suggesting that the variables spec
define a variable that MUST be set (I'm suggesting "Sieve.cause",
"place" seems to me to be a more natural name for this, but I'm not wedded
to any particular term either.
but
I'm not particular about the name) that gives the reason the script was
called. I'm suggesting that the value for mail delivery be "DELIVERY".
And I'm suggesting that the variables spec say that other extensions
may add other values, if they create other causes for having Sieve
scripts called. It seems a simple change, and a useful one in the long
run.
I don't necessarily see running sieves in different environments as
necessitating additional extensions. It seems to me a simple "places" registry
would be sufficient. And it probably should allow for vendor-supplied places
since I suspect there will be non-standard uses of sieve. (In fact I know there
will be because we already have two in our product and another two are
planned.)
I also think additional environmental information might be useful to provide
to script. Indeed, I suspect that knowing, say, the name of the system you're
running on might be even more useful to scripts than being able to distinguish
between delivery and other places sieves are used.
I would therefore suggest an extension specifying an "environment" test as a
better approach. I suspect we can come up with half a dozen things such a test
could operate on.
Ned