Cyrus Daboo writes:
We would like to see a "show of hands" from implementers on each of
the new extensions being proposed so that we can judge the interest
in each.
OK. Other comments also below.
Note that we will need document authors/editors to step up for items
(3) and (4) if we are to include these.
I already have done some work on 4...
The SIEVE email filtering language is specified in RFC 5228, together
with a number of extensions.
The SIEVE working group is being re-chartered to:
(1) Finish work on existing in-progress Working Group documents:
(a) Body (draft-ietf-sieve-body-07.txt)
Have.
(b) Notify mailto (draft-ietf-sieve-notify-mailto.txt)
Unlikely. (We'll do notify and some of its children, but I don't feel
good about notifying about email messages using other email messages,
so mailto isn't an implementation candidate yet.)
(c) Edit header (draft-ietf-sieve-editheader-10.txt)
Very likely.
(d) Mime loops (draft-ietf-sieve-mime-loop-04.txt)
Will do.
(e) Refuse/reject (draft-ietf-sieve-refuse-reject-06.txt)
Have older version, will update. (Have updated? I'd have to check.)
(2) Finalize and publish the following SIEVE extensions as proposed
standards:
(a) Date/Index (draft-freed-sieve-date-index-08.txt)
Have.
(b) iHave (draft-freed-sieve-ihave-01.txt)
Likely.
(c) Environment (draft-freed-sieve-environment-03.txt)
Very likely.
(d) Notary (draft-freed-sieve-notary-01.txt)
Very likely.
(e) SIEVE in XML (draft-freed-sieve-in-xml-01.txt)
Yes or no. We'll do Sieve in XML, but I don't know whether we'll do it
that way. I don't see any reason to do it differently, but if one
appears...
(f) Notify-sip (draft-melnikov-sieve-notify-sip-message-01.txt)
Likely.
(g) ManageSIEVE (draft-martin-managesieve-08.txt)
Have.
(h) RegEx (draft-ietf-sieve-regex-00.txt)
Unlikely.
(j) Meta-data (draft-melnikov-sieve-imapext-metadata-03.txt)
Don't know.
(k) Include/multi-script (draft-daboo-sieve-include-05.txt)
Include is uncertain. (Our code is developing along the lines of Jutta's
expired multiscript document, though, so who knows.)
(k) Address data (draft-melnikov-sieve-external-lists-01)
Uncertain... more likely no than yes.
Additional drafts may be added to this list, but only via a charter
revision. There must also be demonstrable willingness in the SIEVE
development community to actually implement a given extension before
it can be added to this charter.
FWIW, we'll do one other extension, but I think I'll talk more about
that only when we have code.
(3) Work on a "Benefits of SIEVE" guide for client and server vendors that:
(a) Describes the SIEVE protocol and its suite of extensions.
(b) Explains the benefits of server-side filtering in practical terms.
(c) Shows how client-side filtering can be migrated to SIEVE.
Laudable, I'm sure, but my only comment is that I know little about a
little and almost nothing about the rest.
(4) Produce one or more informational RFCs containing a set of test
scripts and test email messages that are to be filtered by the
scripts, and the expected results of that filtering. This will serve
as the basis of a interoperability test suite to help determine the
suitability of moving the base specification and selected extensions
to Draft status.
I did some work on that last summer, which I sent to Barry (and Alexey?
don't remember any more). I'd be willing to continue that on my own.
Arnt