[12:18:04] --- fleegix has joined
[12:18:25] --- fleegix has left
[12:21:00] --- fleegix has joined
[12:22:56] --- fleegix has left
[14:22:45] --- newcat has joined
[14:23:59] --- bkirsch has joined
[14:24:12] --- bkirsch has left
[14:43:49] --- newcat has left: Replaced by new connection
[14:48:30] --- newcat has joined
[14:50:03] --- newcat has left: Replaced by new connection
[14:50:04] --- newcat has joined
[14:50:04] --- newcat has left
[14:53:31] --- Randy Gellens has joined
[14:54:57] --- is has joined
[14:55:18] --- is has left
[14:55:29] --- newcat has joined
[14:55:58] --- newcat has left: Replaced by new connection
[14:57:34] --- Ienup Sung has joined
[14:58:13] --- fujiwara has joined
[15:00:37] --- klensin has joined
[15:01:43] --- eric has joined
[15:03:39] --- resnick has joined
[15:05:27] --- klensin has left: Replaced by new connection
[15:06:03] --- bkirsch@jabber.org has joined
[15:10:26] --- resnick has left: Disconnected
[15:12:38] --- Randy Gellens has left: Logged out
[15:13:59] --- tonyhansen has joined
[15:16:42] --- pguenther has joined
[15:17:36] --- klensin has joined
[15:22:15] --- fujiwara has left: Disconnected
[15:31:19] --- Randy Gellens has joined
[15:32:02] --- Randy Gellens has left
[15:32:30] --- fujiwara has joined
[15:32:55] --- jaap has joined
[15:33:40] --- cyrus_daboo has joined
[15:33:45] --- klensin has left: Disconnected
[15:37:18] --- fujiwara has left: Disconnected
[15:45:19] --- lisa has joined
[15:46:28] <lisa> There's been no logging of the meeting in here? (I expected to see some earlier msgs)
[15:48:56] <tonyhansen> no, unfortunately
[15:49:36] <lisa> Is there a need?
[15:50:18] <bkirsch@jabber.org> I was hoping to track events as they unfold but can read the notes at a later date
[15:50:25] <lisa> Ok.
[15:50:41] <eric> my very bad notes:
[15:50:57] <eric> VI. Internationalized Email and Extensions (IEE) A. John Klensin 1. Approach a. explore one approach thoroughly, rather than debating approaches i initial target is experimental RFCs and impelemtnation b. strong protection, via SMTP Extensions, of existing in frastructure c. Multiple docs to i spread work around ii permit some async development 2. Framkework a. draft-klensin- 3. Model a. SMTP Extension b. MAIL & RCPT verb parameters c. Address fields in headers go to UTF-8 i encoded words optinoally do too ii non-address IDNs in headers stay in Punycode? 4. Downgrading a. Different constraints i in cross-net transport ii between delivery MTA and user software b. May not be as important as generally assumed c. Probably no elegant general solution i but important cases can be covered 5. Lots of work to be done a. Hard engineering and analysis, not magic b. Protocols may be easier to implement than to describe c. Need to watch implications of downgrading to, e.g., signed headers d. message/rfc822bis??? B. SMTP Extension for Internationalized eMail Address Jiankang YAO yaojk@cnnic.cn 1. EHLO IMA keyword a. No parameter values 2. Optional parameter ALT-ADDRESS for MAIL and RCPT for downgrading 3. IMA extension is to protect UTF-8 encoded envelope and headers C. Transmission of Email Headers in UTF-8 Encoding, Jeff Yeh, TWNIC 1. Use Unicode on email header bodies (sic) 2. UTF-8 permited only if IMA advertised 3. Header name rules not changed 4. Does not change date and time specs D. Downgrading 1. Kazunori Fujiwara 2. Options a. bounce mail to sender b. downgrade to RFC2821/2 3. Envelope downgraded to ASCII a. use ALT-ADDRESS if available b. autoatic conversion to ACE from IMA (may require another SMTP parameter 4. Headers need conversion of UTF-8 data to ASCII a. how to encode depends on each header field 5. Can occur before sending, after reception, or in the middle (hardest 6. Present doc just a sketch 7. Many known issues that will have to be worked through E. Q&A 1. Ted Hardie a. why is downgrading not a problem? b. <Klensin> because localized messages tend to be within a single community c. <K> experience shows that 8BITMIME wasn’t downgraded much (just bounced); world finally upgraded and it became a non-problem 2. Chris Newman a. you are “just slightly” underestimating the importance of upgrade b. Charter should have at least an experimental doc on downgrade to go out with base docs c. Mail systems are made up of lots of components, all of which have to be upgraded d. Will work on one subsystem at a time, there will be lots of releases e. “Standards quality downgrade” will take to long f. 2231 one of the nastier issues g. <klensin> first issue is user agent 3. Keith Moore a. Supportive of non-english characters in email addresses b. Familiar with problems of encoding everywhere except display, e.g., cut-and-paste breaks c. Need to think about user presentation, particularly in mixed environments (new/legacy). d. SMTP is the last problem, not the first e. Don’t want to see email fragmented f. Support the concept, but need to be extremely careful g. <klensin> about time we got started on this, because there is a lot of work to do 4. Chris a. IMAP and POP drafts need to be created b. Re: Keith’s point about user experience, do want to think about upgrading punycode at MUA c. (<klensin> Punycode known to not work) 5. Dave Crocker a. Not sure I understand b. Focus seems to be an SMTP-based mechanism c. Supporting non-ascii names seems obvious and non-controversial d. Hop-by-hop enforcement focus will impact more than just mailbox names (am I interpreting him correctly?) e. Mailbox string needs to be in message content as well as protocol f. <klensin> mail has a lot of information leakage g. people find encoding unacceptable h. this proposal is essentially starting with a few assumptions and following the logic through i. <dave> leakage not tied to non-utf-8 — utf-8 is just an encoding j. <pete resnick> utf-8 different because of wide adoption — it’s the new 8859-1 k. <chris> problem of i18n local-parts fundamentally different than IDN l. IDN has no negotiation model, forcing us to ACE m. with local-parts we have SMTP negotiation 6. Pete Resnick a. work done so far is a good framework, but it’s the easy part. b. the end systems are the real hard work (user agents, etc.)
[15:51:18] <lisa> There's some stuff I'm not entirely following about rollout and how i18n email addresses being used in generally closed circles among "consenting adults" would leak out to agents that don't do this i18n.
[15:51:18] <eric> sorry, not complete, i had someone IM me.
[15:51:39] <lisa> Thanks Eric :)
[15:51:39] <eric> that's one of the major discussions right now.
[15:52:09] <lisa> Yeah I'll have to find some time to reflect on this to grok it better
[15:54:20] <lisa> Philip is saying: We all love Unicode. Some east Euro country had a character set that they prefered. There is some possibility that if we just say "send UTF8" without labeling it as such, we might find people sending 8bit data that isn't actually UTF8.
[15:54:52] --- resnick has joined
[15:55:34] <lisa> The author is saying: In China more than 1 billion persons use internet. Our email systems all support transport use GP ?? code translate db code to unicode. So we don't have this problem.
[15:56:32] <lisa> Philip: Is there a requirement to tag for language of the object? Is this going to be needed for address local part or are those just symbols? For prose like Subject header, will we need Subject-Language header?
[15:57:15] <lisa> Harald: There's a not-widely implemente standard for tagging language of email headers (RFC2231)
[15:57:45] <lisa> Harald: The need for language tags on little pieces of text smacked into email headers: the market has decided that, more or less.
[15:58:17] <lisa> Philip: So the consensus is we thought we needed this before but now we think we don't need it?
[15:58:26] <lisa> Harald: We have to discuss that here. It's an itneresting subject.
[15:59:10] <lisa> Ted: I'm a consenting adult. John pointed out that there are consenting adults out there that use i18n messaging all the time. Do we need a mechanism for people to indicate that they're inthat popluation of consenting adults?
[15:59:42] <lisa> Ted: Keith's point is tremendously important here. We have mechanisms that obscure who we're talking to -- e.g. mailing lists.
[16:00:39] <lisa> Ted: One concern I have is there's a constantly moving target. Handling that over time even for the reply-to case is hard. We may face an engineering trade-off: there may be points along the transition curve where for one or more people, this will fail.
[16:00:55] <lisa> Ted: If that's true, we need to decide whether things fail for the consenting adult or the non-consenting.
[16:02:02] <lisa> JohN: The piece of this work I'm most afraid of lies right in that area. If something passes through multiple levels of indirection... there are agents that decide that something unfamiliar is hostile and they throw it away.
[16:02:30] <lisa> John: This is why we need to work through a particular solution and I predict we will be able to go through it but that's it.
[16:03:05] <lisa> Chris: To make me happy, the charter needs to say that the downgrade draft needs to go out at the same time as the others. Fine if it's Informational.
[16:03:23] <lisa> Chris: We also need the POP draft. We don't need the IMAP draft, it's too complicated. The POP draft is an important proof of concept.
[16:03:42] <lisa> Chris: If you don't have a volunteer for the POP draft, it's an interesting problem and I think I can get my teeth around it.
[16:04:06] <lisa> Chris: If we don't address this at all we're not being diligent enough, OTOH we can't solve all the problems right away.
[16:04:42] <cyrus_daboo> MUAs are important. There are still many MUAs in use today that do not support utf8 even in the message body. So I agree with Chris.
[16:04:44] <lisa> Randy: We can't have the SMTP stuff advance without also advancing IMAP and POP. We really need a way to make sure that on retrieval, we can have identification as a consenting adult.
[16:05:17] <lisa> Macro?: I haven't been able to find a syntactical definition of the local part. This is important and sensitive.
[16:06:30] <lisa> Dave: All the focus in the proposals is on mechanisms able to do clear, walled gardens. John doesn't like that I'm saying that. This is about notifying the next thing down the line that this is a new kind of object. I'm focusing on the object because we have experience with this object stuff which has demonstrated a problem.
[16:07:15] <lisa> Dave: We have a default charset for messages: ASCII. You only put the charset on if you're doing something other than that. But in particular "gardens" in the world, they change the default, but not the label. Big surprise, this leaks out. Outside, they belieeve it's ASCII and can't use it.
[16:07:22] --- kmurchison has joined
[16:08:23] <lisa> Dave: We need the object labelled to say that it's special. I'm inclined to say the message ... if the mailbox string is picked up in its raw form and moved, the s/w will enforce rules or be broken and get fixed. Whereas if I pick up the msg object and move it around, the s/w won't look deeply inside...
[16:09:54] <lisa> Tony: We need MUA guidance.
[16:10:29] <lisa> Keith: I'm confident protocols will be affected. If you do not pay attention to the user experience and define mechanisms from there *before* you touch protocols, you will not like the result.
[16:11:00] <lisa> John: Whatever it is IMAP needs to be done, POP needs to be done.
[16:11:09] --- fleegix has joined
[16:11:14] <lisa> John: There is not as great generalizability.
[16:11:38] <lisa> Chris: I agree we need to do both. First, I strongly agree with Keith. Underlying all these proposals is focus on the MUA issues.
[16:12:13] <lisa> Chris: Let me suggest we need the MUA draft. It describes what an MUA does when the ugly local parts leak.
[16:12:20] <cyrus_daboo> What about other protocols that use or store email addresses? Are people going to analyze LDAP, ACAP or whatever etc to see how they are potentially impacted by utf8 email addresses? Remember, as Keith pointed out, the user experience of email goes beyond just messages, it certainly impacts address book interactions.
[16:12:25] <lisa> We do need to be informed by the MUA experience.
[16:12:42] <lisa> --- cyrus this is me speaking now --d o you want us to bring that up at the mike?
[16:13:17] <Ienup Sung> I also would like to second on what Chris and Keith talked about. We should also pay attention to MUA to
[16:13:19] <lisa> Harald sez: I'd like to switch topics to the charter discussion.
[16:13:44] <Ienup Sung> be sure about the whole picture.
[16:14:01] <cyrus_daboo> Yes - I think it would be good to mention the address book issue, and also add my vote for MUA draft.
[16:14:03] <lisa> Randy: On the importance of the POP IMAP stuff, there are cerntaly agents sending i18n amongst themselves and they're all consenting, but we really do need the POP and IMAP changes, because you can't just generalize those happy communities to the internet at large, it won't be happy.
[16:14:23] <lisa> ok
[16:14:55] <lisa> I aksed cyrus quesstion
[16:15:04] <lisa> Anon in the audience answered "No" :)
[16:15:11] <resnick> Cyrus: Are you writing the document? ;)
[16:15:13] <cyrus_daboo> Thanks Lisa.
[16:15:32] <lisa> Cyrus are you on audio?
[16:16:01] <cyrus_daboo> Well actually I have been asked to write a revision to vCard as part of the CardDAV effort I am involved in. Anaylsing how utf8 addresses might fit into that would be intersting.
[16:16:09] <cyrus_daboo> I do have audio.
[16:16:22] <lisa> Harald: The things I've heard hear, there's massive support for going forward with the work
[16:16:52] <lisa> Harald: There's a number of work items. Isuggest to take the charter text and add one piece and clarify one piece.
[16:17:11] <lisa> Harald: Add that the set of experimental RFCs produced will include documents on POP and IMAP and handling IMA on mailing lists.
[16:17:47] <lisa> Harald: The charter now has a two-phase approach, getting experimental docs out, then we should have enough running code to decide what next.
[16:18:03] <lisa> Harald: The LDAP, blah blah, should be evaluated.
[16:18:24] <lisa> Harald: A separate document about user experience, or part of the architecture? The important thing is that we think about it and get the thinking written down.
[16:18:43] <lisa> Harald: I get one set of impressions from what's currently in the doc.. Since Keith reads the same and thinks it's not clear enough, it's not clear enough.
[16:19:05] <lisa> Harald: Comment: Is this a reasonable basis for a charter to ask IESG to form a WG?
[16:19:57] <lisa> Keith: I feel like a broken record. I'll say it in a different form. The first object in the charater should be a document saying how the user experience will work with legacy systems. From that should follow a description fo the pieces of tech.
[16:20:27] <lisa> Keith: If you don't do things int he right order, you get a mess.
[16:20:35] <lisa> Harald: If you don't do things in the right order, you get things done.
[16:21:05] <lisa> Pete: It will take interesting management to get this done, but: trying to deliever a doc on the model before work begins would be counter-productive.
[16:21:36] <lisa> Pete: The work, thinking, on the model, needs to get done, up front. Is there some way to work on model without a deliverable RFC document.
[16:22:02] <lisa> John: I am worried what this desired user experience document means.
[16:22:26] <lisa> John: This would be the first one ever done inthe IETF . I dont want to make that a gating item for other work getting done.
[16:22:49] <lisa> John: We don't have the expertise; it's beyond our capabilities; it's complex; it depends on cultural context. I want to see that task constrained and not a gating factor.
[16:23:34] <lisa> Keith: let me clarify; When you send mail out with UTF8 address, and other recipients don't support display, something needs to happen. Define what that is. You can call it an ugly form of address, but what kind of ugly.
[16:23:47] <lisa> Keith: It's not about defining the entire recipient GUI, it's about choosing the form of that.
[16:24:39] <cyrus_daboo> PS If its not already on the list of things to 'fix': the mailto URI scheme will need some work too.
[16:25:24] <lisa> Keith: It's understood that if we don't address this poeple will do something without us, but trying to tell what the directionis before we know the long term consequences is not good for anyone.
[16:25:46] --- klensin has joined
[16:25:53] <lisa> Dave: I'd like to see an extra paragraph. The gist of what's missing is in a sentence on a mechanism, as an afterthought "here's why we're doing it.".
[16:27:04] <lisa> Dave: You need a real architectural framework explaining the focus on modifying SMTP to keep gardens of consenting adults separate.
[16:27:36] <lisa> Dave: this is not unlike years ago, when we had people that just did 8bit, and we gave them a way to say they were doign that.
[16:27:48] <lisa> Ted: Responding to Keith: THe main thing here is to make sure that the email system doesn't fragment.
[16:28:18] <lisa> Ted: We understand there to be communities that use email this way now, and we look for the aiblity to turn those from walled gardens into open gardens, and specify how to participate if you care to.
[16:28:47] <lisa> Ted: Your concern for the user experience is important, but there are already 10s of milllions of users that get this experience nwo. We 're not trying to explain that, but how to integreate into the larger email system.
[16:29:36] <lisa> Keith: There are multiple ways to fail, and fragmenting the email system is one. People to have to manually manage their technology based on who they're talking to is another. They're both bad, both need to be avoided.
[16:30:17] <lisa> Keith: Legitimizing practice done in isolated places is often the wrong thing to do. We're still on the wrong track with NAT, we don't need to be on the wrong track with email too.
[16:31:28] <lisa> Harald: I'd like show of hands, ask you three questions. First, should the work of this charter (in a final format) be sent to IESG requesting a working group.
[16:31:33] <lisa> Harald: Second: Should we stop working on this.
[16:31:39] <lisa> Harald Third: will youhelp.
[16:31:50] <lisa> Harald: First question: Should we work on this charater
[16:32:01] <lisa> Harald: Yes? That's a substantial majority.
[16:32:09] <lisa> Harald: SHould we stop? Nobody.
[16:32:22] <lisa> Harald: Are you willing to help? Wow [significant hands went up]
[16:32:29] <lisa> Pete: I'd like to see who is willing to write code.
[16:32:52] <lisa> Keith: For Pete's question to be meaningful, I'd like to know who will write user agent code.
[16:33:21] <lisa> [one small scared hand went up and that was me]
[16:33:31] <lisa> Harald: How about server? 6-8 hands.
[16:33:45] <cyrus_daboo> [well if I was still in that business I would defintiely do it]
[16:34:02] <lisa> Harald: You have a task. Find your favorite MUA implementor and help him. Or her.
[16:34:24] <lisa> Keith: If you don't have enough MUA implementors in the room it's hard to know if what you're doing is realistic.
[16:34:38] <lisa> Harald: Mailing list is ima@ietf.org.
[16:35:25] <lisa> Harald: The group will continue work on the charter on the mailing list, find a chair, all the usual stuff, and will then continue the conversation with our area director.
[16:35:30] <lisa> Harald: Thank you for coming.
[16:36:17] <tonyhansen> ima-request@ietf.org to subscribe
[16:36:25] --- eric has left: Logged out
[16:36:28] --- tonyhansen has left
[16:37:35] --- fleegix has left
[16:39:16] <Ienup Sung> Thanks very much, Lisa and Eric for scribing! (If you need MUA coding help, please let me know.)
[16:39:47] --- Ienup Sung has left
[16:42:00] --- jaap has left
[16:46:53] --- pguenther has left
[16:47:10] --- lisa has left
[16:47:48] --- resnick has left: Disconnected
[16:47:56] --- cyrus_daboo has left
[16:56:46] --- klensin has left
[17:20:45] --- bkirsch@jabber.org has left: Logged out
[21:19:09] --- kmurchison has left