Subject: draft-ietf-sieve-variables-07

From: Barry Leiba <[email-masked]>
Date: Mon, 19 Dec 2005 00:22:34 -0500

I've just written, as promised, a lemonade draft describing an
extension to IMAP and Sieve (draft-ietf-lemonade-imap-sieve-00, just
submitted as an I-D, and just posted to [email-masked]).  In writing
that, I've come up with a requirement for the variables extension, and
an editorial comment about the variables doc.

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

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.

Barry

--
Barry Leiba, Pervasive Computing Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Mon, 19 Dec 2005 13:28:29 +0100

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

I couldn't find your posting to the lemonade list, but I'm not on it, so
it may be the archiving software acting slow.  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.

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

> namespace attribute?  It's not explained terribly well, and there are

hmm, I would have to invent an extension for the example, I guess.  what
do you think is unclear about the explanation?
-- 
Kjetil T.

---

From: Barry Leiba <[email-masked]>
Date: Mon, 19 Dec 2005 17:45:54 -0500

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

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

> 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

---

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 20 Dec 2005 11:10:02 -0500

On Mon, Dec 19, 2005 at 12:22:34AM -0500, Barry Leiba wrote:
> caused the script to be run ("APPEND", "COPY", and so on).

I have opined in the past that it would be good for a script to be able
to tell what mode it was being executed in.  So I like that part.  Tying
it to the variables extension could be a an issue though, but it's
probably at least as good as any strictly SIEVE alternative.

mm

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 20 Dec 2005 16:34:33 +0000

>scripts called.  It seems a simple change, and a useful one in the long
I agree. If we are to do the change we must do it now.

> [...]
Using Barry's new variable as an example would be fine with me.