Subject: RE: I don't want to be facing 8-bit bugs in 2013

From: Erkki Kolehmainen <[email-masked]>
Date: Wed, 20 Mar 2002 09:07:56 +0200

Re attached:

The use of local character sets (encoding) is doomed for particularly ww
information interchange.

Local font crafting is quite another issue. With the newly introduced
capability in the UCS (ISO/IEC 10646) and Unicode to predefine sequences for
decomposed characters, font manufacturing is likely to also improve.

Sincerely,
_____________________________________________
Erkki I. Kolehmainen
TIEKE Tietoyhteiskunnan kehittämiskeskus ry
TIEKE Finnish Information Society Development Centre
Salomonkatu 17 A 10, FIN-00100 HELSINKI, FINLAND
Tel: +358 9 4763 0301,   Fax: +358 9 4763 0399
http://www.tieke.fi   <[email-masked]>

-----Original Message-----
From: Masataka Ohta [mailto:[email-masked]]
Sent: Wednesday, March 20, 2002 7:34 AM
To: D. J. Bernstein
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: I don't want to be facing 8-bit bugs in 2013

D. J. Bernstein;

> Paul Robinson writes:
> > You tell him that although it's gobbledygook to people without greek
> > alphabet support, it will still work. It's not convenient, but it WILL
> > work. Guaranteed.
>
> False. IDNA does _not_ work. IDNA causes interoperability failures.

IDNA does _not_ work, because Unicode does not work in International
context.

> People who say that IDN is purely a DNS issue are confused.

It's purely a cultural issue.

> In fact, the cost of fixing UTF-8 displays is much _smaller_ than the
> cost of fixing IDNA displays. UTF-8 has been around for many years, has
> built up incredible momentum (as illustrated by RFC 2277), and already
> works in a huge number of programs.

In international context, it is technically impossible to properly
display Unicode characters.

There is no implementation exist.

While some implementations work in some localized context, local
character set serves better for the context.

						Masataka Ohta

-
This message was passed through [email-masked], which
is a sublist of [email-masked]. Not all messages are passed.
Decisions on what to pass are made solely by Raffaele D'Albenzio.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 21 Mar 2002 08:43:28 +0859 ()

Erkki I. Kolehmainen;

> The use of local character sets (encoding) is doomed for particularly ww

Interestingly enough, ww information interchange is working very
well with local character sets.

The reason is because only people sharing a language, a scripting
system and a character encoding system join each exchange, regardless
of whether it is ww or intranational.

For example, ww IETF communication is with English, Latin script and
ASCII. Introduction of ISO-8859-1 or Unicode does not make IETF use
Finnish.

Your attempt to put ISO-8859-1 characters is not acceptable for me
and your mail is filtered to be pure ASCII by my mailer, which is
fair because many of us have no way to input non-ASCII ISO-8859-1
characters.

						Masataka Oha

---

From: "James Seng" <[email-masked]>
Date: Thu, 21 Mar 2002 09:59:36 +0800

While the discussion of the use of various character set is interesting
topic, one which is also of interest to IDN WG, such prolonged discussion
are better carried out in a forum which is dedicated to this, such as
[email-masked], a list which is formed to talk about the
generic problem of I18N and L10N in IETF, and not IDN.

Please bring it over to the other list and when/if there is a conclusion,
please keep the IDN informed.

Thanks.

-James Seng

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 21 Mar 2002 16:27:23 +0859 ()

James;

Trying to reply your mail, my mailer says:

	[Charset Windows-1252 unsupported, skipping...]

so, could you learn not to Microsoft centric and to use proper charset
for the International discussion of IETF?

> generic problem of I18N and L10N in IETF, and not IDN.

I believe IDN, or bogosity of it, worthes attracting generic attention
of IETF.

> please keep the IDN informed.

As you could have seen, on IETF mailing list, Harald and I have, at
least, agreed that, if you use unicode based encoding, local context
(or locale) must be carried out of band

