Re: Apology -- didn't read the critical section (was I18N)

On Thu, 20 Feb 1997, Masataka Ohta wrote:

> Laryy;

> > It's just a recommendation for the use of character encodings. 
> 
> Recomendation of UTF-8 is technically wrong.
>
> And, it was pointed out several times already.

You were the only one to claim that. You did not have convincing
arguments. Repeating it doesn't make it better.


> For example, it is impossible to restore Big5 from UTF-8, because
> there are duplicated characters in Big5.

Better stop to criticize Unicode if you don't know it.
Please look at code points U+FA0C and U+FA0D, for example in Unicode
Version 2.0 on page 7-472. These are codepoints for the duplicates, in
the compatibility section.


> It is also impossible to restore ISO-2022-CN encoding from UTF-8,
> though distinction between GB and CNS encoding is often essential.

Do you know any http or ftp server, or anything similar, or any
local file system, that currently uses iso-2022-cn? Please note
that should such a server exist, URLs for it are possible with
the new proposals as they are currently.

Can you give us some of the "often essential" cases, in the context
of resource naming (and not coding of document content)?

Do you realize that the above two cases are similar to your
earlier example of Latin "A" and Greek "Alpha"? The user does
not benefit from a greater number of characters that he/she may
perceive as identical but some encoding introduces arbitrary
distinctions. The difference between traditional Chinese (CNS/Big5)
and simplified Chinese (GB) is easy to make both for computers
and for humans on longer texts, but is in many cases impossible
for humans, and impossible for computers if it's not contained
in the encoding.

As I have explained in a previous mail, contextual practice will
develop for handling cases such as Latin "A"/Greek "Alpha".
Contextual practice would be extremely difficult to define
for iso-2022-cn, if not just defining it so that the artificial
distinctions it contains are eliminated.


> > So what about this:
> > 
> > =================
> > Use of Character Encodings
> > 
> > When describing new URL schemes in which the elements of
> > the URL are actually representations of sequences of characters,
> > care should be taken not to introduce unnecessary variety in the 
> > ways in which characters are encoded into octets and then into 
> > URL characters. Unless there is some compelling reason for a 
> > particular scheme to do otherwise, translating character sequences
> > into UTF-8 [RFC 2044] and then subsequently using the %HH encoding
> > for unsafe characters is recommended.
> 
> That's incompatible with the current practice and unacceptable.
> 
> Use of %HH must be mandatory.

Please check your English. The "is recommended" refers to everything
starting with "translating characters" up to "for unsafe characters".
It means
- UTF-8 AND %HH is recommended.
- Chaos AND %HH is possible.
- Arbitrary octets (including UTF-8) without %HH is not considered at all.


> The only safe recommendation to be compaible with existing
> practice is to use ISO 2022.
> 
> The section should be:
> 
> Use of Character Encodings
> 
>    When describing new URL schemes in which the elements of
>    the URL are actually representations of sequences of characters,
>    it's octet value should be represented by corresponding safe
>    ASCII characters or by %HH notation. There is no room of
>    unnecessary variety except that even safe ASCII character
>    may be represented as %HH.
> 
>    Unless there is some compelling reason for a particular scheme
>    to do otherwise, translating character sequences into ISO 2022
>    comformant ones [RFC 1468, RFC 1554, RFC 1557, RFC 1922] or
>    ISO 2022 based scheme assuming initial designation of ASCII to
>    G0 and nothing to G1, G2 or G3 is recommended [ISO 2022]. Then
>    %HH encoding for unsafe characters MUST be used.

Can you tell me, e.g. for my name ("Dürst" in HTML) what
exact sequence of escape codes I should use? It's easy to make
up a dozen or more different ones. Increasing chaos doesn't
solve problems.


Regrads,	Martin.