I suggest to add fourth optional parameter into charset translation schemas that will set up the default fallback charset for rfc2ftn gating. Charset should be assumed as fallback when Content-Type header is in RFC article. There are some groups where default charset is UTF-8, but some old clients are using old 8-bit charsets without Content-Type header. In russian groups is is koi8-r or windows-1251, in english groups it can be us-ascii, iso8859-1 or windows-1252.
Example:
DefaultCharset cp866:cp866:utf-8:koi8-r
In this case:
rfc2ftn:
- FTN message without @chrs should be threated as written in CP866 and recoded to UTF-8
- FTN message with @chrs should be threated as written in charset that in @chrs kludge and recored to UTF-8
ftn2rfc:
- RFC message without charset in Content-Type header should be threated as KOI8-R and recoded to CP866
- RFC message with charset in Content-Type header should be threated as written in that charset and recoded to CP866
Also, I suggest to add special "passthru" charset for rfc2ftn and ftn2rfc schemas which would indicate that no transcoding is needed, only correct headers and kludges.
Examples:
cp866:utf-8:passthru:utf-8
FTN message with LATIN-1 CHRS kludge should not be recoded to UTF-8 when gating ftn2rfc but iso-8859-1 charset should be added to Content-Type header.
Also, ASCII -> us-ascii, LATIN-5 -> iso-8859-9, etc. Unknown charsets should be threated as written in CP866 and recoded as usual.
cp866:passthru:utf-8:utf-8
RFC message with iso-8859-1 in Content-Type header shold not be recoded to CP866 when gating rfc2ftn but CHRS: LATIN-1 kludge should be added.
Also, us-ascii -> ASCII, ibm866 or cp866 -> CP866, etc. Unknown charsets should be threated as written in UTF-8 and recoded as usual.
I suggest to add fourth optional parameter into charset translation schemas that will set up the default fallback charset for rfc2ftn gating. Charset should be assumed as fallback when Content-Type header is in RFC article. There are some groups where default charset is UTF-8, but some old clients are using old 8-bit charsets without Content-Type header. In russian groups is is koi8-r or windows-1251, in english groups it can be us-ascii, iso8859-1 or windows-1252.
Example:
DefaultCharset cp866:cp866:utf-8:koi8-rIn this case:
rfc2ftn:
ftn2rfc:
Also, I suggest to add special "passthru" charset for rfc2ftn and ftn2rfc schemas which would indicate that no transcoding is needed, only correct headers and kludges.
Examples:
cp866:utf-8:passthru:utf-8FTN message with LATIN-1 CHRS kludge should not be recoded to UTF-8 when gating ftn2rfc but iso-8859-1 charset should be added to Content-Type header.
Also, ASCII -> us-ascii, LATIN-5 -> iso-8859-9, etc. Unknown charsets should be threated as written in CP866 and recoded as usual.
cp866:passthru:utf-8:utf-8RFC message with iso-8859-1 in Content-Type header shold not be recoded to CP866 when gating rfc2ftn but CHRS: LATIN-1 kludge should be added.
Also, us-ascii -> ASCII, ibm866 or cp866 -> CP866, etc. Unknown charsets should be threated as written in UTF-8 and recoded as usual.