Re: [idn] Dots, and a path to working IDNs

["James Seng/Personal" <James@Seng.cc>]

> This is part of what I was referring to. Why aren't Keith and Patrik
> screaming that we need dotprep in thousands of programs? Don't they
care
> about millions of confused users who have typed the wrong dot?

Actually this was brought up in the Nameprep design team.

> Reports from Japan suggest that, in fact, keyboard interfaces already
> have adequate support for typing domain names. Users type the good
dot,
> the canonical dot, the ASCII dot. A domain name with a bad dot simply
> doesn't work; the user fixes it.

I see what you mean now. Hmm..it is a thought: to leave the
normalization problem to the users and let them sort learn what is the
right thing to type.

However, I see some problems too. Normalization of diacritics. If my
keyboard only produce decomposed diacritics but the name is in compsed
diacritics, irregardless how much I try, I wont be able to get it in.

And also, I remember Sherin bought up yesterday on a topic of
userfriendiness and I am not sure if this fits it well.

>    * People will register good UTF-8 IDNs. Lowercase, ASCII dots, no
>      confusing characters. We can distribute name-checking software so
>      that DNS administrators can make sure their IDNs are good.

Agree. I think this should be done anyway, whether it is UTF-8, ACE or
whatever else we have (or decided). It is a good practice to do so.

>    * It's the responsibility of the keyboard interface to help users
>      type good IDNs. Bad IDNs simply won't work.

I don't agree with this or even think it is possible to be done.
Keyboard interface deals with generic input. IDN is only one specific
use for the keyboard. I don't think keyboard producer would have any
incentives to change what they doing for one specific IDN.

There are very likely good reasons someone wants to key in a full-width
dot (U+3002). Expecting the keyboard to produce only ASCII dot is not an
option. You see, that is how Chinese and Japanese write a full-stop ie a
hollow circle. Pick up a Chinese/Japanese book and take a look.

>    * Maybe users will keep putting bad characters into domain names
for
>      some reason. Maybe we really _do_ want slow nameprep, with
>      thousands of programs converting bad IDNs to good IDNs. Okay;
we'll
>      do that if and when the need for it is clear. However, in the
>      meantime, we can still use IDNs!

I am not sure I agree with the last statement. Experience has shown that
we can start using IDN in a just-send-utf8 method in some particular
setup with some particular software.

> This way we get useful IDNs as soon as possible. We take advantage of
> all the existing UTF-8 support. If it turns out that the user
interface
> isn't good enough, that we need to suffer the massive costs of
upgrading
> and redeploying thousands of programs, then we'll do that. The
existing
> IDNs will continue to work.

I could build upon this argument and suggest we all use GBK immediately.
In fact, GBK has better support than UTF-8 since it is mandated by the
Standard Burea. GBK is supported on all Chinese Windows and IE. Users
can already render/display and input GBK without problems and a lot of
applications already support GBK. If we were to use GBK on the wire now,
we can put GBK in the zone files, works with IE and Chinese users would
not have any problem input and using these GBK domain names.

I could go down this analogy in greater scary details...but lets stop
here for now.

What I am trying to say is this argument of 'immediate works' can have
devastating consequences if you are not careful. It is should not be an
argument for supporting some standard.

-James Seng