[11:56:21] --- LOGGING STARTED
[13:09:08] --- aaronstone has joined
[13:58:45] --- arnt has joined
[13:58:54] <arnt> hi aaron.
[13:59:12] <aaronstone> hi arnt!
[13:59:23] <aaronstone> everyone must be running late today?
[13:59:53] <arnt> IETF tradition.
[14:00:36] <arnt> surely you must have noticed that everyone sends their draft comments in the week following the Last Call deadline?
[14:00:41] <aaronstone> i had this awful feeling this morning that the sieve meeting would be at 0900 Chicago time, and I was not awake at 0700 California time.
[14:00:46] <aaronstone> haha, totally.
[14:00:56] <aaronstone> i'm still reading things that will be on the agenda
[14:01:09] <arnt> my desktop now displays _three_ clocks. munich, delhi and chicago time.
[14:01:31] --- Glenn Parsons has joined
[14:01:43] <arnt> boy, you're conscientous. I haven't read everything that's going to be discussed.
[14:01:49] --- cyrus_daboo has joined
[14:01:53] <aaronstone> ah here come the rush
[14:02:34] <arnt> if I disappear it's because my daughter has unplugged some crucual piece of equipment or other.
[14:03:12] --- randy has joined
[14:04:18] --- barryleiba@gmail.com has joined
[14:05:04] --- guenther has joined
[14:05:05] --- tonyhansen has joined
[14:05:45] <guenther> <arnt> such as my heart/lung machine
[14:06:37] --- kmurchison has joined
[14:07:29] <randy> test test test
[14:08:28] --- sam.silberman has joined
[14:09:25] --- jhutz has joined
[14:09:27] <arnt> philip: she loves removing keys from laptop keyboards. control, shift, alt and enter are her favourites. close enough? ;)
[14:10:00] <guenther> myspacekey!wherediditgo?
[14:10:21] <arnt> cheater. you hit enter at the end of that.
[14:11:38] * guenther cut and pasted it
[14:12:18] <arnt> I was reduced to that too, until I got a new laptop and offered her the old one.
[14:13:36] <guenther> old laptop == bribe toy
[14:13:42] --- resnick has joined
[14:13:52] --- kdz has joined
[14:17:06] --- randy has left
[14:18:01] <cyrus_daboo> discussion of auto-submitted in notify mailto and whether we need strong text about preventing loops.
[14:18:51] <aaronstone> agreed.
[14:20:22] <aaronstone> (er, agree that notification messages should not trigger notifications)
[14:22:39] --- galvinjamesm@jabber.org has joined
[14:22:50] --- kdz has left
[14:22:58] --- mckeon has joined
[14:23:02] --- kdz has joined
[14:27:42] <cyrus_daboo> edit header
[14:28:22] <cyrus_daboo> new draft addressing issues: some comments from Ned were addressed.
[14:28:45] <cyrus_daboo> from lunch we came up with some better restrictions on deletion of "trace" headers
[14:29:53] <aaronstone> so we'd write a discrete whitelist of headers?
[14:29:59] <cyrus_daboo> Issue as to whether there is a list of specific headers that can always be changed/removed.
[14:31:10] <cyrus_daboo> X- headers should not be specifically called out.
[14:31:31] <arnt> notetaker/alexey/whoever: please remind people to name themselves at the mic.
[14:32:09] <resnick> That was Jeffrey Hutzelman, Chris Newman, and Philip Guenther.
[14:32:13] <resnick> This is now Chris.
[14:32:52] <cyrus_daboo> Chris: some headers (general class) should be editable.
[14:32:55] --- randy has joined
[14:34:28] <cyrus_daboo> 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] <cyrus_daboo> Barry wants clarification of slide bullet points.
[14:36:06] <cyrus_daboo> Is deletion of received forbidden no matter what local policy is.
[14:36:08] <cyrus_daboo> Yes.
[14:36:58] <cyrus_daboo> Randy wants more detail on the language for implementation note. Not happy with current proposal.
[14:37:48] <aaronstone> 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] <cyrus_daboo> Kurt - aren't there other reasons (e.g. privacy)?
[14:41:29] <cyrus_daboo> Part of the problem is the precision in noting which headers are trace or not.
[14:42:34] --- kdz has left
[14:43:19] <randy> 2821/2822 identify trace headers: received and return-path
[14:44:06] <aaronstone> oh right - return-path. that'd be an evil one to modify.
[14:46:07] <cyrus_daboo> Jeff: is it only up to local policy to define this or can the sieve implementation dictate that policy.
[14:46:16] <guenther> randy: it's not a closed set
[14:47:41] <cyrus_daboo> Pete: policy may dictate that nothing can be changed so why not leave it all to local policy.
[14:47:57] <aaronstone> if the script cannot depend on at least one field, then it kills the poor-man's variables possibility
[14:48:08] <aaronstone> ...so what?
[14:49:31] <cyrus_daboo> On to notify
[14:49:47] <cyrus_daboo> Document is ready for IESG
[14:50:40] <barryleiba@gmail.com> On to reject/refuse...
[14:50:56] <barryleiba@gmail.com> Aaron Stone will co-edit the doc and move it along.
[14:51:10] <barryleiba@gmail.com> Two changes, per IETF67 consensus:
[14:51:23] <barryleiba@gmail.com> 1. two actions: reject, ereject.
[14:51:32] <barryleiba@gmail.com> 2.add more details on MDN/DSSN
[14:52:02] <barryleiba@gmail.com> On to MIME loops, and back to Cyrus to scribe.......
[14:52:03] <aaronstone> 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 :-)
[14:52:12] <cyrus_daboo> MIME loops
[14:52:29] --- kdz has joined
[14:52:31] <cyrus_daboo> Remember its not just loops - a whole bunch of things
[14:53:04] <cyrus_daboo> biggest change was pulling extract_text action out of notify
[14:53:15] <cyrus_daboo> IANA considerations greatly expanded
[14:53:21] <cyrus_daboo> other minor tweaks
[14:54:05] <cyrus_daboo> discussion of extract_text: suggestion to extend body to do the same
[14:56:14] --- Darryl has joined
[14:56:46] <cyrus_daboo> issue: does text about how to find the first text part need to be more detailed?
[14:58:22] <cyrus_daboo> Will do last call and comments on those can be included then.
[14:59:03] <cyrus_daboo> extract_text returns empty string if not used in the context of an iterator
[14:59:23] <cyrus_daboo> Phil wants an error instead
[14:59:48] <cyrus_daboo> Jeff: compile time error not runtime
[15:00:03] <cyrus_daboo> Alexey: boundary is somewhat grey between runtime and compile time
[15:00:55] <cyrus_daboo> Jeff: do the "find the first part" logic as the logic of the loop itself
[15:04:15] <cyrus_daboo> Date: ready for last call. Alexey will shepherd
[15:04:54] <cyrus_daboo> iHave: more review please
[15:05:06] <cyrus_daboo> notary: new drafts - more review please.
[15:05:16] <cyrus_daboo> IMAP METADATA
[15:06:04] <cyrus_daboo> Who is planning on implementing this?
[15:07:03] <cyrus_daboo> Extension includes tests for existence and :create option for fileinto.
[15:07:33] <cyrus_daboo> Open issue: server annotations
[15:07:44] <cyrus_daboo> List-extended?
[15:08:20] <cyrus_daboo> Probably not now can be done as another extension later
[15:09:15] <cyrus_daboo> External lists:
[15:09:43] <cyrus_daboo> Now allows URLs as well as user tokens
[15:11:02] <cyrus_daboo> issues:
[15:11:14] <cyrus_daboo> how to handle server outage? runtime error?
[15:11:30] <aaronstone> clearly we need a try/catch at runtime.
[15:13:13] <aaronstone> 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:09] --- cyrus_daboo has left: Replaced by new connection
[15:14:23] <aaronstone> 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] <aaronstone> 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:23] --- tonyhansen has left
[15:21:24] <jhutz> 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] <barryleiba@gmail.com> It's not just for mailing lists.
[15:21:57] <barryleiba@gmail.com> There are lots of good reasons a Sieve script should be able to access my "address book".
[15:22:10] <barryleiba@gmail.com> Now, where might my address book reside?
[15:22:46] <jhutz> 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] <jhutz> Actually, I'm curious as to where your address book resides.
[15:24:26] <aaronstone> 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] <jhutz> 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] <randy> (You don't really need editheader if you want to do an smtp-expn style list)
[15:30:02] <barryleiba@gmail.com> I agree with Jeff...l 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.
[15:31:27] --- resnick has left
[15:35:07] --- Darryl has left
[15:36:38] <aaronstone> 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:06] --- Darryl has joined
[15:37:43] <aaronstone> this is good -- it gives a transition path away from managesieve towards script management via metadata.
[15:38:07] <jhutz> Where is that restriction expressed?
[15:38:36] <aaronstone> barry just said it out loud, that it's in the new imap sieve draft.
[15:40:01] <jhutz> ... and now I can't find the draft :-(
[15:40:38] <aaronstone> http://www.ietf.org/internet-drafts/draft-ietf-lemonade-imap-sieve-03.txt
[15:43:06] --- cyrus_daboo has joined
[15:43:54] --- lisa has joined
[15:45:47] <lisa> is anybody listening to the audio? do I need to keep Jeffrey to get him to the mic?
[15:46:05] <lisa> I mean "kick jeff" not keep him :)
[15:46:08] <lisa> sooooo tired
[15:46:27] <aaronstone> i'm listening to the audio, yeah.
[15:46:49] <jhutz> sorry
[15:47:00] <aaronstone> no worries, i can hear everyone alright
[15:47:19] <jhutz> there aren't enough mics. According to Marcia they're really expensive at this hotel.
[15:49:29] <randy> 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] <aaronstone> ok, sounds good, and an important point that we don't cause the lemonade people to throttle us.
[15:50:03] <randy> If we allow /client/<client-id> as an extra metadata entry under /IMAPSieve/Script, then each client can add its own script
[15:50:25] <randy> These subsequent scripts would be prohibited from doing operations such as Reject and FileInto
[15:51:09] <guenther> 1) if you have two phones, do they use the same client-id or different ones?
[15:53:32] <aaronstone> i'd definitely be at an online interop, and possibly at an in person.
[15:53:42] --- Glenn Parsons has left
[15:53:43] <guenther> 2) if different, and one died, what would delete the scripts for the dead client?
[15:53:52] <randy> 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:54:03] <aaronstone> i think this actually grows into a question of creating a basic interop script test suite.
[15:54:13] <aaronstone> oh, that's what barry and arnt have talked about.
[15:54:22] <aaronstone> huge +1 from me.
[15:55:13] <randy> 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] <randy> 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:09] --- lisa has left
[15:56:10] <randy> Any client will stomp on the script for others
[15:59:07] --- cyrus_daboo has left
[15:59:08] --- jhutz has left: Disconnected
[15:59:09] --- kmurchison has left
[15:59:13] --- randy has left
[16:00:00] --- barryleiba@gmail.com has left
[16:00:01] --- guenther has left
[16:00:04] --- aaronstone has left
[16:02:06] --- sam.silberman has left
[16:04:24] --- galvinjamesm@jabber.org has left
[16:06:55] --- kdz has left
[16:09:47] --- kmurchison has joined
[16:12:57] --- kmurchison has left
[16:20:41] --- Glenn Parsons has joined
[16:21:29] --- Darryl has left
[16:21:52] --- arnt has left
[16:40:49] --- resnick has joined
[16:41:03] --- resnick has left
[16:41:15] --- mckeon has left
[17:07:58] --- Glenn Parsons has left