[07:35:01] --- yone has joined
[07:36:35] * yone has changed the subject to: WG meeting, Montreal
[07:43:49] --- yone has left
[07:44:23] --- yone has joined
[07:45:37] --- Jaeyoun Kim (KRNIC) has joined
[07:47:11] --- Jaeyoun Kim (KRNIC) has left
[07:49:48] --- yone has left
[07:51:47] --- pguenther has joined
[07:54:42] --- Jaeyoun Kim has joined
[08:14:51] --- xiaodong has joined
[08:15:08] * xiaodong has changed the subject to: EAI WG meeting, Montreal
[08:18:27] <xiaodong> agenda, FYI
[08:18:28] <xiaodong> http://www3.ietf.org/proceedings/06jul/agenda/eai.txt
[08:19:51] --- yone has joined
[08:45:52] --- cary has joined
[08:57:29] --- Lisa has joined
[08:57:39] <Lisa> Hello
[08:58:04] <xiaodong> hello, everyone
[08:58:25] --- cnewman has joined
[08:58:37] --- andrewsullivan has joined
[09:01:56] * fanf just lost sound
[09:03:18] <Jaeyoun Kim> hello!
[09:03:21] --- Jelte has joined
[09:03:30] <Jelte> Hi
[09:04:09] --- Randall Gellens has joined
[09:04:48] <cnewman> I'm not getting sound, either.
[09:04:53] <fanf> where are the internationalized nicks? :-)
[09:05:16] <Lisa> That works for some Jabber clients, go ahead and try
[09:05:56] --- hardie@jabber.psg.com has joined
[09:06:14] --- cyrus_daboo has joined
[09:06:16] <Lisa> My name has no accents even though it's french so no need for non-ASCII for me unless I adopt a non-English nickname. I have a translation of "Lisa" in Kanji on my karate gi but I couldn't hope to reproduce it here.
[09:06:27] --- marcos.sanz has joined
[09:06:56] <yone> meeting will start within 5 minutes
[09:07:11] <cary> Any chance of fixing the audio?
[09:08:46] --- marcos.sanz has left
[09:08:59] --- resnick has joined
[09:09:16] --- マルコス has joined
[09:09:21] --- newcat has joined
[09:09:34] <マルコス> This is my katakana nick
[09:09:42] <マルコス> Can *anybody* read it? :-)
[09:09:42] * fanf applauds
[09:10:30] <yone> of course!
[09:10:38] <yone> marcos in Katakana
[09:10:38] --- alexeymelnikov has joined
[09:10:50] <マルコス> Gaim rules
[09:10:52] --- leiba has joined
[09:11:03] <fanf> ah i can hear something
[09:11:47] <alexeymelnikov> I will try to scribe for EAI.
[09:11:52] <hardie@jabber.psg.com> Fanf: can you hear xiaodong?
[09:12:06] <fanf> mostly obscured by background noise
[09:12:11] <alexeymelnikov> On the agenda slide
[09:12:14] --- kmurchison has joined
[09:12:20] --- fujiwara has joined
[09:12:59] <alexeymelnikov> (Xiadong uploaded updated agenda)
[09:13:14] --- Glenn Parsons has joined
[09:13:44] <alexeymelnikov> -framework-01.txt draft first (John Klensin)
[09:14:14] <alexeymelnikov> John would also talk about Harald's document on scenarios.
[09:14:23] <cnewman> I'm listening to POP comments...
[09:14:32] --- sftcd has joined
[09:14:39] <alexeymelnikov> Chris Newman is not here, there are no slides, but he posted a list of open issues.
[09:15:09] --- edmon has joined
[09:15:11] <alexeymelnikov> Any comments on agenda?
[09:15:16] --- eric has joined
[09:15:25] <alexeymelnikov> On Documents Status Summary page
[09:15:32] --- tlr has joined
[09:15:43] <alexeymelnikov> Interim Meeting (Beijing) in June 2006.
[09:15:44] --- tonyhansen has joined
[09:15:45] --- kurosaki has joined
[09:16:18] <alexeymelnikov> 8 WG drafts, one -00 is new since the interim (IMAP)
[09:17:03] <alexeymelnikov> John Klensin is talking about -scenatios-01.txt
[09:17:13] <fanf> ooh i can hear john :-)
[09:17:40] <alexeymelnikov> John doesn't like describing drafts for somebody who haven't read them :-)
[09:17:54] <alexeymelnikov> Actually John is talking about framework
[09:18:10] <alexeymelnikov> He added comments about PGP/SMIME/DKIM
[09:18:44] <alexeymelnikov> PGP and S/MIME don;t sign headers, so they should not be affected by EAI.
[09:18:57] <alexeymelnikov> John also updated terminology.
[09:19:07] <Randall Gellens> ...but dkim does, so it is affected....
[09:20:01] --- Jelte has left: Replaced by new connection
[09:20:03] <alexeymelnikov> Ted: how EAI affects mailto IRI and IRI in general. Is this in scope for the WG
[09:20:07] <fanf> mailto> also vcards, ldap schemas....
[09:20:30] <alexeymelnikov> John: Martin has asked to add some text to -framework.
[09:21:02] <alexeymelnikov> Ted suggests to use new URI schema
[09:21:15] <alexeymelnikov> Philip Guenther: mail3
[09:21:56] <hardie@jabber.psg.com> The suggestion was that we consider a new URI scheme if the changes to mailto involve carrying the alternate addresses, as this is a major syntax change.
[09:22:57] <alexeymelnikov> Philip: S/MIME messages containing 2027 encoded word will have to continue to use 2027 in the future.
[09:23:03] <alexeymelnikov> John: text is welcomed
[09:23:11] <cnewman> ^2027^2047
[09:23:35] <alexeymelnikov> John on Harald's document: editorial changes, nothing major
[09:23:40] <alexeymelnikov> (thanks Chris)
[09:24:03] <alexeymelnikov> On -smtpext-00.txt draft now.
[09:24:35] <fanf> is anyone talking right now?
[09:24:42] <newcat> No
[09:25:18] <hardie@jabber.psg.com> Yao jiankang is coming to the mic now
[09:25:27] <alexeymelnikov> Yao is presenting
[09:25:51] <alexeymelnikov> Open issues:
[09:26:05] <alexeymelnikov> Main changes:
[09:26:17] <alexeymelnikov> Refeind the Mailbox Address Synta definition
[09:26:34] <alexeymelnikov> Updated the keyword value for the SMTP extension
[09:27:12] <cnewman> Current Presentation: http://www3.ietf.org/proceedings/06jul/slides/eai-0.ppt
[09:27:16] <alexeymelnikov> Issue: do we recommend to use SASLPrep (RFC 4013)
[09:27:52] <alexeymelnikov> Issue 2: changed EHLO keyword for the extension to be UTF8SMTP
[09:28:44] <alexeymelnikov> Issue 3: SMTP commands commands syntax (where to put alternative address and what is the exact syntax for MAIL FROM/RCPT TO after that)
[09:29:53] <alexeymelnikov> Yao is now talking about examples for different cases described in Harald's -scenarios document
[09:30:20] <alexeymelnikov> There is a demo implementation based on Sendmail.
[09:31:07] <pguenther> based on sendmail? I thought he said based on qmail
[09:31:14] <xiaodong> TWNIC
[09:31:20] <newcat> Sendmail-based demonstration will be given by TWNIC people not by Yao.
[09:31:24] <xiaodong> TWNIC's demo is based on sendmail
[09:31:26] <pguenther> ah
[09:31:33] <pguenther> thank you
[09:31:35] <alexeymelnikov> The demo implementation doesn't do mailing list related examples, but they are working on it.
[09:31:40] <xiaodong> CNNIC's is based on Qmail
[09:32:54] <alexeymelnikov> Going throught different examples now, live demonstration.
[09:33:03] <hardie@jabber.psg.com> The presented syntax for eaiparam seems to be different from what's in the draft. Did it change, or is the presentation not attempting to capture the syntax?
[09:33:07] --- sftcd has left: Computer went to sleep
[09:33:20] <hardie@jabber.psg.com> In particular, the draft seems to use atomic=y or atomic=n
[09:33:45] <newcat> In beijing interim meeting,
[09:33:53] <newcat> rough consensus was to use
[09:33:59] --- klensin-ietf has joined
[09:34:01] <newcat> just one parameter for both cases.
[09:34:09] <hardie@jabber.psg.com> So we're expecting to see a draft change for this soon?
[09:34:18] <newcat> I guess so.
[09:34:26] <hardie@jabber.psg.com> thanks for the update, newcat
[09:35:31] <alexeymelnikov> There are some minor bugs in the demo, but it is quite impressive
[09:35:57] <klensin-ietf> Actually, this one belongs on the issues list
[09:37:14] <pguenther> the placement of angle brackets seemed odd in the presentation, though perhaps that was metasyntax
[09:37:52] <マルコス> Am I the only one who hasn't a good feeling when conflating two different semantics into one parameter? So now you have to parse its value to determine whether it is "atomic" or something else...
[09:38:14] <hardie@jabber.psg.com> If there is an alt address does it populate the delivered to:?
[09:39:23] <alexeymelnikov> John suggested to skip the demo, as it is difficult to follow.
[09:39:23] <cnewman> John is far too polite about qmail's gross violations of the standards.
[09:39:34] <andrewsullivan> "Am I the only one who hasn't a good feeling. . ." No, you're not
[09:39:45] <hardie@jabber.psg.com> I am not sure why having a single parameter is better, but it seems checking first for the string "atomic" isn't that hard.
[09:40:09] <tlr> this isn't even readable from the back of the room
[09:40:33] <hardie@jabber.psg.com> he's populating the sender email fields with an eaiparameter of an ascii name
[09:40:42] <alexeymelnikov> (alexey) ted: what about not fully qualified email addresses, which are quite "popular" these days?
[09:40:43] <fanf> delivered-to is not standard and doesn't work if there are multiple recipients
[09:40:44] <マルコス> It surely is not hard. But the meaning of "eaipara" is not easy to define in one sentence.
[09:41:19] <pguenther> so, the eiapara is embedded in the _localpart_??
[09:41:21] <cnewman> As a data point, the presentation is of no interest to me, and I have not seen it before. Of course, I'm not seeing it now, either. But I'm having fun imagining which qmail ideosynchrasies are causing John's blood pressure to rise. :-)
[09:41:35] * pguenther really wishes the draft had been updated
[09:42:05] <tlr> please zoom to some font size which is readable.
[09:42:14] <newcat> My answer was misleading. ALT-ADDR and ATOMIC are going to be mutually exclusive.
[09:42:54] <cnewman> I like the fact eaipara eliminates the silly state of both ALT-ADDR and ATOMIC parameters. But it's badly named.
[09:43:10] --- shinta has joined
[09:44:10] <alexeymelnikov> Ted: it seems that in Beijing there was an agreement to change from 2 parameters (for alt address and atomic) to 1 parameter. Why?
[09:44:28] <hardie@jabber.psg.com> so he agrees, that having one avoids the silly state.
[09:44:53] <klensin-ietf> Chris, nothing serious -- just oddities in how trace fields are constructed. Qmail bends the standard in ways that would be almost unnoticable in 2821/2822 mail, but makes it hard to tell what changes are due to these extensions and which to qmail basic behavior. My blood pressure is not rising over that.
[09:45:24] <resnick> I'm still not clear on the difference between ATOMIC and the absence of the parameter.
[09:45:40] <alexeymelnikov> Chair noted that the demo doesn't match the draft. The draft needs to be updated.
[09:46:03] <fanf> resnick: atomicc means algorithmic address downgrading; no parameter meand no downgrade (bounce instead)
[09:46:07] <alexeymelnikov> John: we need to get consensus on the change today.
[09:46:17] <hardie@jabber.psg.com> In the absence, it seems like it would mean you don't know that it is downgradable, so bounce
[09:46:39] <cnewman> I will "hmmm" in support of change to eliminate silly state. I would prefer better names for both "eaiparam" and "atomic".
[09:47:11] <resnick> Ted, fanf: Got it. Chris: hummm along with you.
[09:47:17] <resnick> thx
[09:47:23] <klensin-ietf> pguenther, so do I, in case that wasn't clear from the comment at the microphone.
[09:47:30] <fanf> atomic is a bad name too, because it's based on a model of how the address is interpreted by its home site, rather than on its behaviour as observed by others
[09:47:47] <cnewman> Well said, fanf.
[09:47:47] <pguenther> ah, I see: eaipara is indeed a parameter; their demo works because qmail doesn't require the brackets around the address and the client isn't inserting them!
[09:47:52] <pguenther> (I think)
[09:49:12] <resnick> Why not make the parameter "DOWNGRADE="?
[09:49:22] <hardie@jabber.psg.com> Are others reacting to the double content-transfer-encoding?
[09:49:33] <fanf> "downgrade" is better name for eaiparam since its value is the downgraded address or "atomic"
[09:49:34] <leiba> yes
[09:49:39] <leiba> Ted: yes
[09:49:45] <fanf> resnick: snap
[09:50:32] <xiaodong> you mean the eaipara should be DOWNGRADE?
[09:50:37] <alexeymelnikov> The plan is to finish demo for the remaining cases before the next IETF meeting
[09:50:43] <tonyhansen> "Content-transfer-encoding: 8bit utf8" in the slides was hopefully a typo
[09:50:54] --- sftcd has joined
[09:51:05] <hardie@jabber.psg.com> Ask at the mic, please?
[09:51:06] <Randall Gellens> Why have an ATOMIC parameter? If it's purpose is to permit the RCPT TO address to be converted when ALT-ADDRESS is not supplied, why not just do the conversion and use it as AL-ADDRESS?
[09:51:22] <fanf> randall: agreed
[09:51:26] <alexeymelnikov> Pete Resnick: suggests to change the name the parameter to donwgrade=
[09:51:28] <hardie@jabber.psg.com> Because you cant' convert all address
[09:51:43] <alexeymelnikov> I meant "downgrade"
[09:51:50] <hardie@jabber.psg.com> there are some addresses that have internal structure, so you cannot apply the same downgrade rules.
[09:51:59] <Randall Gellens> Ted, sure, you can't assume you can convert an address, but if you know that you can, why not do it instead of saying you can?
[09:52:28] --- Lisa has left: Logged out
[09:52:45] <Randall Gellens> That is, if ALT-ADDRESS is not supplied, and ATOMIC=y (or DOWNGRADEABLE=Y), that means the sender is asserting that the address can be converted
[09:52:56] <hardie@jabber.psg.com> If you don't know you can convert it, you bounce it. This is an attempt to avoid bounces when the emitter knows it could be downgradable
[09:53:27] <alexeymelnikov> John: disadvantage of a single parameter: the only way to distinguish keyword from alt-address is by looking at @ sign. What happens if some implementation misspells the keyword?
[09:53:49] <cnewman> I find the silly state to be a more serious design error than John's concern about forward parsing.
[09:53:58] <leiba> Chris: I agree
[09:54:12] <alexeymelnikov> John: there is also a performance implication of the change.
[09:54:14] <Randall Gellens> Ted, right, so why not just have AL-ADDRESS
[09:54:40] <マルコス> The plain existence of ALT-ADDRESS implies that atomic is no.
[09:54:43] <Randall Gellens> If the originator knows the address can be converted and doesn't know a better alternative address, it fills in the converted address as ALT-ADDRESS
[09:54:47] <マルコス> That is the best solution.
[09:55:16] --- newcat has left: Replaced by new connection.
[09:55:17] <fanf> chris: agreed. though john's point about unqualified addresses is good.
[09:55:18] <cnewman> I like Randy's proposal.
[09:55:19] <Randall Gellens> If the originator does know a better alternative address, it fills in ALT-ADDRESS with it
[09:55:26] <hardie@jabber.psg.com> That works.
[09:55:29] --- klensin-ietf has left: Replaced by new connection
[09:55:33] --- newcat has joined
[09:55:38] <hardie@jabber.psg.com> Take the proposal to the mic...
[09:55:44] <Randall Gellens> If it doesn't know a good alternate address, and doesn't know if the address can be converted, it doesn't supply AL-ADDRESS
[09:55:58] <alexeymelnikov> John: there are non obvious implication of the change
[09:56:58] <alexeymelnikov> Pete: what about the change to put alternative address inside the <> of the mail from/rcpt to? This requires changes to RFC 2821.
[09:57:17] --- マルコス is now known as marcos.sanz
[09:57:19] --- klensin-ietf has joined
[09:57:46] <hardie@jabber.psg.com> Pete is proposing that this move outside the angle brackets
[09:58:26] <cnewman> Agree with Pete, I would rather reuse existing ESMTP parameter parsing code.
[09:59:04] <fanf> using <> in the downgrade= parameter to distinguish between an alt-address and an atomic keyword solves the problem of unqualified addresses
[09:59:22] <fanf> (i think i heard someone say that)
[10:00:13] <alexeymelnikov> William L.: what an [old] client would see if it doesn't support EAI?
[10:01:48] <alexeymelnikov> John: this is not a problem - if the receiver doesn't support EAI, the sender can either be bounced or downgrade.
[10:02:17] <fanf> can people please use the mic
[10:02:18] <alexeymelnikov> Pete: read the draft!
[10:02:31] <xiaodong> the utf8 headers
[10:02:32] --- dcrocker has joined
[10:02:38] <xiaodong> by Jeff Ye
[10:02:51] <alexeymelnikov> Randy: we really only need alt-address, no need for atomic.
[10:03:19] * fanf hums in favour
[10:03:47] * fanf laughs
[10:04:27] <alexeymelnikov> Randy: if the sender knows alt-address, it specifies it. If it can mechanically convert it, it will put the converted name.
[10:04:42] <alexeymelnikov> John: This is what I wanted originally.
[10:05:42] <alexeymelnikov> Randy: and if there is no alt-address, then the message is not downgradeable.
[10:06:15] <fanf> regarding what john is saying, i think the user interface is very important
[10:06:23] <alexeymelnikov> Ted: are there some clients that don't have code to downconvert utf8 addresses?
[10:07:05] <fanf> especially address books, mailto: urls ...
[10:07:21] <alexeymelnikov> John: we can have atomic flag in the submission server, so that the client doesn't need the code to downconvert the address.
[10:07:33] <alexeymelnikov> Ted agrees (and many others as well)
[10:08:33] <resnick> Xiao Dong: Do you understand what is being suggested and the consensus question?
[10:08:41] <xiaodong> yes
[10:08:47] <Randall Gellens> Permit not an ATOMIC flag, but its moral equivalent: a submission client tells the submit server "please convert and use as AL-ADDRESS"
[10:08:48] <xiaodong> before next presentation
[10:08:51] <fanf> there's not much point limiting the atomic option to submission and not relay
[10:08:56] <resnick> :-) Just checking.
[10:09:11] <tlr> mhhh.. This only makes sense if we assume the client not to know its alt-address.
[10:09:25] <alexeymelnikov> (alexey) fanf: the submission is more likely to know if an address is downgradable
[10:09:30] <Randall Gellens> fanf, it cleans up SMTP relay and gets rid of an extra general SMTP parameter
[10:09:34] <tlr> Which is probably not a good thing if you consider that the client might need that address to create things like key identities in a context where e-mail is encrypted.
[10:10:13] <fanf> randall: it's the same code...
[10:10:21] <alexeymelnikov> Poll: the eaiparameter outside of the <> (i.e. == separate ESMTP parameter)
[10:10:34] <cnewman> hmm outside
[10:10:46] <fanf> alexey: the address is probably not local, and it probably came from an address book
[10:10:48] <Randall Gellens> fanf: it a submission-vs-relay question
[10:10:48] <hardie@jabber.psg.com> I hummed loud for you, chris
[10:10:51] <alexeymelnikov> No support for "inside <>" :-)
[10:13:08] <alexeymelnikov> Eric A.: we can put @ sign before a keyword to make it distinguishable from an address
[10:13:42] <alexeymelnikov> Pete: if we can agree to remove atomic, we don't need to decide on how to encode keywords.
[10:13:43] * fanf supports current speaker
[10:13:56] * marcos.sanz claps at Pete
[10:13:56] <alexeymelnikov> Poll: eliminate atomic?
[10:14:13] <alexeymelnikov> John: I want to give an argument I don't like.
[10:15:55] <alexeymelnikov> John: only the receiving server really knows its addresses.
[10:16:48] <alexeymelnikov> Randy: need submission only parameter for downgrading addresses.
[10:16:57] <fanf> i don't understand why you want to put the atomic address downgrade code in the submission server - why can't the mua do it?
[10:16:58] <cnewman> We can not impose semantics on ASCII local parts without breaking the current model. But we _could_ impose semantics on UTF-8 local parts when we introduce them. I'd say we should impose as few such semantics as possible, but having explicit downgrading rules makes sense to me.
[10:17:04] <alexeymelnikov> Pete: can we eliminate atomic *completely*
[10:17:12] <alexeymelnikov> Consensus to remove the atomic
[10:17:12] <fanf> what was the hum question?
[10:17:22] <Randall Gellens> To remove ATOMIC
[10:18:17] <alexeymelnikov> Ted: with AD hat on: who is doing the draft for submission only parameter?
[10:18:44] <alexeymelnikov> John will to a draft on atomic
[10:18:44] <klensin-ietf> I just signed up to write a submission draft for this, but won't necessarily support it :-(
[10:18:46] <Randall Gellens> I'll sign up
[10:18:52] <tlr> I fear it wasn't.
[10:18:55] <hardie@jabber.psg.com> thanks to both of you.
[10:19:02] <Randall Gellens> But I'd prefer we not need it :-)
[10:19:37] <Randall Gellens> (I'd really prefer we don't do automatic downconvert at all)
[10:19:39] <alexeymelnikov> Tony: going back to the example: CTE had the value "8bit utf8", why?
[10:21:21] <alexeymelnikov> Yes, there was a bug in the example.
[10:22:03] <alexeymelnikov> Moving on to the next draft
[10:22:17] <alexeymelnikov> "UTF8 Header" draft
[10:22:29] <alexeymelnikov> Major changes:
[10:22:38] <alexeymelnikov> i-Email header was added
[10:22:44] <alexeymelnikov> ABNF has changed
[10:23:27] <alexeymelnikov> Pending changes: update ABNF to disallow UTF-8 in Message-ID and Received header
[10:23:34] <alexeymelnikov> Issues:
[10:23:58] <alexeymelnikov> alt-separator - currently using { }
[10:24:23] <alexeymelnikov> Issue 2: name of the i-Email parameter
[10:24:46] <alexeymelnikov> Next presentation: testing report
[10:25:17] <alexeymelnikov> (alexey): I think the alt-separator issue is now not important, as the WG decided to move alt-address out of <>
[10:26:05] <alexeymelnikov> Test based on Sendmail.
[10:26:13] <yone> decision was for SMTP parameter, not for EMAIL headers, right?
[10:26:29] --- dcrocker has left
[10:26:38] --- dcrocker has joined
[10:26:47] <alexeymelnikov> Different test cases:
[10:27:02] <alexeymelnikov> 1) downgrade envelope
[10:27:03] --- newcat is now known as yangwoo ko
[10:28:21] <marcos.sanz> Yes,the decission was for 2821 syntax
[10:28:26] <alexeymelnikov> 2) downgrade headers (punicode in Received header, add i-Email header, etc.)
[10:28:35] <resnick> So, they've got <local-part@domain {downgraded-local@downgraded-domain}>
[10:28:47] <resnick> Do we want to stick a special in there?
[10:28:53] <eric> he had two formats, one with { }, one with a separate param.
[10:28:56] <resnick> (Like, a semicolon maybe?)
[10:29:03] <resnick> Curly braces are not specials.
[10:29:16] <eric> yeah, but as part of the domain name?
[10:29:45] <fanf> i have already said that the character that separates the utf8 address and the alt address should be a special, probably : (M$ software confuses ; and ,)
[10:29:51] <marcos.sanz> Curly braces are allowed domain characters
[10:29:57] <alexeymelnikov> 3). also tested mailing lists
[10:30:10] <resnick> Yeah, they'll parse as part of the domain and then fail when you try to look it up.
[10:30:22] <marcos.sanz> Pete: Yes. Dangerous.
[10:30:24] <eric> i defy you to parse "foo@example.com {bar@example.net}" today
[10:30:30] <pguenther> again, the syntax doesn't match the draft
[10:30:43] <alexeymelnikov> Linux "mail" was used as EAI-aware client. Outlook Express as non EAI-aware client
[10:31:01] <Randall Gellens> *screams in horror*
[10:31:02] <pguenther> not just the braces: i-email header now has trace info
[10:31:05] <marcos.sanz> Pete: Fail, or look up the wrong domain
[10:31:16] <fanf> marcos: allowed in dns labels but not mail domains, but still, all special characters should continue to be special characters
[10:31:26] <resnick> Eric: You'll get "example.com{bar@example.net}" as the domain.
[10:31:33] <resnick> The lookup will certainly fail. :-)
[10:31:41] <alexeymelnikov> A simple EAI POP3 server was written with Perl
[10:32:02] <eric> my point precisely.
[10:32:10] <alexeymelnikov> tested with CAPA UTF8 and without it
[10:32:26] <alexeymelnikov> Issues:
[10:32:37] <resnick> Eric: The question is, wouldn't it be better if the parse failed in the first place?
[10:32:39] <alexeymelnikov> 1) no longer relavant due to todays discussions
[10:33:05] <eric> well, that address does have two @ in it....
[10:33:10] <marcos.sanz> fanf: You are right. 2821 enforces LDH for domain labels
[10:33:20] <cnewman> You could use ".." as the delimiter ;-)
[10:34:27] <resnick> Eric: So does "@relay.com:presnick@qualcomm.com"
[10:34:40] <resnick> Not that we do that. :-)
[10:34:44] <alexeymelnikov> 2) alt-separator for mailing lists is the same as for (?)
[10:34:52] <hardie@jabber.psg.com> Is 中文＠ 台網中心.tw a mailing list inthe examples?
[10:35:42] <resnick> Chris: Bite your tongue. ;-)
[10:35:48] --- fred.lefebvre has joined
[10:35:52] <alexeymelnikov> 3) EAI-parameter replaces Envelope from: can alt-address be from another domain; interaction with DSN ESMTP extension, etc.
[10:35:55] <pguenther> how about nesting <>s for the downgrade? <utf8@utf8<ascii@punycode>>
[10:36:10] <pguenther> old sendmail's would automatically downgrade that!
[10:36:13] <alexeymelnikov> (I've missed 4 - SPF)
[10:36:25] <alexeymelnikov> 5) Interaction with DKIM
[10:36:36] <eric> The route-addr syntax includes the comma and/or colon, and the first "@" is at the front.
[10:37:08] <alexeymelnikov> Ted: go back to the mailing list example
[10:39:10] <marcos.sanz> I'd rather have square brackets then.
[10:39:13] --- yangwoo ko has left: Lost connection
[10:39:27] <marcos.sanz> which are specials
[10:39:30] <resnick> Eric: I guess I'm looking for some clear way for the parser to see (at the first character it encounters) that it has hit a parse error.
[10:39:38] <alexeymelnikov> Moving on to IMAP draft
[10:39:42] <cnewman> I like utf8@utf8 [ascii@punycode]
[10:39:47] <alexeymelnikov> Pete Resnick presenting
[10:41:25] <alexeymelnikov> The major issue: non extended LIST returning UTF-8 stuff? Will try to address in the next revision
[10:42:54] <alexeymelnikov> Another issue (from Harald): does the server have to upgrade all messages in the mailstore?
[10:43:56] <alexeymelnikov> Philip: there is some complexity with server not willing to do upgrade for *some* mailboxes. Can we eliminate this (all mailboxes are UTF8)
[10:44:10] --- fred.lefebvre has left
[10:44:26] --- yangwoo ko has joined
[10:45:44] <alexeymelnikov> There is performance issue for servers
[10:46:45] <pguenther> dang RFC822.SIZE
[10:47:01] <alexeymelnikov> Next presentation: EAI Mailing lists
[10:47:07] --- sftcd has left: Computer went to sleep
[10:47:09] <cnewman> It was less effort to write the draft in a way that is UW c-client compatible than to write the simpler always-upgrade design and deal with the political fallout.
[10:47:13] <alexeymelnikov> Edmon Chung presenting
[10:47:38] <cyrus_daboo> I still think a mode switch with a '* NOUTF8' response on select for those mailboxes the server won't 'upgrade' is a simpler implementation approach.
[10:47:42] * pguenther nods
[10:48:06] <alexeymelnikov> "Mailing-lst should not introduce any additional protocol requirements for EAI"
[10:48:31] <cnewman> Cyrus: feel free to suggest alternate text. A spec is done when there's nothing left to remove...
[10:48:42] <alexeymelnikov> Is it a requirement to obtain alt-addresses on mailing list expansion?
[10:48:47] <resnick> :)
[10:48:59] <resnick> Right, Chris.
[10:49:00] <klensin-ietf> Cyrus, *NOUTF8 is also consistent with the principle that one should design for the long term then work in transitions, rather than designing kludges that one has to carry around forever.
[10:49:19] <alexeymelnikov> Scenarios:
[10:49:53] <alexeymelnikov> 1) Pure case (all only subscribers involved)
[10:50:14] <alexeymelnikov> 2) Mixed case (some members might not have alt-addresses)
[10:50:54] <alexeymelnikov> List-* headers are mostly using URIs, so they should be using IRIs
[10:50:55] <cyrus_daboo> I will put something in email in the next few days...
[10:51:04] <resnick> Cyrus: thx.
[10:51:14] <alexeymelnikov> So there is an issue of extending mailto: schema to allow for EAI.
[10:51:24] <tlr> +1 to using a different schema
[10:51:28] <alexeymelnikov> Open issues:
[10:51:37] --- dcrocker has left
[10:51:50] <alexeymelnikov> 1) How to obtain downgrade information
[10:52:19] <alexeymelnikov> 2) Downgrade Considerations for mailto URLs
[10:52:40] <cnewman> FWIW, I did the implicit UTF-8 mode switch for two reasons: 1. to see if people were paying attention. 2. avoid the potential IMAP client-capabilities rathole. Since people were paying attention, I guess Pete gets to navigate the rathole :-)
[10:52:58] --- doug_trend@jabber.org has joined
[10:53:11] <alexeymelnikov> 3) operational policy of requiring alt-address/ atomic info
[10:54:50] <alexeymelnikov> Ted: we can't require all addresses to be downgradable (e.g. if there is a community of tai users exchanging email in tai - why do they need to have alt-addresses?
[10:54:52] * resnick puts on his rathole helmet with built-in light.
[10:56:48] <alexeymelnikov> Example problem: sender has non-downgradable address, some subscribers have ascii-only addresses - is the message to be bounced?
[10:58:02] <fanf> it'd probably be better to decide what workes best in this situation after some years experience...
[10:58:39] <hardie@jabber.psg.com> for "experience" read "pain"
[11:00:00] <alexeymelnikov> William L.: if mail from was non downgradable, but the mailing list rewrites MAIL FROM, bounce might not be needed.
[11:00:32] <alexeymelnikov> Philip: EAI mailing list can help two groups of people to communicate (one is ascii only, ther other is utf8 only)
[11:01:13] --- pluscom has joined
[11:01:38] <hardie@jabber.psg.com> So the clear thing is that making a mailing list address with a non-downgradable address is a bad idea.
[11:01:41] <fanf> main problem is that the behaviour of a list for non-downgradable posters is likely to change when the first non-utf8 subscriber is added
[11:02:08] <cnewman> Thought experiment: what if the mailing list simply replaced all UTF-8 addresses with the list submission address?
[11:02:21] <marcos.sanz> fanf: Maybe in that moment we send a warning to the list :-)
[11:02:39] <alexeymelnikov> Pete: is it realistic to expect that people are not going to have algorithmically derivable ascii addresses?
[11:02:45] <fanf> the problem posters might not be subscribers
[11:03:18] <alexeymelnikov> John: it is difficult to prevent people from doing stupid things (referring to previous Ted's comment about legislating human behavior)
[11:04:54] <eric> i'm confused about something: what is the scenario where an address cannot be downgraded? are there addresses that can not be represented in punycode?
[11:05:16] <fanf> eric: if the address is not atomic and has no alt-address
[11:05:48] --- dcrocker has joined
[11:05:48] <Randall Gellens> Downgraded only during certain hops? Or downgraded and stays downgraded?
[11:05:59] <eric> does "atomic" mean something beyond "please auto-convert to punicode"?
[11:06:06] <alexeymelnikov> John: needs to describe possible implementation options for "bounce non downgradable sender addresses"
[11:06:20] <resnick> Eric: The case is where someone is doing sub-address processing and punycoding it would screw up the subaddressing.
[11:06:26] <alexeymelnikov> No comments in the room on Chris's draft
[11:06:30] <alexeymelnikov> Next presentation:
[11:06:38] <alexeymelnikov> -dowrngrade-01
[11:06:39] <marcos.sanz> Upgrade doesn't occur in transit
[11:06:41] <resnick> (i.e., stupid utf-8 only sub-address parsers)
[11:06:44] <alexeymelnikov> Major changes:
[11:06:49] <Randall Gellens> Or where the downgraded address doesn't get delivered to the same user (nor does it get automatically upconverted)
[11:07:18] <alexeymelnikov> 1) follow new header format, added iEmail header, etc.
[11:07:20] <pguenther> atomic=y means "can be algorithmicly downgraded using ACE"
[11:07:27] <alexeymelnikov> 2) Received doesn't contain UTF8
[11:07:46] <resnick> I don't actually believe that in the long run there will be such cases, but maybe I'm too optimistic.
[11:07:50] <pguenther> a non-atomic address can't be algorithmicly downgraded
[11:08:04] <alexeymelnikov> Overview of the draft, 3 options
[11:08:05] <pguenther> e.g.: <utf8stuff+foldername@domain.com>
[11:08:19] <pguenther> ACE of that would munge the +detail
[11:09:26] <alexeymelnikov> 1) Don't downgrade headers (new?)
[11:09:36] <alexeymelnikov> 2) Downgrade headers
[11:09:46] <alexeymelnikov> 3). MIME encapsulation
[11:10:28] <cnewman> Personally, I don't accept that argument. Since no software exists today that supports utf8stuff+foldername@domain.com, why can't we simply require such software to decode punycode?
[11:11:07] --- leiba has left: Replaced by new connection
[11:11:08] <eric> Pete, Philip: thanks, I get it now.
[11:11:13] --- healthyao has joined
[11:11:33] --- healthyao has left
[11:12:00] --- healthyao has joined
[11:12:12] --- leiba has joined
[11:13:25] <resnick> Chris: Agreed.
[11:13:37] <pguenther> cnewman: so, if you are domain.com and accept <utf8+detail@domain.com>, then you must also accept <punycode-of-'utf8+detail'@domain.com>
[11:13:39] <pguenther> ?
[11:13:53] --- leiba has left: Replaced by new connection
[11:14:03] <cnewman> Yes.
[11:14:08] --- leiba has joined
[11:14:44] <fanf> this is an argument in favour of ditching alt-address and requiring that all utf8 addresses are atomic
[11:15:04] <klensin-ietf> Keep in mind that punycode(thing) (actually ToASCII(thing) ) loses information, sometimes seriously
[11:15:05] <pguenther> this is, because the remote end doesn't have to understand the structure of your address (which it can't anyway), you must accept ACE form of your structured addresses
[11:15:25] <cnewman> We can't ditch alt-address for usability reasons.
[11:15:31] <resnick> fanf: No, because I might want a "friendlier" alt-address than a punycoded one.
[11:15:39] <fanf> true
[11:15:42] <resnick> rather than, that is.
[11:15:50] <cnewman> If punycode(thing) loses information, then we're using the wrong "punycode" algorithm for this application.
[11:15:55] --- leiba has left: Replaced by new connection
[11:15:56] <pguenther> klensin: loss of information? what sort of stuff is lost?
[11:16:02] <marcos.sanz> punycode() function ist lossless
[11:16:11] <marcos.sanz> ToAscii() is lossy
[11:16:14] <resnick> Normalization.
[11:16:19] <klensin-ietf> Case
[11:17:10] --- leiba has joined
[11:17:18] <doug_trend@jabber.org> Once all MUA support puny-code conversion to display, puny-code local-part and domain would be friendly.
[11:17:25] <fanf> why can't we use a case-preserving toascii()?
[11:17:26] <hardie@jabber.psg.com> By the way, why does this presume that downgrading happen only once. I thought one of the advantages of toAscii was that i f you ran it multiple times, you got the same thing out the 2nd or Nth time.
[11:17:34] <klensin-ietf> And, if we permit font-trash in addresses (no discussion here on that yet) then it disappears too (font-trash :== "Mathematical" BOLD ITALIC A"
[11:17:48] <klensin-ietf> )
[11:18:17] <andrewsullivan> klensin: and given your remarks about legislating against stupidity. . .
[11:18:19] <cnewman> The ToAscii transformation of the local part should be lossless, IMHO. Only the recipient domain should be permitted to apply a lossy transformation to the local-part.
[11:18:48] <klensin-ietf> Chris: agree completely
[11:18:49] <alexeymelnikov> Pete: why "Downgraded: To:" instead of "Downgraded-To:"
[11:18:55] <fanf> cnewman++
[11:19:30] --- dcrocker has left: Replaced by new connection
[11:20:52] <cnewman> Downgraded-Resent-To
[11:21:02] <hardie@jabber.psg.com> Downgrade-x-face:
[11:21:09] <tlr> Resent-Downgaded-To
[11:21:10] <alexeymelnikov> Cyrus: many tools do grep on headers (include IMAP servers), so having Downgrade-to: would work better for them.
[11:21:14] <fanf> resent-downgraded-to
[11:21:19] <fanf> (snap)
[11:22:34] <alexeymelnikov> Philip (rephrasing previous question): can we just check for 8bit, instead of checking for UTF-8? The former is certainly easier to do.
[11:22:57] --- Randall Gellens has left
[11:23:24] --- Randall Gellens has joined
[11:23:29] <cnewman> Checking for UTF-8 is easy:
[11:23:32] <cnewman> int hula_utf8verify(const char *str, int len) { int state = 0, code; const char *end; unsigned char u1, u2; if (len < 0) len = strlen(str); end = str + len; while (str < end && (code = utf8_table[(unsigned char)*str]) != BAD) { if ((state == 0 && code == EXT) || (state > 0 && code != EXT)) { return (-1); } if ((state & SP) != 0) { state &= ~SP; u1 = (unsigned char) str[-1]; u2 = (unsigned char) str[0]; if ((u1 == 0xE0U && u2 < 0xA0U) || (u1 == 0xEDU && u2 > 0x9FU) || (u1 == 0xF0U && u2 < 0x90U) || (u1 == 0xF4U && u2 > 0x8FU)) { return (-1); } } if (code != EXT) { state = code; } --state; ++str; } return (str == end && state == 0 ? 0 : -1); }
[11:23:50] <cnewman> lookup table is an exercise for the reader.
[11:24:40] <resnick> Did he just say that base64-ing 8-bit breaks the nesting rule?
[11:24:45] <resnick> It doesn't, does it?
[11:24:56] <marcos.sanz> First, it is a stateful check. Second it is no security that it really is UTF-8.
[11:25:45] <marcos.sanz> It is a necessity test, but not a sufficiency one.
[11:25:46] <fanf> yes - only encodings 7bit 8bit and binary are allowed for message/rfc822
[11:26:13] <healthyao> john's draft-klensin-emailaddr-i18n-03 has some example that can not be downgraded. (to eric)
[11:26:46] --- leiba has left: Replaced by new connection
[11:26:52] --- leiba has joined
[11:28:27] <cnewman> Marcos: there are three case: Message is standards compliant and has UTF-8 headers. Message is standards compliant and has 7-bit headers only. Message is not standards compliant. Treating the third case as GIGO is not a problem in my book. So the UTF-8 test is necessary and sufficient, IMHO.
[11:28:35] <resnick> OK, I reversed it. I now understand.
[11:28:38] --- leiba has left: Replaced by new connection
[11:28:42] <alexeymelnikov> ?: Downgrade can replace utf8-only address with MAIL FROM address, which are not necessarily the same thing
[11:29:12] --- pluscom has left
[11:29:19] <tlr> ? was me
[11:29:31] <fanf> good question about DSNs
[11:29:34] <tlr> Problem: MIME-encapsulating is going to break nested encoding rules.
[11:29:43] <marcos.sanz> Chris: If the GIGO case can be ignored, then checking for the highest bit set is sufficient and necessary, too :-)
[11:29:44] <eric> healthyao: do you have a section number? I can't quickly find the example.
[11:30:35] <klensin-ietf> Pete, to capture the microphone discussion here... assume I have UTF-8 headers and a body part that is, itself, CTE=foobar (a type you don't recognize). If I now encapsulate the whole thing as base64, the multiple encoding rule is broken. You can't upgrade CTE foobar to 8bit and then re-encode the whole business (as you could in principle do with Base64) because you have never heard of foobar. QED, I think.
[11:31:53] <cnewman> Marcos: true, except for any potential security issues with overlong UTF-8 sequences.
[11:32:21] --- leiba has joined
[11:32:23] <eric> healthyao: never mind, i found it (section 4.6)
[11:32:30] <tlr> incidentally, the nested encoding rule is phrased as a restriction on message/* and multipart/* in 2045
[11:32:32] <pguenther> the question at the mike is this: some ESMTP parameters (e.g., ORCPT) pass address
[11:32:50] <pguenther> how do utf8 addresses get encoded in them?
[11:33:03] <pguenther> use the utf8headers <foo@bar{foo@bar}> ?
[11:33:17] <pguenther> that's a mixing of header format into SMTP envelope...
[11:33:33] <pguenther> or should there be ORCPT-DOWNGRADE=....
[11:33:39] <fanf> ugh
[11:33:41] --- Randall Gellens has left: Logged out
[11:33:44] <tlr> errr, no, multipart/* and "some subsets". So it might be compatible with the restriction as specified, but it wouldn't be consistent with the restriction as it makes sense.
[11:33:46] <cnewman> ORCPT has a tagged address: ORCPT=rfc822;encoded-addr. So we could use ORCPT=eai;encoded-addr
[11:33:46] <cyrus_daboo> Eric: rfc2046 section 5.2.1 says message/rfc822 can only be 7bit, 8bit or binary
[11:34:24] --- leiba has left
[11:35:04] <alexeymelnikov> Comparison of different downgrade methods: MIME encapsulation preserves all header information, but make information unreadable in old UAs.
[11:35:10] <cnewman> Of course, the xtext encoding used by ORCPT explicitly forbids 8-bit, we'd have to change that to permit UTF-8.
[11:35:19] <alexeymelnikov> There is also different cost associated with different methods.
[11:35:20] <tlr> incidentally, I'd rather have to implement the header thing than the MIME encoding.
[11:35:45] --- eric has left: Logged out
[11:35:46] <klensin-ietf> Yes, and that change would presumably discuss what to do with the interactiions and decoration.
[11:36:05] <healthyao> 3.5.2 Embedded commands in http://bgp.potaroo.net/ietf/idref/draft-klensin-emailaddr-i18n/#page-15 also has some descriptions (to eric)
[11:36:11] --- cyrus_daboo has left
[11:37:16] --- kurosaki has left
[11:37:49] <alexeymelnikov> Chair is talking about outstanding issues for all docs:
[11:38:08] <alexeymelnikov> 1). ATOMIC parameter needed (agreement to remove it)
[11:38:31] <alexeymelnikov> 2) Syntax for alt-address in the envelope
[11:38:32] <cnewman> Doesn't RFC 3463 already have: X.6.3 Conversion required but not supported and X.6.2 Conversion required and prohibited
[11:38:56] <alexeymelnikov> 3) Do we nee new extended SMTP error codes for cover bouncing and downgrade cases?
[11:40:20] <cnewman> RFC 1893 has been obsoleted by 3463
[11:40:28] --- tlr has left
[11:40:32] <alexeymelnikov> 4)> Encapsulation Model issue: is it satisfactory? (Multiple issues with existing text)
[11:40:36] --- hardie@jabber.psg.com has left: Logged out
[11:40:36] --- kmurchison has left
[11:40:43] <alexeymelnikov> 5). Terminology notification
[11:40:46] --- andrewsullivan has left
[11:41:17] --- marcos.sanz has left
[11:42:35] --- yangwoo ko has left
[11:42:37] --- shinta has left
[11:42:51] --- cnewman has left: Logged out
[11:43:00] <klensin-ietf> Edmon to summarize ATOMIC question /status and take it to the mailing list.
[11:43:05] --- resnick has left
[11:43:11] --- snw has joined
[11:43:25] <alexeymelnikov> ?: was Thomas R.
[11:43:25] --- yone has left
[11:43:27] --- pguenther has left
[11:43:29] --- alexeymelnikov has left
[11:44:14] --- doug_trend@jabber.org has left
[11:45:40] --- fujiwara has left: Logged out
[11:47:00] --- healthyao has left
[11:47:32] --- snw has left
[11:51:59] --- xiaodong has left
[11:54:08] --- tonyhansen has left
[12:02:03] --- LOGGING STARTED
[12:04:48] --- Jaeyoun Kim has joined
[12:40:07] --- fanf has joined
[12:54:32] --- yone has joined
[12:55:24] --- yone has left
[13:00:40] --- kurosaki has joined
[13:05:33] --- edmon has joined
[13:05:38] --- edmon has left
[13:07:08] --- kurosaki has left
[13:13:11] --- Glenn Parsons has joined
[13:15:43] --- Glenn Parsons has left
[13:18:18] --- xiaodong has joined
[13:32:50] --- cary has joined
[13:33:53] --- cary has left
[14:14:11] --- xiaodong has left
[19:24:32] --- Jaeyoun Kim has left