Last Modified: 2005-10-11
|Done||Submit revised variables draft.|
|Done||Submit revised vacation draft.|
|Done||WG last call for variables draft.|
|Done||Initial submission of RFC 3028bis.|
|Done||WG last call for RFC 3028bis.|
|Done||Initial submission of revised relational draft.|
|Done||Initial submission of revised subaddress draft.|
|Done||Initial submission of revised spamtest/virustest draft.|
|Done||Submit revised editheader draft.|
|Done||Submit revised imapflags draft.|
|Done||WG last call of revised subaddress draft.|
|Done||Submit revised body test draft.|
|Done||WG last call for editheader draft.|
|Done||Submit revised reject before delivery draft.|
|Done||WG last call for body test draft.|
|Aug 2005||Submit editheader draft to IESG|
|Done||WG last call for refuse draft|
|Done||WG last call of revised spamtest draft|
|Done||Submit variables draft to IESG|
|Sep 2005||Submit revised loop draft|
|Sep 2005||Submit revised spamtest draft to IESG|
|Sep 2005||Submit 3028bis to IESG|
|Done||Submit revised notification action draft|
|Done||WG last call of revised relational draft|
|Done||WG last call for imap-flags draft|
|Done||WG last call for vacation draft|
|Oct 2005||Submit revised regex draft|
|Oct 2005||WG last call of revised subaddress draft|
|Oct 2005||Submit revised relational draft to IESG|
|Oct 2005||Submit imapflags draft to IESG|
|Oct 2005||Submit refuse draft to IESG|
|Oct 2005||Submit vacation draft to IESG|
|Nov 2005||Submit revised subaddress draft to IESG|
|Nov 2005||Submit body test draft to IESG|
|Nov 2005||3028bis interop report|
|Nov 2005||WG last call of regex subaddress draft|
|Nov 2005||WG last call for loop draft|
|Nov 2005||WG last call for notification action draft|
|Jan 2006||Submit loop draft to IESG|
|Jan 2006||Submit regex action draft to IESG|
|Feb 2006||Submit notification action draft to IESG|
Scott Hollenbeck has asked what was the resolution on "multiple executed vacation actions in a script". Alexey has replied that after a long discussion on the mailing list there was no change in the behaviour of the vacation action.
Spamtest, imap flags, relational extensions are ready for IESG writeup.
Edit header needs to say something about stripping leading/trailing spaces, but it is done otherwise. Barry has mentioned that the relational draft got bounced by Internet Draft editor, resubmitted.
The body draft is waiting for resolution on comparators in the base document, but otherwise is done. Once comparator issues are addressed, the body can be revised in a couple of days.
IESG has raised a discuss comment on Sieve variables: ":lower" and ":upper" were underspecified, the vague text about using comparators is not good enough to implement. Two ways to solve the issue:
a). just say that :lower and :upper only affect US-ASCII subset, other characters are not affected;
b). do stringprep like approach (full Unicode).
Several people are in favour of US-ASCII-only approach, which is perceived to be quicker and will satisfy IESG. 6 people in the room are in favour of US-ASCII-only approach, plus some more in jabber. No people objecting. Need to confirm the decision on the mailing list.
Alexey has expressed his desire to get resolution on comparators by the end of November.
There are several open issues with the base document:
1). ABNF for match types (done)
2). Matching uses glob characters, but is not fully specified in the document. Need to clarify that matching depends on substring operation of collation.
3). Base spec and variables: Clarify that when matching is done then pieces of the original value are returned in match variables, not the result of applying the selected comparator.
4). Stripping leading/trailing whitespaces in the relational draft - text needs to be moved to the base spec.
Short discussion about Barry's proposal to string leading/trailing whitespaces any time a header field is touched. No objections from people who've seen the new text (Alexey, Philip). Barry will send the text to the mailing list.
Philip has promised a new revision of base document by November 18th.
Alexey has talked about the notification draft. Received many comments, much more than expected :-). Separate documents will be created for different Sieve notification methods.
Alexey & Barry will co-edit the main notification document. Barry & Michael will co-edit SMTP notification draft. Alexey will do XMPP, but need a co-editor. Peter Saint-Andre has agreed to co-edit. No editor for SMS notifications, but Stephane might be working on the drafts.
Discussion about SMS has followed: what does it mean to implement SMS notifications, what kind of payload is used (do we need multiple different ones?), what kind of parameters are needed, how payload is generated and delivered, etc. Ray Cromwell has mentioned that there are a lot of requests to limit number of SMS generated per day, in order to limit cost. Discussion on whether URIs are the best way to specify notification methods and whether a generic Lemonade notification method should be defined. Discussion on complexity of different SMS gateways - different gateways need different parameters, in most cases users of Sieve scripts wouldn't care about such parameters. Consensus from the group that it is too premature to discuss details until we see a first revision of the SMS notification draft.
A detailed discussion about current issues in the base Sieve Notifications document has followed. Alexey has presented open issues.
1) Many people have requested to remove "denotify", it will be removed in the next revision, as there were no requests to keep it.
2) Comments from Jabber that "mailto" should be a mandatory to implement notification method, as Sieve engines already able to send mail.
3) Need a way to extract textual message body. Kjetil's suggestion will not work, as "body" extension explicitly prohibits setting variables on body test. Barry has mentioned that we need the ability to send the whole body as well as first starting bytes.
Alexey has asked Philip if "body" can be changed to relax the restriction? Philip said "no", "body" is already widely deployed. If body extraction is only useful for Sieve notification, we can add it to the Sieve notifications document. Otherwise we need a separate extension. Decision to bring the issue to the mailing list.
4) Can notification method parameter be optional (i.e. if not present - use site specific default. If no default - noop)?
Barry: keep it optional; if there is no default - "notify" action is a noop. No objections from the room.
5) What should happen if an unrecognized notification method is specified in the "notify" action? Error or ignored?
Alexey: scripts can't have "require" statements for notification methods, because a notification method can be specified as a variable, who's value can be obtained from an external service.
Do we need to add a test "if a notification method is available"? One use case is when notification method is stored as an IMAP server annotation. Agreement to add the test.
Once the room has agreed to add the test for available notification methods, the room has reached the agreement to make an unrecognised notification method an error.
Cyrus (in Jabber) suggested to add ManageSieve protocol capability to advertise supported notification methods. The room agrees.
Cyrus suggested Sieve presence extension, so notification types can be customized based on presence and time of day. (The latter is already possible using Ned's time extension).
6) Add :from to the "notify" action? It is useful for all envisioned notification mechanisms, but it might not be generally useful. However a notification method is free to ignore the parameter. No objection from the room.
7) Ned (in Jabber) is bringing another issue: URI formats need URI "percent encoding" for different values, inserting variables into an URI will not work. He would like to avoid options, but can't see a way to do without them.
8) Do we want to allow suppression of identical notifications?
Greg: the answer might depend on whether we need to provide confidentiality. No consensus was reached, so the discussion should continue of the mailing list.
Discussion about status of refuse/reject. Most people don't know the difference between MDNs, DSNs and protocol-level-refusal. Would script writer really care? Consensus from the room that script writers wouldn't care, so refuse and reject can be merged into a single action ("reject"). Confirm the decision on the mailing list.
Cyrus has pointed out that sysadmins care about protocol-level refusals versa DSNs, however the draft is already recommending protocol level refusals whenever possible.
Cyrus said that non-ascii text in the reject action can't be sent as a protocol level refusal. Ned added that if non-ascii text results in DSNs, sysadmins will disallow users to use the reject action. The draft needs more work in this area.
Alexey and Philip will discuss if it make sense to put the new reject back into the base Sieve document.
WG has covered the main agenda items. Barry will publish a new individual submission that describes how Sieve can be executed in IMAP store on different events, such as flag changes, message deletion, etc. He believes that this will require a small extension to Sieve and a detailed description on how this would work on IMAP side.
Discussion of the main documents has concluded, so the room has discussed other Sieve related issues.
Nobody wanted to talk about index or include extensions.
Cyrus will address scoping issue and he hopes that this is going to be independent of the variables draft, i.e. it will be an extension to variables.
Philip has promised a new revision of the base document on November 18th.
Dave Cridland (in jabber) has asked about outcome of the comparator discussion. Philip did a quick review of the discussion that happened during the IMAPEXT meeting few days earlier. Match type is built on comparator's substring matching. <?> matches a single character as defined by the comparator (e.g. octet or sequence of UTF-8 octets corresponding to a single Unicode character).
Alexey has asked the WG and IMAPEXT chairs if the collation (comparator) draft should be done in the Sieve WG, as it is moving much faster than IMAPEXT. The answer was no, as most people are participating in both working groups. Chairs of both WGs should nag authors of the collation draft to move it forward quicker.
Variables need to be updated to say that matching with glob characters returns pieces of the original string, i.e. before any comparator was applied. Alexey wants to send the variables document back to IESG asap.