Alexey Melnikov wrote:
This message officially starts the Sieve Working Group Last Call for the
following document:
SIEVE Email Filtering: Ihave Extension
<http://www.ietf.org/internet-drafts/draft-freed-sieve-ihave-02.txt>
The Working Group Last Call for this document starts on September 8th
and will end on September 22nd.
I just scanned though this draft specification and, although I like the
potential of this new Sieve feature, I am very worried about the
implementation of all this. The issue described here was already coined
in November of 2006 (e.g.
http://www.imc.org/ietf-mta-filters/mail-archive/msg03315.html), but to
my knowledge it was never discussed further.
I've built a compiler that compiles Sieve scripts into a byte code
representation. I'd like to see this ihave feature work for my
implementation even when the compiler is completely oblivious of the
extensions listed by the ihave test. Given the fact that most extensions
introduce new language elements, the compiler must have some means of
ignoring/discarding the regions of the script that need the obscure
extensions. Alternatively, doing the actual ihave test at runtime
requires that the compiler can distinguish between erroneous language
features and features that would have been introduced by the unknown
extension (in order to produce compile time errors or runtime errors
respectively). This would require knowledge about that obscure extension.
As the document itself indicates, it will be very difficult to 'parse
around' the script regions that depend on the obscure extensions listed
by ihave for two reasons: ihave is a test that can be arbitrarily
combined with other tests using allof/anyof and the extensions activated
by ihave remain active even after the block of the (els)if command has
ended. Now I am wondering why this choice was made. What is the benefit
of being able to write complex conditional expressions with the ihave
test and why not 'scope' the use of the extension within the block it
controls? (Note that these issues are somewhat interdependent).
Both of these problems could for instance be mitigated by introducing
ihave as a control structure instead of a test command, e.g.:
require "ihave";
redirect "copy(_at_)example(_dot_)com";
ihave "fileinto" {
fileinto "INBOX.folder";
}
keep;
Here, the use of the fileinto extension is scoped within the block
controlled by the ihave command and it is invalid outside that block. If
the compiler is completely oblivious of the fileinto extension it can
now safely discard the ihave command and implicitly be rid of all script
regions (in this case the block containing the fileinto command) that
depend on the unknown extension. It thus becomes similar to C's #ifdef
for Sieve compilers that handle ihave at compile time.
The only thing the above sample script omits is a form of 'else' case to
execute when one of the listed extensions is missing. Other solutions
are of course imaginable (more are listed in the posting referenced above).
Regards,
--
Stephan Bosch
s(_dot_)bosch(_at_)rename-it(_dot_)nl