[10:14:00] --- LOGGING STARTED
[10:45:34] --- jas has joined
[11:11:53] --- tonyhansen has joined
[11:21:13] --- tonyhansen has left
[11:51:52] --- pguenther has joined
[12:59:30] --- LOGGING STARTED
[12:59:40] --- jas has joined
[13:03:30] --- LOGGING STARTED
[13:04:40] --- jas has joined
[18:05:05] --- newcat has joined
[18:25:09] --- pguenther has joined
[18:27:35] --- yone has joined
[18:27:54] --- xiaodong.lee has joined
[18:35:05] --- newcat has left
[18:38:47] --- newcat has joined
[18:43:54] --- Thierry has joined
[18:43:56] --- marcos.sanz has joined
[18:45:01] --- Thierry has left
[18:45:16] --- alexeymelnikov has joined
[18:45:23] --- robsiemb has joined
[18:45:25] --- resnick has joined
[18:45:59] <alexeymelnikov> Harald: we are not here to discuss whether the approach is Ok or not.
[18:46:04] --- corby has joined
[18:46:10] --- Barry Leiba has joined
[18:46:28] <alexeymelnikov> Harald: will walk through all documents and try to resolve as many issues as possible.
[18:46:35] <pguenther> alexey, you're scribing? If so, thank you!
[18:46:50] --- tonyhansen has joined
[18:46:56] <alexeymelnikov> Ted is talking about IESG changes to the charter
[18:47:11] --- randy g has joined
[18:47:24] <alexeymelnikov> Philip - I am trying to
[18:47:54] --- klensin has joined
[18:48:05] * resnick was asked to do issue tracking - if you see an open issue and don't explicitly hear that it is on the list, yell "Hey! Pete! That's an issue!"
[18:48:20] --- hardie@jabber.psg.com has joined
[18:48:56] --- cnewman@jabber.org has joined
[18:49:03] <pguenther> "Yeah, it's an ugly font!"
[18:49:12] <pguenther> not all...
[18:49:33] --- cyrus_daboo has joined
[18:49:34] <alexeymelnikov> John will talk about EAI contraints
[18:50:36] <alexeymelnikov> How to address "potential fragmentation issue"
[18:50:37] --- fenton has joined
[18:50:50] <alexeymelnikov> John is not going to repeat his draft
[18:51:01] <alexeymelnikov> (You should have read it)
[18:51:56] <alexeymelnikov> John doesn't think that the draft should necessarily become a WG document. It is a personal opinion.
[18:52:33] --- kdz has joined
[18:52:49] <alexeymelnikov> The document is a set of tradeoffs. We can't satisfy all of them.
[18:53:15] <alexeymelnikov> Paul Hoffman: why can't this be published as individual submission?
[18:53:31] --- apn has joined
[18:53:52] --- fujiwara has joined
[18:53:58] <alexeymelnikov> John: processing for individual submissions takes long time, can be much slower than a WG document.
[18:55:06] <alexeymelnikov> Ted said earlier about charter: IESG will consider very seriously transition from experimental phase to the standard track (see the charter)
[18:55:30] --- apn has left
[18:55:32] <alexeymelnikov> Harald is talking about his scenarious draft
[18:56:06] <alexeymelnikov> Harald: the draft tries not to constraint the solution (tries to be generic)
[18:57:27] <alexeymelnikov> Style of the document: identify true requirements, remove everything that is not 100% needed. Compare solutions against the requirements.
[18:57:43] <alexeymelnikov> Paul Hoffman: fold the document into the framework document
[18:58:34] <alexeymelnikov> John: two many informational documents is bad
[18:58:55] --- newcat has left: Lost connection
[18:59:04] <alexeymelnikov> But John thinks that consolidation should not be done too soon.
[19:00:00] <alexeymelnikov> Harald is pretending to be an editor and not a chair ;-)
[19:00:19] <alexeymelnikov> Consensus to make the document a WG document, but keep it separate.
[19:00:40] <alexeymelnikov> John is talking about the framework draft
[19:01:10] <alexeymelnikov> Ted: "problem statement" says that major rework is needed, what is planned?
[19:01:28] <alexeymelnikov> John: take out the text about major rework ;-)
[19:01:58] --- nsb has joined
[19:02:18] <alexeymelnikov> Lisa D.: are there competing proposal or is it all a single solution?
[19:02:43] <alexeymelnikov> John: there is a single solution, but we wanted to spread the load between editors.
[19:02:44] --- newcat has joined
[19:03:14] <alexeymelnikov> Paul Hoffman: the document doesn't say which documents are mandatory and which are optional.
[19:03:34] <alexeymelnikov> Paul suggests to clarify that all documents are mandatory.
[19:04:22] <alexeymelnikov> John: everything is mandatory, but we are not sure when to downgrade and under what considions.
[19:04:44] <alexeymelnikov> Ted: the document only allows downgrade or bounce?
[19:04:48] <alexeymelnikov> John: yes
[19:04:53] --- newcat has left
[19:05:15] --- newcat has joined
[19:06:03] <alexeymelnikov> Dave Crocker: DSN has strict rules when to bounces, why this draft is not as strict?
[19:06:17] <pguenther> the DSN analogy works to, as you change NOTIFY=never to FROM=<>
[19:06:18] <alexeymelnikov> John: the intent was to make it as strict as DSN rules
[19:06:21] <pguenther> s/to/too/
[19:06:33] <resnick> Issue: Paul: Mandatory to implement
[19:06:50] <resnick> Issue: Dave: Clarify that MUST bounce if the next hop doesn't support.
[19:06:53] <alexeymelnikov> John: this will be clarified
[19:07:13] <pguenther> is part of Paul's item whether downgrade is mandatory to implement?
[19:07:17] <alexeymelnikov> Talking about Email Headers now.
[19:07:24] <pguenther> downgrade in SMTP, that is
[19:07:50] <xiaodong.lee> downgrade in smtp by Jeff@twnic
[19:07:54] <alexeymelnikov> Changes since 00:
[19:08:14] <alexeymelnikov> added new header to signal that headers are in UTF-8
[19:08:32] <alexeymelnikov> New format requires SMTP extension
[19:09:09] --- Glenn Parsons has joined
[19:09:10] <alexeymelnikov> Rules in 2822 are not changed (in particular header names are still ASCII)
[19:09:28] <alexeymelnikov> Message-ID and date-time are not changed!
[19:09:55] <alexeymelnikov> "Phrase" and "comment" can contain UTF-8 now.
[19:10:12] --- fenton has left: Replaced by new connection
[19:10:22] <alexeymelnikov> (Jeff Yeh is presenting)
[19:10:55] <alexeymelnikov> Jeff is talking updated ABNF for addresses (mailbox) - see the draft
[19:11:30] --- levigner has joined
[19:11:32] <alexeymelnikov> Ted: what issues are anticipate for mailing lists?
[19:11:42] --- kivinen has joined
[19:12:12] <alexeymelnikov> Jeff: mixture of i18n and ascii addresses in a single message
[19:12:24] <pguenther> hmmm
[19:13:13] <alexeymelnikov> Dave Crocker: References include text, why not I18N them?
[19:14:31] <alexeymelnikov> Pete R. has jumped to the microphone: References only allows for comments, which are addressed by general rule about comments.
[19:15:01] <resnick> Issue: Dave/Chris: Comma in address lists.
[19:15:48] <kdz> Dave noted that RFC 733? provided a syntax form multiple addresses for an entity and it might be nice to reuse it.
[19:15:49] <alexeymelnikov> Chris: important to give an example of internationalized timezone in the date-time.
[19:16:20] <resnick> Issue: Chris: Comment, especially after date, needed
[19:16:31] --- Fang has joined
[19:16:49] <alexeymelnikov> John think that I18N time zone might be an issue
[19:18:31] <alexeymelnikov> Pete: restrict where UTF-8 can be used, not just say "everywhere where 'comment' is used"
[19:20:27] <alexeymelnikov> Paul Hoffman: give detailed instructions "do this, don't do that", so that other WG like DKIM and PKIX can see any interactions with EAI.
[19:21:03] <alexeymelnikov> Pete R: there is some shared syntax between 2821 and 2822, so it is better to abstract it out.
[19:21:36] <pguenther> do the changes to these rules also effectively change the rules for MIME part headers inside the body?
[19:21:52] <pguenther> UTF-8 inside Content-Foo: headers at the starts of parts?
[19:21:52] <alexeymelnikov> Pete R: be explicit about which rules affect email format, which affect SMTP
[19:22:14] <resnick> Issue: Paul: Canonicalization issues (PKIX/DKIM)
[19:22:36] <resnick> Issue: Pete: Clean separation (or explanation) of what is message format and what is SMTP
[19:23:25] <pguenther> Pete, can you add the MIME header question as an item?
[19:23:43] --- lisaDusseault@jabber.psg.com has joined
[19:24:16] <alexeymelnikov> Philip: Harald has relayed your question.
[19:24:30] <pguenther> yep, thanks
[19:24:30] <resnick> Phil: Waiting to see if it is an issue.
[19:24:42] <alexeymelnikov> Chris Newman: suggests to use SASLPrep for email address canonicalization.
[19:25:00] * pguenther notes on the canonicalization issue: S/MIME at least has *NO* canonicalization level
[19:25:48] <pguenther> Content-Disposition, etc
[19:25:49] <pguenther> yeah
[19:25:57] --- fenton has joined
[19:26:02] <pguenther> Harald's got the gist
[19:26:17] <resnick> Issue: Phil: UTF-8 in MIME structures
[19:26:37] <pguenther> Content-Disposition: attachment; filename="utf-8-stuff here"?
[19:26:43] <alexeymelnikov> John: header names, MIME keywords are unchanged
[19:27:09] <pguenther> at least we have a downgrade path (2231)
[19:27:31] <pguenther> gone..
[19:27:35] <resnick> Content-Description: My Résumé
[19:27:36] <alexeymelnikov> John: Philip's issues is not addressed, will be added to todo list
[19:27:58] <resnick> Rephrase issue:
[19:28:17] <alexeymelnikov> Yao is talking about SMTP extension
[19:28:44] <resnick> Issue: Phil: UTF-8 in MIME Content-* fields
[19:28:51] <alexeymelnikov> Changes since the last revision: added mailbox address synta
[19:29:16] <alexeymelnikov> Added the ATOMIC parameter
[19:29:29] <alexeymelnikov> Descibed use of ATOMIC
[19:30:11] <alexeymelnikov> and ALT-ADDRESS
[19:31:12] <alexeymelnikov> The draft adds two parameters to MAIL FROM and RCPT TO
[19:31:25] <alexeymelnikov> IEmail is the capability (EHLO) name
[19:31:47] --- nsb has left
[19:32:05] <alexeymelnikov> Both parameters to MAIL FROM/RCPT TO are optional
[19:32:31] <alexeymelnikov> ALT-ADDRESS requires all ascii email address
[19:34:38] <alexeymelnikov> [Read the draft for details]
[19:35:52] <pguenther> is there any reason to permit both ATOMIC and ALT-ADDRESS on a single address?
[19:35:59] <alexeymelnikov> ALT-ADDRESS takes precedence. If not specified and ATOMIC=yes, the I18N address can automatically be converted to ASCII (using to be decided Ascii Compatible Encoding)
[19:36:26] <pguenther> as written, ATOMIC is ignored if ALT-ADDRESS is present
[19:36:57] --- psavola has joined
[19:37:39] <pguenther> spaces are the big one
[19:38:18] <alexeymelnikov> Pete R: why change atom ABNF? Why not use ABNF for the quoted string?
[19:38:36] <pguenther> currently, in RFC 2821, <foo@bar> has *exactly* the same meaning as <"foo"@bar>
[19:39:36] <pguenther> the ability to quote a localpart is necessary in cases where localparts are being algorithmicly handled
[19:39:42] <pguenther> (ala user+detail)
[19:41:13] <alexeymelnikov> John: quoted strings are nothing but troubles operationally (based on 20 years of experience)
[19:41:22] <pguenther> hmmm
[19:41:49] <alexeymelnikov> John: tried to get rid of quoted strings on purpose
[19:42:06] <resnick> Issue: Pete: Do we allow UTF-8 in quoted-string?
[19:42:07] <pguenther> there are established uses of email addresses containing spaces
[19:42:31] <pguenther> (mainly for +detail parts naming IMAP mailboxes...)
[19:42:36] <randy g> Phil -- does that work in practice?
[19:43:16] <pguenther> yeah
[19:43:27] <pguenther> I have coworkers who use it all the time
[19:43:41] <alexeymelnikov> Dave Crocker: if ALT-ADDRESS is ascii, why do we need the parameter?
[19:43:57] --- fenton has left
[19:44:15] <pguenther> this involves multiple hops and at least 5 pieces of software examining the address
[19:45:18] <randy g> Plus whatever is on the sender's side, of course. That's great that it works. Maybe implementations have gotten a lot better (maybe it was EHLO that finally did it?)
[19:45:33] <pguenther> now, whether they would work channeled through random mailing lists and multiple MTAs...
[19:46:04] <alexeymelnikov> Dave Crocker is confused about ATOMIC and ALT-ADDRESS
[19:46:05] <pguenther> MTAs from multiple vendors, that is
[19:46:20] <randy g> I'll bet you can't enter those addresses on most web forms (I find that, often enough, web forms insist "+" isn't a valid email character)
[19:46:34] <pguenther> working for an email company means we get yelled at when our own stuff breaks...
[19:46:55] <pguenther> yeah, they dont' work there, but that isnt' what they get used for
[19:46:59] <randy g> I wonder if those addresses get less spam?
[19:47:08] * pguenther hates those forms dislike of '+' tooo
[19:47:43] <randy g> I usually email the webmaster. Once in a while it works and they fix the form.
[19:47:47] <alexeymelnikov> Paul Hoffman: we can't have UTF-8 examples in the document.
[19:47:56] --- kdz has left
[19:48:18] --- Barry Leiba has left: Replaced by new connection
[19:48:18] --- Barry Leiba has joined
[19:49:10] <pguenther> the obfuscated RFC contest?
[19:51:43] --- psavola has left
[19:52:11] --- lisaDusseault@jabber.psg.com has left: Logged out
[19:52:14] <alexeymelnikov> Ted: email address can be in either UTF-8 or punycode?
[19:53:31] <alexeymelnikov> Pete R: Why ATOMIC is need, my guess is for subaddressing.
[19:53:51] <alexeymelnikov> Harald request to defer the question till downgrade draft
[19:54:36] <resnick> Deferred issue: Chris/Pete: Need for ATOMIC/non-ATOMIC
[19:54:43] <alexeymelnikov> Yoshiro Yoneya is talking about the downgrade draft
[19:54:52] <alexeymelnikov> Changes from -00:
[19:55:07] <alexeymelnikov> Added downgrade requirements section
[19:55:30] <alexeymelnikov> 2) Separate SMTP and message downgrading
[19:56:10] <alexeymelnikov> Downgrade requirements: downgrade once, don't upgrade until delivered
[19:56:31] --- newcat has left: Lost connection
[19:56:41] <alexeymelnikov> Downgrading must be easy
[19:56:52] --- newcat has joined
[19:57:00] <alexeymelnikov> Must preserve header information
[19:57:45] <alexeymelnikov> Should work with DKIM/SPF
[19:58:15] <resnick> Issue: Chris: MUST is too strong for preserving all info
[19:58:18] <Barry Leiba> Downgrade + DKIM sounds like a disaster.
[19:58:18] <alexeymelnikov> Chris Newman: some requirements can't be met (e.g. charset info is lost on conversion). Suggest to use "best effort"
[19:58:38] <alexeymelnikov> An attempt to downgrade must be recorded
[19:59:19] <resnick> (Chris: Is that close enough for your issue?)
[19:59:57] <alexeymelnikov> [Read the draft for detailed description of downgrading.]
[20:00:09] <klensin> Thank you Chris :-(
[20:00:44] <alexeymelnikov> Original UTF-8 email addresses is recorded in a new header
[20:01:08] <alexeymelnikov> Two ways to downgrade: MIME encapsulation and header-by-header conversion
[20:04:23] <alexeymelnikov> Harald wants to ask a question as a participant
[20:04:57] <alexeymelnikov> Harald: removing the text about upgrading can make the document simple
[20:05:19] <pguenther> +1
[20:05:22] <alexeymelnikov> Harald is also suggestion to remove MIME encapsulation (and Chris Newman agrees)
[20:05:43] <resnick> Issue: Harald/Chris/Paul: Maybe we don't have to upgrade
[20:06:56] <alexeymelnikov> Chris Newman wants to have upgrade in a different spec (or not at all). But he doesn't think upgrade can be avoided.
[20:07:19] <pguenther> my +1 is about only having one method of carrying stuff
[20:07:49] <alexeymelnikov> Lack of upgrade makes writing IMAP client very difficult (2 different cases to handle)
[20:08:25] <alexeymelnikov> Lisa: encapsulation can be useful, as MUAs can be upgraded to support UTF-8 easier
[20:09:52] <alexeymelnikov> Pete R: recommends to split upgrade (or downgrade) of SMTP and message
[20:10:59] <alexeymelnikov> John: encapsulation preserve all information
[20:12:19] <alexeymelnikov> Chris Newman: protocol level upgrade can only happen inside an AS, no need to talk about this in the draft
[20:15:34] --- corby has left: Replaced by new connection
[20:15:42] --- corby has joined
[20:15:44] <resnick> Issue: Pete: Split upgrade between SMTP upgrades and content upgrades
[20:16:07] <alexeymelnikov> Ted: header-by-header has advantage that only MUA need to be updated, no changes to POP/IMAP server
[20:16:50] <alexeymelnikov> John: how can we downgrade headers we don't know?
[20:17:13] <alexeymelnikov> John: encapsulation and header-by-header are not necessarily mutually exclusive
[20:18:42] --- corby has left
[20:18:50] --- corby has joined
[20:18:58] <alexeymelnikov> Harald: encapsulation can produce a message that the recipient can't use (doesn't recognize the format)
[20:19:03] <resnick> Possible consensus: No upgrading of content in the transport system
[20:19:28] --- corby has left
[20:20:35] <alexeymelnikov> Chris will talk about POP UTF8 extension
[20:21:00] <alexeymelnikov> It adds RET8,LST8 in addition to RETR, LIST.
[20:21:18] <alexeymelnikov> Optional USER parameter
[20:21:29] <alexeymelnikov> USER/PASS/APOP use SASLPrep
[20:22:43] <alexeymelnikov> NO-RETR capability to say that the server can't support "old" 7bit mode.
[20:23:11] <alexeymelnikov> There is no TOP8 command
[20:23:15] <resnick> Issue: Randy: TOP8 command
[20:23:45] <alexeymelnikov> Up-conversion is required to make clients easier
[20:25:29] <alexeymelnikov> An alternative approach is to use a global switch
[20:26:26] <alexeymelnikov> Randy Gellens: TOP8 is useful in mail clients (to check if a message is to be downloaded)
[20:27:47] <alexeymelnikov> No consensus for "not having TOP8"
[20:27:52] <pguenther> hahah
[20:27:53] --- Barry Leiba has left
[20:28:07] --- Barry Leiba has joined
[20:29:10] <alexeymelnikov> John wishes that TOP have never existed
[20:29:25] <pguenther> overloading the migration to act as an crowbar to make people change protocols is unlikely to be successful, IMHO
[20:31:00] <alexeymelnikov> John: for libraries that support both IMAP and POP, TOP adds extra effort and requires specific mode of parsing message.
[20:31:04] --- Barry Leiba has left: Replaced by new connection
[20:31:04] --- Barry Leiba has joined
[20:31:29] <alexeymelnikov> Chris is about to give about on not adding TOP8.
[20:31:34] --- lisaDusseault@jabber.psg.com has joined
[20:32:27] <alexeymelnikov> Tony Hansen: how RETR works on UTF-8 mailstores?
[20:32:33] --- lisaDusseault@jabber.psg.com has left: Logged out
[20:33:13] <alexeymelnikov> Chris Newman: downgrade. The behavior of RETR is not changed in any way.
[20:34:08] <alexeymelnikov> Pete R: clients who wants to download just headers will use RETR and drop the connection. So it is better to have TOP.
[20:34:40] <pguenther> I vote parallel
[20:34:49] <pguenther> cleaner, simpler to work internally
[20:35:03] <resnick> Issue: Chris: Maybe just have an 8-bit switch, instead of separate commands
[20:35:05] <Barry Leiba> Sever view: I don't care. Clients have to answer that one.
[20:35:59] <alexeymelnikov> Question: why clients are using TOP? Because they have limited memory? Use LIST.
[20:36:13] <randy g> Clients use TOP both to look at headers and to peek at body.
[20:36:25] <alexeymelnikov> Chris: global swich versa a parallel set of commands?
[20:36:30] <alexeymelnikov> Harald: take to the list
[20:36:36] <randy g> It's not limited memory but limited bandwidth (dialup, typically,)
[20:36:43] <pguenther> I don't see the use in POP of the locallization bits that the IMAP stuff has
[20:37:47] <alexeymelnikov> John is talking about fragmentation of group of users due to EAI
[20:38:33] <alexeymelnikov> See John Klensin's message on the mailing list
[20:39:08] <cyrus_daboo> Phil: the question is how many pop clients simply pass on the server error text to the end user. I think many do that so there is some benefit in localization. Admittedly POP does have extended response codes which should avoid the need to use the server error text but I'm not sure how well that is supported.
[20:39:14] <pguenther> this is in response to Dave Crocker's, right?
[20:39:49] --- kdz has joined
[20:40:04] <randy g> We could make support for UTF8 in POP depend on supporting extended response codes.
[20:40:51] <alexeymelnikov> Barry Leiba: if there is partitioning, EAI helps to limit it (by preventing deployment of multiple uncompatible methods)
[20:41:46] <alexeymelnikov> Nathaniel: I though the proposed solution will keep Reply working?
[20:42:21] --- kdz has left
[20:43:55] * pguenther ponders attacks based on having the ALT-ADDRESS be completely unrelated to the UTF-8 version
[20:45:07] <alexeymelnikov> to Philip - exactly!
[20:46:34] <alexeymelnikov> Paul Hoffman: partitioning of people based on left-to-right versa right-to-left scripts
[20:46:36] <resnick> Issue: Paul: RTL issues should be looked at
[20:46:49] --- robsiemb has left
[20:46:50] <Barry Leiba> RTL? Oh, Peter..........!
[20:47:15] <resnick> Right to Left. Sorry. :-[
[20:47:18] <Barry Leiba> :-)
[20:47:32] <Barry Leiba> Gotta watch those TLAs.
[20:47:52] <klensin> Yes, that attack is possible. But it is not clear that it is much worse that simply faking the primary address. There is also a phishing-like attack inherent in moving in this direction at all
[20:47:55] --- randy g has left: Logged out
[20:47:56] <cyrus_daboo> Has anyone thought about the distribution/publication of i18n email addresses? e.g. vcard, mailto URLs etc?
[20:48:04] --- tonyhansen has left
[20:48:05] <alexeymelnikov> We are done...
[20:48:05] --- hardie@jabber.psg.com has left: Logged out
[20:48:11] --- newcat has left
[20:48:14] --- Barry Leiba has left
[20:48:15] --- resnick has left
[20:48:32] --- marcos.sanz has left
[20:48:35] <klensin> Cyrus: yes. And Martin Duerst has been quite insistent that we do an IRI mailto review as part of this.
[20:49:22] <cyrus_daboo> I just mentioned vcard because there is some interest in doing a revised version of that. If we do we should take IMA stuff into account in an appropriate fashion.
[20:49:23] --- Fang has left
[20:50:03] --- alexeymelnikov has left
[20:50:14] --- cnewman@jabber.org has left: Logged out
[20:50:30] --- Glenn Parsons has left
[20:50:32] --- yone has left
[20:50:50] --- cyrus_daboo has left
[20:51:48] --- xiaodong.lee has left
[20:56:01] --- klensin has left
[20:56:51] --- fujiwara has left: Logged out
[20:58:39] --- kivinen has left
[21:06:02] --- levigner has left
[21:10:57] --- levigner has joined
[21:13:00] --- levigner has left: Replaced by new connection
[21:13:00] --- levigner has joined
[21:13:00] --- levigner has left
[23:05:23] --- kdz has joined
[23:08:38] --- kdz has left