[00:26:34] Exodus joins the room [00:26:38] Exodus leaves the room [00:26:44] yone joins the room [00:27:26] healthyao2000 joins the room [00:27:58] healthyao2000 has set the subject to: EAI @ IETF 77 [00:35:01] yu kyung joins the room [00:35:10] yu kyung leaves the room [00:36:01] shawnsteele joins the room [00:38:19] xiaodong joins the room [00:40:38] Dave Thaler joins the room [00:41:15] yu kyung joins the room [00:41:25] yu kyung leaves the room [00:41:50] joseph.yee joins the room [00:42:04] Dave Thaler leaves the room [00:42:15] ɹəlɒɥʇ əʌɒp joins the room [00:43:32] Randall Gellens joins the room [00:43:50] Barry Leiba joins the room [00:43:54] YATSUGATAKE joins the room [00:44:05] fujiwara joins the room [00:44:24] agenda bashing now [00:44:28] agenda bashing? none from room [00:44:42] rgonzalez joins the room [00:44:57] YATSUGATAKE is Martin Dürst [00:45:02] yu kyung joins the room [00:45:30] resnick joins the room [00:45:41] joseph: I am jabber scriber today [00:46:09] Colman Ho joins the room [00:46:53] Thanks, Joseph! [00:48:36] pete resnick - volunteer to mailing list proto writer for mailing list [00:49:00] Downgrade discussion [00:49:20] based on section 6.5 of RFC 2418 [00:49:30] Downgrade design team formed [00:50:17] downgrade result introduction by Yao [00:52:32] Yao: design team met several times to investigate the problems around EAI downgrade [00:53:28] Yao: 1) declared pair address, eg: alt-address [00:53:44] 2) discoverable fallback address [00:54:14] jaeyounkim joins the room [00:54:23] 3) no fallback [00:54:45] 1) address pairs reviewed and rule out [00:54:58] the mechanism are inherently fragile [00:55:05] 2) fall back address [00:55:24] - do not require alt-address [00:55:31] - no need to be visible in core doc [00:55:52] - discussion to continue in parallel to group [00:55:59] 3) no fall back [00:56:09] - "simple" solution [00:56:59] conclusion: DDT recommends recharter EAI to focus on core standard doc [00:57:14] RFC 5504 should be deprecated [00:57:38] - discoveralbe fall back address discuss in parallel of core standard doc [00:58:00] informational RFC of elsection of address would be helpful [00:58:14] end of Yoa's presenetation [00:58:37] chair: any comments to DDT recommendation? [00:58:42] <ɹəlɒɥʇ əʌɒp> are slides online? there's nothing at https://datatracker.ietf.org/meeting/77/materials.html [00:59:16] No, they're not. [00:59:28] yao: after years of pushing, should focus on core doc now [00:59:32] <ɹəlɒɥʇ əʌɒp> that makes it rather hard for remote participants... [01:00:01] randall gellen: concern of lack of downgrade [01:00:18] hthaler, Yao's result are in WG archive [01:00:26] dthaler, sorry [01:00:32] skudou joins the room [01:01:17] randall: concern on the POP/IMAP side, on encoding [01:01:37] <ɹəlɒɥʇ əʌɒp> I'm actually in the room but I had remote people asking me if slides were available [01:02:03] - should reivew the RFC 5504 for canonical downgrade.... [01:02:40] My comment is that POP and IMAP still need a canonical downgrade (with address encoding, not alt-address) [01:02:52] And that a revised 5504 could serve this purpose [01:03:11] fujiwara: eai program cannot ?? [01:03:27] ned freed: push off until future - bad idea [01:04:20] ned: client is best to know this info (downgrade) rather than mid server [01:04:25] jgoldber joins the room [01:04:35] Ned says client, not submit server [01:04:53] (submit server, not mid server) [01:05:01] thanks [01:06:13] ned: 3 alternatives: encode, alt-addr, some algo [01:06:38] ned: choice is hard [01:07:09] EAI un-aware client cannot access EAI message in POP server without downgrade. I think some mechanism is required. [01:07:15] yao: alt-addr has issue to phishing, and encryption prob [01:08:03] randall: 8 bit MIME could be fine [01:08:55] randall: could get address into non replyable manner [01:09:49] john klensin: mean for delivery, will come back on this [01:10:08] yao: encode could be independent on standard track [01:10:26] randall: should not go standard until how pop/imap done downgrade [01:11:16] I was saying that the equivalent of MIME encoding would be OK. Non-ASCII email addresses could be encoded into something nasty and non-replyable, such as with a requirement that there NEVER be an MX or A record for UTF8mail.arpa. [01:11:17] klensin: to ned- concerns of leak [01:11:55] leaking damage outweigh advantage [01:12:40] Sorry, don't know convention for requesting to speak: The result of the Design Team doesn't preclude further discussion of downgrade, it just moves it to a parallel track so that work on the core documents can continue. Even without downgrade, the core documents are useful, not all implementations need downgrade. [01:12:54] To Randy: Would that mean punycode(lhs@rhs)@UTF8mail.arpa? (where punycode(lhs@rhs) is a functional notation for converting the whole of the email address to punycode) [01:13:30] Yes [01:13:36] skudou leaves the room [01:15:05] klensin: hard to define downgrade, and define it at different peices [01:15:10] submission, delivery [01:16:09] pete resnick: distance between submission / delivery, but there's a break from client submission and the net [01:16:40] not sure how to avoid not knowing what happen at the end [01:19:11] randall: if no automatic downgrade outside, if client does proper downgrade, if no utf8 mailstore, it has to bounce [01:19:32] can't prevent end user coming with old pop/imap client [01:21:27] If we don't have downgrade in the network, then we say it must bounce unless there is UTF8 support all the way to mail store. [01:21:31] ned freed: submit server does not know the remote end can do utf8, or cache it, we should nto do it [01:22:15] Colman Ho leaves the room [01:22:35] ned: submit server will need not just second addr, but all ascii header [01:22:40] terrible for submit server [01:23:09] need to see more define before pushing forward [01:24:25] klensin: concerns on deployment [01:26:53] ned: client infrastructure is different, upgrade is concern [01:27:30] Colman Ho joins the room [01:27:52] randall: regards to submission server, is to reject mail if no path [01:29:04] resnick: clean path or bounce [01:29:40] The term "submission system" is different from "submission server" -- the term "submission system" means something in the submission, be it client, server, or both. In practice, this is likely to often be just the client. [01:30:51] works for closed community [01:34:23] sm joins the room [01:34:30] barry: info doc needed for deployment [01:35:32] randall: primary MX and secondary MX not consistent is problematic [01:36:33] chris newman: wg should say on submit server: dumb server or allow it to do certain thing... [01:39:25] I'm in favor of dropping downgrade :) [01:39:31] alexey: about to vote [01:39:49] chair shows back teh slides [01:40:05] objection? [01:40:18] few hands up [01:41:44] The problem is the wording of the third statement of the proposal says that we ignore downgrading at the edges (before/during submission and after delivery) [01:41:47] klensin: downgrade in transite will slow down core, with need to define addition syntax [01:42:42] yao: some may agree some points instead of all 3 points, try to vote point by point [01:43:22] ted: refer to downgrade, calling it downgrade is problem [01:44:09] would it be useful to take 'downgrade' to BOF [01:46:20] chris newman: suggest of language - interoperable to 7 bit env [01:47:43] jgoldber leaves the room [01:48:40] ted: would result in language island [01:49:20] ted: one of goal would be how to get inter island communicate [01:50:51] vote time on 1st bulletin - recharter to focus on core - objection? [01:51:21] ask 2nd point first - objection to drop RFC 5504 [01:52:16] o That we immediately recharter EAI to focus on the core standards track documents, i.e., RFC4952bis, RFC5335bis, RFC5336bis, RFC5337bis, RFC5721bis, and the in-progress drafts. o RFC5504 should be deprecated. The core documents will not rely on fallback or downgrade techniques, particularly by relays. o Discoverable fallback addresses may be investigated independently of the core documents. Any such work would be part of, or connected to, an optional MUA/submission protocol, independent of the core transport documents. [01:52:32] 1) That we immediately recharter EAI to focus on the core standards track documents, i.e., RFC4952bis, RFC5335bis, RFC5336bis, RFC5337bis, RFC5721bis, and the in-progress drafts. 2) RFC5504 should be deprecated. The core documents will not rely on fallback or downgrade techniques, particularly by relays. 3) Discoverable fallback addresses may be investigated independently of the core documents. Any such work would be part of, or connected to, an optional MUA/submission protocol, independent of the core transport documents. [01:52:55] raise hands for these 3 questions [01:53:25] I support moving forward with rechartering, etc. [01:53:43] Hyong-Jong Paik joins the room [01:54:11] tonyhansen joins the room [01:54:38] barry: downgrade display doc decision [01:54:56] cnewman joins the room [01:55:04] randall: need doc about post delivery scenarios [01:55:18] most supprot 1 and 2, no objection observed [01:55:26] (Side note: Shawn - Are you here in Anaheim?) [01:55:37] Shawn is in Bellevue, WA :) [01:55:56] ack. Too bad. [01:56:09] Dave Thaler is there from Microsoft. [01:56:36] Yeah, but I *always* give Dave a hard time. I wanted to bug someone new. ;) [01:56:48] <ɹəlɒɥʇ əʌɒp> I haha [01:57:16] Roughly the question I asked at the mic: Does the WG support moving forward on the standards track with the core documents (4952bis, 5335bis, 5336bis, 5337bis, 5721bis and the in-progress drafts) while dealing with necessary end-point 7-bit header interoperability, but omiting support for in-transit downgrading or alt-addresses? [01:57:19] James Rinker from Exchange is also listening in, and another from Live [01:57:40] alexey: annoucement of new chair [01:57:52] <ɹəlɒɥʇ əʌɒp> they're on the audio but not in the jabber room obviously [01:58:03] <ɹəlɒɥʇ əʌɒp> hence my question about slides being online [01:58:29] new chair: John Klensin and Joseph Yee [01:58:39] for the question raised by chris newman, most say yes, [02:00:13] There were no visible objections in the room to the question I asked and significant support in favor. [02:01:16] thanks for old charis [02:01:27] new chairs are on the stage [02:01:58] the new chairs are John Klensin and Joseph Yee [02:02:58] new charter discussion [02:05:46] to ɹəlɒɥʇ əʌɒp : pls see http://www.ietf.org/proceedings/10mar/agenda/eai.txt [02:06:33] now charter discussion, charter is on http://www.ietf.org/proceedings/10mar/agenda/eai.txt [02:11:08] names are cheap, getting them to be used may be very expensive [02:11:14] ned suggest to rename utf8 smtp exteion document's name [02:11:51] Ned points out we need a new name for the SMTP extension when we move to standards track, because it will be a different extension [02:12:23] It's the extension name within the protocol that needs to be changed, the document name doesn't matter) [02:13:02] Deliverables The following deliverables are foreseen in this charter. The WG chairs may (re)structure the deliverables into specific documents or document sets as needed. Adding or removing documents outside of these deliverables will require a charter update. * Overview and Framework for Internationalized Email(Info/Standard) * UTF-8 SMTP extension specification (Standard) * Header format specification (Standard) * Internationalized DSN specification (Standard) * UTF-8 POP specification (Standard) * UTF-8 IMAP specification (Standard) Additional possible documents suggested: * Advice for MUA implementors (Info) * Advice for EAI deployment (info) * Advice for non-ASCII and ASCII addresses for the same mailbox (Info) * Mailinglist(info) * Mailto(Standard) [02:13:09] My proposal at mic: I think we need a submission protocol extension. It can be done experimental. Without it, any list of recipients with a 7-bit only recipient will fail. That's OK but some people will want to do better so we need to give them something better to do optionally. [02:13:10] no obejction to aboce [02:13:20] no objection to above [02:14:07] Are we Ok with the goals/milestones? [02:14:13] Slight tweak to Chris' text: It's OK for a Submit server to reject any messages with non-ASCII address if it can't deliver them, but people will want a way to do something smarter, so we should provide this as an experiment. [02:14:33] Thanks, Randy. [02:14:43] Barry Leiba leaves the room [02:14:49] cnewman leaves the room [02:15:21] sm leaves the room [02:15:48] ɹəlɒɥʇ əʌɒp leaves the room [02:16:05] yone leaves the room [02:16:19] tonyhansen leaves the room [02:17:02] resnick leaves the room [02:17:34] Randall Gellens leaves the room [02:19:29] shawnsteele leaves the room [02:25:26] joseph.yee leaves the room [02:26:06] xiaodong leaves the room [02:30:37] yu kyung leaves the room [02:31:09] yu kyung joins the room [02:31:55] Hyong-Jong Paik leaves the room [02:32:34] YATSUGATAKE leaves the room [02:38:18] healthyao2000 leaves the room [02:45:46] jaeyounkim leaves the room [02:54:09] yu kyung leaves the room [03:09:47] healthyao2000 joins the room [03:16:29] rgonzalez leaves the room [03:18:48] healthyao2000 leaves the room [03:18:51] healthyao2000 joins the room [03:27:49] healthyao2000 leaves the room [06:21:21] fujiwara leaves the room [06:43:31] Colman Ho leaves the room [21:51:37] KIM K joins the room [21:51:51] KIM K leaves the room