[...]
>> [Cross-posting to news:news.software.readers and setting
>> Followup-To: there. Adding news:comp.mail.mime, on a second
>> though.]
[...]
> If you think this discussion is off topic, why did YOU
... And when Followup-To: is then ignored, is the expectation
that two wrongs will make a right? Or is a failure of one
poster to behave is a license to do so for everyone else?
> post a followup to it in this newsgroup?
Because it's a well-established part of the netiquette (which,
IIRC, you've been pointed at before): when moving a conversation
to another newsgroup, keep the subscribers of the former one
informed. One simple way to do it is as follows: add the
relevant groups to Newsgroups:, copy the result to Followup-To:,
remove the irrelevant ones from the latter (only.)
Yet another way is to send a separate followup to the irrelevant
newsgroup, which is what I'm going to do for this response.
[...]
>> The only issues with forgoing MIME completely I'm aware of are:
>> * pure-ASCII is simply not enough for the majority (90% or so) of
>> the world population; (this isn't a problem should Usenet be though
>> of as a kind of pure-English sect; but it isn't);
>> * use a non-compliant newsreader to quote MIME-compliant messages,
>> and havoc will ensue.
> My newsreader expects me to add headers, if necessary. If I must
> quote an article with non-ASCII characters, I cut them. Typically,
> this happens when I encounter articles written by Google Groups users
> to which non-plain-text characters have been added (like non-breaking
> spaces).
... Which reminds me of the thing I've used to call the
"American Usenet" attitude.
Naturally, I wouldn't expect one participating in
news:tw.bbs.soc.politics, news:pl.comp.os.linux, or
news:alt.russian.z1 to find a non-MIME newsreader all that
convenient.
[...]
>>> The syntax of the CTE header, which is used to indicate a type of
>>> unencoded data
>> Is it?
[...]
> The Content-Transfer-Encoding values "7bit", "8bit", and "binary" all
> mean that the identity (i. e. NO) encoding transformation has been
> performed. As such, they serve simply as indicators of the domain of
> the body data,
[...]
ACK, thanks. (Though the range of the octets used is /not/ what
I'd generally call "type.")