I think Harald's language tag is highly semantical and is not
useful for purely lexical (not even syntactic) issues such as
charset disambiguation or space elimination for format=flowed.

For example, the follwing Japanese text in Romaji script:

	IDN tte zenzen dame

follows, as you can easily guess, usual folding rules for Latin-based
scripts.

But, anyway, the discussion so far in IETF list is enough to deny IDN.

I'm happy to discontinue the thread, then.

							Masataka Ohta

PS

I have found a theory to deny PKI and to explain why public key
cryptograpy is not so polular dispite the efforts of ISO, which will
destory entire business of a company or companies owing several
important TLDs.

So, don't bother to say that there are so many so-called-international-
but-actuallly-local domain names registered.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 21 Mar 2002 18:03:34 +0859 ()

James;

> Few will disagree (including me) that using Unicode to do localization is
> almost impossible without locale context.

Huh? No one said such a thing.

What is agreed is that, to use unicode, it must be supplied out of
band local context.

So, could you explain how the context is supplied with current IDN spec?

> But I am touching on a sensitive topic about what you considered as I18N &
> L10N and what the rest of the world thinks.

Totally irrelevant.

> I am not aware there was a IETF wide last call on IDN yet.

To deny IDN, IESG can simply say "IDN is disbanded". There is no last
call necessaruy.

> Very interesting. Could you share the theory, or privately if you prefer?

I will post it later if I have time.

						Masataka Ohta

---

From: "James Seng" <[email-masked]>
Date: Thu, 21 Mar 2002 21:29:49 +0800

> What is agreed is that, to use unicode, it must be supplied out of

In that case, I disagree with "to use unicode, it must be supplied out of
band local context".

You only need out of band local context to use Unicode if you are doing
localization.

> So, could you explain how the context is supplied with current IDN spec?

Internationalization as defined in POSIX, means making software location
neutral. Making a program specific to any particular language or culture or
codeset is known as localization.

I in IDN is Internationalization.

> To deny IDN, IESG can simply say "IDN is disbanded". There is no last

Ah of course IESG can. But sorry, you dont represent IESG.

> I will post it later if I have time.

Please do. Thanks.

-James Seng

---

From: "Meritt James" <[email-masked]>
Date: Thu, 21 Mar 2002 08:48:14 -0500

You want to be facing 8-bit bugs in 2002?  I recommend reconsideration
of priorities.

-- 
James W. Meritt CISSP, CISA
Booz | Allen | Hamilton
phone: (410) 684-6566

---

From: "James Seng" <[email-masked]>
Date: Thu, 21 Mar 2002 16:58:07 +0800

[Note: IDN WG list removed]

ps: btw, what effort of ISO are you referring?

> but-actuallly-local domain names registered.

Huh? Since when this was ever a factor in IETF consideration?

-James Seng

---

From: [email-masked]
Date: Thu, 21 Mar 2002 15:43:47 -0500

On Thu, 21 Mar 2002 16:47:58 +0859, Masataka Ohta said:

> As my mailer says;
>
>	 [Charset utf-8 unsupported, skipping...]
>
> you should learn that Unicode is not usable in international context
> of IETF.

However, from http://www.iana.org/assignments/character-sets

Name: windows-1252
MIBenum: 2252
Source: Microsoft  (see ../character-set-info/windows-1252)       [Wendt]
Alias: None

Name: UTF-8                                                    [RFC2279]
MIBenum: 106
Source: RFC 2279
Alias: None 

Odd.. They're properly tagged and registered charsets.   They're as legal
as iso-8859-1 and us-ascii.  Given that 'windows-1252' is probably a
supported character set on more systems than anything *you* are likely
to propose (given that I expect you won't propose Unicode or UTF-8 based
solutions), I would be *very* careful in equating "it isn't supported on
my MUA" to "is not usable in international context".   That's a very steep
and slippery slope that you probably do not want to be standing near....

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech