Re: URL internationalization!

"Martin J. Duerst" <[email protected]> Sat, 15 Mar 1997 17:22:32 +0100 (MET)
Newsgroups gmane.ietf.url
Message-ID <Pine.SUN.3.96.970315162401.245r-100000@enoshima>
On Tue, 11 Mar 1997, Masataka Ohta wrote:

> If it's individual characters, character sets containing Latin,
> Greek and Cyrillic 'A's are ambiguous and is unusalble.

There is a big difference between ambiguous and unusable.
ISO 10646 contains several areas with possibilities for
ambiguity. It is clear that such ambiguities have to be
avoided for URLs to work. It is important to note that
ISO 10646, encoded as UTF-8, contains considerably less
possibilities for ambiguity than ISO 2022, the alternative
that Masataka is suggesting repeatedly but half-heartedly.

Here is a list of the main possibilities for ambiguities
in ISO 10646 and the way to solve them:

Different encodings of the same diacritic combination
(precomposed and decomposed):

	Define a normalization standard based on the
	already existing equivalence relations. I am
	already working on a document proposing normalization
	rules; in my proposal, the most important one
	will be: Precomposed characters in Unicode 2.0
	stay composed, anything else stays decomposed.


Compatibility and pseodo-compatibility characters:

	With "pseodo-compatibility" I mean characters
	that are not in the compatibility section, but
	which most probably should have ended up there,
	such as the Angstrom/A-ring at U+212B.
	In this case, the non-compatibility characters
	should be used.


Otherwise easy-to-confuse characters:

	An example of this is the Latin/Greek/Cyrillic "A"s
	mentionned above. These are ambiguous, but not
	unusable. They have to be used with care. We already
	have examples in ASCII URLs where such care is necessary:
	O/0 (add D here for Japanese) and l/I/1. Written on
	paper, they are often ambigous. Nobody would want
	something like 0O00Oo0O0O.com. Similarly, nobody
	would invent AAAAAAA.com, where each a is from a
	different alphabet. There is a lot that can be done
	with technology, but there are limits; on the other
	hand, there is no need to assume that users are more
	stupid than they actually are.

Regards,	Martin.