[14:52:43] --- NFreed has become available [15:00:08] --- cyrus_daboo has become available [15:01:21] --- kmurchison has become available [15:01:33] --- Dave Cridland has become available [15:05:27] --- alexeymelnikov has become available [15:06:00] We should start in a couple of minutes. Still waiting for Philip and Barry... [15:06:11] --- tonyhansen has become available [15:07:09] I'm scribing [15:07:49] starting up [15:09:30] agenda bashing [15:09:38] nothing [15:10:30] docs ready for IESG [15:10:49] --- NFreed has left: Lost connection [15:10:49] --- cyrus_daboo has left: Lost connection [15:10:49] --- tonyhansen has left: Lost connection [15:10:49] --- Dave Cridland has left: Lost connection [15:10:49] --- kmurchison has left: Lost connection [15:10:49] --- alexeymelnikov has left: Lost connection [15:14:14] --- alexeymelnikov has become available [15:14:57] --- tonyhansen has become available [15:15:05] am I on? [15:15:31] docs ready for IESG vacation: clarified hash construction, auto reply subject : no change -- 2nd is runtime error [15:15:43] spamtest, imap flags, relational, edit header ready for IESG relational bounced by rfc editor, resubmitted body -- waiting on comparators variables -- issue for collation/lowercase/uppercase [15:15:45] --- NFreed has become available [15:16:02] (the room bounced or something glitched) [15:16:12] --- NFreed has left: Disconnected [15:16:54] use us-ascii or stringprep? stringprep would take longer [15:17:06] --- cyrus_daboo has become available [15:17:07] opinions anyone? [15:17:23] --- kmurchison has become available [15:18:29] usascii is sufficient, stringprep is for other things [15:18:46] is we change, change to unicode, not stringprep [15:19:23] --- Dave Cridland has become available [15:19:44] US-ASCII is fine by me. [15:19:52] --- Glenn Parsons has become available [15:19:57] question from chair: usascii, stringprep, or more [15:20:12] agreement in the room for usascii [15:20:21] going to the list for confirmaton [15:21:11] body document needs tweaking [15:21:17] chair: how long? [15:21:28] edit header is not with IESG right now. I have the write-up done and we will submit to them next week. [15:22:06] after comparator issue is done, a matter of days to get body out [15:22:24] doesn't require comparator to ship, just agreement on the issue [15:22:49] chair: can comparaotr discussion be decided by the end of the month [15:22:56] chair: on to base [15:23:34] issue with abnf of match type, so added non terminals [15:23:58] --- alexeymelnikov has left: Disconnected [15:24:05] --- alexeymelnikov has become available [15:24:24] matching uses glob, but not fully specified in doc -- depends on substring op of collation [15:25:45] matching on characters needs i;basic, does anyone implement that? [15:26:25] header issues were in relational draft -- moved to base doc [15:27:17] relational said should strip leading/trailing spaces, wouldn't match unless done on both sides: new text proposed [15:28:44] because meaning of ws differs, all heading operations must be done in a normalized fashion, including ws folding, crlf folding, etc. [15:28:58] mailing list? [15:29:16] Barry's suggestion sounds reasonable on first pass. [15:29:29] no screaming from from those who reviewd the new text -- to be verified on mailing list [15:29:37] --- pguenther has become available [15:30:10] new base spec end of next week [15:30:27] --- resnick has become available [15:30:28] (a week from friday) [15:31:07] chair: on to notifications [15:31:30] unexpectedly receied lots of comments :-) [15:33:26] requires several docs for notification methdos -- looking for coauthor on xmpp, authors of sms [15:34:07] what does main doc say? [15:34:27] must sms be sms or emm? [15:35:05] if anyone wants multiple payloads for sms, may need ?? [15:35:17] do we need multiple docs? [15:35:31] that's what is wanted [15:35:49] ?? [15:36:31] willing to work on sms doc, but push for one that is method agnostic [15:36:41] peter is willing to work on xmpp [15:37:22] concur with stephane, have method agnostic that discuss mapping of uri to payload [15:37:40] would like to see base string as part of base spec that gets passed to method [15:38:01] how would script operate if movced from system to system [15:38:48] maybe solution is there is a "lemonade" method, which does generic lemonade method [15:39:26] unclear to how things fit together with lemonade [15:39:57] would having lemonade uri help, without knowing what method specific text looks like? [15:40:34] need to send the string somewhere, assume that's all you need to do here [15:41:33] needs more details as to what lemonade notif would mean, mismatch between protocol and payload [15:41:54] uri tags seem to be best so far, may not be [15:42:15] uri could take tags specifying protocol [15:42:31] sms supplies even more semantics [15:42:43] --- NFreed has become available [15:43:05] ?? [15:43:45] --- cnewman has become available [15:43:48] if want to send notif to smsc, or push gateway, want to generate right msg to be put into right place, so gateway can do the work. how do we do that? [15:44:05] wap push? [15:44:18] Well, that was nasty. Every jabber client I had installed failed to work this afternoon. Now using BuddySpace2. [15:44:19] only need to make sure msg is in right format [15:44:48] Ned: I had some odd problems at the start of this session and had to restart my client. Its been OK since. [15:44:58] Same here, actually. [15:45:16] there is value in what amounts to redirect having semantics -- how you implement wap push is implement specific [15:45:26] put stephane down for "other" [15:45:31] Tried restarting several times, tried Psi, Jabberfox, Gush, Fire, and Nitro. [15:45:39] I using Psi. [15:45:48] I'm using Adium [15:45:50] payload formatting is somewhat implicit in payload type [15:46:06] Adium was next on my list to try. [15:46:07] I'm using gaim, did have to restart it earlier [15:46:15] I'm using Gaim too. [15:46:43] iChat's happy as a clam. [15:46:44] f seieve script is responsible for formating payload, how can you write one script that handles all of them [15:47:00] COuld be worse, we could be using the SIMPLE stuff. :-) [15:47:09] use sieve variables? get info from imap annotation [15:47:24] payload doesn't mean what you think it does [15:48:50] ... processing will generate fake headers, etc, in protocol specific ways, to carry the event [15:49:16] was Ray Cromwell [15:50:24] notif method spec would say what script has to pass in (variables, message, etc) and spec says what it would do with them. main doc talks about generic parms. may be too immature to really discuss it right here. [15:51:37] some method docs will specify port numbers, etc. that sieve processor will need, and script may need variables/info specific to the method [15:51:47] info part of uri [15:52:12] stuff here is so far above ability of most users [15:52:25] need higher level semantics [15:52:49] I'm sorry, I don't think it follows that all these advanced features are useless to a GUI-constructor. [15:52:59] Greg: a UI can abstract the complexity out into simple checkboxes for 'email me at ...', 'im me at ...', 'sms me at ...'. [15:53:04] There's such a thing as task-oriented GUIs [15:53:28] Greg is assuming that a GUI has to be able to both generate and operate on existing sieve scripts. [15:53:31] sieve needs rules saying "I want sms notification" -- and let installation handle the rest [15:53:34] This is a false assumption. [15:55:01] Exactly. Templates are one way of building a task-oriented GUI. [15:55:11] we create templates that can be filled easily for sms, etc.. script specifies blob that is sent, templates handle rest [15:55:31] But our understanding of the higher order functions is nowhere close to complete enough to build this stuff into sieve. [15:56:32] on to notifications issues slide [15:56:32] --- NFreed has left: Disconnected [15:57:18] The obvious mandatory choice would be mailto since sieve already knows how to send messages. [15:57:28] --- NFreed has become available [15:57:57] denotify is gone -- predated variables, but no longer makes sense [15:58:05] --- shmaes has become available [15:58:05] Yes, mailto is the obvious choice. [15:58:30] --- lisa has become available [15:58:34] need a way to extract message body [15:59:35] also need to send the whole message -- semantic distinction btw redirect and ?? [15:59:48] can body be changed to remove restriction? [15:59:53] Would we need this body extract function elsewehere? If not then it could be part of notify itself. [15:59:54] no, body is out there [16:00:55] channel cyrus [16:01:26] is part of notify spec was should be [16:01:36] going to list with issue [16:02:02] notification method parameter: can it be optional? [16:02:43] if not there, must be runtime error [16:03:25] unrecognized notification methods? error or ignored [16:03:43] has to be [16:04:08] concur [16:04:18] can we test if method is available? [16:04:33] ManageSIEVE should advertise which URIs are supported. [16:04:34] argument for method putting all info into the uri [16:04:53] Cyrus: I agree. [16:05:03] Cyrus: Much nicer than suck-it-and-see discovery. [16:05:34] discussion of managesieve ... concurrence in room [16:06:04] <>capability for notification methods? [16:06:30] ok, but not thrilled [16:06:59] can uri be a variable? yes then can't have require [16:07:26] Is it worth being able to specify the URI as a list of strings, such that the first available is used? [16:07:41] from sieve POV, need text and way to gen payload, issue is ?? [16:07:57] oops, was [16:08:26] Actually the type of notification used may vary depedning on other factors. e.g. I might want to use mailto during office hours and sms out of hours (as detemined by date tests). [16:08:28] suggests "if X" an "if X" to test for method would be useful [16:09:01] add :from? [16:09:22] In fact if you want to take this to exteremes what we need is a presence extension in sieve that could determine where I am and what devices I have turned on and then pick the appropriate notifcation from that! [16:10:15] Even if it is true for all existing interesting URIs, can we be sure it is true for all future URIs? [16:10:23] specific to notif method? we need to agree on set of generic options that make sense across methods need it all in uri or some generic way of saying "there are parms that follow" [16:10:32] I'm happy to author the draft for Barry's suggested newpaper wacking method. ;-) [16:11:17] i'm sitting right behind phil, so i could test the strawman right now :) [16:11:53] Another issue: Suppose I have a URI with a subject field. How do build and encode that field and insert it into aURI using variables? [16:11:59] channeled cyrus [16:12:08] What Phillip is saying... [16:12:23] ? [16:12:53] script can choose which method to use [16:13:57] channelling [16:14:28] I'd prefer not to have generic options, but I don't think we can do without them, [16:14:56] cost based mechanisms? no more than 20 sms's per day? [16:15:40] lots of requests for that [16:15:49] goes back to cyrus' presence comment [16:16:01] --- resnick has left [16:16:08] need more implementation experience! [16:16:24] is sieve not the right language for this? [16:16:48] is this nf, df, vf? (lemonade terms) [16:17:11] ... [16:17:18] need to iterate docs [16:17:33] --- resnick has become available [16:17:44] "pass the message to notification plugin", ? [16:18:09] [16:18:13] subject needs to be sep for xmpp, not part of blob [16:18:40] need to cycle docs [16:18:58] not uncommon in msg store to use simple notification [16:19:37] not really that many variables in usual implementation of this interface [16:20:07] do we want to suppress identical notifications? [16:20:32] do we have to provide confidentiality services? affects answer. [16:20:48] Let's not forget traffic analysis... Confidentiality may be needed regardless of content. [16:20:51] refuse/reject [16:22:03] most people don't know diff btw mdn,dsn,protocol-level-refusal. would script writer really care? no 3 alternatives [16:24:51] if script writer does not care 1) keep reject capa, but change its action 2)change cap name but keep using refuse semantics, define what to do if both are required 3) obsolete reject, start using refuse [16:25:18] do script writers care? are there some who do care? [16:25:37] script writers really don't care. The person who does care is the sieve system admin who gets to determine where sieve itself runs (smtp time, delivery time etc). [16:26:04] I would prefer to sue a protocol level refusal wherever possible. I'm not sure whether I speak as a script writer or a sysadmin right now, though. [16:26:08] (ned, I missed seeing your comment to channel it) [16:26:16] Ack. s/sue/use/ [16:26:27] Tony: No worries [16:27:12] IMO people don't really care if they get a DSN or an MDN. The people that care are sysadmins who don't want to deal [16:27:27] with a queue full of undeliverable junk. [16:27:31] we think no one cares, so make it SHOULD do protocol level rejection but may do another. we can deal with others latter [16:27:36] One problem with do any of three is issue of non-ascii: MDNs can support that, protocol level SMTP errors cannot. So we need some way to downgrade non-ascii for that case. [16:27:42] So they want this to be a protocol level reject whenever possible. [16:28:25] And if that means users are forced to specify their reject text in US-ASCII, that's just too bad. The alternative sysadmins will pick is [16:28:39] not to allow users access to refuse/reject, period. [16:29:03] af/df lemonade references -- border filter area can only do protocol error, df can only do dsn [16:29:44] --- lisa has left [16:30:40] That's what we see, at least. [16:31:00] ... discuss 8 bit ... [16:31:04] Yes, that's fine. [16:31:26] I'm happy with sinmgle action. [16:32:04] hands for single action? lots in room clarification: implementation picks appropriately yes ... consensus declared -- to be confirmed on list [16:32:19] So then do we want to have this back in the base spec. [16:32:43] --- alexeymelnikov has left: Replaced by new connection [16:33:00] will put text back in base [16:33:48] anyone on jabber want to discuss index or include? [16:34:44] issue of execution of sieve on flag changes is probably lemonade -- individual submission -- go from there [16:34:47] Ned, what's the status of index and time extensions? [16:34:48] The only problem with include was the issue of scoping and I was going to propose a solution to that that is independent of variables. [16:35:22] Independent of the variables spec - it will be an extension to variables. [16:36:08] Sorry, I haven't had time to do an update to the date extension. [16:36:20] I want to get vacation out the door first. [16:37:21] Should be done soon/ [16:37:27] short discussion of loop/mime tests [16:37:39] channelled ned [16:37:39] You said exciting... [16:37:42] We should begin to talk about draft report for 3028bis [16:37:44] <any other topics [16:37:59] I wouldn't mind hearing a quick exachnge of views on the match extraction of globbing with comparators, actually. [16:38:30] started covering it earlier [16:38:56] --- alexeymelnikov has become available [16:39:01] --- klensin has become available [16:39:05] (match) match type is built on substring, ? matches single char that defines collation (octet, etc) [16:39:19] (or full utf8 char) [16:39:21] I agree with phil on this. [16:39:34] It isn't pretty but it is what makes sense. [16:39:37] agree [16:39:38] Yes, they match based on substring operations. That's cool. But what does the ? match for "i;ascii-casemap" - does it return the internal Thing it matched, or the octet present in the location of the original string where it matched. [16:40:20] Dave: Returning the uncanonicalized form is more useful so that's the way it should work IMO. [16:40:35] That's fine. [16:40:37] belives all implementations return octet in original string [16:40:39] My implementation didn't, but it "got better". [16:41:00] I definitely don't think that internal stuff should be exposed from comparators. [16:41:14] (We were actually inconsistent in a couple of places.) [16:41:17] will put in text to reflect that [16:41:23] a week from friday [16:41:32] in variables draft [16:42:19] ?? [16:42:56] do we make this wg item rather than individual? shrug [16:43:28] will put in base a clarification of what ? means? [16:43:38] variables draft would then build on that [16:43:52] sooner rather than later [16:44:05] need to double check w/ list [16:44:14] will be sent to IESG quickly [16:44:25] we're done. thanks for coming. [16:44:30] --- cnewman has left: Disconnected [16:44:53] --- kmurchison has left [16:44:56] Night night, all, then. [16:44:58] --- tonyhansen has left [16:45:30] --- cyrus_daboo has left [16:45:37] --- klensin has left [16:45:45] --- Dave Cridland has left [16:55:26] --- alexeymelnikov has left [17:00:38] --- kjetilho has become available [17:02:49] --- resnick has left [17:09:09] --- Glenn Parsons has left: Disconnected [17:15:59] --- lisa has become available [17:19:23] --- Glenn Parsons has become available [17:27:24] --- Glenn Parsons has left: Disconnected [17:38:21] --- shmaes has left: Disconnected [17:45:13] --- lisa has left [18:22:30] --- NFreed has left [19:07:24] --- pguenther has left