Re: [idn] IDN eamples for testing

["James Seng" <jseng@pobox.org.sg>]

And no, I dont think we need to bring this offlist.

It would be better if this is discussed in public, so we can put the end of
this.

So, please answer a simple yes or no to my answer. And believe me, I have
long memory.

-James Seng

----- 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 11:05 PM
Subject: Re: [idn] IDN eamples for testing


> Please dont obscure it by marketing talk.
>
> Is that a yes or no? I dont want to misinterpret your email.
>
> -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:58 PM
> Subject: 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
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
>
>
>