[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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" <ietf-imaa.amc+0@xxxxxxxxxxxxxxxxxxxxxxxxxxx> 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.
...