Below is a specific list of additional technical problems that
currently prevent Keld's "mnemonic" algorithm specification from being
useful even as an "experimental" protocol. I believe that most of the
problems in this note could be addressed with a rewrite of the draft,
though other more fundamental technical problems that I have earlier
and repeatedly raised would not be resolved.
(I have organised this in the same way as the draft)
"Summary" section: The memo does NOT define "a family of coded character sets"
rather it defines a format for representing (to be defined elsewhere)
encodings of glyphs into ASCII or ISO 646-ICS. This distinction is
important. ISO-646-ICS or ISO-8859-1 or ANSI X3.4 (US ASCII) all
define "character sets" and this memo does not do the same thing.
Further, the reference to "the memo on 'Character Mnemonics & Character
Sets'" should be removed from the summary because any format used
for representing glyphs in ASCII/ISO-646-ICS should be general enough
to be useful with various mnemonic encoding profiles that might exist.
An example of one that has been used for much longer and is not the
same as the one that Keld cites is the "Viet-Net" convention for
representing Vietnamese text using US-ASCII. The Vietnamese Standards
Group has discussed Keld's proposals at length and the consensus of
that group is that the existing Viet-Net menmonics are much more useful
and significantly more readable than those proposed by Keld. The
VSG is preparing a document with unlimited distribution describing
the Viet-Net mnemonic conventions.
Section "1." Paragraph 5 should be removed for the same reasons I cite
in my previous comment or it should be rephrased to make very clear
that the cited document is a non-normative example of what a Mnemonic
encoding might look like.
Section "1." Paragraph 6 should be moved to the "Status of Memo" section.
Section "2." Paragraph 3's reference to Keld's other document should be
changed into a direct reference to the ISO-646-ICS document.
Section "2." Paragraph 4 is not clearly written and I don't think it
means what it is intended to mean, based on other comments from Keld.
Clearly if a user's display can display the original glyph correctly
then that should be the way it is displayed, regardless of whether
the transport encoding differs from that display's encoding. To do
otherwise would be to impair the user's ability to read text.
Section "2." Paragraph 6 should be rewritten to allow that "The use
of non-native formats to represent ideograms (for example in Chinese,
Japanese, or Korean) is discouraged because such formats, including
this one, cannot be truly mnemonic to the user." It is particularly
noteworthy that many Korean and Japanese ideograms and phonics have
no significant relationship to Chinese ideograms (examples include
but are not limited to KataKana and HiraGana). Moreover, the same
problems that apply to the CJK ideogrammatic languages are in fact
general to all ideogrammatic languages and the draft should say this.
Section "2.1" This paragraph is unduly restrictive and should be rephrased
or removed.
Section "2.2" Note that the non-printing and white space characters are
in fact defined in ISO-646 and would be legitimate introductory
character sets so the restriction to only "&" as an introductory
character from ISO-646 is excessive and unreasonable.
Section "2.2" The requirement "Character mnemonics longer than two
characters are surrounded by the underline character" would prevent
the existing and widely used Viet-Net convention to be made illegal
ex post facto. This requirement should be removed because it causes
significant problems for Vietnamese because Vietnamese uses roman
letters with multiple diacritical marks per roman letter.
Section "3." The reference of "can be done according to the charset
tables below" should be rewritten "might be done according to
the charset tables below, for example, " and made clearly non-
normative. Other tables might be useful in particular environments
and so there should be no needless restrictions placed on users
of the mnemonic formatting scheme.
Section "3." The special meaning of "/c" is needlessly restrictive
because it prevents any mnemonic scheme from using that as a
mnemonic string regardless of how appropriate it might be in
the particular environment of the mnemonic scheme.
In general, the scheme proposed by this document is not suitable for
standards track status for reasons previously cited in detail on the
IETF-822 extentions mailing list and elsewhere, though if sufficient
editorial and content changes are made (including all those suggested
here) it might be appropriate for "experimental" status.
Ran
atkinson(_at_)itd(_dot_)nrl(_dot_)navy(_dot_)mil