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

Re: [idn] IDN eamples for testing



Hi James,

I think I have made it quite clear.
Neteka provides tools, products and services for all facets of TLD registry
systems.

----- Original Message -----
From: "James Seng" <jseng@pobox.org.sg>
>     Did Neteka advertise a server-side resolution DNS?

Of course DNS resolution includes a server-side element.
If you are asking about IDN, we resolve Punycode.
If you are asking about Punycode conversion, yes our servers do that for
administration and DNS Zone preparations.

If this is not clear enough for you, I am happy to discuss with you
off-list.

Edmon

PS.  I have recently been working on a number of documents on IDN
Operations, that discusses mainly issues around character equivalence
preparation and management.  More specifically taking the discussional
IDN-ADMIN document to create a more generic technical framework that is
capable of allowing different registries to develop their policies freely,
yet driving towards a standard EPP implementation that could take care of
the different needs of registries.  Since this is not the right forum for
this particular discussion, I have not included the documents.  But I will
be more than happy to share it with anyone who might be interested and
comments will be very valuable to help improve the documents.








> It is not my business to tell you if you should or should not. I just want
> to clarify if you have advertise such a product or not.
>
> ps: It is simple question. I would appreciate a simple yes & no answer. I
am
> not interested in any of your other product as your long email below
> described.
>
> -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 10:14 PM
> Subject: 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
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >
>
>
>