[09:02:55] --- resnick has become available
[09:11:44] --- resnick has left: Replaced by new connection
[09:11:44] --- resnick has become available
[09:29:52] --- resnick has left: Replaced by new connection
[09:29:53] --- resnick has become available
[09:46:42] --- resnick has left: Disconnected
[09:46:47] --- resnick has become available
[10:11:47] --- resnick has left: Disconnected
[10:11:59] --- resnick has become available
[10:14:13] --- resnick has left: Disconnected
[10:18:46] --- resnick has become available
[10:20:33] --- resnick has left: Disconnected
[12:48:03] --- alexeym has become available
[15:02:21] --- alexeym has left: Disconnected
[15:19:17] --- brabson has become available
[15:19:23] --- sakai has become available
[15:21:06] --- yone has become available
[15:27:47] --- randy has become available
[15:32:29] --- warlord has become available
[15:32:40] --- leslie has become available
[15:32:40] --- leg has become available
[15:32:45] --- michael has become available
[15:33:02] --- hta has become available
[15:33:19] --- nsb has become available
[15:33:59] --- mrose has become available
[15:35:03] --- stpeter has become available
[15:35:25] --- hildjj has become available
[15:36:11] --- rjs3 has become available
[15:37:08] --- hardie has become available
[15:37:08] --- hardie has left
[15:37:42] <michael> I'll try and jabber scribe as well
[15:37:43] --- stpeter has left: Disconnected
[15:37:52] --- jaltman has become available
[15:37:59] --- orange has become available
[15:38:02] --- dcrocker has become available
[15:38:12] --- hardie has become available
[15:38:22] <michael> draft-hoffman-imaa-03.txt out for a month
[15:38:28] <michael> covers protocol completely
[15:38:36] --- stpeter has become available
[15:38:41] <michael> 1.5 early implementations are known, others probably exist
[15:39:00] <stpeter> michael: i can scribe here if that helps you
[15:39:05] --- resnick has become available
[15:39:25] <michael> I'm having laptop issues so I may simply drop off without warning
[15:39:29] <stpeter> ok
[15:39:31] <stpeter> i'll scribe here
[15:39:44] <mrose> 1.5 implementations = implementable???
[15:39:59] <stpeter> IMAA protects the position of all ascii characters other than leters and digits, and doesn't introduce them
[15:40:20] --- hardie has left
[15:40:26] <stpeter> (LHS delimiters)
[15:41:04] <stpeter> e.g., IMAA does not introduce "+"
[15:41:18] <stpeter> adds complexity to the processing
[15:41:44] <stpeter> any non alphanum asii char can act as subpart delimiter
[15:41:57] <stpeter> this enables imaa to interop wigth existing uses of these characters
[15:42:21] <stpeter> handling ASCII punctuation:
[15:42:31] <stpeter> 1. don't treat them as special
[15:42:35] <stpeter> 2. current imaa method
[15:42:53] <stpeter> 3. simply ToASCII and TUInicode, but use encoding other than Punycode
[15:43:07] <stpeter> re-using Punycode seems better than inventing and testing a new encoding
[15:43:22] <stpeter> particularly because RHS already uses Punycode
[15:43:29] <stpeter> work remaining on IMAA
[15:43:33] <stpeter> add examples
[15:43:39] <stpeter> (both simple and complex names)
[15:43:53] <stpeter> add discussion of why IMAA works even in non-SMTP environments
[15:44:13] <stpeter> add more discussion of where encoded mail addreses would and would not appear
[15:44:24] <stpeter> decide about the ACII punctuation handling
[15:45:56] <stpeter> obvious case of where addresses would and would not appear: sender is more advanced than recipient (on MUA or server)
[15:46:28] --- anewton has become available
[15:47:13] <stpeter> END draft-hoffman...
[15:47:28] <stpeter> BEGIN John Klensin
[15:48:15] <stpeter> genesis of proposal: not convinced that IMAA will work
[15:48:38] --- hartmans has become available
[15:48:56] <stpeter> architectural debate here, not just two proposals
[15:49:03] <stpeter> arch problem....
[15:49:18] <stpeter> where do we want to end up and what is important?
[15:49:41] <stpeter> multilingual internet with English as one language?
[15:49:54] <stpeter> or English Internet with some other scripts grafted on?
[15:50:07] <stpeter> fully i18n email or kludge forever?
[15:50:31] <stpeter> smooth working in i18n environment or ability to transmit encoded non-ASCII information to non-updated environments
[15:51:13] <stpeter> localization felt to be more important than true i8n/global interop
[15:51:14] <stpeter> global interop vs. good localization..
[15:51:42] <stpeter> can/should we keep addressing in ACII on the theory that it is all about protocol elements?
[15:51:57] <warlord> "If global interop, then everyone should learn one language. I would suggest either English or Chinese"
[15:52:18] <stpeter> as we have seen with URLs, email addresses will be internationalized
[15:52:41] <stpeter> Q: will it be done in a standard way or locally and incompatibly?
[15:52:46] <stpeter> missed that last comment
[15:53:08] <stpeter> concentrate on making i8n-ised envionments work well
[15:53:39] <stpeter> less important to ensure that non-18n enviros can send transmit receive i1n mail8
[15:53:50] <stpeter> use transport capability negotiation to be sure recipient systems can handle new options
[15:54:16] <stpeter> transport address: utf8-string@utf8-domain
[15:54:57] <stpeter> UTC problems, not IETF problems
[15:54:57] <stpeter> (canonicalization and normalization)
[15:55:00] <stpeter> the bad news: this changes everything
[15:55:14] <stpeter> changes to received, head from to cc, etc.
[15:55:29] <stpeter> what to do aboutg threading, minor, or user-defined fields?
[15:55:41] <stpeter> new fields to carry i18n fields?
[15:55:51] <stpeter> error cases: bounding is acceptable
[15:56:04] <nsb> bouncing
[15:56:32] <stpeter> new addresse will be most useful within communities who share language / script / degree of upgrading
[15:56:35] --- yone has left: Replaced by new connection
[15:56:45] <stpeter> bouncing is a transition problem, not a catastrophe
[15:57:05] <stpeter> best address for unknown person halfway around the world will be ASCII for a long time
[15:57:08] <stpeter> fallback addresses?
[15:57:22] <stpeter> POP3 and IMAP need upgrades
[15:57:34] <stpeter> could use IMAA-like approach for local transition
[15:57:48] <stpeter> "keep kludges local"
[15:57:59] <stpeter> why is this plausible?
[15:58:10] <stpeter> email i18n local parts are more important than domain names
[15:58:18] <stpeter> domain names are multiprotocol
[15:58:30] <stpeter> MUAs in many non-English countries are internationalized already
[15:58:31] --- randy has left: Disconnected
[15:58:53] <stpeter> there are no quick fixes, deployment will take time, so let's get it right
[15:59:22] <stpeter> the goal: a truly internationalized internet
[15:59:27] --- randy has become available
[15:59:35] <stpeter> END John Klensin
[15:59:44] <stpeter> BEGIN Dave Crocker
[16:00:48] --- yone has become available
[16:00:53] <stpeter> we are experiencing technical difficulties IRL, please stand by
[16:02:22] --- hardie has become available
[16:02:48] <stpeter> SWITCH: Paul Hoffman
[16:03:19] <stpeter> topics: problem description, proposed solutions, Paul's opinions
[16:03:38] <hildjj> the power problem is probably a tripped circuit breaker.
[16:05:03] <stpeter> proposed solutions: bounce the message
[16:05:23] <stpeter> downgrade the address to an ASCII encoding (such as IMAA)
[16:05:32] <stpeter> downgrade to a second address
[16:05:59] <stpeter> other approaches encouraged
[16:06:27] <stpeter> bouncing: easy to do, gives the sender no options, prevents forwarding and mailing list problems later
[16:07:17] <stpeter> downgrade to ASCII: works all the time, will expose ugly ACE to the recipient, recipients will want to have MUAs that visiually transform the ACEs
[16:08:07] <stpeter> downgrade to second address: sender has to have two addresses that probably both arrive in the same mailbox -- could be done with new header or with a lookup protocol
[16:08:18] <stpeter> more administrative overhead and coordination for senders
[16:08:38] <stpeter> Paul's opinions:
[16:08:48] <stpeter> 1. bouncing is unnacceptable
[16:09:23] <stpeter> no one will want to use i18n address until everyone has upgraded
[16:09:35] <stpeter> 2. downgrade to ASCII is OK
[16:09:50] <stpeter> still has visual problems, forces support of multiple encodings
[16:09:52] --- dcrocker has left: Disconnected
[16:10:07] <stpeter> 3. downgrade to a second address is probably too complicated
[16:10:18] --- iea has become available
[16:10:18] <stpeter> (particularly when messages get forwarded)
[16:10:41] <stpeter> downgrade to ASCII may or may not be better than a pure IMAA approach
[16:11:02] <stpeter> END Paul Hoffman II
[16:11:16] <stpeter> BEGIN Dave Crocker
[16:12:07] <stpeter> understanding the problem...
[16:12:27] <michael> I haven't read all of the drafts so I'm not going to get up and say this at the mic, but IMHO, all of this illustrates the fact that we need a 'user interface' layer that translates what users/humans use to interact with Internet resources and what protocols use to identify/route/etc with those resources.... if we continue exposing protocol guts as user interface we will always be dealing with stuff like this.
[16:12:56] <stpeter> global syntactic parts are only "@" and "."
[16:13:59] <stpeter> users don't construct addresses, they copy them
[16:13:59] <stpeter> MTAs move message to <domain> (don't interpret local part, i.e., LHS)
[16:13:59] <resnick> michael: I will have a comment about this after Dave's presentation (I think).
[16:14:01] <stpeter> target domain interprets LHS
[16:14:19] <stpeter> <local> *might* follow local structuring conventions
[16:15:23] <stpeter> <local> conventions -- mailbox assignment vs. system-chosen, login specific or not
[16:16:05] <stpeter> structuring is function of *target* MTA
[16:16:05] <stpeter> *may* include MUA
[16:16:05] <stpeter> encoding: no global standards (this is for local part)
[16:16:05] <stpeter> may be *layers* of encoding
[16:16:18] <stpeter> IEA goals...
[16:16:31] <stpeter> 1. expand permitted lrange of characters
[16:17:08] <stpeter> constraints: global enhancement (don't break installed base or local concentions)
[16:17:17] <michael> the strawman we wrote to go along with John's stuff last year worked with email... it gave you a fully internationalized (and localized) email 'name' that was mapped to a never seen email address that was simply used for routing by SMTP servers....
[16:17:23] <stpeter> approaches: reserve unused bits
[16:17:44] <stpeter> unicode representation vs. encoding
[16:17:54] <stpeter> UTF-8 vs. ACE
[16:17:58] --- hta has left: Disconnected
[16:18:30] <stpeter> must respect local conventions
[16:18:38] <stpeter> create unicode segments
[16:18:48] <stpeter> IDN could rely on "." to flag end
[16:19:22] <stpeter> END Dave Crocker
[16:20:02] <michael> aw! come on! you could've said more! ;-)
[16:21:04] <stpeter> BEGIN Michel Suignard
[16:21:45] <stpeter> IRI -- Internationalized Resource Identifier
[16:21:45] <resnick> Lead by example.
[16:21:45] <stpeter> IRI = new protocol element syntax
[16:21:47] <stpeter> use native Unicode characters
[16:21:49] <stpeter> heh
[16:22:08] <stpeter> address all languages/writing systems covered by Unicode (no exception)
[16:22:18] <stpeter> URI, that is
[16:22:32] <stpeter> fully specify mapping to URI
[16:22:50] <stpeter> rely on IDNA for hostname syntax and latest URI revision for its ABNF
[16:23:25] <stpeter> address bidi issues re: logical vs. visual representation
[16:23:46] --- dcrocker has become available
[16:25:46] <hartmans> How does this relate to email? Reading the draft, I don't see for example a proposal to carry IRI in SMTP.
[16:25:47] <stpeter> ...some examples on the screen, which I could type here if I were more l33t...
[16:26:07] --- nsb has left: Disconnected
[16:26:26] <stpeter> IRI status: authors believe ready for Last Call
[16:27:08] <stpeter> hartmans: not sure yet...
[16:27:13] --- jis has become available
[16:27:30] <stpeter> why IRI in a IEA BOF? hartmans has his question answered....
[16:27:42] <stpeter> likely that IEA will be an extension to the mailto scheme
[16:28:15] <stpeter> IRI codifies many scheme elements: repertoire, bidi, IDNA for hostname, Unicode normalization, mapping to URI
[16:28:25] <stpeter> therefore, IEA doe snot need to address these issues
[16:28:27] <hartmans> OK, so this is solving a different part of the problem than the first two presentations?
[16:28:57] <stpeter> IRI is relatively neutral regarding how to deploy IEA (mapping required)
[16:29:01] * hartmans wonders whether one normalization will meet all URI needs.
[16:29:11] <stpeter> but IEA would have a dependency on IRI for deployment
[16:29:18] <resnick> Sam: No, this is "we have to deal with mailto: if we're addressing e-mail addresses.)
[16:29:58] <hartmans> That sounds like a yes, not no. First two presentations sound like they dealt with 2821 and 2822; this seems to deal with mailto.
[16:30:13] <stpeter> Ted Hardie question....
[16:30:31] <iea> Pete: Thanks for the note for us folks on multicast
[16:30:44] <hildjj> it seems reasonable to talk about mailto: and to: at the same time.
[16:30:50] --- iea has left: Disconnected
[16:31:21] --- randy has left: Disconnected
[16:31:23] <stpeter> ted: most critical thing is "new protocol element syntax"
[16:31:46] --- NedFreed has become available
[16:31:49] <stpeter> the point is to develop a common syntax for *new* protocol elements
[16:32:27] --- resnick has left: Replaced by new connection
[16:32:31] --- resnick has become available
[16:32:32] <stpeter> are we trying to change the syntax of an existing protocol element?
[16:32:32] <stpeter> are we trying to create a new protocol element?
[16:32:35] <stpeter> (if new, how do we map new to old, do we have fallbacks, is it part of new infrastructure?)
[16:35:19] <stpeter> BEGIN discussion
[16:35:45] <stpeter> Pete Resnick: do we just want to solve the problem for local part, or do something more grand?
[16:36:18] <stpeter> decision is about how we approach the problem
[16:36:56] <stpeter> nothing we do is going to take a few months -- even just ASCII represetation will take 3+ years after agreement
[16:37:21] <stpeter> Keith Moore comments....
[16:37:50] <stpeter> not acceptable to circle off communities based on language/writing system
[16:38:07] --- randy has become available
[16:38:22] <stpeter> email addresses are used in auth etc., syntax is often borrowed
[16:38:54] <hartmans> Yeah, that's why we're here interrupting our discussions of i18n in auth protocols;)
[16:39:12] <stpeter> is matching of people's names similar enough to matching of domain names? probably worse
[16:39:21] <stpeter> END Keith Moore
[16:39:34] <stpeter> Steve Belvin (sp?) comments
[16:39:38] <resnick> Belovin
[16:39:39] <jis> Bellovin
[16:39:42] <stpeter> sorry
[16:39:45] <resnick> Ah, better.
[16:39:46] <jis> no problem
[16:39:54] <jis> (from us stuck at home)
[16:39:59] <jis> Watching the multicast as well
[16:40:06] * stpeter waves
[16:40:09] <warlord> x.509 names require IA5 strings..
[16:40:23] <stpeter> S/MIME comment that the scribe missed
[16:40:37] <stpeter> we wil lhave to put in new types in PKIX
[16:40:41] <warlord> phoffman: yes, smb is right, we will need to fix that.
[16:41:10] <warlord> probably not an issue for PGP -- they use UTF-8
[16:41:21] <stpeter> issue for PKIX and S/MIME -- need something to disambiguate old email address from new
[16:41:28] <stpeter> Michael Mealling comments
[16:41:45] <stpeter> we are exposing protocol elements as user interface
[16:42:16] <stpeter> a question here: do we want to stop talking about protocol elements and instead talk about user interface?
[16:42:49] <stpeter> perhaps need a translation between protocol elements and user interface?
[16:42:52] <stpeter> many years of conflating protocol element and user interface
[16:42:55] <stpeter> not a clean break
[16:43:09] <stpeter> (last two lines are comments from Pete Resnick
[16:43:14] <hartmans> what does it mean to talk about UI? Do we have a good enough understanding of what the UI issues are that we will consistently and for all be time be talking about UI elements? Or will the UI elements of today be the protocol elements of tomorrow's better UI hiding protocol?
[16:43:46] <stpeter> Dave Crocker comment: "we could use ASN 1"
[16:44:06] --- Gordon58 has become available
[16:45:02] <stpeter> Dave: need to find area of common agreement
[16:45:32] <stpeter> if we can get agreement on the information goal, the encoding paths to that goal may be pursued in parallel
[16:45:42] <stpeter> s/may/could/
[16:46:59] <stpeter> Pete Resnick: do we only care about Unicode in email addresses, or is that one of the things we care about?
[16:47:09] <stpeter> Larry Mastiner comment...
[16:48:02] <stpeter> "making whitepages / directories work might be easier than making i18n email addresses work"
[16:48:31] <stpeter> Jeff (?) comment....
[16:49:41] <stpeter> if we require intermediate MTAs to transform messages, some will not do it
[16:49:41] <leg> and it's time for him to upgrade
[16:50:09] <stpeter> some intermediate MTAs don't correctly transform to/from 7bit
[16:50:11] <stpeter> heh
[16:50:54] <stpeter> John Klensin: at some point, some things are not going to work -- best to not work in an orderly fashion
[16:50:54] <stpeter> bouncing is orderly
[16:50:56] --- dcrocker has left: Disconnected
[16:51:23] <NedFreed> this is my big concern. Regardless of which approach is used, this will
[16:51:36] <stpeter> Nico Williams comment: people will want to use their i18n addresses
[16:51:43] <NedFreed> inevitably share some characteristics with encoded words. How many
[16:51:51] <NedFreed> clients get encoded words right?
[16:51:58] <michael> why not a simple "LHS lookup protocol"? I.e. when a mail client sees an address with a non-asii LHS it connects to a service at the domain on the RHS and asks it for an ASCII-network-safe LHS that the email is then sent to.....
[16:52:06] <stpeter> in practice there will be second layer addresses
[16:52:27] --- warlord has left: Logged out
[16:52:33] --- warlord has become available
[16:52:36] --- warlord has left: Logged out
[16:52:36] <stpeter> (i.e., the business card problem)
[16:52:59] <hartmans> First of all handling authentication and integrity protection for lookup protocols cross-domain is hard
[16:53:01] <leg> LHS lookup protocol: what if that server is down? where does the message get queued?
[16:53:08] <hartmans> Secondly, the MUA may not be upgraded yet.
[16:53:08] <stpeter> Dave Crocker: the ability to have a larger char set will result in showing the more human friendly Unicode
[16:53:27] <leg> authenticatoin & integrity: who cares? we're in the e-mail world here!
[16:54:08] <hartmans> leg: for new protocols we are defined to care about authentication. Email access, submission and transport do all support auth.
[16:54:44] <michael> leg, the message doesn't get queued because it never gets to the point where a message is sent... its a mail client interface function.....
[16:54:56] <stpeter> Marshall Rose comment: please ask for a hum before end of session whether this is a research problem or an engineering problem solvable in our lifetimes
[16:55:06] <hartmans> O, that's even worse; offline mail reading/submission is important.
[16:55:34] <michael> its the same problem of sending mail when you're offline and you get the address wrong....
[16:55:47] <michael> offline mail reading can't be perfect.....
[16:55:53] <leg> so you treat the "remote LHS lookup service unavailable" identical to "local submit server unavailable"? that's probably workable, since probably the majority of e-mail goes to well connected sites that have big uptime. hmmm.
[16:56:35] <hartmans> What does this LHS lookup service buy you anyway?
[16:56:51] <hardie> a new place for the monkey in the middle
[16:57:12] <michael> it buys you the ability to have internationalized email 'addresses' without having to upgrade anything that currently consumes non-i18n-ed addresses....
[16:57:40] <leg> it doesn't fix the i18n addresses in the headers of RFC 2822 messages, so it probably isn't good enough.
[16:57:42] <hartmans> You have to upgrade the MUAs. And there is already a proposal on the table (Paul's) that gives you the same thing for only a MUA upgrade.
[16:58:19] <michael> ted, yea, but given the alternative of changing every prtocol ever built and forcing people to keep using protocol elements as interface, a new potential for a MIM attack is a risk I'll accept.
[16:58:48] <stpeter> Paul Hoffman: do we want to think beyond just the LHS and RHS?
[16:59:04] <hardie> yeah, if you are going to do a translation between the mua's view and the wire format, there would be no difference between doing it locally under the covers and doing it with the lhs server.
[16:59:06] <michael> leg, again, stop using RFC 2822 as a user interface....
[16:59:11] <hartmans> michael: Do you believe you have a firm idea on what UI elements you actually want to be using? I didn't see you answer my earlier question.
[16:59:24] <stpeter> Paul Hoffman: why not just go to UTF-8 headers?
[16:59:52] --- randy has left
[17:00:14] --- resnick has left: Disconnected
[17:00:19] --- randy has become available
[17:00:19] <michael> not particularly, I know people who do and who've written software to do it... they have the problem well in hand. They just need something a network service that can provide them that translation step.
[17:00:23] --- resnick has become available
[17:03:10] --- jas has become available
[17:05:07] <hildjj> heh. if we're going to rewrite SMTP, i have some requirements....
[17:07:40] <hildjj> stpeter lost power.
[17:09:08] <hildjj> dcrocker: timeliness matters. unicode is the right goal for the right term, but that's 15 years out.
[17:09:08] <hildjj> Klensin: but in the transition time, we're protected by a negotiated option.
[17:09:08] <hildjj> resnick: 8bitmime says there are 2 choices. a) downgrade b) bounce
[17:12:41] --- randy has left: Disconnected
[17:13:37] --- leg has left: Disconnected
[17:14:52] --- anewton has left
[17:17:05] --- randy has become available
[17:17:14] --- leslie has left: Logged out
[17:17:22] --- leslie has become available
[17:17:24] --- leslie has left: Logged out
[17:18:54] --- randy has left
[17:19:02] --- randy has become available
[17:20:10] --- resnick has left: Disconnected
[17:20:16] --- sakai has left
[17:20:18] --- randy has left: Disconnected
[17:20:53] --- hildjj has left
[17:21:26] --- hildjj has become available
[17:21:28] --- stpeter has left: Disconnected
[17:22:18] <hildjj> nathaniel: utf-8 headers isn't enough for the grand plan, and too much for the hack
[17:22:33] <hildjj> resnick: well, since it's your fault....
[17:22:53] <hildjj> nathaniel: hack in IETF, grand plan in IRTF
[17:23:10] --- brabson has left
[17:23:59] --- randy has become available
[17:25:15] --- randy has left: Disconnected
[17:25:59] --- randy has become available
[17:26:21] <hartmans> I really wish people wouldn't misuse second system effect that way.
[17:26:37] <hartmans> Strictly it refers to the designer, not to say the second version of a protocol.
[17:29:03] --- rjs3 has left: Disconnected
[17:30:29] --- michael has left: Disconnected
[17:30:57] --- resnick has become available
[17:31:26] --- hardie has left
[17:31:44] --- hartmans has left
[17:32:11] --- Gordon58 has left: Disconnected
[17:32:15] --- mrose has left
[17:32:24] --- jaltman has left: Disconnected
[17:32:25] --- hildjj has left: Disconnected
[17:32:32] --- resnick has left: Disconnected
[17:34:09] --- yone has left
[17:36:46] --- jis has left
[17:36:55] --- jas has left
[17:46:38] --- randy has left: Disconnected
[17:51:14] --- orange has left: Replaced by new connection
[18:46:10] --- NedFreed has left: Disconnected
[19:32:34] --- randy has become available
[20:04:02] --- leslie has become available
[20:05:07] --- leslie has left
[20:43:26] --- randy has left: Disconnected
[20:59:09] --- resnick has become available
[21:00:24] --- resnick has left
[21:00:35] --- hildjj has become available
[21:02:41] --- hildjj has left: Disconnected
[21:02:48] --- resnick has become available
[21:02:57] --- resnick has left
[21:27:10] --- hildjj has become available
[21:28:52] --- hildjj has left: Disconnected
[22:08:26] --- hildjj has become available
[22:20:32] --- hildjj has left: Disconnected
[22:26:28] --- hildjj has become available
[22:49:39] --- hildjj has left: Disconnected
[22:49:44] --- hildjj has become available
[23:22:42] --- hildjj has left