With regard to the status report on 10646, and assuming for purposes of
argument that this is how things will come out, two observations and a
question that might affect the message format effort. While they were
written independently, these comments partially reinforce Walt Daniels's
posting on the 21st. Unlike Walt, I do not want to see RFC-XXXX contain
specific language about the handling of 10646 before it is case into
concrete, and I think that dropping mnemonic would be a poor idea even
after 10646 comes into moderately wide use.
(i) The statement
> A claim of conformance should identify the form (UCS-2 or UCS-4), the
implementation level, and the identified subset of characters
implies, I think, "you can't interoperate with 10646 without a profile".
I will avoid extensive comments on the "they do it again" topic, but this
implies that any incorporation of 10646 into child-of-XXXX will require
specification of such a profile if it is to meet *our* standards of
interoperability.
(ii) The statement
> The UCS Transformation Format (UTF) is defined in the informative
annex to specify a variable-length encoding of the data avoiding C0,
C1, NUL and SPACE octets
implies that UTF is *not* to be standardized, in the sense that the
former compaction methods were, just commented upon. Nothing would
prevent us from adopting it, but, at a minimum, this means more profile
information.
(iii) I assume that UTF is equivalent to, or nearly so, the proposed AUC.
Could someone confirm that the only contribution to confusio here is a
change of name, or do we have two such proposals on the table?
john