I'd like to briefly summarize some of the positions taken on various sides
in this discussion.
1. The IETF community has identified "language" tagging as a requirement for
Unicode-encoded plain text representations so as to achieve, among other things,
the ability to interchange parallel texts (alternative language representations),
support round-trip transcoding between ISO-2022 encoded texts, and provide hints
or markers for implicit font switching.
2. Some members of the Unicode community have identified similar requirements and
have proposed various solutions over the past few years, none of which have been
acted on yet. Nonetheless, these proposals continue to appear afresh in the context
of the UTC.
3. Some members of the Unicode community wish to see this issue resolved outside
the context of Unicode plain text, either by application conventions in the context
of plain text (e.g., plain text markup) or other higher level protocols.
4. The MLSF proposal generally addresses the needs of (1) and (2) above while
encountering opposition from (3) above.
5. MLSF is restricted to use (i.e., defined in the context of) UTF-8 as an
interchanged character encoding scheme (CES). As such, it is not suitable for use
with other CESs (e.g., UTF-7 or UTF-16) and it is not suitable for use as
a process code (internal representation) unless UTF-8 is the process code.
6. MLSF will produce exceptions with UTF-8 implementations that generate exceptions
on finding non-standard UTF-8 sequences or octet values.
7. A number of alternatives to MLSF satisfy part or all of the needs of (1) and (2)
above. 2022-ICODE satisfies transcoding with ISO-2022 texts. The UDC approach (as
proposed by Ken Whistler) is logically equivalent to MLSF while eliminating (5) and
(6) above. However, the UDC approach suffers from the use of user defined codes and
the inherent non-portability that entails. A identical approach which does not suffer
this problem would use standard code-positions reserved for this function; however,
this approach will encounter some amount of delay in its formal acceptance as part of
the code assignments.
My personal position on the above is that an alternative non-UCD (i.e., standard
code assignment) approach is preferred. Its only negatives are (a) opposition from
(1) above and (b) the time required to make actual code assignments.
I imagine that (a) can only be resolved by vote. If a proposal were quickly formulated
and an email ballot conducted among UTC and/or NCITS L3 members, then, assuming
passage, the proposal could be presented in Crete at the WG2 meeting, where, if it
is accepted, could result in fixed code point assignment. Of course, the actual acceptance
of the assignment (in a pDAM) by ISO P-members would be complete until at least early
next year. However, given the rather wide-spread support for a solution to this problem,
I would expect certain passage.
Would the authors of MLSF be willing to revise their proposal to work within the
framework of such an alternative proposal?
Regards,
Glenn Adams
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:34 EDT