From: Erland Sommarskog (sommar@algonet.se)
Date: Thu Nov 20 1997 - 16:15:58 CST
Leonid Yegoshin <egoshin@genesyslab.com> writes:
> I don't agree with it. With this requerement news process software
>MUST have UTF-8 understanding, and additional headache. SMTP/MIME allow _any_
>coding in any headers. And news-processing software should convert
>MIME-encoding Newsgroup: to UTF-8 ... Why ?
Notice that a relayer does not need to know much at all about UTF-8. It
should just passed the octets around. The Newsgroup header is by
definition never encoded, which means that if the server sees a
Newsgroups line with se.test.?iso-8859-1?Q?r=E5ksm=F6rg=E6s it should
look for a group with this funny name in its active file, and nothing else.
The clients will need probably need to know about UTF-8, but of course
they should rely on routines provided by the OS.
> But I don't see any arguments for UTF-8-only encoding, yet...
I guess the argument is that at some point in future all other character
sets are hopefully eradicated.
>>If there is no Content-Type header at all, then the body SHOULD be in
>>US-ASCII. But actually, the proposed default is UTF-8, since it does no
>>harm to be that way.
>
> You are in error here. Long before MIME there was and there is software
>which can send/recieve 8-bit mails/news without MIME-headers,
>for exam in Russia. Defaulting 8-bit body as UTF-8 is error, look at RFC1428.
>The reason for creating this RFC is not occasional.
I guess a good software implementor will have some fallback for the
case when there is no MIME headers, but the text is obviously not
UTF-8. For instance, he could opt to present the data as-is, and
hope that sender and receiver is using the same character set. This
should probably not be in the RFC, but only leave this case undefined.
-- Erland Sommarskog, Stockholm, sommar@algonet.se