A severe additional problem with the mnemonic proposal (besides its
western-centricity) is this. Given that the special header appears that
identifies key text strings as being in mnemonic encoding, what fields
and sub-fields are subject to this encoding (and therefore decoding)?
Clearly, lines like Subject:/Comments: are to be decoded. And the
intent is that the ``mailbox'' RFC 822 type is to receive special
treatment:
mailbox = addr-spec ; simple address
/ phrase route-addr ; name & addr-spec
I'd guess that the ``phrase'' should be decoded, but in addr-spec, the
``local-part'' should be left alone. How about comments? Are they to
be decoded in From: lines? How about in other lines, like Received: or
Date:? How about all the extension fields--are they to be decoded? How
about the Received: header: its optional ``for'' clause contains an
addr-spec. Is that to be decoded? What about the message massagers
along the way that add Received: lines and possibly manipulate other
headers? What should they do about interpreting encoded text, or making
sure that the text they generate is encoded if that's indicated?
Now, I can make guesses about these questions as well as the next guy,
but implementors can't be allowed to guess. The problem must admit
these decisions as part of its specification, and I'm not convinced that
the problem will admit any such solution.
Why not explicitely state where in the syntax to allow it.
822 has a rigid definition of syntax, and our enhanced character
support could be applied in the texts, e.g. in "text", "ctext"
and "dtext".
keld