On Fri, 4 Aug 2006, Philip Hazel wrote:
> On Fri, 4 Aug 2006, W B Hacker wrote:
>
> > I'd far rather see UTF-8 compatibility than a breakup of top-level
> > routers into, for example, Chinese encoding and ASCII.
>
> Me too!
I've been following the Email Address Internationalization discussions,
and the direction they have chosen is to extend SMTP to allow UTF8 local
parts, domains, and message headers. I think this is great. (Exi18n,
anyone?)
It probably wasn't possible to do this much before now, because it can't
be done without a universal character set - imagine having to tag email
addresses with charsets, as you currently have to do with RFC 2047
encoding of non-ASCII header text. Yuck. (Charset tags are less of a
problem when they are much smaller than the data they are tagging, as is
the case for MIME message parts.)
UTF8SMTP is also being done based on the successful experience of MIME and
ESMTP, which by now have pretty much completely displaced flat ASCII email
and non-extensible SMTP. Part of the hope is that, although we'll have to
start off with support for downgrading from UTF8SMTP to 7 bit SMTP,
eventually we should be able to just-send-8 - which is what most MTAs
currently do for 8BITMIME.
Speaking of which, there are currently three levels of transparency in
SMTP: 7 bit, 8BITMIME and BINARYMIME. The difference between the last two
is that 8BITMIME is allowed to have restrictions on line lengths and
control characters, and in particular it may screw up line endings - for
example, Exim has this limitation. BINARYMIME also requires the CHUNKING
extension to avoid problems caused by trad SMTP's line-based dot-stuffing
message delimiting. I would really like wider support for binary email,
but it's much harder to do once you consider upgrading message stores and
MUAs as well as MTAs...
Tony.
--
<fanf@???> <dot@???>
http://dotat.at/ ${sg{\N${sg{\
N\}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}\
\N}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}
