Re: SIEVE WG Status

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

The main requirement would be that individual rules in the script can be 
annotated with a name and that a parsing GUI can distinguish where rules 
begin and end. A standardized means to achieve this could, in my 
opinion, increase interoperability between Sieve script generators.

However, I have only implemented a Sieve interpreter so far (which 
obviously doesn't care about metadata encoded in comments) and I 
therefore have no experience with Sieve GUIs and web interfaces and the 
complexities involved. I haven't seen much discussion about this subject 
and I am wondering whether this is currently perceived as a concern at 
all. I vaguely remember a short discussion about this in a thread 
related to Sieve in XML, but nothing else.

Are users expected to use only one interface/method for editing their 
(active) scripts? Would it be useful to provide a specification on how 
to encode meta-data in Sieve script comments?

Regards,

Stephan.




_______________________________________________
sieve mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sieve