Re: Proposed charter change

[Arnt Gulbrandsen <[e-mail]>]

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