[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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".
--On Saturday, 11 October, 2003 21:16 +0000 "Adam M. Costello"
I have now read draft-klensin-emailaddr-i18n-00. For
convenience, here's a link:
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.