Re: [idn] IDN eamples for testing

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

You only have "transition" issue *IF* you move from one operational mode to
another. But a testbed, by implication, means it is NOT operational.

Secondly, we have not closed our previous discussion:

Let me quote you again: "No, we never advertise about any "special DNS
server to resolve IDN without requiring any patch to the client", In fact,
IDNA does NOT require any "special DNS" and IDNA-aware clients do NOT need
any "patch".

So could you explain the existence of NeDNS, which claims "server side
technology that enables the resolution and management of multilingual domain
names that could be transparently deployed
without requiring any client side reconfiguration or plug-in"

-James Seng

----- Original Message -----
From: "Edmon Chung" <edmon@neteka.com>
To: "Doug Ewell" <dewell@adelphia.net>; <idn@ops.ietf.org>
Sent: Tuesday, March 25, 2003 1:36 AM
Subject: Re: [idn] IDN eamples for testing


> ok.  So the right way to do it is a clean break with no transition is what
> we are saying.
> That is good.
> Edmon
>
>
> ----- Original Message -----
> From: "Doug Ewell" <dewell@adelphia.net>
> To: <idn@ops.ietf.org>
> Cc: "Edmon Chung" <edmon@neteka.com>
> Sent: Monday, March 24, 2003 11:41 AM
> Subject: Re: [idn] IDN eamples for testing
>
>
> > Edmon Chung <edmon at neteka dot com> wrote:
> >
> > > This is actually an interesting question. Since we know that there are
> > > actually quite a bunch of clients out there that uses bq--RACE, do we
> > > think that those testbeds (such as in the case of JPRS) should keep
> > > bq--RACE in the zone (together with xn--punycode) for a while for
> > > transitional purposes? Or must this be considered non-conformant to
> > > the standards?
> >
> > I would think the answers would be unequivocally No, the RACE mechanism
> > should not be retained, and Yes, it would be non-conformant.
> >
> > Testbeds are testbeds, intended as temporary feasibility studies to
> > determine if a new standard or technology will fly in the real world.
> > Once the "real" standard has been approved, the testbed becomes obsolete
> > (to the extent it differs from the approved version) and any code or
> > data created in support of the testbed needs to be updated or removed.
> >
> > Creating de-facto standards by promoting the use of testbeds beyond
> > their intended use subverts the standardization process.
> >
> > -Doug Ewell
> >  Fullerton, California
> >  http://users.adelphia.net/~dewell/
> >
> >
>
>
>