Fwd: "International Domain Names" support in KDE

[Krall, Gary]

Dirk (et. at):

At the request of David Faure I am responding to Dirks' email below to the
list in an effort to provide broader education regarding IDNs.

At the macro level the problem is that DNS is fundamentally an 128-bit ASCII
world.  It has no conception of Unicode or characters above this range.  As
a consequence some form of encoding must take place.  Therefore a working
group of the IETF (IDN Working Group) has been working on a series of
documents which specifically address how client based applications should
perform this encoding/decoding function.

Essentially there are 4 documents which address the issue of "IDNs" within
applications.  Of the 4 only one has moved from a Draft to a full RFC and
Verisign, like the rest of the world, is waiting for the other 3 to go the
same route.  We are optimistic that this will happen within the next 90 days
given the fact that Stringprep has been approved and relies on the other 3.

The specific documents are:

http://www.ietf.org/internet-drafts/draft-ietf-idn-idna-14.txt which is the
overview document.

http://www.ietf.org/internet-drafts/draft-ietf-idn-punycode-03.txt this
describes the encoding routine (more on this below)

http://www.ietf.org/internet-drafts/draft-ietf-idn-nameprep-11.txt this
describes name preparation

http://www.ietf.org/rfc/rfc3454.txt?number=3454 this RFC describes string
preparation.

Currently there are only 4 TLDs which have launched a commercial IDN
service.  They are:  .com, .net, .org and .jp.  As the commercial service
was launched prior to the standards noted above the implementation for these
4 domains are based on the following documents:

http://www.i-d-n.net/draft/draft-ietf-idn-race-02.txt - which is the
encoding (precursor to Punycode) and 
 
http://www.i-d-n.net/draft/draft-ietf-idn-nameprep-03.txt which is an early
version of NamePrep. 

Once the above "drafts" have become standards then Verisign (.com, .net),
JPRS (.jp) and Public Interest Registry (.org) will begin the process of
migrating to the standards off their current implementations.  In addition,
all of the ccTLDs who did not launch an IDN service will begin to
immediately implement based on the standards (in particular .se, .dk, .de,
.ru, .cn, .tw and .kr).

Now in terms of software there are two reference implementations.  One is
from JPNIC which is referred to as "IDNkit" and can be found at:
http://www.nic.ad.jp/ja/idn/mdnkit/download/index.html and Verisign's
"Xcode" which we produce and I would be pleased to send this to the
appropriate person who would look to facilitate this integration.

Gary.

-----Original Message-----
From: David Faure [mailto:dfaure at klaralvdalens-datakonsult.se]
Sent: Wednesday, January 22, 2003 3:21 PM
To: Krall, Gary
Subject: Fwd: Re: Fwd: "International Domain Names" support in KDE


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



- ----------  Forwarded Message  ----------

Subject: Re: Fwd: "International Domain Names" support in KDE
Date: Thursday 23 January 2003 00:02
From: Thiago Macieira <thiagom at wanadoo.fr>
To: kde-core-devel at kde.org

- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dirk Mueller wrote:
>On Mit, 22 Jan 2003, David Faure wrote:
>> Does anyone know which parts of KDE would need to me modified to work
>> with the new "International Domain Names" standard from the IETF?
>
>Almost everything. KURL for example doesn't use utf8 encoding, so you
cannot
>access any domain that has nonascii characters.
>
>a nice testcase is www.müller.com. The domain exists and has a webpage, but
>you can't browse it with konqueror.

Actually, that's a problem in KURL. I've done a quick check in other places,

and they all use QStrings and don't care about the contents. They just 
happily feed it to the lookup procedures.

I've also taken a look at what happens if I do a lookup on müller.com:
$ host www.müller.com
www.m\252ller.com has address 198.41.1.35

In principle, Latin 1-encoded hostnames already work. You could even use it
in 
Konqueror, because in the range U+0080 to U+00FF, it won't discard the 
character. For hostnames with letters out of the Latin 1 range, KURL drops 
the extra chars and replaces them by ?

So I tried to telnet into it:
$ telnet www.müller.com 80
telnet: www.müller.com: Name or service not known
www.müller.com: Unknown host

How come? Quick check reveals:
$ host ftp.müller.com
ftp.m\252ller.com has address 198.41.1.35
$ host -t aaaa ftp.müller.com
Host ftp.m\252ller.com not found: 3(NXDOMAIN)
$ host ftp.müller.com
Host ftp.m\252ller.com not found: 3(NXDOMAIN)

It isn't Konqueror's or KDE's fault, then. It won't work in Konqueror
because 
the DNS server resolving it (Network Solution's) says it doesn't exist when 
we do an IPv6 lookup, which is always done first. And even if we did the v4 
one first, any subsequent lookups would fail.

- - -- 
  Thiago Macieira - UFOT Registry number: 1001
 thiagom at mail.com
   ICQ UIN: 1967141  PGP/GPG: 0x6EF45358
     Registered Linux user #65028
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+LyMjM/XwBW70U1gRAvTBAKChqIBdHMcFGfVJfuhBkF8xlwphMgCeJAe2
I1fBtXQzCyjESZONZlk9mnc=
=l/7z
- -----END PGP SIGNATURE-----



- -------------------------------------------------------

- -- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Klarälvdalens Datakonsult AB, Platform-independent software solutions
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
KOffice-1.2.1 is available - http://download.kde.org/stable/koffice-1.2.1/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+LydV72KcVAmwbhARAnEXAJ46T6NXAkwXY4E1pFEDUqY9+8dJ9ACfb03H
jK7VG1ABQ46H1aFqiwLh9vg=
=US6p
-----END PGP SIGNATURE-----