Any protocol that used sieve to describe filters would have to be
extensible, of course. For example, if IMAP or ACAP or whatever were
extended to allow a user to set up filters, then the client could
attempt to pass a filter that used a certain feature.. A server that
didn't understand that feature might return with a parse error. If
the parse error were specific enough, the client could restate the
filter without using that feature if possible. This could be automated
so that human intervention isn't required.
Hmm, a very interesting idea, indeed.
I had a similar idea of having a more detailed protocol where client
and server could exchange not only capabilities and general parsing
errors, but also ok/no responses on individual lines of filtering
rules. My idea is not very different from the ipfw command in
FreeBSD, if you happen to know about it, although message filtering
will require more sofisticated conditional expressions.
If you keep "require", and make it processed at parse time, and then
make some standard way for a server to report require failures, then
the client could easily use extensions if they are there, and fall back
to more basic constructs if they're not. So, it's extensible.
But then, why would "require" be part of the script?
If you have established a two-way communication to the server,
wouldn't it be better to exchange the requirements, or capabilities,
as part of the protocol and not as part of the script?
Either that have some standard way of describing revisions of
sieve. Then the server could just tell the client what revision it
supports, and the client could form the text accordingly.
No, I don't like the version style.
Versions is something that should be coordinated.
Extensions or capabilities is, at least as I view it, a method to
extend a base spec without the need of coordination. Which I think
was the idea for Sieve.
So I don't think the sieve language itself needs to support an
extension mechanism, necessarily.
To that I can concur. Thank you for pointing out the difference in
this regard between a protocol and a language.
--
Tomas Fasth