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

Re: [idn] IDN eamples for testing



Hi James,

Allow me to clarify again, in terms of IDN, Neteka focuses on helping
registries to understand the registration issues, including character
equivalence preparations, the implications to provisioning protocols that
they are using, finally the zone preparation and publishing policies
including equivalency preparation issues.

All of which are IDNA driven. However, in many cases, databases and
provisioning will likely not be using Punycode, because it likely makes more
sense to store UTF8 or Local Encoding in local databases for all intents and
purposes.  This includes administration of IDNs as well.  So, the servers
does take care of the conversion between UTF8/16/LocalEncoding to Punycode
at the zonefile for the DNS.  So I am not sure which part you are alluding
to.

Anyway, I wish not to continue to advertise our services in this forum
because it is not right.  However I must clarify that we are very supportive
of the standard and we are urging TLDs and other relevant parties to make
appropriate preparations for the challenges of IDNs beyond simply the
"client", because there are a lot of administrative and operational issues
as well as transition and migration issues that warrant attention.

Edmon



----- Original Message -----
From: "James Seng" <jseng@pobox.org.sg>
To: "Edmon Chung" <edmon@neteka.com>; "IDN" <idn@ops.ietf.org>
Sent: Sunday, March 23, 2003 8:46 AM
Subject: Re: [idn] 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" <edmon@neteka.com>
> To: "James Seng" <jseng@pobox.org.sg>; "IDN" <idn@ops.ietf.org>
> 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" <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
> > >
> > >
> > >
> >
> >
> >
> >
>
>