[16:50:19] --- mckeon has joined
[16:50:31] --- mckeon has left
[17:00:25] --- pguenther has joined
[18:09:02] --- cyrus_daboo has joined
[18:13:29] --- alexeymelnikov has joined
[18:13:37] --- matthewelvey has joined
[18:17:00] --- mckeon has joined
[18:17:58] <matthewelvey> Anyone available to do an audio chat, so I can listen in (from San Francisco)?
[18:20:52] --- cnewman@jabber.org has joined
[18:21:08] <cnewman@jabber.org> Meeting is started, I'll be jabber scribe
[18:21:26] <cnewman@jabber.org> Agenda slide
[18:21:29] --- resnick has joined
[18:21:45] <resnick> Can you not get the mp3 feed?
[18:21:55] <cnewman@jabber.org> WG Status slide
[18:22:12] --- Lisa has joined
[18:22:17] <cnewman@jabber.org> 6 specs in RFC editor queue blocked on 3028bis
[18:22:26] <matthewelvey> Didn't know there was an MP3 feed. Looks like I missed an email somewhere...
[18:23:04] <resnick> ietf67-ch2
[18:23:49] <matthewelvey> Got it.
[18:24:24] <resnick> See http://videolab.uoregon.edu/events/ietf/ for other sessions.
[18:24:36] --- Barry Leiba has joined
[18:25:14] <cnewman@jabber.org> On Base Spec slide
[18:26:08] <resnick> The presentation does not seem to be uploaded to the agenda page.
[18:26:14] <cnewman@jabber.org> Issues: UTF-8 quoting, EKR comments: is Sieve Turing complete? Loops can occur in the mail system -- does that count?
[18:27:03] --- kmurchison has joined
[18:27:10] <cnewman@jabber.org> Link to preso was sent to Sieve list.
[18:33:41] <matthewelvey> Standards/techniques already limit loops. Don't think we should pretend those don't exist.
[18:34:00] <cnewman@jabber.org> Ned: need to mention redirect can cause mail loops, but don't want to go into a lot of detail about it.
[18:34:16] <cnewman@jabber.org> (on security considerations issue)
[18:34:31] <resnick> (If you are participating remotely: Specifically note if you want your comment relayed to the room.)
[18:37:05] <cnewman@jabber.org> Phil/Ned: Our intention of Sieve is that it not be Turing complete. Although it's may be possible to create something Turing complete with certain types of mail loops, that does not change the intention.
[18:37:25] * resnick nods in agreement with Ned that intentions need to be stated
[18:38:17] <cnewman@jabber.org> Next slide: Reject/Refuse
[18:39:56] <matthewelvey> To Room: I think having the current (rfc) syntax continue to work the way it currently does is a horrible idea.
[18:40:22] <cnewman@jabber.org> Had design team discussion; Alexey summarizes outcome: there are use cases where you want to reject over protocol if at all possible and lose UTF-8 if necessary, and there are use cases where preservation of UTF-8 is paramount. Want to go back to two actions: original reject which does MDNs and preserves UTF-8, the other is ereject which tries to reject over protocol.
[18:40:40] <resnick> Expand Matthew?
[18:40:46] --- tonyhansen has joined
[18:40:55] <matthewelvey> Any objections to having reject do the new way, and oreject do the old way? (OldReject)
[18:43:04] <matthewelvey> To room. Old scripts using UTF 8 will continue to work.
[18:43:48] <matthewelvey> Answer: The script writer will often know, so the script will know.
[18:44:13] <Lisa> A creative idea from Chris :)
[18:44:24] <alexeymelnikov> Chris suggests to provide automatic migration from old reject
[18:44:38] <Lisa> (as an implementation choice, not as part of the standard)
[18:44:40] <alexeymelnikov> Chris doesn't want the behaviour of existing reject change
[18:44:51] <cnewman@jabber.org> Chair: consensus around two verbs
[18:44:51] <matthewelvey> To room: The current behaviour is broken. I challenge the speaker to show how having reject change breaks something important. A specific real world answer (who is speaker?)
[18:45:38] <Barry Leiba> The speaker is Chris Newman, Matthew.
[18:48:28] <cnewman@jabber.org> Chair: do we want to upgrade old reject to generate protocol-level reject as long as it doesn't require language downgrade?
[18:48:36] <matthewelvey> Yes.
[18:49:09] <cnewman@jabber.org> me: no objection
[18:51:29] <matthewelvey> To Room. (As the initial author, I'd like to propose:) how about keeping current spec, but replacing :exacttext with its opposite, e.g. something like :asciifiedtext. Would that address what folks want? Or do we need to switch to 2 actions? I think this is the proposal that folks now want to do.
[18:54:23] <cnewman@jabber.org> Randy: concerned that users read MDNs but not DSNs or protocol rejects. Uncomfortable changing the behavior of the existing command.
[18:54:51] <matthewelvey> We're not saying the most important part is UTF8, we're saying it's a factor.
[18:56:14] <matthewelvey> To room: For the record: I still want to change the default, common behaviour. That was the main point of the entire effort of creating the new draft.
[18:57:31] --- randy has joined
[18:58:38] <cnewman@jabber.org> Proposal: Keep reject as MDN. New action for protocol level or MDN. (optional) Allow reject to do protocol level if ascii only text.
[18:59:32] <matthewelvey> Answer to question: I want to change the default, common standard-based behaviour. Alexey, we've talked about it, and I know you can, just not easily.
[19:01:49] <matthewelvey> No it doesn't.
[19:02:18] <matthewelvey> The gateway can wait to send the response to the end-of-data, so that it can send a 550.
[19:02:31] --- arvelh has joined
[19:02:38] <matthewelvey> Above to room, please.
[19:02:47] <resnick> How much of it?
[19:02:55] <resnick> (And what was it in answer to?)
[19:02:56] <matthewelvey> Just the last one.
[19:03:01] <cnewman@jabber.org> Chair: who would disagree with keeping reject as is.
[19:03:18] <matthewelvey> Someone said an lmtp-smtp gateway can't.
[19:03:52] <cnewman@jabber.org> Chair: room rough consensus for keeping reject action as MDN based on hum.
[19:04:03] <cnewman@jabber.org> Char: new action for protocol level?
[19:04:05] <matthewelvey> Was there a hum on that?
[19:04:11] <resnick> Yes. There was humming.
[19:04:20] <cnewman@jabber.org> Yes. We assumed you hummed opposition, matthew.
[19:04:20] <resnick> Did you want to hum against?
[19:04:35] <matthewelvey> I didn't hear any hums either way...
[19:04:40] <matthewelvey> (Yes).
[19:04:44] <resnick> It's hard to hear hums on the mic.
[19:04:50] <cnewman@jabber.org> Any hums against adding a new action for protocol level reject?
[19:04:56] <pguenther> matthew: yes, if there was a single rcpt and the gateway delays acceptance...which isn't always possible
[19:05:48] <cnewman@jabber.org> Third question: allow implementations to do protocol level "reject" if text doesn't require downgrade?
[19:07:03] --- Aaron Stone has joined
[19:07:24] <matthewelvey> I'm going to request hum 1 on-list.
[19:08:05] --- randy has left
[19:08:14] <Lisa> Matthew: that's good, but unless the chairs feel that new issues are brought up which could have changed the hums in the room, those can stand.
[19:08:47] --- randy has joined
[19:08:50] <cnewman@jabber.org> On issue three, wishy-washy in favor, no opposed.
[19:09:02] <matthewelvey> no comment.
[19:09:54] <cnewman@jabber.org> Chair: rough consensus in room for three points.
[19:11:26] <resnick> Lisa: Or if there is excessive *humming* by others on the list. (Matthew: Read, "Get new things that will unconvince the folks in the room or get implementors not in the room who agree with you.)
[19:12:16] --- arvelh has left
[19:13:22] <Lisa> Yes. The hums in the room can stand and may yet be overridden by new votes. Yet I would think that the number of hums by implementors in favour of keeping the current behavior as is, would indicate a lack of consensus for the opposite view given that we don't have 100 Sieve implementors humming on issues.
[19:13:48] * resnick nods
[19:14:08] <resnick> Just making sure Matthew understood. I figured you did. :)
[19:14:37] <cnewman@jabber.org> Also, when it comes to changing the behavior of an existing standard, there must be rough consensus to change behavior; absent consensus the published behavior should stand.
[19:15:20] <cnewman@jabber.org> Next slide: MIME Loops
[19:18:25] <Aaron Stone> Are there any mime parts besides message/rfc822 where the headers are not specified by mime itself?
[19:20:42] <Aaron Stone> Ok, Content-Disposition: and Content-Description: are things you would want to edit in a non-message/rfc822 mime part.
[19:24:52] <cnewman@jabber.org> My suggestion: implementation can descend into parts they understand, but MUST descend into multipart/* and message/rfc822, and SHOULD NOT descend into text/rfc822-headers
[19:25:31] <resnick> I'm not asking this at the mic yet, but: A message/rfc822 has it's own headers (say, (Content-Description: A message from my mother") and the content have headers. Which ones are you talking about when you "descend".
[19:25:34] <resnick> ?
[19:26:29] <cnewman@jabber.org> The tests would be applied to the message/rfc822-headers as well as the MIME headers.
[19:27:18] <resnick> Interesting. Of course, something like Content-Description could occur in both places (theoretically).
[19:29:38] <cnewman@jabber.org> Cyrus: any other issues on MIME loops?
[19:29:52] <cnewman@jabber.org> Next slide: notification
[19:33:42] <cnewman@jabber.org> Phil has volunteered to work on text for loop detection for notify.
[19:34:38] <cnewman@jabber.org> Barry wants a loop prevention mechanism that works across notification in some way.
[19:34:58] <cnewman@jabber.org> Barry will try to work on text.
[19:35:33] <Aaron Stone> Area for new work: spanning tree protocol tunneling over notification methods.
[19:38:05] <cnewman@jabber.org> more issues: need to change extension name
[19:39:54] <pguenther> the principle for sieve extensions is that _if_ an implemention accepts the 'require's that the script contains, _then_ the script will be executed with the expected behavior
[19:40:27] <pguenther> that rule basically means that we can't use the same name for the revision of notify
[19:41:38] --- matthewelvey has left: Replaced by new connection
[19:43:00] --- matthewelvey has joined
[19:52:55] <alexeymelnikov> Consensus: allow the default :message to be mechanism specific
[19:54:41] <cnewman@jabber.org> Moving on to "other topics"
[19:55:11] <cnewman@jabber.org> RegEx - lack of progress. If no more progress by this meeting, it should be dropped. So we're pulling it from our charter
[19:56:33] <alexeymelnikov> Notify: consensus: don't have default notification method - this leads to surprises
[19:56:52] <cnewman@jabber.org> Date - Ned: one comment to change the part parameter from positional to tagged. nobody else in favor, will drop that issue. New draft adds one more test type to get back an RFC822 format.
[19:57:56] <Aaron Stone> Ned, what is holding up RegEx?
[19:58:26] <cnewman@jabber.org> ManageSIEVE - no update
[19:59:21] <Aaron Stone> Include I think is still held up due to lack of concensus about interaction with variables. Is there anything else holding it up?
[20:00:17] <pguenther> regex needs careful thinking about how regexps interact with comparators
[20:00:28] <cnewman@jabber.org> Barry - work on IMAP Sieve and Sieve environment.
[20:00:50] <pguenther> header :regexp :comparator "i;ascii-casemap"
[20:00:51] <pguenther> vs
[20:01:18] <pguenther> font size="3">header :regexp :comparator "i;that unicode comparator"...
[20:01:34] <cnewman@jabber.org> Barry - will work on that to have something by christmas
[20:01:55] <Aaron Stone> thanks Philip
[20:03:11] <cnewman@jabber.org> refuse timeframe: Alexey will do revision by end of November as long as we don't change minds again.
[20:03:59] --- Robbie Stone has joined
[20:04:01] <cnewman@jabber.org> refuse is more important than notify since it was pulled from base spec.
[20:04:46] <cnewman@jabber.org> new refuse drafts by december
[20:04:59] <Aaron Stone> Question about procedure: ManageSieve is currently a personal submission from Tim Martin and Alexey -- what would move it into the IETF drafts status? Is that the issue about bringing something into the Charter of a WG?
[20:05:07] <cnewman@jabber.org> notification by december
[20:05:26] <Lisa> aaron I'd be happy to explain at the cookie break
[20:12:18] --- Robbie Stone has left
[20:14:39] --- kmurchison has left
[20:14:45] <cnewman@jabber.org> Discussion of standards dependency and issue on taking things to draft. Proposal to move 2821/2822 to draft perhaps on a variance because they're better than 821/822 which are full standard.
[20:14:48] <cnewman@jabber.org> Meeting concluded.
[20:14:53] --- randy has left: Logged out
[20:15:36] --- cnewman@jabber.org has left: Logged out
[20:17:32] --- Barry Leiba has left
[20:17:32] --- Barry Leiba has joined
[20:17:37] --- Barry Leiba has left: Logging off
[20:18:01] --- Lisa has left: Logged out
[20:18:17] --- resnick has left
[20:18:25] --- cyrus_daboo has left
[20:18:32] --- alexeymelnikov has left
[20:18:38] --- matthewelvey has left
[20:22:57] --- Aaron Stone has left
[20:24:48] --- mckeon has left
[20:34:32] --- tonyhansen has left
[22:12:30] --- pguenther has left