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

[Rick Wesson <wessorh@ar.com>]

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
> > > >
> > > >
> > > >
> > >
> >
> >
>