Subject: Draft minutes from Vancouver

From: Alexey Melnikov <[email-masked]>
Date: Wed, 23 Nov 2005 19:56:38 +0000

Hi folks,
Below are the draft minutes I've produced from the Jabber logs. (Thanks 
to Tony Hansen for scribing in Jabber!) Please send any comments on 
correctness/completeness. Editorial comments are welcome as well.
=========

The meeting has started with a quick review of documents ready for IESG 
writeup (or nearly ready). The vacation extension has two minor 
outstanding issues: clarification on how hash should be constructed when 
some tagged arguments like :subject are omitted; default auto reply 
subject when the original message had no subject.

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.
 
Regards,
Alexey

---

From: Barry Leiba <[email-masked]>
Date: Wed, 23 Nov 2005 22:21:07 -0500

The minutes look good to me.

Barry

--
Barry Leiba, Pervasive Computing Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 25 Nov 2005 14:08:44 +0000

> The minutes look good to me.

Ok, I've uploaded minutes to the ietf.org site
(<https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=64>)

There is still time to correct them.