Hi,
On 6/20/2011 5:07 PM, Cyrus Daboo wrote:
> Next question: does anyone have any new SIEVE work they would like to
> propose at this time?
>
> I don't think anyone can deny this WG has been successful over the
> years in addressing the needs of SIEVE implementations, even if at our
> own, sometimes slow, pace. Shutting it down now would not be
> unreasonable, but I think we do need to prove the utility of keeping
> it alive. So please chime in with your thoughts.
>
There is one thing I've noticed: the more user-friendly GUIs and web
interfaces allow users to edit Sieve scripts as a set of intuitive
(structurally pre-defined) mail filter rules. This avoids the need to
learn Sieve and write detailed Sieve scripts directly, which can be
daunting for the less capable mail user. However, Sieve has no real
concept of a `mail filter rule', so a translation is necessary from the
rules defined in the editor and the Sieve script on the server. Also, a
convention is to name the mail filters to provide an indication of their
purpose. Other forms of such metadata are imaginable, such as creation
date, name of the creating software etc.
The base Sieve language may not have these constructs (and IMO should not), but
that doesn't mean they haven't been defined. See RFC 5784.
The problem is that such data needs to be stored somewhere. Some
solutions involve storing the metadata along with the rules themselves
in a database or another form of storage external to Sieve. The Sieve
script is then created from this storage once the rules change. On the
one hand, this avoids the complexity of parsing Sieve scripts to regain
access to the original rules and metadata, but, on the other hand, it
completely blocks using multiple different interfaces for editing the
same Sieve scripts. Direct changes to the Sieve scripts would simply be
lost once the rules change.
Alternatively, some script generators encode such metadata in Sieve
comments and parse the Sieve script itself to extract the rules.
This is the approach taken in RFC 5784. Note that the format is defined for
both the XML form and native form of Sieve, as well as the rules for converting
between the two.
This
way, the Sieve script itself is the only means of storage,
theoretically allowing multiple distinct Sieve generators (GUIs and web
interfaces) to inter-operate with the same Sieve scripts. Unfortunately,
I've seen little or no coordination between the script generator
authors, which probably means that scripts generated by one interface
cannot be edited through an alternative one, mostly because the encoded
comments are going to be incompatible.
Yes, this is a problem, and it partially addressed in RFC 5784: Structuring
conventions are defined so that at least the basic rule structure can be
shared. But sharing of specific rule semantics is a lot trickier.
Of course, the Sieve code itself
can also be incompatible if the Sieve generators don't support the same
set of Sieve features or if some code structure is not recognized.
However, I think this could be mended quite easily by presenting rules
that cannot be handled by the GUI itself as custom or external; not to
be touched by that particular interface.
RFC 5463 provides some solutions for these issues.
Ned
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve