[00:00:25] <harald> so back in 1.5 hours.
[00:00:28] <harald> talk to you then!
[00:01:41] --- fujiwara has left: Logged out
[00:01:41] --- harald has left: Lost connection
[00:02:17] --- harald has joined
[00:02:52] --- klensin has left: Disconnected
[01:41:47] <xiaodong.lee> we are back
[01:43:03] <harald> let's see if we can bring everything back up....
[01:47:25] <harald> xiaodong, tried to call you on skype. no answer yet.
[01:54:21] <harald> wait a bit - somethin's wrong.
[01:54:30] <harald> I can hear you.
[01:59:39] --- xiaodong.lee has left
[02:00:02] --- harald has left
[02:03:02] --- xiaodong.lee has joined
[02:04:01] <xiaodong.lee> harald is restarting his computer
[02:04:09] <xiaodong.lee> please wait a moment
[02:05:33] --- fujiwara has joined
[02:07:38] --- harald has joined
[02:11:25] <yangwooko> (Harald) Header encapsulation has problem with section 2.5 of scenario doc.
[02:13:10] <xiaodong.lee> fujiwara-san response harald's question
[02:13:17] <yangwooko> (Fujiwara) ASCII user will be able to reply to original sender.
[02:14:07] <harald> the requirement of section 2.5 is that when the ASCII user replies, he can reply to both recipients of the first message.
[02:14:19] <harald> Either we have to satisfy the requirement, or we have to remove the requirement.
[02:14:51] --- klensin has joined
[02:24:08] <yangwooko> (Klensin) We should not depend on envelope address to replace header addresses.
[02:44:32] <yangwooko> We promise to cover mail expoder issue....
[02:45:38] <yangwooko> (Harald) We need voluneer(s) for mailing list doc.
[02:53:23] <xiaodong.lee> now, discussion on maillist problem
[03:02:40] <yangwooko> Edmon volunteered to work in mailing list doc.
[03:03:50] <yangwooko> Fujiwara will update downgrade doc to incorporate current utf-8 headers doc.
[03:04:44] <fujiwara> I will add scenario consideration
[03:06:15] <yangwooko> http://member.wide.ad.jp/~fujiwara/received-200606.txt
[03:06:26] <yangwooko> Fujiwara will cover received header.
[03:06:34] <harald> and you will work out details of the 5.3 approach.
[03:07:21] <xiaodong.lee> fujiwara will work out the details
[03:07:48] <xiaodong.lee> now fujiwara-san is reporting another issue
[03:11:07] <yangwooko> Fujiwara presented 4 methods for received header downgrading.
[03:12:20] <yangwooko> (Klensin) Only method 1 is not having UTF-8 in received header field.
[03:15:15] <yangwooko> Xiadong asked Harald whether he has comments on this.
[03:15:43] <klensin> And, if one has UTF-8 in those fields, one either has to violate the RFC 2047 sect 5 constraint (and end up with the encoded words being treated as addresses in legacy software) or violating the rule against tampering with prior header fields, or both.
[03:16:02] <harald> I'd touched the mute button without realizing. sorry.
[03:17:22] <klensin> Means we check, and maybe change, the SMTP and UTF-8 header docs to make it clear that UTF-8 never goes into a received field, even as a comment. Right?
[03:17:36] <harald> right.
[03:19:03] <yangwooko> (Klensin) 2821 related things should go SMTP-EXT doc.
[03:23:31] <yangwooko> IMAP / POP doc
[03:24:29] <yangwooko> (Harald) IMAP mentions upgrading.
[03:27:00] <yangwooko> Implementation and Testing Plan
[03:27:42] <yangwooko> Xiadong suggests that we have prototype before IETF 66 and workable system before IETF 67.
[03:28:37] <xiaodong.lee> Time Plan Prototype Demo before 66th IETF meeting Developers: Players: Workable System before 67th IETF meeting Developers: Players: Report on the results of testing
[03:29:41] <yangwooko> (Yao) CNNIC will be able to do demo on "main" parts at IETF 66.
[03:30:15] <delphij@gmail.com/Gaim> Which parts are considered "main" parts? A working MTA?
[03:30:36] <yangwooko> (Jeff) TWNIC is also working on it.
[03:30:44] <yangwooko> TWNIC is based on sendmail.
[03:30:45] <delphij@gmail.com/Gaim> My suggestion would be that the work would be done on sendmail and/or postfix
[03:30:50] <yangwooko> CNNIC is based on qmail.
[03:32:11] <delphij@gmail.com/Gaim> Perhaps we can implement a very simple mailing list which individual mail service providers can subscribe, which sends EAI-complaint e-mails?
[03:32:20] <delphij@gmail.com/Gaim> That would be helpful for testing.
[03:32:54] <harald> test data generator? yes.
[03:33:03] <delphij@gmail.com/Gaim> yes, test data generator
[03:33:53] <yangwooko> Yangwoo and Fujiwara will participat in test as well.
[03:34:28] <delphij@gmail.com/Gaim> Maybe some small stuff like mutt?
[03:34:50] <delphij@gmail.com/Gaim> I mean the MUA part
[03:36:11] <yangwooko> Fujiwara will provide MUA supporting UTF-8 addresses.
[03:37:22] <delphij@gmail.com/Gaim> What would be that based on? Or purely written from scratch?
[03:37:50] <yangwooko> Will be based on open source simple mail related tools.
[03:38:12] <harald> the easy part is to let the code through. the hard part is to make sure it doesn't escape without proper handling/gatewaying.
[03:39:08] <delphij@gmail.com/Gaim> We will make a postfix based patchset
[03:39:53] <fujiwara> I will make text based mail tool 'im' patch. http://tats.haun.org/im/
[03:40:19] <yangwooko> (Klensin) Please do not forget whether right things happen with "un" upgraded softwares.
[03:42:17] <yangwooko> Jeff with Yao will prepare IETF 66 demo.
[04:01:10] --- erin has joined
[04:10:11] <yangwooko> Suggested to defer fixing of the plan to IETF 66 f2f EAI WG meeting.
[04:10:33] <yangwooko> Suggested to include web-mail parts.
[04:11:42] <yangwooko> Solicitation will be put on EAI WG mailing list.
[04:12:12] <yangwooko> TERMINOLOGY ISSUE
[04:12:44] <yangwooko> (Xiadong) Mailing list name is still ima.
[04:14:14] <yangwooko> (Xiadong) Just leave it as is.
[04:15:19] <yangwooko> (Klensin) Iemail is registered trademark.
[04:15:55] <yangwooko> (Klensin) EAI is used for several different things.
[04:16:32] <yangwooko> (Harald) UTF-8 mail.
[04:18:19] <harald> UTF8MAIL
[04:21:29] <yangwooko> (Klensin) UTF-8 email is used to describe mails containing utf-8 data.
[04:23:06] <yangwooko> (Edmon) IMX
[04:25:55] <yangwooko> (Yao) IMAE
[04:26:17] <delphij@gmail.com/Gaim> There's a company called IMX...
[04:27:18] <yangwooko> UTF8SMTP
[04:28:07] <yangwooko> ISMTP
[04:29:41] <yangwooko> UTF8SMTP is "currently" google-safe.
[04:34:02] <xiaodong.lee> EAI, I-email , i18nemail, utf8email, emailng, IMX, IMAE, utf8smtp, ismtp
[04:34:09] <xiaodong.lee> many options
[04:34:18] <harald> can we support multiple options?
[04:34:32] <xiaodong.lee> sure, I do think so
[04:35:21] <harald> I want to support utf8email and utf8smtp.... just run through them; we'll do a reballot on the most popular ones.
[04:35:29] <delphij@gmail.com/Gaim> What about just "220-EAI" or "220-EAI 1.0"? :)
[04:35:34] <klensin> In informal text , yes. But there must be exactly one EHLO response value
[04:36:06] <JeffYeh> TWNIC prefers utf8smtp
[04:36:59] <yangwooko> i18nmail --> 3
[04:37:23] <JeffYeh> i18nemail +1, i like it
[04:37:24] <yangwooko> utf8 email --> 1
[04:37:50] <yangwooko> IMX --> 1
[04:37:54] <yangwooko> IMAE --> 1
[04:38:17] <yangwooko> UTF8SMTP --> 4
[04:39:14] <harald> so we should do a rerun with UTF8SMTP and I18NMAIL
[04:40:12] <JeffYeh> i18nmail is not that good for pronounce
[04:40:36] <yangwooko> Rerun with UTF8SMTP and I18NMAIL
[04:41:30] <yangwooko> UTF8SMTP vs. I18NEMAIL
[04:42:29] <yangwooko> Klensin wants to choose one sooner.
[04:43:52] <yangwooko> UTF8 SMTP --> 5
[04:44:17] <yangwooko> I18N EMAIL--> 3
[04:45:50] <yangwooko> (Fujiwara) Names for different email addresses e.g. ascii@ascii, utf8@utf8, ascii@utf8, utf8@ascii.
[04:46:22] <harald> this terminology needs to go in the framework document, as per previous discussion about terminology
[04:46:30] <yangwooko> Sure
[04:50:28] <xiaodong.lee> ascii@ascii, Non-ascii@Non-ascii ascii@Non-ascii Non-ascii@ascii
[04:52:20] <yangwooko> All three cases are called as "non ascii".
[04:53:52] <yangwooko> "non ascii" may contain ascii characters but they cannot be represented by ascii only.
[04:57:36] <yangwooko> Fujiwara wants to have two names for ASCII address obtained from ALT-ADDR and the one generated thorugh algorithmic conversion.
[04:58:19] <harald> algorithmic ascii address?
[05:00:07] <harald> sender-specified ascii address and algorithmic ascii address.
[05:01:06] <yangwooko> Sounds good.
[05:04:34] <yangwooko> (Xiadong) Any other terminology issues?
[05:05:42] <yangwooko> OPEN ISSUES
[05:09:16] <yangwooko> (Klensin) Things that should be considered but we still don't know the answer. 1. When and how much useful downgrading will be.
[05:10:32] <klensin> 2 Range of characters permitted in addresses and whether/how normalized
[05:21:25] <klensin> Decision: If an alt-address is specified and must be used in downgrading, but the host at the alt-address domain advertizes the SMTP extension, the alt-address MUST still be used, but the UTF8 headers do not need to be downgraded.
[05:21:36] <klensin> (and SHOULD NOT be downgraded)
[05:26:49] <yangwooko> edmon@afilias.info
[05:26:49] <klensin> edmon@afilias.info
[05:27:04] --- delphij@gmail.com/Gaim has left
[05:27:20] <harald> done!
[05:29:22] <yangwooko> Two more docs are operation guideline and design decisions.
[05:30:12] <yangwooko> As individual submissions.
[05:34:40] <klensin> Operational guidelines --which include suggestions to SMTP delivery site maintainers as to how to create names -- gets temporarily (at least) dropped from work list, but may be important and were asked for. In particular, they become very important if we avoid most or all canonicalization and preparation specifications in SMTP but dump that problem on delivery system decisions about naming. That clearly interacts with the SASLPrep (or whatever) issues
[05:35:25] <yangwooko> Meeting adjourned.
[05:35:29] --- yangwooko has left
[05:35:58] --- jaeyounkim has left
[05:38:00] --- xiaodong.lee has left
[05:38:59] --- fujiwara has left: Logged out
[05:40:16] --- harald has left
[05:40:30] --- JeffYeh has left
[05:52:13] --- snw has left
[06:06:00] --- klensin has left: Disconnected
[06:35:27] --- erin has left
[19:46:17] --- newcat has joined
[19:46:40] --- newcat has left