W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2002

RE: Open issues with internationalization section

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 25 Jul 2002 13:48:42 +0200
To: "Taisuke Yamada" <tai@iij.ad.jp>, <w3c-dist-auth@w3c.org>
Message-ID: <JIEGINCHMLABHJBIGKBCIEEGFAAA.julian.reschke@gmx.de>

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Taisuke Yamada
> Sent: Thursday, July 25, 2002 1:38 PM
> To: w3c-dist-auth@w3c.org
> Subject: Re: Open issues with internationalization section
> >> Does everybody agree to extend the encoding requirements to UTF-16?
> >
> > We don't "extend" - we clarify. Any XML parser is required to
> > support UTF-8 and UTF-16. RFC2518 requires that an implementation
> > uses a conforming XML parser.
> Agreed. Also, this update shouldn't cause much problem anyway, as
> everyone seems to have gone with UTF-8.
> > On the other hand, it may make sense to *discourage* any other
> > encoding (such as ISO-8859-1 or win-nnnn).
> Hmm, do you mean by MUST NOT? Banning use of other encodings in the
> spec sounds too aggressive to me. Simply keeping it optional (as XML
> does) should be effectively the same.
> For world-wide interoperability, it is good to have Unicode as a MUST.
> But why not allow use of other encodings under controlled or non-public
> environment?

Well, if a client/server uses an optional encoding (and any except UTF-8 and
UTF-16 *is* optional in XML), it may have to live with the fact that the
other side requests the message, so there's no guaranteed interoperability.

If you control both sides, that's fine. But the whole point in *having* an
open internet protocol is to take care of the case where you *don't* control
both sides.
Received on Thursday, 25 July 2002 07:49:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:26 UTC