In <8588837(_dot_)1067340808(_at_)localhost> John C Klensin
<klensin(_at_)jck(_dot_)com> writes:
(1) Another advantage of "just" using UTF-8 in an appropriately
negotiated, controlled, and constrained environment is that any
idiosyncracies and coding difficulties are Unicode
idiosyncracies and coding difficulties. If we decide to use a
specialized coding designed for email local-parts (and, fwiw, I
think Adam's coding solution is brilliant... I'm ultimately just
unhappy with the problem definition to which it responds), then
we have to deal with both its idiosyncracies _and_ those of
Unicode. Strikes me as a bad idea -- better to just blame
"them" :-)
Exactly so. "Just send UTF-8" is undoubtedly going to happen, and probably
sooner rather than later. All the IETF can do is to try to ensure that the
transition to it is an orderly one.
Therefore, solutions to this problem should be on the assumption that
ultimately "just send UTF-8" will happen, and they should look sensible in
that context. That then means the solutions can be based on Unicode
practice (which will already be dealing with rather similar problems in
other protocols). Issues such as what normalization and/or strinprep to
use, who is responsible for doing the normalization, and when, how wide
your "@" character should be (and doesn't NFKC and/or stringprep already
narrow it anyway?), and so on.
Encodings into and out of punycode (and other encodings) will be needed
during a transitional period, and that period may well last for a very
long time. But the system must appear to the users as if the UTF-8 had
indeed travelled end to end, and eventually that should be exactly what it
does.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave,
CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5