Thanks to Chris Newman for scribing in Jabber. Some editorial changes were made by Alexey Melnikov. Agenda slide in WG Chair's Presentation Cyrus: priority is base spec revision Chairs: Any other issues for agenda? Moving on to the WG status slide Approved: vacation, variables, relational update. All documents blocked on 3028bis, which in its turn blocked on comparators. Completed: spamtest update, IMAP flags, edit header. Will be sent to our new AD (Lisa) shortly. Minor issues: body draft. Others: 3028bis, subaddress, date, loop, notifications, refuse, regex Cyrus presents spamtest-bis draft. Review comment: should we keep both scales (1-10 and percentage) or have only one scale? Alexey: want to keep both, as spamtestplus is not yet deployed. Will re-evaluate when moving document to Draft standard, Ned: we've implemented the percentage model Date draft status: no progress, as Ned didn't have time to update it. Ned: two issues: need to add day of week, use modified julian day. Will add both. Now is a good time to send any additional issues to Ned. Ned: hopes to have new revision of spec by March 31st. Alexey: Should this be a WG draft? Personally in favor. Ken talks about subaddress draft. Last remaining issue: how flexible should address parsing/splitting be? Ken: need a concrete example Alexey: will email Ken with example Ned: fine line between subaddress type stuff, but no for VERP or other encoding mechanisms Ned: want to let it work with any local subaddressing conventions (not just prefix/suffix), no matter how obscure. Chris: EAI WG will use punycode form of local parts, subaddress can help with decoding them. Ken talks about regexp draft. Open issues: what to do with localization/internationalization? Ken: the document needs work, in particular some feedback from Ned. The milestone for regex will be pushed out. Alexey talks about reject/refuse draft. Open issues: how to deal with non-ASCII reason when not possible via SMTP. Cyrus: EAI WG isn't going to i18n SMTP error messages in present plan Alexey: can revive old draft for SMTP i18n error messages Ned/Chris: good idea. Cyrus: case where this will fail if move script from one environment to another which changes the nature of the refuse handling. Alexey: can't know in advance if rejection text contains non-ASCII - the script might be using variables. Open issue 2: reject interaction with editheader? Edit header requires bounce of edited text. Is that too strong? Ned: this makes us nervous. Perhaps we should do the opposite. Barry: concur Straw poll: who is in favor of changing editheader to say that reject SHOULD/MUST return original? Rough consensus to return original message Question: SHOULD vs. MUST? Barry: would rather have MUST. Generally doesn't like SHOULD. Dave Cridland (remotely): concur Barry: should note about making changes via editheader and then bouncing due to match caused by the change. Open issue 3: vacation text on i18n implies that might be useful to add :mime tag for case where DSN/MDN is generated. Question: Good idea, bad idea, don't care? Room: silence Ned: Easy to implement, but hasn't seen much use of :mime tag in vacation. Alexey: Will not add :mime to reject until somebody really wants it. This can be added as an extension later on anyway. Alexey: will post message to mailing list asking for feedback. Tony talks about MIME Loops draft. Open issue 1: how to deal with nested loops? Open issue 2: shorthand to get to MIME type/subtype was a suggestion. Cyrus: would like examples other than spam/virus Cyrus: ability to extract part for notification -- e.g. to extract calendar part Ned: has usual objection to the way MIME tests are done. But the draft does not have way to do address tests or MIME header existence test. Philip (remotely): a mimeparameter test would be useful in some cases too Ned: do like way draft separates do the test from ability to modify the body (the latter might be difficult to implement for Sun). Ned: agrees about mime parameter Alexey/Barry talk about Sieve Notifications Draft Open issue 1: need way to extract message body, as body extension specifically disallows extraction with variables extension. Cyrus: overlaps with loop comment about extracting body part Barry: might want way to extract first text part Ned: extraction of textual data from message is very sticky. Issue with using notifications to extract information from classified to unclassified net. Open issue 2: should we push the question of error recover to the individual methods? Alexey: should add section describing requirements on notification methods. That would be a requirement for that section. Barry: not a bad idea No objection from the room Open issue 3: priority vs. importance? Philip: so it's a transport thing, not a contents thing? Barry: Field means how important is it that the notification be delivered and be delivered quicker or slower / more or less intrusive Barry: how we change the name and specify what to do with it? Alexey: also an issue with how many levels. Barry: thinks high / medium / low is sufficient. Ned: thinks 3 priorities is fine. Cautionary tale about X.400 priorities and broken timeouts for high priority messages. Open issue 4: script can generate multiple notifications. Add text about suppression of identical notifications, or is this too mechanism specific? Alexey: I now think this is too mechanism specific Open issue 5: should there be mandatory to implement (mailto:)? We say there must be a default mechanism. Barry: believes we should not mandate a specific mechanism. Barry: asks Lisa directly. Ned: issues with notification with entire message attached causing loops and bouncing. Need cautionary text: don't use this as a crappy form of redirect. Cyrus: do you want message extraction as another option? Ned: conflicting requirements from customers. Some want it disabled forever. Others insist on the feature. Barry: On redirect: keeping a semantic difference between redirect and notify. Ned: agrees. there are times when redirect is the wrong tool and notify should be used. Alexey: anything for the base spec about redirect/notify? Barry: perhaps warning to avoid misuse of redirect. something brief. Moving on to the second slide on Sieve Notifications. The slide contains authors "todo" list: ToDo 1: need to bring back and update old example using denotify. We are not reviving denotify, but examples are useful. ToDo 2: change tagged :method to the positional parameter. Already broke backwards compatibility so might as well do this. Philip: can we please change the extension name in this case. Barry: yes. ToDo 3: Add :from to the "notify" action Barry talks about mailto notification draft: Barry: got really little comment on the list Barry: will wait for notify 03 before iterating mailto and others Cyrus presents 3028bis issues: 3028bis-06 version has been released (also -08 version of comparator draft) Cyrus: anyone read both drafts and interaction between the two? Alexey: not enough people in room have reviewed. Barry: will read and comment on the list. Open issues with base spec: Open issue 1: merge reject back in with textual changes to permit MDNs and protocol level rejection? Cyrus: suggest we don't do that. Open issue 2: map UTF-8 to mUTF-7 when working with an IMAP store? Philip: for bullet 2: any comments on Michael Haardt's suggested text? continue on list... Ned: doesn't think requirement in this area is appropriate as mUTF-7 is only a "convention" in the IMAP base spec. However it's important to point out mUTF-7 as a convention. Ned: SHOULD map to appropriate naming scheme. BTW, the one for IMAP is mUTF-7. Alexey: Ned's agreeing with what Alexey posted on mailing list. Open issue 3: IANA template not precisely defined. Cyrus: bringing up base spec on his display Cyrus: current registration has "capability name", "capability keyword", "capability arguments" Cyrus: odd because a capability might be defining a test, new parameters, etc. Philip: the published extensions in other RFCs ignore the "arguments" field and always set the name and keyword to the same Philip: we've always set name == keyword Barry: Capability Name is what we call it. Capability keyword is what we put in requires Barry: not sure what "capability arguments" is. Alexey: arguments doesn't make sense with multiple commands, etc. Ned: suggests list of new tests and actions in place of capability arguments Chris: suggest just removing arguments Cyrus: we may need to register language tokens to avoid collisions Dave Cridland: Something for Cyrus: Actions can be claimed by two capabilities. Generally when they're backwards compatible updates. Ned: just leave this to the editor Ned: as long as you're backed up by an RFC which says what to do IANA will do it. So we can just clean up the registry. Alexey talks about ManageSIEVE protocol draft: Make this a WG item? Seems like Lemonade needs it, even thought it is still not clear what state of this draft is in lemonade WG. But getting close for it to be done and needs more reviews. Alexey: volunteered Barry to review. Barry: wants to add this to the WG. Ned: will need charter revision to do this. Ned: agrees OK to add this to charter. Lisa: managesieve sounds pretty useful. Cyrus: charter updates need to go through full IESG? Alexey: need to push base spec before adding Manage Sieve to the charter. Q: How many people will implement manage sieve? Dave Cridland: I've vaguely planned on doing the ACAP Sieve stuff at some point, just because I can. A: one wavy hand in room + Dave Cridland, Alexey. Q: How many people in the room do something else? A: one implementation (Sun's implementation store pieces of Sieve scripts in LDAP) Ned: fine for per-user, but not fine when scope broader. Ned: we would just put manage Sieve front-end on LDAP. Philip: we store scripts in LDAP with a provided GUI Alexandros Vellis (remotely): I find ManageSieve essential in that it provides a) capability keywords b) syntax checking Rob: Regardless of what lemonade ends up doing, this is probably desirable, I'm not convinced that extensions to managesieve are the right thing for lemonade's problems though Cyrus: show of hands for manage sieve as WG item? A couple of hands and nobody opposed. Cyrus: will add date as well at the same time. Alexey: will push out base first, however. Randy: The ACAP Sieve dataset provided syntax checking too ;-) Cyrus talks about his "include" draft: Open issue 1: are variables global to all scripts or local to script? Cyrus: punting on issue, no comments on scoping in draft. Cyrus: is "implementation dependent" OK? Poll: who interested in include? Two hands Ned: given our methodology to store Sieve, we can't implement include in a meaningful way. Likes idea, but we can't get there. Chris: Store Sieve scripts in mailbox annotations, define URL for ANNOTATEMORE :-). Open issue 2: interaction with variables (variable scope) Open issue 3: scope of require statements Jeffrey: all scripts are self contained, so they must have all necessary require statements just for themselves. Philip: an included script can defined a set of "functions" (currently there is no such construct in Sieve) Jeffrey: useful case for something that's not a useful sieve script in it's own right. But it doesn't have to fail the require test. Barry: each script needs to be syntactically valid on its own. Barry: don't require "require" for the outer script when including the inner script. : no need for the included (inner) script to include require from the including (outer) script or vice versa Dave Cridland: Could one use: require "include:some-file" To ensure that the requires are checkable easily? Cyrus: what do we want to do with this draft now? Cyrus: may be more interest in near future than we have right now. Cyrus: propose keeping this as individual submission for now, but see where we are in a couple months. [room: nodding heads] Next topic: exception handling &optional "require" Q: do we need some form of exception handling in SIEVE? Q: should there be a test for the presence of extensions? Alexey: if reject action fails because UTF-8 is not allowed, do we want to catch that and do something else? Barry: we had discussion about environment tests. Ned: Yes, we had agreed Barry would write draft to add environment tests. Barry: yes there should be test for presence of tests. Jeffrey: thinks that the two bullets are very different issues. Jeffrey: the problem with test for presence of extension is they add new syntax to language. Ned: No. Key design feature of Sieve is that extensions don't change syntax. Alexey: ...at least so far Jeffrey: not clear we need exception handling. We have exception handling today: if there's a runtime error processing stops. Ned: hard for our implementation, but still in favor of proposal for feature tests. But exception handling makes Ned very nervous, would prefer we avoid that. Cyrus: alternative to exception handling: would like error reporting (e.g. if scripts fails, send notification to ...) Ned: that's a very limited form of exception handling. Jeffrey: if sufficiently limited, it's OK Barry: is that really an interoperability issue? Or can we leave that to the implementation. Do we really have to standardize that? Philip: who gets to control error reporting - the admin or the user? Ned: do you just send an error to the user? Barry: nods. Ned: that's what we do too. Philip: ours is similar with options to tweak where the email gets sent Cyrus: do you have a tracing feature? Ned: not yet. Majority of errors so far are syntax errors. Barry: just put the line of the sieve script which failed. Barry: maybe we should just put advice in the spec or leave it up to the implementation. Jeffrey: SHOULD as long as we're not specific about what the notification is. Randy: My Sieve implementation has tracing, but only admin can control. It's great for my own use but would suck for casual users. Never had time to update it. Alexey: something we forgot. What is the state of "envelope auth" document? Ned: not written yet. Barry: do we want it in base spec or environment? Ned/Philip: don't put it in the base spec. Put it in environment spec. Barry: will roll this into environment draft. Barry: are we going to add environment draft to the WG? Cyrus: publish individual submission and if it's before the anticipated charter change, we'll go from there. Cyrus/Alexey talking about updating Sieve WG milestones. Are new dates reasonable? Need feedback from document authors. Cyrus: 3028bis for May. What's up for comparator? Alexey: Comparator has been through 4 week last call, but several major comments. One revision done fixed several comments, but add few more. Lisa: Comparator will be last called in imapext. Lisa: agreed to shephard document. Ned: Mark Davis's comments ran to 10 pages on this. Lisa: might not be ready to shephard this until it's been through more comments. But it's an important document. Alexey: do you want to push this to somebody else to shephard the document? I am willing to do that. Lisa: thought IMAPEXT agreed to take document and therefore shephard it. Jeffrey: somebody, not the document editor, needs to make sure issues are addressed. Lisa: any volunteers for doing a sanity check? Alexey: reluctantly volunteering for this. Ned: will try to take a look at it. Cyrus: do we want another last call on 3028bis Lisa: anyone want another WG last call for 3028bis? Room: no Cyrus: regexp draft to june Cyrus: subaddress done Cyrus: imapflags, will go to IESG this month Cyrus: push refuse to July? Uncomfortable doing this because it was originally part of the base spec. Alexey: would rather beat milestone Cyrus: Jul/Jun regexp, loop, notification action Philip: MIME loop in June seems quick to me Jeffrey: given that not-loop part of loop extension has lot of issues, Phillip's point sounds right. Cyrus: Ok, will push loop to august Cyrus: may still have i18n issues with regexp, but see how it goes. Cyrus: 3028bis interop report. Want to move to draft. Need to start work in aug timeframe. Jeffrey: how much work has been done on interoperability report for Sieve? If two implementations never talk to each other, how does this work? Jeffrey: thinks August is ambitious Barry: clear what it means, not clear how to determine success. Barry: can take script from one server to another and "it will do same thing", but that's not quite right. Ned: interop testing: we have had previous examples of strangeness in this area, so we can expect some leeway. Example is ABNF document. IESG wouldn't make it BCP, but did accept report that all ABNF features were used in multiple drafts. Ned: thinks this is a case to request an exception to the normative reference rule to 2822 when moving to draft. Cyrus: comparator draft? Ned: that one we have to wait for. Barry: what is process for moving 2821/2822 to draft? Ned: go whack Pete regarding 2822. Cyrus: may need work to shephard comparator moving to draft as part of Sieve interop. Cyrus: what impact of EAI on Sieve? Philip: we should all be attending EAI and thinking about it Jeffrey: going to be a while before EAI is something we need to refer to from a standards document. Philip: we'll be going for full standard Ned: it's a conundrum if EAI is going experimental. Chris: create EAI Sieve extension (Ned agrees) Jeffrey: there is an issue with downgraded EAI addresses Cyrus: how IDN aware is Sieve?