Re: [idn] IDN eamples for testing

["Edmon Chung" <edmon@neteka.com>]

Hi James,

If you are discussing about Neteka, I think you must be misguided in your
discussions.

Neteka supports the IDNA standards and we try to accomodate to the needs of
registries.  In fact we are scheduled to start publishing Punycode to TLD
zones that we work with in the very near term.  While I can understand your
obsession about clients and plugins, asking each registry to create a
"client" is not realistic!  Most will look to Microsoft or Netscape or other
browsers/DNS applications to be upgraded over time to IDNA.  Registries are
not DNS resolver or browser vendors.

Meanwhile, registries really should be exerting some energy in preparing for
their "servers" for IDN registrations (and NOT the resolution side as you
have probably gotten mixed up with).  For example handling registrations and
management of multilingual domain names within registration databases,
considering character equivalence issues and provisioning, defining zone
publishing policies for IDNs, etc. all of these are critical to the success
of the deployment of IDN.  And this is where Neteka mainly focuses on
working with registries and preparing their "servers" to accept IDN
registrations from their end-users.

I hope this clarifies Neteka's works for you and others. :-)

Edmon


----- Original Message -----
From: "James Seng" <jseng@pobox.org.sg>
To: "IDN" <idn@ops.ietf.org>
Sent: Saturday, March 22, 2003 7:06 PM
Subject: Re: [idn] IDN eamples for testing


> > The .nu operator supports IDNA, among other things (you also
> > can sent UTF-8 and various local encodings to their DNS servers).
>
> This sound bad. This is breaking the basic functionity of DNS.
>
> <whinning>This reminded me: Various registries have contacted me regarding
> how to deploy IDN, should they wish to. At least two of them have mention
> that some company in Toronto have told them they can deploy IDN using
"just
> DNS servers only", customized made I supposed.
>
> Obviously, IETF (or I for that matter) cannot tell anyone what they must
do,
> how to market their product, or how to deploy it.
>
> But when someone asked me "Are you sure I need to get some client deploy
for
> IDN? They told me I could just deploy their DNS servers to support IDN.",
I
> have to explain IETF standardization, the pros & cons from technical &
> business perspective, and why they *really* dont want to do so IMO.
>
> I have to do it twice now and it is not fun (not that I get paid for doing
> so either). Of course I am chessed off by this Toronto company! Couldnt
they
> just do their own marketing and educating their potential customer
> properly?</whinning>
>
> > P.S. On a related issue: I was wondering whether this is proper
> > operation of IDNA with HTTP, i.e. whether the ToASCII version
> > of the host should be put into the Host: header. The obvious
> > alternative would be to put a MIME-encoded version of the host
> > name into the Host: field, but RFC 2616 is silent on whether
> > this is allowed or not (they say that HTTP is "MIME-like")
>
> RFC 2616 is silent. But IDNA did specify that for any other protocols,
> unless it is updated to handle IDN, we will default the encoding to be
> Punycode. So yes, Punycode should be used in Host:.
>
> -James Seng
>
>
>