[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] IDN eamples for testing
No, I am not "misguided" whatever that means. I am repeating what the people
Neither did I ask them to develop a client, or not to.
Lastly, in your private mail to me, you mention that you have not advertise
any server-side resolution solution. Could you confirm this in public?
Once you do, I will forward your response to the registries who have told me
"they said they can provide a DNS server that can resolve IDN" to put the
end to their misconceptions.
----- Original Message -----
From: "Edmon Chung" <email@example.com>
To: "James Seng" <firstname.lastname@example.org>; "IDN" <email@example.com>
Sent: Sunday, March 23, 2003 9:03 PM
Subject: Re: [idn] IDN eamples for testing
> Hi James,
> If you are discussing about Neteka, I think you must be misguided in your
> Neteka supports the IDNA standards and we try to accomodate to the needs
> 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
> obsession about clients and plugins, asking each registry to create a
> "client" is not realistic! Most will look to Microsoft or Netscape or
> browsers/DNS applications to be upgraded over time to IDNA. Registries
> not DNS resolver or browser vendors.
> Meanwhile, registries really should be exerting some energy in preparing
> their "servers" for IDN registrations (and NOT the resolution side as you
> have probably gotten mixed up with). For example handling registrations
> 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
> 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. :-)
> ----- Original Message -----
> From: "James Seng" <firstname.lastname@example.org>
> To: "IDN" <email@example.com>
> 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
> > how to deploy IDN, should they wish to. At least two of them have
> > that some company in Toronto have told them they can deploy IDN using
> > DNS servers only", customized made I supposed.
> > Obviously, IETF (or I for that matter) cannot tell anyone what they must
> > 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
> > IDN? They told me I could just deploy their DNS servers to support
> > 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
> > so either). Of course I am chessed off by this Toronto company! Couldnt
> > 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