Re: not all is lost but far too much for far too long
  By: Maurice Kinal to Rob Swindell on Wed Jul 03 2019 10:13 pm

 > 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.

Yes, but what I'm saying is that there's already a control paragraph (FTN
kludge) defined for charsets, just use that.

 > The "CHRS: UTF-8 4"
 > is totally useless especially when it is wrong such as in "CHRS:
UTF-8 2"
 > which still happens.

FTS-5003 seems to address that just fine:
  Some implementations do not add the  field and some
  implementations erroneously present "UTF-8 2" instead of
"UTF-8 4".
  Well mannered implementations should gracefully handle this situation
  when reading messages. The recommended way of doing this is to
  ignore the level parameter and only use the name of the identifier.
  In future the level parameter may become obsolete.

 >  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.

That's my perspective as well.
--- SBBSecho 3.07-Linux