Fwd: "International Domain Names" support in KDE

[Krall, Gary]

Thiago:

Just checking in and I wanted to let you know that the standards have been
released for IDNs.  The specific RFCs guiding implementation are:

IDNA: RFC 3490 (http://www.ietf.org/rfc/rfc3490.txt)

nameprep: RFC 3491 (http://www.ietf.org/rfc/rfc3491.txt)

punycode: RFC 3492 (http://www.ietf.org/rfc/rfc3492.txt)

stringprep:  RFC 3454 (http://www.ietf.org/rfc/rfc3454.txt)

As I may have mentioned in my previous emails, currently all IDNs for .com
and .net are registered in the RACE encoding format which was a precursor to
Punycode.  We, along with JPNIC the holder of .jp names (which are the only
effected domains), are planning a migration from the RACE names to Punycode.
The Verisign schedule is to cutover to the new standard no later than
7/19/2003 at which time all RACE names will need to be migrated to the new
standard and will no longer resolve in DNS.  Any other ccTLDs (for example
.cn, .tw, .hk, etc) who will be launching an IDN service WILL NOT launch
with RACE but instead will launch with Punycode.  In the short term, ~4
months, if you wanted to support .com and .net names you would need to
support RACE and add the mltbd extension.  With that said, by July all names
for any TLD will support ONLY Punycode.  In addition, we are actively
working on a revised version of our publically domain Xcode libraries (for
both Java and C) which will be available on or before the 9th of April,
2003.  This update will include changes to the NamePreparation libraries in
conformance with the final RFC.

Hope you find this information useful.

Gary.
-----Original Message-----
From: Thiago Macieira [mailto:thiagom at wanadoo.fr]
Sent: Thursday, January 23, 2003 3:59 AM
To: Krall, Gary
Cc: kde-core-devel at kde.org
Subject: RE: Re: Fwd: "International Domain Names" support in KDE


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

Krall, Gary wrote:
>  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.

That is the missing piece of code.

Our resolver API already uses Unicode strings and is, thus, ready to accept 
domains in any language. Summarising a quick check I've done of the KDE 
programs:

- - QStrings (thus, Unicode) are used almost everywhere when hostnames are
being 
regarded. So there should be no loss of information when moving that data 
around in applications and libraries

- - The current resolver API (of which I'm the author) uses has QStrings in 
input and output values.

- - The current resolver code doesn't know how to handle IDN domains, so it
just 
transforms the Unicode into a 8-bit representation and sends to the lower 
level functions. It is here that the new encoding/decoding functions have to

be added.

- - Most problems arise when related to legacy code (i.e., before this API
was 
introduced), C code and other stuff outside the KDE libraries (DCOP,
KDE-ICE, 
Arts, krfb) and the encoding of special characters done in URLs. These 
problems have to be quickly dealt with.

I should also mention that the resolver API is currently being rewritten and

IDNs have always been considered. I had even planned of adding an 
encode/decode function to translate a Unicode-based hostname into its 8-bit 
(or, in this case, 7-bit) format, which would be a placeholder for the
future 
encoding.

>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.

I believe I would be that person in KDE.

- -- 
  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+L9kaM/XwBW70U1gRApBoAKCpH8fgp5KTYabbjKbJHoFRjiOdJgCgnH07
sOw20VyP5iypKJidLCj69qE=
=oq8/
-----END PGP SIGNATURE-----