I would like to see the Sieve language provide a generalized extension
syntax, which would permit a Sieve parser to
parse a file containing extensions that it didn't necessarily support.
This seems like it would maximise interoperability, and would make
future extensions easier, since their impact on existing implementations
could be more easily assessed.
I propose to add extension functionality as follows. Basically, a
sieve extension is either a test or an action. Both tests
and actions are functions which operate on messages.
test: Message -> {true,false}
action: Message -> {Continue, Stop}
The current grammar for the 'action' statement in Sieve is:
[OLD] action = toss / fileinto / forward / bounce / reply / stop
[OLD] toss = "toss"
[OLD] fileinto = "fileinto" WSP string
[OLD] forward = "forward" WSP address
[OLD] bounce = "bounce" WSP string
[OLD] reply = "reply" WSP string
I would propose to replace this with:
[NEW] action = ATOM *( [WSP] ( string / number ) )
[NEW] ATOM = LETTER *(LETTER / DIGIT / "_" / ".")
Similarly for the 'test' clause, currently spec'ed as:
[OLD] test = [WSP] (any-of / all-of / exists / false / header /
[OLD] not / size) [WSP]
I would propose using:
[NEW] test = [WSP] ATOM (string / string-list) [WSP]
And I would add a statement to the standard like this:
A Sieve implementation MUST interpret unknown extension
tests as always returning false, and unknown actions as
no-ops returning 'Continue'.
The standard could then go on to define a base set of tests and
actions (pretty much what we've got now), in terms of the
expected arguments and semantics, within this more generalized
framework. Some kind of IANA registry could be used to keep
track of various extensions.
I could write all of this up in RFC-speak, but I thought
I'd see what people thought of the basic idea first...
Stan