Re: [registrars] REALNAMES - stopping service 30th June.

[Rick Wesson <wessorh@ar.com>]

Edmon,

I don't appreciate any "advertising" by any RC member on this list.

that said, I also can't advocate, nor does any IETF standard, a DNS
resolution path that is not predictable.

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.

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.

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