Time for an alternative?

Hi.

Those who have been on this list from the beginning have 
probably noticed that I raised some early concerns about whether 
it was reasonable, and even possible, to do internationalized 
email addresses at the MUA level, without involving the 
transport machinery.   While it might not be obvious from 
concerns I've raised over the years, I actually prefer MUA-level 
solutions when they are feasible, given poor experiences getting 
the MTA infrastructure upgraded and the notion that users can, 
more or less, pick their own MUAs but not MTAs.

So I pretty much tracked the list, commented on a few specific 
technical points, and then went silent in the sincere hope that 
a satisfactory MUA-level solution would emerge.

I have now concluded that it isn't going to happen and that my 
original, vague, concerns, were, unfortunately, correct.  The 
BIDI-related discussions have been more or less the last straw, 
but are certainly not the only issue.

So...

(i) I've just sent a draft off for I-D posting (it will probably 
be draft-klensin-email-i18n-00.txt).  I expect it will turn up 
Tuesday or Wednesday.  It contains what I hope is a fairly 
comprehensive high-level analysis of the advantages of an MTA 
approach and the disadvantages of an MUA one.  It also contains 
a rather specific proposal for what to do instead.  The 10,000 
foot view/summary of that proposal is that there is an ESMTP 
capability announcement that the relevant server is able to 
handle internationalized addresses.  If the announcement is not 
made, communication needs to be in traditional forms.  If it is 
made, the syntax for email addresses ("mailbox" in RFC 
2821-speak) becomes UTF-8, basically subject only to the 
restrictions in 2821 about the characters that need to be 
distinguished to parse the address.   The domain-part, I hope 
obviously, will need to conform to the names permitted by IDNA, 
but the local-part is essentially unrestricted: if it is valid 
Unicode, then it is a valid local-part.  I can think of strong 
arguments to restrict that a bit, and ways to do it (including a 
stringprep profile and/or mandatory application of a few UTC 
TRs), but it seemed to me that it would be in the spirit of 
historical local parts to see how few restrictions we could 
impose and still have something that works.

(ii) The key issues here go beyond what is in IMAA and whether 
or not it can be fixed and beyond what is in my proposal and 
whether or not it can be fixed.  There are fundamental 
architectural issues here about
	
	* whether email addresses are transport or MUA functions.
	
	* how far we are willing to go, and how much we are
	willing to constrain the future and create permanent
	kludges, to make a somewhat quicker transition (even
	assuming that an MUA solution will yield a faster
	transition).
	
	* how important it is to design things so that the
	character coding used in the MTA, the coding used in the
	MUA, and the coding used in user presentation are the
	same or whether doing that has no value.
	
	* how important the notion of a completely opaque
	local-part is to the Internet and the use of email and
	whether that question can be answered by "see how many
	people get hurt" surveys.

If one is a committed advocate of doing this at the MUA level 
(i.e., "with changes to the infrastructure"), my document should 
be viewed as a set of challenges that MUA approaches need to 
address in a serious way, with the understanding that MUA 
approaches aren't the only alternative.

Consequently, I am sending a note to the Applications Area 
Directors asking for a Minneapolis BOF in this area.  My hope is 
that at least some of us can get together face to face in that 
framework and wrestle with these architectural issues in a 
serious way.

 regards,
    john