I think we really need to focus on keeping the base spec simple, and
compatible with IMAP and ACAP. The simplest way to store the filters in
ACAP would be as one attribute, in the user's options dataset. That would
give you the explicit ordering you want, but would make it a bit difficult
for some clients to deal with very long sets of filters. The other
approach I see is to store each filter rule in its own attribute. Ordering
could be enforced by an extra attribute (execute-order) which would contain
a number.
If anything, they should be in one dataset with 'sieve-filter' or some
variant
as the name. If we have to do individual entries for individual rules, any
sense of ordering or inclusion would become increasingly difficult. Even
if we keep such elements out of a first draft, you don't want to preclude
them from a future draft.
I'd go along with either approach. Personally, I think having each rule in
its own attribute is easier to manage, but it's not something I feel very
strongly about.
Here is what I think we need to get server-based filtering moving along:
(1) A very simple filter language. Minimal functionality, easy to
implement, with an extension mechanism.
(2) A spec for how to store filters in ACAP. If all of a user's filters
are stored in one attribute, it seems kind of silly to have a whole dataset
for it, but I don't really care that much.
(3) A spec for how and when filters are to be executed, and what to do in
case of errors, unrecognized elements, etc. Also, how to notify users of
the filter results (if such notification is desired). Plus, how a delivery
entity advertises support of filter extensions. It seems to me that any
unrecognized filter should result in default action (file in inbox).
Simple mail messages could be used for notification. An IMAP CAPABILITY
keyword seems to make sense for advertising support of filtering (and
filter extensions), but does tend to blur the lines between the protocols a
bit. But it seems the most logical place to start.