[16:03:15] Alexey opens meeting [16:03:33] agenda bashing [16:04:14] Aaron Stone: do we want to hum on doing anything with ManageSieve [16:04:24] I support publication of managesieve [16:04:25] Alexey: yes, ManageSieve to be added to agenda [16:05:13] Ned (or anyone else remote)--if you'd like a comment to be channeled, please say so [16:05:18] Gee, thanks [16:05:24] Working group status: [16:05:37] Slew of RFCs in RFC Ed Q (all hail Ned!) [16:05:55] bunch more in IESG processing [16:07:16] Phil: Body document needs some nits fixed, he will upload new rev tonight [16:07:30] Phil: EditHeader will be last called with others [16:07:50] Alexey: Notify past IETF LC, no substantive comments, details later [16:08:07] Alexey: Notify-mailto had substantial comments from Ned, new rev needed [16:08:26] Alexey: Notify-xmpp, no substantial comments from IETF LC [16:08:37] Alexey: other documents [16:08:58] Switching over to Alexey's notification slides. [16:09:07] I'll get back to regex once date/index is off my plate [16:10:18] Alexey: notifications draft [16:10:39] We will discuss RegEx/WG long term status at the end... [16:10:44] two revs since Chicago, then AD comments causing more canges [16:12:10] Deferring registry definition seems reasonable to me [16:12:52] Comments on Notifications draft include suggestion that an extra IANA registry be created for "notifications capability", but as this is not expected to grow, seems reasonable to defer creation of registry [16:13:21] Registry would currently only contain "is online" and "I don't know" [16:14:08] Sieve notification methods registration template: should it be "tags" or "options"? [16:14:38] Barry: I did mean "tags", there are 4 tags now defined [16:14:50] Barry: an extensions that defines notification mechanism might add new tags [16:15:14] Barry: then we created options, do mechanisms need tags or just options? [16:15:43] Barry: so we need to decide: allow extensions to create tags? If so, we need registry. [16:16:07] Alexey: if we add this we'll need a new capability (otherwise scripts could break) [16:16:41] Barry: propose to specify how to create a notification mechanism, be very explicit [16:17:12] Barry will change registry to be registry of options, add text that notification mechanisms can not add tags (MUST NOT) [16:18:31] Aaron: where are we with adding/creating tags, options? [16:19:36] Registry text needs to be clear on how to parse options [16:21:20] Alexey: registration template for mechanisms now says only standards or experimental RFC. Is this too strict? [16:21:34] Barry: needs only stable reference and IESG approval [16:24:11] ??: Do we need IESG approval? [16:24:44] ??: We currently need IESG approval for everything except independent submission [16:25:14] Kurt: say that any name starting with "E" is first-come first-served [16:25:54] E or "E-" [16:26:24] E, not X, because X is for private use [16:26:25] Pete: private use tags leak [16:26:28] +1 for Pete's point... [16:26:46] ??: Sieve scripts don't leak onto the Internet [16:26:59] Barry: intent of Sieve is that the scripts get moved around [16:27:01] unless you post your script to your blog and say OMG MY EMAIL IS TEH ROXX! [16:27:04] Private tags will leak [16:27:55] Pete: experience with email headers has been that experimental tags don't work, they leak, but then can't be registered [16:28:20] Pete: don't use x- at all, it is a disaster [16:28:31] Exactly. I really do not want to be forced to implement support for someone else's notification method sans docs [16:29:05] Dave Crocker: X- was a mistake. Public space for private conventions was a mistake. Intent of X- is that they will never get standardized, but of course some became popular [16:29:35] Dave: private space for exp., exp. becomes production [16:29:51] Dave's point is key - experiments have a nasty way of becoming production when we're not looking [16:30:12] Dave: if it can be dangerous, require approval, if there is no danger, then make it easy to register [16:31:02] Ned -- what causes you to be forced to support for someone else's extension? [16:31:13] Here's what 3028bis says: [16:31:15] 6.1. Capability String Capability strings are typically short strings describing what capabilities are supported by the server. Capability strings beginning with "vnd." represent vendor-defined extensions. Such extensions are not defined by Internet standards or RFCs, but are still registered with IANA in order to prevent conflicts. Extensions starting with "vnd." SHOULD be followed by the name of the vendor and product, such as "vnd.acme.rocket-sled". [16:31:16] Big customers have a way of making demands [16:31:38] Mark: years ago I created an X-, and later was flamed for not correctly implementing it, even though he'd created it [16:31:58] Ned -- what I'm asking is what can be done with the namespace to make this more or less likely? [16:32:27] Lisa: it was a mistake to ??? [16:32:30] IMO vendor tags are the apprpropriate compromise [16:33:09] Barry reads prior docs, which say that everything other than "vnd." requires IESG approval [16:33:10] X- is for all intents and purposes an attractive nuisance. [16:34:56] Pete: "vnd." tags are an OK compromise. But the problem is that it becomes someone else's responsibility. Pete creates "vnd.pete.cool-thing" ad registers it. It can never move over to standards track. [16:35:19] Others say that "vnd." can be standardized [16:35:49] Good. So we will have standardized extensions with potentially funny names. That's OK. [16:35:59] Pete, the situation is a little different from headers. I don't see a problem with retaining the funny name, but if you [16:36:23] want to there's nothing to prevent an implementation from supporting two names for a mechanism. The key [16:36:29] --- hta has joined [16:36:42] difference between this and headers is with headers you can end up with both fields in a single message and have [16:36:55] a silly state. That won't happen with notification methods. [16:37:00] Barry suggests "Specification Required" [16:37:11] Ned, yes, agreed. [16:37:19] I am now made content. [16:37:33] Then you're doing much better than I am... [16:37:37] ;) [16:37:47] Contextual contentness. [16:37:58] Indeed [16:38:43] OK Pete, you're on the hook to specify vnd.pete.cool. When can you have a draft ready? [16:39:41] We have published RFCs defining media types in the vnd. space. [16:40:02] OK, I cam convinced [16:41:25] So Pete comes up with "vnd.pete.cool-thing". He implements it in his Sieve engine. Alexey loses a bet to Pete and is forced to also implement it. Someone sees scripts posted on a blog and pressures his vendor to also support it. So Pete writes the thing up, gets it published, and then updates the registration to point to the RFC. [16:42:06] did I just hear that a standard notification mechanism might get vendor options? [16:42:43] notify :options "vnd.crazymail.something=Special Crazy" "mailto:foo@bar.com"; [16:43:17] as opposed to notify :options "something=Special" "vnd.crazymail.mailto:foo@bar"; [16:46:39] Sieve-mailto [16:48:27] Barry will add "Auto-submitted" [16:49:05] suggestion to add a parameter to auto-submitted to include the email address of the script owner [16:49:25] Recommendation that "From:" be owner of script, but it can also be global identifier [16:50:19] I was thinking of using it for filtering. Kind of a sender: field. [16:50:20] What is the intent of the email address parameter on auto-submitted? Extra filtered? Ignore? Spam? [16:50:43] Barry: if auto-submitted is omitted, mail loops are likely [16:50:47] it's also plain useful for tracking down the causes of loops for application of beatings [16:51:13] Both of those uses only apply if the email address is there [16:51:25] If it is optional, why would anyone include it? [16:51:44] Barry suggests a non-Sieve BCP on mail loops [16:52:32] But this issue really is specific to this sort of notification [16:53:11] Exactly. This specific loop is unique to this mechanism. [16:53:25] Chris: this draft introduces more severe mail loops [16:53:31] Notify doesn't preserve Received: fields. Redirect does. [16:54:31] This doc could be approved with a dependency on another document [16:54:47] the other document being a mail loops one [16:55:32] Barry: if the doc is approved but waiting on a dependency, people will know it is stable [16:56:32] Randy: but if the doc is in the rfc ed q and then the mail loops doc needs to change this, it will be bad [16:56:58] Barry: this document has already done everything it can on mail loops [16:57:36] Cyrus asks why this isn't a problem is XMPP, since there are XMPP-to-email gateways [16:57:46] Lisa: yes [16:58:03] Lisa: this may require the ability to track forks across protocols [16:58:21] But such gateways aren't specified by the IETF. I see real problems with trying to solve the general cross-protocol [16:58:23] looping problem. [16:59:24] Lisa: there are lots of such gateways, including an SMS URI that is partly squelched [16:59:30] did X.400 <--> SMTP gatewaying work ever formally deal with the looping issue [16:59:31] ? [16:59:45] Yes, X.400 gatewaying did. [17:00:04] Pete: agrees with Ned; [17:00:10] "we don't do gateways here" [17:00:36] Yes, the X.400 "solution" to this problem was hideous. [17:00:49] Barry: that's why we need a BCP [17:00:58] It involved a header extension that was hard to implement and practically nobody got right. [17:01:47] Dave Crocker: we need to do this, but acknowledge that it is bad [17:01:55] I agree that we have done gateways. And since we have our feet on both sides of XMPP<->email picture, we might [17:02:11] be able to handle that. But I cannot seriously believe we can deal with sms this way. [17:03:02] +1 This is WAY outside this group's purview. [17:04:13] No, vacation doesn't. [17:04:30] Vacation has timers that prevent messages from being sent too often. [17:04:33] ??: this is outside the scope of this group. Let's do what we can in NOTIFY and then let it block on the solution. [17:04:41] ??: This is also a problem for Sieve Vacation [17:05:23] Why don't we just ask the IESG for advice on how to proceed/ [17:07:24] Nice summary Randy. [17:09:05] Suggestion: This needs to go to the list. [17:10:59] Randy: sending any sort of mail automatically in reaction to a message with a null MAIL FROM causes mail loops. The only currently working way of preventing mail loops is to not send any auto mail in reaction to a null MAIL FROM. Thus, allowing this for NOTIFY invites mail loops [17:11:11] ??: But I want to be notified of a bounce to an important message [17:11:19] I don't think the message was sent to the list. Do you want me to do that now? [17:11:23] Randy: Odds are the bounce is blow-back and not useful anyway [17:11:51] ??: There are techniques to avoid blow-back, when those are used, notifications of boucnes might be useful [17:12:04] 6 [17:12:28] should there be a specific test that determines if a message is a bounce, rather than a heuristic test on the null mail from? [17:12:39] Ned - please send to the list... [17:12:48] Randy: Given that automatically sending mail in response to null MAIL FROM is a known problem, suggestion that this be prohibited in initial version. let someone implement doing so in a private extension, see how it works, then publish extension [17:13:05] Discussion of preserving Received headers in notifications [17:13:29] Discussion of classifying auto-submitted as trace field [17:14:02] Barry: lots of challenge-response systems don't use auto-submitted headers [17:14:09] Done. [17:14:13] Thanks. [17:14:16] Barry: not much we can put in the document that is an improvement [17:15:15] Barry: could keep table of email addresses in incoming mail, and don't act on more mail from same source in short time [17:15:28] Cyrus: take to list, then maybe take to IESG [17:17:09] Barry: one solution would be to require that bounces contain auto-submitted, but it is too late for that [17:17:21] ??: require that all notifications be sent with a null MAIL FROM [17:17:49] Barry: current text says it should be mail box of script causing notifications, or be a global address [17:17:56] Doesn't solve the problem. Remember, envelope from only comes into play when there's a failure. [17:18:01] "??" is Jeff Hutzelman. [17:19:03] It does solve the specific issue I raised in my message, but not some others. [17:19:34] yay I has a name! [17:20:12] you do? [17:20:36] Barry: even requiring auto-submitted doesn't solve the problem, because not everyone looks at that (challenge-response) [17:20:41] Barry: Randy has concerns [17:23:52] http://tools.ietf.org/html/draft-degener-sieve-multiscript-00 [17:23:54] ? [17:23:59] Randy summarizes the issues with per-client Sieve scripts, and couldn't resist describing Sieve as two somewhat different use cases [17:24:35] (My message was sent to the lemonade mailing list, and that's where this discussion was held) [17:25:03] Cyrus suggests adding a command to manually execute a Sieve script [17:26:28] Randy: there were suggestions on the lemonade discussion that per-client Sieve scripts should be a delivery feature, not a mailbox feature [17:26:32] it would be neat to combine "run the script in the /sieve/foo annotation" with "here's my search result key" [17:26:34] So it belongs here, not Lemonade [17:27:38] Alexey: what extensions are needed to allow this? [17:27:47] Cyrus: need a way to make this interoperate [17:27:58] phil: do we need to ressurecent multiscript? [17:28:16] Phil: also need extensions to managesieve, which isn't a WG draft [17:29:14] Phil: hard to come up with way to make this not order dependent [17:29:54] Randy: my text suggested a way to make the scripts not order-dependent, by restricting what non-primary scripts can do, so those actions can't stomp on each other [17:32:17] OK, I am lost on the scribing [17:32:21] Help? [17:34:08] Zoltan: there are shared mailboxes [17:34:37] Discussion that allowing multiple scripts can let users shoot themselves [17:35:05] Dave: this community is not competent in human factors [17:36:03] Randy: everything we do can be implemented by clients in a way that makes it easy for non-email-engineers to shoot themselves [17:36:15] Eliot: agrees with Randy [17:36:50] http://hydricacid.com/ietf/70-vancouver/reject.html [17:39:05] Aaron: Reject [17:39:17] Now two actions: reject and ereject [17:39:27] Do we replace or obsolete the ereject action? [17:40:17] everyone is ok with replacing it, no one has implemented it [17:40:25] downref to LMTP? That seems OK. [17:42:15] http://hydricacid.com/ietf/70-vancouver/managesieve.html [17:43:14] Cyrus: MIME loops issues [17:53:24] Not for the purposes of replacing sieve format, only to make sieve accessible to more agents... [17:54:57] Date/index and ihave are ready to go IMO. [17:55:00] Cyrus: we've almost completed all key charter documents [17:55:14] Do we want to adopt individual docs, close down WG, or what? [17:55:29] Cyrus: do we want to move original documents to draft? [17:55:44] Alexey: we are chartered to move base spec to draft