2.1.14 Internationalizing Email Address (iea) Bof

Current Meeting Report

Internationalized Email Addresses BOF Minutes  IETF 58, 2003-11-10.

Chairs: Pete Resnick, Patrick Faltstrom
Minute taker: Chris Newman

Agenda Bash: Dave Crocker and Paul Hoffman presentations added.

Paul Hoffman presentation, draft-hoffman-imaa-03.txt

See proceedings (or jabber logs) for Paul's Presentation, highlights of 
comments below:

Has been out for a month.  Author believes this draft is near 
complete.  Author knows of working prototype and one "real" 

Problem with left-hand-side delimiters (e.g. for sub-addresses), have 
three choices of solution (details in presentation).  One choice is in the 
draft, but author could do any of the three choices.

John Klensin presentation, 

See proceedings (or jabber logs) for John's Presentation.

Clarification Questions: (none)

Paul Hoffman - Thoughts on ESMTP-protected internationalizing of email

See proceedings (or jabber logs) for Paul's Presentation.

Clarification Questions: (none)

Dave Crocker presentation - Structure and Scope of Internet Mail 

See proceedings (or jabber logs) for Dave's Presentation.

Clarification Questions: (none)

Pete Resnick: clarification comment.  Dave's presentation assumes that this 
discussion is about how to internationalize the local part.  That may not be 
what we decide is the right bite to take.

Keith Moore comment (paraphrased): The local part is not globally 
opaque, it is only opaque to transport.

Michel Suignard - IRI and IEA, draft-duerst-iri-05.txt

See proceedings (or jabber logs) for Michel's Presentation.

Ted Hardy clarification issue: IRI is a new protocol element syntax.  Not 
allowed in existing protocol elements.  Are we trying to change the 
syntax of an existing protocol element, or are we trying to create a new 
protocol element?  This question is critical and a lot harder than it 

Open Discussion

Do we want to just solve the problem for local part, or do something 
grander? John's draft chooses the latter, but is not a complete 
specification.  Nothing we do is going to take a couple months -- three 
years at best after we agree on an approach.

Keith Moore: Don't think it's acceptable to have a solution that only 
people who don't correspond with other languages can use the new syntax.  
May have to vary on a per-recipient basis.  Email addresses aren't just 
used by email (e.g., authentication protocols).  An analysis of just email 
protocols may not be adequate.  Keith doesn't buy the deployment 
arguments in John's document. Question: is matching of people's names 
similar enough that we can use the same solution?  People's names may be a 
worse problem.

Steve Bellovin: Another requirement from security area: S/MIME for email 
requires an IA5 string with an email address with an exact match.  This 
causes issues with PKIX and S/MIME WGs.

Michael Mealling: We are exposing protocol elements as user 
interface.  Should we create protocol features to translate between 
protocol elements and user interface.

Pete Resnick: We have conflated the two for many years, not a clean 

Dave Crocker: Believe we have agreement that we want to move towards 
Unicode characters for email addresses.  Given this agreement we can then 
work on syntax issues.

Pete Resnick: Is this limited only to email addresses.

Larry Masinter: Used to think that URLs could be protocol element only and 
translated or looked up, but IRI strategy assumes that won't happen.  
Perhaps white pages directory would work for email addresses, however.

Jeff Hutzelman: If we require a "new format MTA" to translate to "old 
format MTA" then some of them will not do it in the real world.  Some MTAs 
claim to support 8BITMIME and fail to down-convert or bounce it in 
violation of spec and refuse to change this behavior.

John Klensin: We have to accept that some things are not going to work with 
un-upgraded systems.  We can do this cleanly or uncleanly.

Nico Williams: People will want to use i18n addresses.  But with 
business cards, there will be secondary addresses in 
non-internationalized form.

John Klensin: Would be nice if secondary address on business card is 

Marshall Rose: Request to poll the room to see if this is a research 
problem or engineering problem.

Nico Williams: If people are going to have two forms of email address and 
one is not going to be an ACE-encoding, then S/MIME encoding issues come up 
(attributes for both).

Ienup Sung: Email addresses are already cryptic in non-English 
countries. Don't necessarily have glyphs for all Unicode characters, but may 
still have cut&paste problem.

