Re: Preliminary minutes from the meeting in Minneapolis

Sorry, is there a conclusion? I mean like where we heading next with this?

-James Seng

Patrik Fältström wrote:

> 
> Here are the preliminary minutes. Thanks to Chris Newman for being a 
> scribe.
> 
> If anyone have comments, let me know asap. I intend to publish these at 
> the end of this week.
> 
>       Regards, paf
> 
> 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.
> 
> 
>