[registrars] To Resolve or NOT to Resolve, that is the question

["Edmon Chung" <edmon@neteka.com>]

Hi Rick,

----- Original Message -----
From: "Rick Wesson" <wessorh@ar.com>
> that said, I also can't advocate, nor does any IETF standard, a DNS
> resolution path that is not predictable.

Agreed.  But I am not asking for you to advocate it, I am just pointing out
the fact that a registry has these two choices.
1. ignore multilingual domain requests sent via existing applications
2. resolve multilingual domain requests sent via existing applications AS
WELL AS upgraded applications

> If a resolver passes a natively encoded request and the IETF STANDARD does
> not provide for 'interpeting' said request insted of returning NXDOMAIN I
> would say your software does not implement the IETF standards and as such
> no REGISTRY should be using it.

So you believe that multilingual requests that successfully got to the
registry DNS should be ignored.  That is fine, it is your opinion, but I am
sure some registry operators would rather just resolve the domain name than
deal with numerous support calls asking why their domain does not work.
Also, I believe you are misguided.  ALL regular requests will be responded
as specified by the standards, so we are 100% COMPLIANT with the IETF
standards.  How can you say otherwise?

> We have standards so we all understand what to expect, as a registrar I
> could not allow ICANN to condone any REGISTRY to use non-standard DNS
> software on REGISTRY DNS servers.

Absolutely agreed. That is why we offer STANDARDS BASED software that are
FULLY COMPLIANT with IETF standards and are capable of smoothly
transitioning your existing software to the FUTURE of MULTILINGUAL domain
names.

Edmon



> regards,
>
> -rick
>
>
> On Wed, 15 May 2002, Edmon Chung wrote:
>
> > Hi Ross,
> >
> > Based on your comments, it seems that you didnt really understand what I
was
> > trying to say about Neteka's offerings.  I apologize for doing a bit of
> > advertising here, but I feel it necessary to clarify my point.
> >
> > What I meant by:
> > > > 2. accept requests sent by existing software and prepare for the
> > standard
> > > at
> > > > the same time
> >
> > Is that it is evident that a lot of the existing software will send out
a
> > multilingual request to the wire and the request will successfully be
passed
> > through the ISP resolvers and root servers and end up at the registry
DNS.
> > It is then up to the registry DNS whether to try to resolve the name,
which
> > could be in a certain local encoding, or unicode or might even have been
> > tampered with by one of the nodes it went through while getting to the
> > registry DNS.  Neteka's software (NeDNS) can successfully decode these
> > requests and match it uniquely with the intended multilingual domain
name.
> >
> > This is what Neteka offers.
> >
> > At the same time, if the standard specifies a particular ACE format to
be
> > used for multilingual domain names, then future software will convert
> > multilingual names into ACE format before sending to the wire, in that
case
> > when the Registry DNS receives the request, it will be in xx--ACE
format.
> > Neteka's software can also successfully resolve these request to the
same
> > intended multilingual domain name.
> >
> > This is what we mean by allowing a smooth transition.
> >
> > The fact that existing software will continue to be used and will
continue
> > to generate non-conforming requests for multilingual domain names mean
that
> > the Registry can choose to either ignore them or resolve them.  Neteka
> > believes that the registry should resolve them to allow a transparent
> > experiece for the user.
> >
> > Thoughts?
> >
> > Edmon
> >
> >
> >
> > ----- Original Message -----
> > From: "Ross Wm. Rader" <ross@tucows.com>
> > > What I do have strong concern about is the
> > > general capability to deliver on the transition plan over the long
term.
> > > Microsoft pulling the plug on Realnames shines a very bright light on
the
> > > capability of alternate naming systems (including IDN at this point)
to
> > > actually deliver on the promises that are necessarily made to
consumers to
> > > drive adoption. I am sure that Realnames had a very good transition
> > strategy
> > > to deal with CNRP, as I am sure that VRSN has/had a very good strategy
to
> > > migrate IDNs. And, were it not for the fact that we are discussing the
> > > fabric of the Internet, this would be nothing more than an
intellectual
> > > exchange.
> > >
> > > Perhaps I'm naive, but when I hear people like Klensin advocating a
> > cautious
> > > approach, advocating that the transition to a global IDN standard
will,
> > and
> > > should, take ten years, I listen. And, like others in this forum I'm
sure,
> > > had this been the story presented to us when IDNs were first
introduced by
> > > VGRS, our rush to offer them may have been somewhat different.
> > >
> > > >
> > > > 1. only implement the standard and reject unconforming requests sent
by
> > > > existing software
> > > > 2. accept requests sent by existing software and prepare for the
> > standard
> > > at
> > > > the same time
> > > >
> > >
> > > A large part of the problem is that, at least from a registry
perspective,
> > > these options seem to change on a weekly basis. Further, these
continually
> > > seem to be tied to the cooperation of various vendors of proprietary
> > > technology or worse, platform specific plug-ins. The DNS is not
something
> > > that can be changed from the client in, or the server out.
Paradoxically,
> > as
> > >  Postel pointed out, it needs to happen "all at the same time" - and
until
> > > this is recognized, I can't see the buy-side portion of the industry
> > looking
> > > upon the proposed solutions with the same sort of grace that we did
the
> > last
> > > time around.
> > >
> > > Thanks again,
> > >
> > > -rwr
> > >
> > >
> > >
> >
>
>