Paul Hoffman: When we started on IMAA, we looked at a very narrow 
protocol problem.  John's document moves from just left hand to full email 
address.  But people are waiting for us to fix a bigger problem.  But why 
don't we just go to UTF-8 headers altogether.  Perhaps have "new 
headers" vs. "old headers".  This would solve a lot of people's 
problems.  With IMAA we can have 3 encodings in the From header.  Well 
worth it to make the headers a single sane piece of text.

John Klensin: Doing all of UTF-8 might be better than ASCII sometimes and 
encodings sometimes.

Keith Moore: We may not want two similar formats, one UTF-8, one not.  But we 
may want to redesign MIME and RFC 822 so the new format is very 

Nathanial Borenstein: Spam issue also drives a desire to change to a new 
system.  But we have to be careful because our user community can't wait ten 
years.  We may need to do both: a quick hack, and a redesign.

Dave Crocker: If we talk about using bits that are illegal or making 
changes to MTA, then we talk about replacing the email 
infrastructure with a new one.  If we talk about encoding, then we're not 
talking about breaking things.  The point about timeliness is more 
significant than we believe.  But it could take 15 years.  We need to do 
something that is near term 3-5 years.  Debate of ugliness is 
important but different.

John Klensin: If it's a negotiated option, then it's not breaking the 
infrastructure.  It's a transition strategy.

Pete Resnick: 8BITMIME spec says you can downgrade or bounce.  At 
beginning people bounced, then people downgraded.  Most people now do 
8BITMIME.  People who can't deal with it get reasonably downgraded stuff.  
And it's about ten years.

Dave Crocker: Breakage comes in different forms.

Nico: If we know users will have two names on business cards, that may 
determine which of three choices Paul mentioned that we should take.

Keith Moore: We don't understand the problem yet.  We need to continue the 

Ted Hardy: Nathanial had concrete suggestion: 1. quick hack and 2. long 
term upgrade.  We should poll the room to see which have energy.

Ienup Sung: We may not have the right sample of Internet users to 
address the problem properly.

Straw Polls:

Lots of people have read at least one of the drafts.

How many people are willing to work on ASCII encoding of addresses?  About 1 

How many people willing to work on a grander proposal -- transport 
related, actually changing mail transport?  About 15.

Continuing Discussion:

Observation: There are points in between.

Does the grander proposal belong in the IETF or IRTF?

John Klensin suggests it is a reasonably understood problem.  A hard 
problem with many details, but it is an engineering problem.

Nico Williams: If we have both romanized and pretty forms, perhaps have MTA 
headers use romanized names and pretty forms in new headers and S/MIME.

Chair: that issue is out-of-bounds at the moment, but is an approach that 
can be talked about.

Nico Williams: We need to research if two name forms are what users are 
going to do.

Chair: move this to list, after reading documents.

Nathaniel Borenstein: Email protocols are over 30 years old and have lots of 
cruft.  Strongly supports either extreme, but not the middle.  John's 
proposal may be an undesirable middle ground that changes too much to be a 
hack, but not enough to be a revolution.

Chair: If we did the grand start all over, should we do it in IETF?

Nathanial Borenstein: Would prefer to see the hack in the IETF and the 
grand plan in the IRTF.

Jeffry Altman: Many organizations already provide users with random name 
forms and presentation name forms for the same mailbox.  On subject of hack 
and long-term proposal: if we have both, people will never migrate to the 
long-term proposal.  And therefore we should not do the hack.

Dave Crocker: John Klensin has a well understood goal.  But the rest of us 
may not have an equally clear sense of the goal, as demonstrated by 
desire to expand the goal.  Cost benefit analysis is worth pursing.

Keith Moore: Don't think we can abandon the near term issue due to danger of 
second system syndrome.

Leslie Daigle: Beware of local minimum analysis for email only.  Other 
identifier addresses have modeled themselves on email addresses (e.g., SIP 
addresses).  Need to take this into account in cost-benefit analysis

Mark Crispin: We face a fairly stark choice.  Is preserving existing 
facility highest goal?  Or is the idealized possibility for i18n the 
overriding goal? Can't be reconciled.  Perhaps either extreme is better 
than the middle.  Let's make a decision.  Pick one extreme or another, do 
not try to do something in the middle.

Keith Moore: Convinced there are middle-term solutions better than either 
extreme and we haven't explored that space enough.


Looking at email Internationalization