[EMAIL PROTECTED] wrote:
>
> In a message dated 2001-07-11 15:03:27 Pacific Daylight Time,
> [EMAIL PROTECTED] writes:
>
> > One exception to this should be US-ASCII because not only the repertoire
> > of US-ASCII is a subset of the repertoire of UTF-8 but also the
> > representation of all characters in US-ASCII is identical in UTF-8.
> > A smart mail client would notice that all characters
> > are in US-ASCII repertoire and label outgoing messages as in
> > US-ASCII EVEN if it's configured to label outgoing messages
> > in UTF-8
> [...]
>
> I thought this might even be enshrined in an RFC. It certainly makes sense.
> If you are using a mailer that sends CP1252 down the wire (not that this is a
> good idea, but some mailers do this), the mailer should examine the message
> and if it only contains US-ASCII characters, the message should be tagged as
> US-ASCII.
The RFCs/BCPs do encourage using as minimal a charset as possible.
Anyway, UTF-8 email is nowhere right now. Kat Momoi of Netscape has suggested
that about the only this could change is if email client vendors turn it
on by default in new product releases. I won't be the first!
Having done a lot of email client programming using the RFCs as a basis,
let me say that in general RFCs are vague, and not always the best practice
for interoperability when it comes to email.
For example, CRLF in message bodies is recommended, but actually reduces
interoperability, particularly with subversions of IE 5. So I don't know
of any email client that does it. And quoted-printable is way too
complicated to expect conforming implementations.
And don't get me started about all the random charsets that RFCs promote that
nobody adopts!
James.
