Thank you to Dave Cridland for being the Jabber scribe this time. Alexey was the only co-chair present this time. He briefly talked about status of different documents (see slides). About half WG docs are in RFC ed queue. Collation document got published as RFC 4790, thanks to Arnt. Base spec was submitted for IESG review. Philip promised to update Sieve body one more time before sending it to IESG for publication. Editheader - need to resolve handling of mail loops. Alexey/Cyrus think that notify extension is basically ready, but needs reviews and feedback on changes. Mailto notification is in WGLC, has some open issues, but not much feedback. Refuse/Reject: Alexey has been too busy recently for an update. The WG briefly talked about Editheader interaction with redirect/reject. Philip replied in jabber that the new text doesn't affect reject, which still requires to return the original headers, as per another paragraph in the document. And he basically agrees with other comments and will do another revision of the draft before sending it to IESG. Alexey talked about recent changes to Notify. No comments or objections were received, so Alexey & Barry think that the document is done. TODO: Dave Cridland & Randy Gellens to do a full review of notify. Barry has presented the Mailto notification draft. He talked about open issues: 1. URI Parameter conflicts with other notify parameters: Do notify parameter Override the URI parameters, is it an Error or something else? Barry likes "Error". Alexey & Michael prefer Override. Alexey is thinking of external URIs being pulled in (perhaps from IMAP METADATA). Barry thinks that Ned might have useful opinion. Philip: I suppose a script can code itself defensively to test the URI before it uses it. Possible, but ugly. Later he added that there were no practical way to test the contents of a URI using just ":matches", one needed regexps to break them down. TODO: Ask Ned for opinion. Unless more people say there opinion, the Override option will prevail. 2. Undesirable URI params: what do we do if a URI specifies unsafe headers? Barry slightly prefer ignoring bad headers. Ted saying the mailto scheme RFC is pretty limited on these points, so Sieve advice and mailto RFC advice would probably be different. 3. Message origin: does the notification message come from the original "RCPT TO", or from the notification system? Alexey pointed out a suggestion to make it an option. Pete asked what the From is for and whether we were going to reply to these messages. Philip: if the notification system can autoprocess bounces, then it belongs in the envelope MAIL FROM Maybe always is better, to block the loop possibility. Dave Cridland: not clear why worry about "from" for notifications: are they to send msgs *to* a user, not necessarily be *from* anyone in particular. Philip/Pete: The important 'from' here is the envelope from. IMHO, the env-from should *never* be the original. No clear consensus on this issue in the room. 4. Body excerpts: "is Barry being silly" for wanting this? Alexey commented that the Sieve Notify used to have body extraction action, which was removed. But it will move to MIME-loops, so he thinks that this is still useful. Dave Crocker said that there was a long history of an excerpt being useful. But it's tricky to get it perfect. Randy was discussing whether the spec ought to say more than "this is a good idea", or should we stipulate down to the last octet. Barry likes the idea of vague specification, with a view that mime-loops and body extraction to a variable would provide a strictly specified method for doing this. Randy: I'm concerned that if we try and standardize it we end up with a sprintf format for how the script specifies how much of the body to use and how it appears. Since that prospect is so scary I urge us to instead say "engine may do this if it wants, it is helpful" Barry commented that this automatic vague excerpt could be the default. TODO: verify consensus for "vague description of body excerpts" in the document. Tony has presented the updated MIME loops document: Open issues: 1. Should enclose throw away modifications? Philip: I think enclose should honor changes. Anyone using enclose to create bounces should be shot. Aaron: why would we *not* want to honor changes? Ted says we can always get unmodified behavior by structuring the script carefully (As in not doing any modifications). Consensus to use the modified version. 2. Should we synthesize Date and From headers to reflect the current user and time? Philip: Is there text that can be stolen from the submission spec? It's kinda like a submission, the creation of a full message from a partial one... Alexey prefer synthesized: the original are still in the enclosed part. Sometimes it is useful to see when the message was created and when it was enclosed. Note from the room about synthesizing new message id. Kjetil and Tony were discussing syntax for extracting key/value pairs from variables). Everybody else except Philip don't have a clue about the discussion, because people haven't read the most recent message from Kjetil on the mailing list. Philip: Kjetil's idea is cute, but they're not much better than simply using a comma separated list, partly because there's no way to quote the value properly when adding it. You can put quotes around it, but that won't handle embedded quotes or backslashes Regexps would be as good (or better), but you can't do the extraction with just :matches. Time for that SQL access extension. General comment from Alexey (as a co-chair): the list of open issues that Tony presented differs from the one from the latest San Diego IETF, and the issues were not addressed. Tony agrees to review the San Diego list. Alexey: Assuming all issues are resolved, MIME loops will be last called in a couple of weeks. Alexey briefly talked about Ned's individual Date-Index Draft. The document has no major issues now, Alexey to shepherd to IESG. Alexey has briefly talked about Ned's Environment & Notary (DSN) extension. Barry/Alexey: the two extensions don't belong to the same document. TODO: Ask Ned to split the draft into 2. Next Alexey presented his draft on "Accessing IMAP per-mailbox annotations from Sieve". Alexey described features of the extension: 1). Ability to test for mailbox existence 2). Ability to create mailbox on fileinto. Without the new :create tag fileinto creates mailboxes in some implementations, but doesn't in others. Some short discussion about Sendmail implementation: it still treats :create as an optional request, which is arguably a bug. Sendmail implements Sieve in SMTP server, so fileinto turns into +detail email address, thus the mailbox creation request might not be honored. Alexey talked about an example: an annotation can be used to turn vacation autoreply on or off. Open issues: 1). Do we want access to server annotations? - Alexey thinks "yes" Chris pointed out that testing server annotations and testing environment are basically the same thing. Barry agreed. Barry commented that there is no namespace-like thing in Environment that might support this. TODO: Talk to Ned about namespaces in Environment. 2). Do we want access to LIST-EXTENDED data? ACLs? - Alexey thinks "maybe" on LIST-EXTENDED data. Philip threatened to lose the breakfast he just ate. Alexey presented a new (not yet written) draft on "Externally stored lists". The basic idea is to be able to store lists of users or email addresses in SQL/LDAP/ACAP/... Such lists can be updated externally, without the need to update Sieve script. The proposal is to extend redirect action and header/envelope tests to reference externally stored lists. Barry showed his Sieve script. It has many email addresses hardcoded, so he would like to have such an extension. Randy said that maybe an external list reference should be via URLs. (The proposal as described had list labels as opaque UTF-8 strings, e.g. "blacklist") Philip agrees. Philip: hmm, how about using imap: URLs to access annotations/metadata in IMAP? Aaron: so, :list "string" is probably a bad name because its confusable with :param ["string", "list"]. And, this would be cool together with variable namespaces: ${external:name} Kjetil suggests that this probably doesn't scale too well, for example if the list contains ten thousands of addresses (like an enterprise address book). Kjetil suggests a comparator which takes a URI on one side. Alexey: Sure, testing membership in big lists can be optimized (e.g. use LDAP search). This is an implementation detail. Randy pointed out that we needed to handle updates, and the LDAP server going down. Pete says there are email clients which already have addressbook interaction in filtering. Aaron: I'm in favor of some kind of managesieve extension to maintain the external lists. Randy said that the extension should also cover management of mailing lists. (Alexey didn't like the idea) Randy: It's a generalization of Eudora's 'intersects address book' test, and 'add to address book entry' action. Aaron: Automatically adding inbound/outbound addresses to the address book? Kjetil: with "include" in Sieve, it wouldn't be that much of a difference to upload a new list using ManageSieve. But I want it to use your *real* address book which is already stored in LDAP or whatever. Also, duplicating lists is not good. A huge discussion started on whether the identifier for a list has to be an opaque string or an URI: Alexey: I don't like URIs in this case. I don't want to force users to write LDAP URIs, they are just too complex. The whole point of the extension is to make this easier for users. In LDAP case users don't need to know the base DN for search, search criteria (e.g. which object classes), etc. Philip: who says the user will be writing the URI? won't the MUA be generating the URI to match the URI it uses for the address book? Pete suggested that the "mylist" can be a relative reference, so the script engine uses a base URI to resolve it to an absolute URI. Alexey thinks that this would not work with LDAP, for example. Barry likes the notion of a magical URI for "Your data". Kurt thinks it's all too complex. Pete says "Thou shalt support URIs", but "Thou may support arbitrary tokens". Philip: one catch with URIs is that they all have distinct quoting requirements for various fields. Given an arbitrary string, generating an LDAP URI that searches for entries that have a particular attribute with that value is non-trivial. Randy agrees. Philip: have to apply both the LDAP filter escaping *and* the URL escaping, in that order. And finally Alexey talked about ManageSIEVE draft. One update since last IETF, mostly bugfixes. NOTIFY capability text moved here. Open Issues: 1. Reference implementation doesn't implement non synchronizing literals. So the spec will be updated to match the real world. 2. Suggestion from Arnt: Remove anonymous script verification mode. Any objections? Kjetil: Means the UA doesn't have to store the password for syntax checking. Alexey: But clients already cache passwords, at least while they are running. Aaron notes that different users can have different capabilities granted to them, so it is important to authenticate properly. TODO: Consensus to remove the text. 3. IANA registry for response codes Dave Cridland: Could reuse http://www.iana.org/assignments/acap-registrations for response codes. Alexey talked about WG milestones. There was a proposal to update them, but the WG is already 1 month behind on the updated ones. Other business: Alexey wants to talk about Sieve interop on Tuesday or Wednesday. Alexey instructs WG members to drink Czech beer. The meeting has ended.