No, I am not "misguided" whatever that means. I am repeating what the people asked me.
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. -James Seng ----- Original Message ----- From: "Edmon Chung" <[EMAIL PROTECTED]> To: "James Seng" <[EMAIL PROTECTED]>; "IDN" <[EMAIL PROTECTED]> 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 > 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" <[EMAIL PROTECTED]> > To: "IDN" <[EMAIL PROTECTED]> > 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 > > > > > > > > > >
