Re: [idn] IDNA and other things

[James Seng <James@Seng.cc>]

Dan wrote:
> As I currently have very little free time to discuss IDN and will soon
> be away several weeks I cannot be that active on the list.

Enjoy your holiday and don't forget us when you are back!

> IDNA is only about internationalised host names. I do not think this is
> enough. 

Maybe. This is where other proposal can fill in the gap I suppose :-)

> All of DNS must be internationalised. 

We are doing Internationalized Domain Names. While we have spend quite a lot
of time focus on DNS, this does not mean I18N DNS is the only way to get IDN. 

> All character data in
> DNS must allow non-ascii, and to be really usefull they must use the same
> encoding and normalisation. 

Agreed. That is why Nameprep I-D is important :-)

> IDNA says that updating DNS servers for IDN will be difficult. Maybe, but
> experience shows that applications are the last thing to be updated!

Lets not argue on specific cases. For every example you bring up, there is
always a counter example. I think the best way to please everyone here is to
say *everything* is difficult to upgrade, application, resolver or servers.

> When an application displays a domain name for me, I want it to be displayed
> using my local character set. If my local character set cannot display
> all characters, I want it to display all characters that can be displayed
> directely and others in some "escape" fashion. I do not want it to
> be turned into something totally unreadable like RACE.

If the characters cannot be display, then what is the difference between a
8-bit gibberish and a ASCII gibberish (like leaked RACE)? 

IMHO, they are both gibberish if my system cant render them so they might as
well be in something I can write and type in.
 
> IDNA states that the RACE encoded host names returned by gethostbyaddr
> are not a big problem because so few application shows then to users.
> The host names returned by gethostbyaddr is used in log files, used
> when checking access rights and other places. Many of them I as a user
> will see and have to handle.

Agreed! We sometimes forgot the System Admins are human too. :-)
 
> I guess IDNA requires only one encoding for a host name is so that names
> can be matched in the DNS server as they have removed all matching
> logic from DNS. I think this is the wrong way to go, encodings that
> represent the same name should be allowed. It removes a lot of possibilities
> of difficult to find errors. It is like saying www.xab.com does not
> match www.XAB.com. One mall bug in a RACE/nameprep code in one
> application will make matching not work for some names, and resulting
> in difficult to understand failures.

IDNA does handle this. By specifying one method of nameprep, one method of
encoding, we ensure any IDN would be encoded in one possible way. And hence,
the DNS can remains dumb and just compare the two string, case insensitively.
 
> Zone files: Using internationalised DNS I expect to be able to store and
> edit my zone files using my local character set. It is the DNS server,
> not me, to convert the names from my local character set into the
> standard set used internally by DNS. DNS must be user friendly, we cannot
> expect a user to enter UTF-8 or ACE encoded names.

Out of scope. But your comments makes me wonder. If UTF-8 and ACE are both
user-unfriendly, then what is user-friendly?
 
> When we start using names using non-ASCII we can expect some to want to
> have both a "real" non-ASCII name and an alias in ASCII. Both names
> representing the same name, but the ASCII name is not an ACE of the
> non-ASCII name. DNS should therefore support a way to get both the real
> and the ASCII alias. You can have a look at my latest UDNS draft
> which includes a way for this.

Agreed.

-James Seng