ietf-mta-filters
[Top] [All Lists]

Re: draft-ietf-sieve-variables-07

2006-01-10 17:21:51

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

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.

We don't (or at least I don't) know what the actual use cases are
likely to be, so I don't know whether I agree with you or not.  If we
provide a good way to manage multiple scripts, perhaps with an
extension to ManageSieve, it might turn out that people always want to
do different things at the different processing points, and they'll
always use separate scripts for each.  In that case, no, this isn't
necessary.

Or it might be that there are common things that people will want done,
and they'll just occasionally want to test this to do something
different now and then.  In that case, we need this.

Anyway, as the discussion's gone since the note I'm responding to,
there seems to be agreement that this and other identifying stuff would
be useful in an "Environment" extension, or some such.  Really, I
didn't think it needed to be in Variables -- just that Variables seemed
a logical place to put it.  I'm happy to put it in its own extension
that defines some new test, like this (using one of the examples from
the imap-sieve draft):

     require ["copy", "environment"];

     if anyof (environment :is "cause" "APPEND",
               environment :is "cause" "COPY")  {
         if environment :is "mailbox" "ActionItems" {
             redirect :copy "actionitems(_at_)example(_dot_)com";
         }
     }

Note, here, that I've used two "environment" items, called "cause" and
"mailbox".

I agree that I like this better than doing it with variables, and it
means that if the "environment" extension is available, it can specify
the "DELIVERY" cause that I'm asking for.  That satisfies everything.
I'll write up an "Environment" extension draft, if y'all think I
should.  Ned?  Alexey/Cyrus?

I still wonder whether there ought to be a way to test for the presence
of an extension, rather than only to have the choice of *requiring* it
or not using it at all.  I can see a script wanting, for example, to
send a notification IF the Notify extension is available, but not
wanting the script to FAIL if it's 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