Charles Lindsey wrote:
The _real_ problem is that they are not using UTF-8. They are using
whatever character set they fancy, and too bad if the recipient cannot
guess which it is.
I.e. the *real* problem is lack of tagging. Pretending that all untagged
content is utf-8 isn't consistent with reality.
However, that is a problem for the email community.
Not really, since the mainstream mail user agents (mwny of which also
happen to be news user agents) already provide proper encoding and
tagging in header phrases and comments using the RFC 2047 methods. The
untagged non-ASCII content is primarily confined to spam; spammers
tend to use software which is writeen by largely clueless people as
is evident by the large number of syntax errors in spam. Indeed, those
errors (including untagged non-ASCII content) are a good indicator of
spam.
My concern is to see
that Usenet does not get dragged down into the same pit, by laying out a
coherent plan for Usenet.
It appears that Usenet is being dragged into a deeper, darker pit, and
I have not yet seen any sort of coherent plan in the Usefor drafts --
only untested, half-baked, and/or unworkable proposals.
Yes, fixing this situation for either Usenet or for Email is going to
cause some pain, but sooner or later that pain is gping to have to be
faced. Better to do it sooner, and try to minimize it so far as can be.
But do not kid yourselves that it can be avoided. It cannot.
Leaving aside spam, the solution is to bring rogue software into
compliance with the standards. Substituting one untagged charset for
another untagged charset and/or substituting an untagged encoding (utf-8
is both a charset and an encoding) for an existing mechanism which
provides for tagged charset and encoding, while preventing language tagging
which is provided for by the existing mechanisms certainly will cause pain,
but cannot "fix" anything. It can only make matters worse.