Re: [idn] IDN eamples for testing

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

Please, it is a simple question:

Did you ever tell your potential customers that all they need is to deploy
your DNS servers to support IDN?

You dont need to give me a whole marketing brochure to answer this question.
It is only a yes and no. Neither is it as complicated as you said. Everyone
knows IDN is complex, and need requires different level of perspective. But
my questions isnt so...it is a simple yes and no answer.

So please try again.

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


> You will not misinterpret me if you include my words in entirety and not
try
> to take anything out of context.
> IDN challenges is not a simple issue James, and definitely it does not
boil
> down to any yes or no question.  Please do not create a fake sense of
> simplicity for the community.  There is a multitude of issues and you know
> as well as I do and many in this list that it is critical for the success
of
> IDNs for more people to understand those challenges.  I personally is
quite
> passionate to see that IDN is successfully deployed and used.
>
> By the way, there is a discussion at ICANN on IDN Registry implementation,
I
> am not sure if this is also the right forum to discuss implementation.
Does
> the people in this group think this is the right place also to discuss
these
> issues?  (it will include character equivalence preparation issues, and
> since this group have rightly dismissed the discussion for the sake of the
> "protocol", I am not sure if we should raise this dead horse from the
ground
> in this list)... what do people think?...
>
> 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 10:05 AM
> 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
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >
>
>
>