3. mnemonic with & as intro-char: you have a good idea what
is in the text, but the & is disrupting your reading.
Have you tried using underline "_" as the intro-char? In my opinion,
it seems to be less disruptive. (But I do not read text with accented
letters very often, so I guess actual users like you should be the
Yes, I think _ is less disruptive, but this is reserved for the
more-thatn two-character mnemonics. The design gives
priority to this level. The use of _ is buried low down in the
design of the mnemonic names, and it will need a whole
redesign of names to change this.
OK, I think I now understand why you want to include iso-2022-jp in
RFC-CHAR. (Just to make sure, perhaps I should write down my current
interpretation of the situation: You want to include the information
that is needed to be able to convert between current "transport"
encodings and the mnemonic "presentation" encoding. Japanese is
usually encoded in iso-2022-jp, so you need to include its
specification as well.)
My point is that, to cater for interoperability, the transport
format should be the same as the lowest presentation format,
to provide backwards compatibility with current conforming technology.
For Japanese text, the best presentation format
is iso-2022-jp, as you really should have Kanji support
to read such messages, and thus it should also be the preferred
However, a TS that is likely to apply to more than one domain of
applicability should be developed in a modular fashion, to
facilitate its incorporation by multiple ASs.
Well, RFC-CHAR is written for modularity, and does not mention
RFC-MIME, eg. It can be used in a number of ways, in other specs.
Latin-1 would be only a small fraction of the work, and
unsatisfactory for the scope I have tried to address.
I understand your position. How should we proceed from here? Since
RFC-CHAR is so big and difficult to check, it may take a long time to
get it accepted as an RFC. Perhaps we should split it into several
parts? Or maybe have separate documents that point to specific parts
of RFC-CHAR? I'm quite convinced that a mnemonic-like approach for
Latin-1 is a great idea, and really needed soon.
Actually the tables in RFC-CHAR has been checked extensively
against other sources, by software. All the main charsets
including IBM charsets have been checked at least against
two other machine readable sources. And the 10646 naming and codes
have been checked against independent up-to-date machine readable tables.
There may be errors in some less-used charsets, but I am pretty
confident that the quality of the tables are high.