IDNA has defined nameprep+punycode as a new 7 bit ACE (ASCII-compatible
encoding). In fact, every i18n newsreader will need to implement punycode to
correctly display domains.
I suspect that the better answer for usenet is to tighten the specification of
2047, if that's what's causing interoperability problems. But, using punycode
encoding of Subject headers would enable compliant software to take advantage
of the i18n without disrupting existing software, similar to MIME's deployment.
- dan
--
Dan Kohn <mailto:dan(_at_)dankohn(_dot_)com>
<http://www.dankohn.com/> <tel:+1-650-327-2600>
-----Original Message-----
From: Jean-Marc Desperrier
[mailto:jean-marc(_dot_)desperrier(_at_)certplus(_dot_)com]
Sent: Tuesday, January 07, 2003 12:58
To: Dave Crocker
Cc: ietf-822(_at_)imc(_dot_)org;
usenet-format(_at_)rkive(_dot_)landfield(_dot_)com
Subject: Re: UTF-8 over RFC 2047 (Re: Call for Usefor to recharter)
Dave Crocker a écrit:
[...] (No, folks, please don't correct me it
is any other number over 16.)
It's now 0x10FFFF.
Cramming those bits into a 7-bit environment is just one more cramming
effort. It stands equal to the others as an alternative that has benefits
and detriments.
No, because the only standardised 7-bit encoding for unicode is UTF-7
that has so many drawbacks it's strongly deprecated.
If you have a text editor, you can view the 7-bit encoding. The fact that
it is "ugly", therefore is actually a feature, not a bug.
Don't worry, the "pretty" aspect of UTF-8 is not that, it's truly that
it's already implemented in most any client that is able to support more
than one encoding (many more than the one that would support UTF-16).
If it were not, a new seven bit encoding would be better.