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?
I couldn't find your posting to the lemonade list
Try now. I'm not on the list either, at least not with the address
that I post from (this one), and so my post waited for the moderators
to deal with it.
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.
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", 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.
there is something to be said for making namespaces an IANA item.
currently, it says the namespace SHOULD have the same name as the
extension. this doesn't guarantee uniqueness, but the publishing
process for RFCs should be sufficient to stop that from happening,
Well, since Sieve extensions that define a capability string register
with IANA, if you change SHOULD to MUST, then we should indeed have
uniqueness guaranteed.
IMHO. if we did have a IANA registry for it, we could use more
finegrained delegations, so that one extension could handle Sieve.Foo
and another Sieve.Bar. the benefit seems slight, though.
I agree that I don't see a compelling need for that.
For the latter: Can we please add an example of the use of the
namespace attribute? It's not explained terribly well, and there are
no examples.
hmm, I would have to invent an extension for the example, I guess.
what do you think is unclear about the explanation?
I just think it's useful to have examples of things, and I saw the lack
there. Why not?
Barry
--
Barry Leiba, Pervasive Computing Technology
(leiba(_at_)watson(_dot_)ibm(_dot_)com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam