3028bis (base spec): blocked on Cullen's DISCUSS. Need to try to catch Cullen during the IETF week to discuss his issue. Notify Mailto draft: [14:18:01] discussion of auto-submitted in notify mailto and whether we need strong text about preventing loops. [14:20:22] (agree that notification messages should not trigger notifications) Editheader: [14:28:22] new draft addressing issues: some comments from Ned were addressed. [14:28:45] We has a Sieve lunch yesterday. From the lunch we came up with some better restrictions on deletion of "trace" headers [14:29:53] so we'd write a discrete whitelist of headers? [14:29:59] Issue as to whether there is a list of specific headers that can always be changed/removed. [14:31:10] X- headers should not be specifically called out. [14:32:52] Chris: some headers (general class) should be editable. [14:34:28] So, must permit changes to Subject, security consideration about changes to "trace" headers, then implementation note about being wise to allow changing classification headers. [14:35:38] Barry wants clarification of slide bullet points. [14:36:06] Is deletion of received forbidden no matter what local policy is? [14:36:08] Yes. [14:36:58] Randy wants more detail on the language for implementation note. Not happy with the current proposal. [14:37:48] MUST allow: Subject. MUST NOT allow: Received. SHOULD allow: everything else, because we like editing headers. MAY disallow: anything else for site policy. [14:38:59] Kurt - aren't there other reasons (e.g. privacy)? [14:41:29] Part of the problem is the precision in noting which headers are trace or not. [14:43:19] 2821/2822 identify trace headers: received and return-path [14:44:06] oh right - return-path. that'd be an evil one to modify. [14:46:07] Jeff: is it only up to local policy to define this or can the Sieve implementation dictate that policy? [14:46:16] randy: it's not a closed set [14:47:41] Pete: policy may dictate that nothing can be changed so why not leave it all to local policy. [14:47:57] If the script cannot depend on at least one field, then it kills the poor-man's variables possibility... so what? Notify: [14:49:47] Document is ready for IESG Reject/refuse: [14:50:56] Aaron Stone will co-edit the document and move it along. [14:51:10] Two changes needed, per IETF67 consensus: [14:51:23] 1. two actions: reject, ereject. [14:51:32] 2. add more details on MDN/DSSN [14:52:03] I have my asbestos Inbox filter turned on, so I'm ready for the flood of comments from everyone about what else this should go into refuse-reject :-) MIME loops: [14:52:31] Remember its not just MIME loops anymore - a whole bunch of other MIME related things [14:53:04] biggest change was pulling extract_text action out of the notify [14:53:15] IANA considerations greatly expanded [14:53:21] other minor tweaks [14:54:05] discussion of extract_text: suggestion to extend body to do the same [14:56:46] issue: does text about how to find the first text part need to be more detailed? [14:58:22] Will do last call and comments on those can be included then. [14:59:03] extract_text returns empty string if not used in the context of an iterator [14:59:23] Philip wants an error instead [14:59:48] Jeff: compile time error not runtime [15:00:03] Alexey: boundary is somewhat grey between runtime and compile time errors [15:00:55] Jeff: do the "find the first part" logic as the logic of the loop itself Ned's Date: ready for last call. Alexey will shepherd. Ned's iHave: more review please Ned's Notary: new drafts - more review please. Alexey's IMAP METADATA: [15:06:04] Who is planning on implementing this? [15:07:03] Extension includes tests for existence and :create option for fileinto. [15:07:33] Open issue: server annotations [15:07:44] List-extended? [15:08:20] Probably not now can be done as another extension later Alexey's External Lists: [15:09:43] Now allows URLs as well as user tokens as list identifiers [15:11:02] issues: [15:11:14] how to handle server outage? runtime error? [15:11:30] clearly we need a try/catch at runtime. [15:13:13] i'm just reading this for the first time, and yes, an entire mailing list could be implemented. If you could write to the external list from sieve, then you can even handle the maintenance addresses like list-subscribe, list-remove. [15:14:23] What is a "real mailing list"? It's a program written in some language that re-sends messages to a list of addresses. [15:21:23] on the issue of LDAP result paging, i brought this up in prague: we don't want the ":list foo" to be evaluated strictly and result in a huge stringlist. rather, we would want the action to accept the :list foo and lazy evaluate it inside the action handler. [15:21:24] sure, but is it really necessary to extend Sieve to the point where it can be used to write mailing list software? There are plenty of mailing list pakages out there today, none of which are written in sieve. [15:21:41] It's not just for mailing lists. [15:21:57] There are lots of good reasons a Sieve script should be able to access my "address book". [15:22:10] Now, where might my address book reside? [15:22:46] Barry, I think some of the other use cases you and Philip have presented are compelling. I just don't think "implement mailing lists" is. [15:23:02] Actually, I'm curious as to where your address book resides. [15:24:26] I'm tempted to write a mailing list manager in Sieve now just to see what it looks like. It would need basically every major extension - editheader, date tests, variables, etc. per the ietf "running code" mantra, let's see what it looks like before we pass judgment. and yes, i do think its the most pedantic use case. As barry points out, there are lots of very reasonable use cases that are not crazy at all. [15:29:12] I don't think a sieve-based mailing list manager would be very useful operationally. However, it certainly would excercise a lot of the language features and extensions, and that alone might make it a worthwhile endeavor. [15:29:43] (You don't really need editheader if you want to do an smtp-expn style list) [15:30:02] I agree with Jeff... While I can come up with some limited good uses of Sieve to fan out messages, I don't think we should design Sieve to support mailing list usage in general. Barry's IMAP Sieve: [15:36:38] would we be comfortable lifting the restriction against running multiple scripts if there were some document explaining what happens? I recall this being something that has been discussed before and several implementations _do_ currently use more than one script run at different stages of message delivery. [15:37:43] this is good -- it gives a transition path away from ManageSieve towards script management via metadata. [15:38:07] Where is that restriction expressed? [15:38:36] Barry just said it out loud, that it's in the new IMAP-Sieve draft. [15:40:01] ... and now I can't find the draft :-( [15:40:38] http://www.ietf.org/internet-drafts/draft-ietf-lemonade-imap-sieve-03.txt [15:49:29] My point is that if clients are generating the scripts, if there is only one script per mailbox, then clients will stomp all over each others' scripts [15:49:36] ok, sounds good, and an important point that we don't cause the lemonade people to throttle us. [15:50:03] If we allow /client/ as an extra metadata entry under /IMAPSieve/Script, then each client can add its own script [15:50:25] These subsequent scripts would be prohibited from doing operations such as Reject and FileInto [15:51:09] 1) if you have two phones, do they use the same client-id or different ones? [15:53:43] 2) if different, and one died, what would delete the scripts for the dead client? [15:53:52] Depends on how the phone's client is written. Assuming it creates a script based on local user configuration, I'd say each client needs its own id [15:55:13] Don't know how best to reap scripts for dead clients, but there are possible solutions based on age of last change and so forth [15:55:59] But without per-client scripts, it's unclear how these scripts get created or used. It seems to be a per-user thing that can't be per-client [15:56:10] Any client will stomp on the script for others Other business: Q: Sieve face-to-face interop in Greece this fall (hosted by University of Athens)? A: Mostly silence in response Q: Is online interop better? A: People are more entusiastic about that, but still not clear how much support this idea has. [15:53:32] I'd definitely be at an online interop, and possibly at an in person. [15:54:03] I think this actually grows into a question of creating a basic interop script test suite. [15:54:13] oh, that's what Barry and Arnt have talked about. [15:54:22] huge +1 from me.