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

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

Ok, just one final clarification:
I am saying that
ALL DNS servers MUST answer consistently all requests for existing domains
IDN enabled DNS servers WILL answer all IDN requests consistently
Please do not twist my message.
Edmon

----- Original Message -----
From: "Rick Wesson" <wessorh@ar.com>
To: "Edmon Chung" <edmon@neteka.com>
Cc: "Ross Wm. Rader" <ross@tucows.com>; "'Registrar's Constituency'"
<registrars@dnso.org>
Sent: Wednesday, May 15, 2002 3:29 PM
Subject: Re: To Resolve or NOT to Resolve, that is the question


>
> Edmon,
>
> I think we should take this off the list if you would like to continue to
> advocate that some DNS servers should answer diferently than other DNS
> Servers based on the same standard.
>
> I'm happy to continue this discussion pirvately.
>
> -rick
>
> On Wed, 15 May 2002, Edmon Chung wrote:
>
> > 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
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>