My intent here was something entirely different. In case you haven't bothered
to look, RFC-CHAR contains a substantial number of tables of information.
These
tables have to interwork in a fairly complex way in order for RFC-CHAR to be
an
effective document. Examples:
(0) All commands used in the charset tables must be within the set of
predefined commands.
(1) All descriptions in the table of available mnemonics must be unique.
(2) All mnemonics used in the charset tables must be defined in the mnemonic
tables.
(3) All charset names should be unique.
(4) It should be noted if a mnemonic appears in two places in the same
character set. This is not a problem, exactly, but if it does happen
it must be noted so that appropriate actions can be taken to deal with
it.
(5) The tables of combining mnemonics that Keld has added to the latest
draft must apply to mnemonics that are actually in the associated
character set.
I have also used programs to check this, except (3) (where Ned once
found an error!)
Now, there is a problem here, in that I have attempted to test mechanically
only the potential problem areas that concern me as an implementor. An
implementor using RFC-CHAR for something else might have an entirely different
set of concerns. And this is a problem -- a big one, in fact. This is one of
the reasons I'm concerned about the lack of public comment on RFC-CHAR.
Well I have had something like 20-30 people commenting and suggesting
changes to the document and data. I dont know what is the normal
volume of comments for an RFC. I hope it should not be in the order of
the comments for RFC-MIME!
Keld