[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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