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" implementation. 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, draft-klensin-emailaddr-i18n-01.txt 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 Addresses 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 looks. 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 break. 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 readable. 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 different. 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 discussions. 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 dozen. 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. |