B. 6: Character sets.
B. 8: Incomplete "character sets" -- How to handle 2022, 10646, MNEMONIC
We agree that ISO 2022 as use by our Asian friends is not a character
set. It is a mechanism, and as such should be designated a text
subtype which reflects it's current usage. Same applies for NMONIC.
With a good write-up of necessary parameters, this should be included.
Keld-Mark? It is not possible to write a good profile of 10646 at
this time and it should be skipped.
I really have to strongly disagree with Greg's position. 2022, 10646, etc
really *have* to be treated as character sets and not content types. If
they are content types, then you cannot have any "structured documents"
(or any other content type) that uses 2022 the way ASCII is used now.
How, for example, would you send something of type "Makefile" that uses
japanese characters encoded using 2022? The character set(s) and encodings
need to be treated as an orthogonal issue to content "type" if you want
the system to be useful in non-US countries.
On the same theme, why treat well specified 2022 character sets any
differently than iso-8859-1?