Re: http charset labelling

> No, I think that if people write URLs on business cards, they should
> write them in a way that the recipient of the business card can type
> in. So if I visit Japan and someone gives me a business card with
> their URL on it, and I come home and type this into my system, I
> should be able to type it in based on the capabilities of *my* system,
> and not the system of the person who gave me the card.

I mostly agree.

But the restriction comes from our brains, not from the capabilities of
our systems.

I'm sure that most of you can't distinguish Han characters for "big",
"dog" and "fat" though the first character of my name is a "fat"
character.

Machines will be rapidly improved but...

> Maybe they'll need or want to print two URLs on their business card,
> the Kanji version for those folks who can type in Kanji directly, and
> the ascii-encoded version for those people like me who have to deal
> with a Kanji-impoverished system like this dumb workstation I'm using
> now.

They can't.

As I pointed out with Big5, which is not the only example, because
of duplicated encoding, it does not work without superintelligent
file system (and other directory systems) which automagically
choose the intended code point among duplicated ones.

So, the available choices of representation on our namecards are:

	1) pure ASCII
	2) a few % notations embedded in ASCII
	3) a lot of % notations
	4) MIME QP with charset labelling

Obviously, 1) is the best both for recognizing and for typing in.

Note that ASCII text may be non-English transliterated text.

							Masataka Ohta

Received on Friday, 2 February 1996 02:10:10 UTC