RE: internationalization/ISO10646 question

[ned.freed@mrochek.com]

> > > So if we have Content-Transfer-Encoding: BASE64 in MIME it should be ok.
> > > SMTP server can handle this!
> >
> > If by "handle this:" you mean you can send UTF-16 using BASE64 in SMTP, the
> > answer is still NO. You may be able to get away with it in some cases, but I
> > can assure you that there are others where you cannot. And again,
> > the standards are clear: This is illegal, you do it and you get what you
> > deserve: Corrupted mail, bounced mail, lost mail, and so on.

> I understand what standards say. I understand SMTP standard. But I am asking
> about HTTP and you all the time avoid answering the core of my question
> clearly.

Well, you sure fooled me: You referred to SMTP explicitly here and mentioned
HTTP not at all. If you have a question about HTTP by all means ask it and
make it clear that's what you are asking about.

> > > I unserstand that charset parameter of Content-Type: text/... specifies the
> > > charset for the end-user application, not for the server. Therefore, the
> > > message can be transported through the SMTP network with no problem (CRLF
> > > are present in the correct places..). Then there is mail client' turn. It
> > > removes BASE64 encoding and has a text part to display with some charset given.
> > > YOU say that it can only be UTF-8 (or us-ascii, but it is obvious).
> >
> > Your understanding of the actual nature of the SMTP infrastructure is limited,
> > hopelessly optimistic, and astonishinly naive. Lots of other things can happen.
> > And do.

> Any examples?

The list is practically endless, but here are a few examples: SMTP relays
downgrading or upgrading encodings, signature validators, signing agents, virus
scanners, spam filters, policy enforcment software, gateways of every
description, and on and on and on. If anything such software has been getting
increasingly popular, not less.

				Ned