Re: Comments on <draft-ietf-acap-mlsf-00.txt>

From: Kent Karlsson (keka@im.se)
Date: Wed Jun 11 1997 - 06:40:06 EDT


Chris Newman <Chris.Newman@innosoft.com> wrote:

> readable strings. Why not just create a format for "human readable strings
> which meets the IAB charset workshop recommendations" and solve the
> problem for all protocols? I think it's quite clear that solving this at
> the protocol level is the wrong level from an architectural standpoint. It
> may seem to keep Unicode "purer", but only at the expense of a significant
> increase in complexity for *every* Internet protocol carrying human
> readable text.

I have no argument against the idea of creating a simple form of
"language tagged, but otherwise plain, text" (usually for short texts)
for use in multiple internet protocols.

   I am not sure it is always appropriate, and the idea could, and
perhaps should, be generalised. But that is not the major opposition
to MLSF as it stands.

> Solving this below the application protocol level is more expressive and
> far more practical. The architectural complexity at the protocol level is
> so significant that it far outweighs any aesthetic concerns you have with
> UTF-8/Unicode.

The major concerns raised are *not* about aestetics, they are about
the technical viability of the MLSF suggestion. As it stands it is
technically highly inappropriate, for reasons I and others have
explained before in this thread. You have also been given viable
suggestions, not deviating far from the original proposal (i.e.,
language tags "in-band"). I have seen no good arguments against
any of those suggestions, except some minor "inefficiency" arguments,
which are too minor to be further considered (the extra processing
must be done anyway, no matter how the language tags are coded).

   I might agree that an "out-of-band" solution is too complex to
be appealing. The major problem being that it may then be difficult
to have a single solution for multiple protocols or even multiple
parts of a protocol.

   But if you take up on any of the alternative "in-band"
suggestions, the more flexible the better, and stop messing
with UTF-8, I am sure the opposition will be far less severe.

                /kent karlsson



This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:34 EDT