[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] UTF-8 / RACE
- To: James Seng/Personal <James@Seng.cc>
- Subject: Re: [idn] UTF-8 / RACE
- From: John C Klensin <klensin@jck.com>
- Date: Wed, 30 May 2001 09:13:05 -0400
- Cc: idn@ops.ietf.org
- Delivery-date: Wed, 30 May 2001 06:13:28 -0700
- Envelope-to: idn-data@psg.com
--On Wednesday, 30 May, 2001 17:24 +0800 "James Seng/Personal"
<James@Seng.cc> wrote:
>> I belive the hardest problem is upgrading the end users.
>> Please try
> and
>> keep in mind that whatever the solution, the greatest pain
>> will
> probably
>> be compatibility issues between the computer and the user.
>>
>> The sysadmins and support techs will be the ones dealing with
>> these compatability issues. Dont make our lives harder.
>>
>> Please.
>
> Any suggestions or ideas how we can make it easiler? I am
> curious to know...
>
> If I am a tech support guy in Europe, and some users calls me
> up over the phone asking me how to access his Korean domain
> names, I probably freak out anyway. (Yes, it does not matter
> how slowly he speaks in korean :-).
James,
I think this is illustrative of one of the key problems, and is
tied to the reason why I no longer believe in a "class=IN"
DNS-based solution. I believe that the only thing that helps
that tech support person is for the call to never occur, and
that means we have to engineer protocols and user interfaces to
do the right thing in the marginal cases. I was taught many
years ago that the key to software that is perceived by users as
effective, easy-to-use, and reliable is to figure out all of the
failure cases (actual errors and having the computer do
something different from what the user expected) and then design
backward from those cases to make sure that reasonable things
happened.
The case (to use your example) of a Korean-speaking user,
sitting in Korea and connected to a Korean ISP, in front of a
Korean workstation, accessing a site in the KR domain, and
(obviously) with Korean-speaking tech support, is always going
to be the easiest one (although a DNS solution may still not be
adequate if fuzzy search or keywords/hint are needed). There are
a whole range of approaches that will "work" or appear to work
(even though some of them are Internet- fragmenting, etc.).
The hard problems all arise when some of those assumptions are
not met. The person speaking a particular language in a country
where another one dominates, accessing a largely
internationalized domain from a different one, using client
software that does not provide for the relevant language, etc.,
is in more or less big trouble, and "call tech support" may just
result in additional frustration.
Clearly, seeing the Korean characters through a user agent that
understands how to handle them is the best solution, especially
if they are supplemented by language-switchable help files and
hint mechanisms. If that is not possible, it is an open
question as to whether seeing an untranslated ACE or a
collection of "undisplayable character" glyphs is likely to
cause the greater frustration. There is even a strong case that
the best answer is to get a clear "undisplayable international
domain name -- upgrade your user agent software or install a
shim" message rather than any failing approximations at the
display. And, of course, such mechanisms are aided by a clear
separation between "legacy" and "internationalized" systems,
rather that tricking the existing DNS (and class) into carrying
non-LDH names or names with non-LDH interpretations.
john