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.
Well, you can say what you please, but we have several times
in the WG, latest in Santa Fe, said that mnemonic is a character set
in the sense of RFC-MIME. This is why I use this terminology.
I think it is fair to call it a "family of coded character sets"
as the various instances is a way of encoding characters.
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.
This is a pecification of an EUnet standard, you can just count it as
an European equivalence to the JUNET spec. It is specific in the format
specified, and is firmly tied to RFC-CHAR.
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.
Well, I welcome another spec, but it is not compatible with RFC_MNEM,
and it is also having a completely other aim than RFC-MNEM; it
is only aimed at Vietnamese (to my knowledge).
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.
Well, this is not the aim of the document, which is completely tied
to RFC-CHAR.
Section "1." Paragraph 6 should be moved to the "Status of Memo" section.
That could be done, yes.
Section "2." Paragraph 3's reference to Keld's other document should be
changed into a direct reference to the ISO-646-ICS document.
Well, I think the general IETF rule is either to reference another
RFC (preferred) or a non-IETF document. I chose the preferred IETF
way of referencing things.
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.
What are the problems you have with this?
The paragraph says implicitely, that if the transport encoding
is the same as the presentation encoding, well, no need to translate.
If they differ, you should translate to the presentation encoding,
with possible mnemonics.
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.
Well, I am only talking about "Chinese characters" in the paragraph,
which means characters of Han origin; the Kanas and the hangul etc.
are not addressed here.
Section "2.1" This paragraph is unduly restrictive and should be rephrased
or removed.
We cannot define something out in the blue air.
We must have a reference to which character set names this is build on.
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.
I am specifying a term "invariant ISO 646" which is much more
restrictive than just "ISO 646". Please read the draft carefully, Ran.
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.
Well, this does not specify the Vietnamese encoding.
That is a separate spec, IMHO. You may call it: another "charset".
The Vietnamese encoding is very specialized towards Vietnamese, and
I think it will be very hard to generalize the Vietnamese encoding
to most other character scripts.
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.
I think we need references to clear specs.
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.
Then it is not in accordance to the RFC-MNEM.
I beleive that you are trying to push too much into RFC-MNEM,
it describes one instance of a mnemonic scheme, namely the one
employed by EUnet. The scheme proposed here is very general, though,
and the only world-wide mnemonic encoding I have seen.
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.
Could you summarize why it is not suitable for standards track status?
Ran
atkinson(_at_)itd(_dot_)nrl(_dot_)navy(_dot_)mil
Keld