Hallo Rob!

 RS> It's an idea. But that's not how *other* charsets/encodings work

Other than the existance of 8-bit characters utf-8 is totally different
than standard 8-bit character sets.  If one is to scan msgs for 8-bit
characters it won't help to decypher the message without knowing beforehand
what the character set is, whereas with utf-8 it doesn't matter.  The
"CHRS: UTF-8 4" is totally useless especially when it is wrong
such as in "CHRS: UTF-8 2" which still happens.

 ON> So, if we wanted to help enforce at a reader (or even tosser
 ON> level) how to handle, I would offer this up as a required BOM to
 ON> the message body that is UTF8.

 RS> And why is that better than a header field ("control paragraph"
 RS> as defined in FTS-5003) which indicates UTF-8?

It isn't.  Also the 0x8d bug present in many fidonet software will ensure
that the utf-8 kludge will be false if there is the existance of that
particular trailing byte.  With true 8-bit character sets, such as CP866
that only affects one character in 128 whereas in utf-8 increases to about
3 or four per language probably more for many of the 24-bit languages.

-={ echo "A Møøse once bit my sister..." | file -b - }=-
UTF-8 Unicode text

Going purely with UTF-8 is the way to go.  It is rather obvious that it is
superior to all the 8-bit character sets combined ... which is a ridiculous
statement but true.

Het leven is goed,
Maurice

... Huil niet om mij, ik heb vi.
--- GNU bash, version 5.0.7(1)-release (x86_64-pc-linux-gnu)