Re: IDN eamples for testing

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