Re: draft-klensin-emailaddr-i18n-00

Adam,

Thanks for the careful reading.  You raise several points I 
should address in the draft.  I will try to do so, and get 
another version out, before the posting deadline, but I have a 
lot on my plate right now.

Your notes identify one additional issue you should probably 
address explicitly: The notion of not encoding ASCII delimiters 
in order to permit special addressing arrangements to go through 
not only doesn't help with position-based and ASCII-letter-based 
address splitting, it doesn't permit one to have an address that 
is entirely in some non-ASCII script and still use any of these 
special address treatments.  I.e., a delimiter-based approach 
that uses a non-ASCII delimiter would encounter the same problem 
as a string that used an ASCII letter as a delimiter rather than 
a conventional ASCII delimiter.

And I am certainly assuming some changes in MUAs: without an 
internationalized MUA, simply having internationalized addresses 
makes little sense to me in the general case (although I can 
come up with edge cases in which that would not be true, as, I'm 
sure, can you).

However, as I am sure you understand but others may not, the 
primary tradeoff here is really at the level of a fundamental 
architectural and strategic issue, not about fine-tuning either 
approach.  One way of stating it (you may have others, and they 
may be better) is that we are looking at a tradeoff between

	* A model that optimizes deployment that is as rapid as
	possible, especially for individuals who wish to use the
	facilities but are operating in areas of the network
	that are indifferent to them and
	
	* A model that tries to move toward the best
	internationalized use of Email that we can get, even if
	it sacrifices short-term deployment in some situations.

There are sacrifices and tradeoffs either way.  Your model has, 
in my opinion, poor consequences for address presentation and 
imposes some constraints on email local-parts I don't believe we 
should have to live with in the long term.  Mine does require 
MTA changes (as well as the MUA ones that I think are 
inevitable), but the MUA changes are going to be very natural on 
those systems that are Unicode-native (especially if they are 
UTF-8-native).  By contrast, yours, IMO, requires more fussing 
in the MUAs (especially those of UTF-8 native environments), 
perhaps to the extent of actually delaying deployment... we can 
all speculate, but there is really no way to know.   By 
requiring MTA changes, my approach essentially forces an "either 
you internationalize or you don't" situation.  Your approach 
permits, I think, several intermediate points -- do nothing, 
display and/or process the specially-coded form, display and 
process "normal script".

One can argue which of those is better either way, although, 
clearly, if one's main concern is about somehow getting 
addresses in and out of individual, e.g., Hotmail, accounts, 
your clearly has the advantage.   Even there, however, we may 
disagree a bit about impacts: putting a non-ASCII address into 
one of those accounts would probably be easy for you, or me, or 
most of the readers of this list... but we don't seem to be 
using Hotmail accounts.  Teaching the casual user who depends on 
a Hotmail account where to go on the network to get a Unicode 
string encoded into the encoding needed here, then to paste that 
address into a Hotmail signup script, then to teach one's 
friends to use that string as necessary (since it would 
presumably have little mnemonic value in any language) would, I 
think, discourage most such users.  Conversely, when all of the 
MUAs are upgraded, and Hotmail's web page is upgraded 
sufficiently to support more or less direct Unicode input, all 
this trouble will probably be for nothing, but we will be stuck 
with the circumventions in the email system.

While there are details on which we disagreed, and will continue 
to disagree --more of them about what disclaimers should have 
been made explicitly, and how the protocol should have been 
defined, than about the protocol details-- I really do think 
IDNA, or something _very_ like it, was the right approach for 
the DNS.  But it seems to me that the tradeoffs and 
considerations are different for email addresses and that 
"worked there" isn't sufficient justification for "the right 
thing to do here".

regards,
      john


--On Saturday, 11 October, 2003 21:16 +0000 "Adam M. Costello" 
<[email protected]> wrote:

> I have now read draft-klensin-emailaddr-i18n-00.  For
> convenience, here's a link:
>
> http://www.ietf.org/internet-drafts/draft-klensin-emailaddr-i1
> 8n-00.txt
>
> I'm glad that John took the time to write this.  Whatever we
> end up with, we'll have more confidence in it knowing that
> specific alternatives were explored.
>
> Here are my initial reactions.
>
> The solution proposed in the draft presents itself as an
> MTA-level extension to SMTP (RFC 2821).  But it implicitly
> assumes a corresponding extension to the message header format
> (RFC 2822).  The messages carried by ESMTP+I18N would not
> conform to RFC 2822, and existing MUAs could not be expected
> to be able to reply to them.
>...