-----BEGIN PGP SIGNED MESSAGE-----
According to NSI registry for now the MLDN names in the converted RACE
form are not supposed to resolve since they are not inserted into the root zone.
They are placed on REGISTRY-HOLD.
So any domain that does resolve right now is not an MLDN domain and will
not work in native form.
You can find more info on NSI registry's web site.
Cheers
Paul
- -----------------------------------
Dont worry Marge.
Trying is the first step to failure
-- Homer J. Simpson
On Sat, 2 Dec 2000, Merlin wrote:
> Chuck,
> In this case.
> That domain name - bq--3ci46w2qaawwlyd6x52tk.com - is actually registered correctly - Through the OpenSRS MLDN interface under
> Simplified Chinese.
> The Chinese Characters were input into the [Domain Name.com] field in the MLDN interface, and the Submit button pressed.
> The OpenSRS interface comes back and the correct Characters are displayed on the screen when in the correct code page etc etc.
> The email to the user instructs that the MLDN has been correctly registered, with the appropirate encoding stored with it.
>
> Because you can't actually get any of the DNS engines to resolve Chinese Characters, then if a person actually wants to get to that
> domain, they have to use the RACE encoded ascii string (bq--....), as well as having that as the web address in Apace etc, and the
> Nameservers configs. Quite understandable. Lot of work to do there yet!
>
> However, your statement here is the key to the whole confusion..............
>
> > However - these will not (supposedly) work properly with decoded MLDNs
> > if/when the VeriSign root actually starts resolving.
> >
>
> This refers to bq-- names that are entered from the standard interface as simple ascii names, and NOTas part of a language
> translation interface.
>
> When Verisign starts working/resolving, I believe it will look at that record, and also look for the encoding type. If it doesn't
> find any encoding type, it can't proceed.
>
> So if you are going to register MLDNs then you have to actually input them into the Registration Interface in the language of
> choice, so that the correct coding type can be recorded with the name - for later decoding of the string into it's correct language
> type.
>
> Therefore, if people just RACE a whole list of names and submit the bq-- strings, they are just throwing away their money. Unless of
> course they actually WANT a domain called bq--asw34dc.com
>
> and to follow up this bit...
>
> > > This is the clarification I am seeking. Is it that the names "will not
> > > resolve at all" or that they will not resolve as anything but ASCII
> > > characters? There is a huge difference.
>
> At the moment -
> if you register a MLDN and register it correctly, it will resolve, but ONLY on the ascii string. Later, when the work is done by
> Verisign etc, then it will resolve from it's native language input (if you have a native language browser that will take the
> characters...BIG issue there yet)
>
> if you register a RACE ascii string only, without going through the correct language interface, you will end up with a plain
> vanilla ascii name. bq-youve-wasted-your-money.com. Which will always resolve - because its a straight out domain anme. BUT - it
> will _never_ resolve under a MLDN interface.
>
> Think I have that right.? I understand it all a little better myself now... ;-)
>
> cheers
> Bob
>
>
>
>
> ----- Original Message -----
> From: "Charles Daminato" <chuck@tucows.com>
> To: "John Keegan" <john@rackshare.com>
> Cc: <dev-list@opensrs.org>
> Sent: Saturday, December 02, 2000 12:28 PM
> Subject: Re: mlds and nameserver modification
>
>
> > Many persons have registered names in the "regular" name space already
> > RACE encoded - so their regular ASCII versions (like you see below) are
> > there...
> >
> > However - these will not (supposedly) work properly with decoded MLDNs
> > if/when the VeriSign root actually starts resolving.
> >
> >
> > Charles Daminato TUCOWS Product Manager (ccTLDs) chuck@tucows.com
> >
> > On Fri, 1 Dec 2000, John Keegan wrote:
> >
> > > > It resolves because the dns sees it as it is. Just the same as
> > > > http://www.bq--3ci46w2qaawwlyd6x52tk.com /net/org
> > >
> > > That part is evident. It just does not jive with Ken Joy's statement that:
> > >
> > > > Multilingual domains will not resolve in DNS at all
> > >
> > > This is the clarification I am seeking. Is it that the names "will not
> > > resolve at all" or that they will not resolve as anything but ASCII
> > > characters? There is a huge difference.
> > >
> > > --
> > > John Keegan
> > > john@RackShare.com
> > > http://RackShare.com
> > >
> > >
> > > > From: "Merlin" <robert@chalmers.com.au>
> > > > Organization: Quantum Radio
> > > > Reply-To: "Merlin" <robert@chalmers.com.au>
> > > > Date: Sat, 2 Dec 2000 10:54:06 +1000
> > > > To: "John Keegan" <john@rackshare.com>, "Ken Joy" <kjoy@tucows.com>,
> > > > <dev-list@opensrs.org>
> > > > Subject: Re: mlds and nameserver modification
> > > >
> > > >
> > > > But there is no way BIND will understand the Chinese character version of
> > > > that.. The native language if you like. (Chinese in this
> > > > case).
> > > > It needs that rACE decoding between it and the BIND interface.
> > > >
> > > > .
> > > > bob
> > > > ---
> > > > Robert Chalmers
> > > > http://www.quantum-radio.net.au Quantum Radio
> > > > robert@quantum-radio.net.au
> > > > http://www.inexpensivewebsites.com Inexpensive Web Sites
> > > > info@inexpensivewebsites.com
> > > >
> > > >
> > > >
> > > >>> Multilingual domains will not resolve in DNS at all...so nameserver changes
> > > >>> are largely irrelevant. We will probably allow people to change them
> > > >>> eventually, but since they don't resolve, it's not a priority. (To give you
> > > >>> some perspective, .ca changes ARE a priority, and we don't have that done
> > > >>> yet)
> > > >>
> > > >> Do you mean resolve to their native language encoding?
> > > >>
> > > >> Because I happened to come across a domain that does resolve:
> > > >>
> > > >> http://bq--3bmspgai.com/
> > > >>
> > > >> Does this name resolve because it was not registered properly (i.e. without
> > > >> the character set bit) or is there some other explanation?
> > > >>
> > > >> --
> > > >> John Keegan
> > > >> john@RackShare.com
> > > >> http://RackShare.com
> > > >>
> > > >>
> > > >>
> > > >
> > >
> > >
> >
> >
>
>
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
Comment: Public key ID: 0xD467B527
iQEVAwUBOih6bVj6i6zUZ7UnAQHgVwgAgp1xIP6lLgonic7aHX1VSp2ynO2Y2hVf
sHofUhfu2ADjC3vjDsEYsE8dE8mv+Youj2J8YaQ+iV9xvpIPur+H6IaZjDxqydPq
zr9OVLOXqnJYvC3FhxZTYDwwUp4xGRQx/3xGm01HNCpZPap1SAzEY5bseJYIHnWd
xIxwdLOMvsQcXz4ylRQnwFyWgfTF0kHCQWUYawHdK4MO/M8hb79JODl/zMX0Wor7
gz8uWeOuITCvadOxUHOY/syClHBoj5dz+Tc5oBWlO/9VGj+mDMhBI7SBqhOhiWJf
Rjj777xR5ucpoPNSr6c3DPG1q//XWoeY/mvzEJFeJzF480wiF7pBlA==
=OKYZ
-----END PGP SIGNATURE-----
This archive was generated by hypermail 2.1.3 : Tue Oct 19 2004 - 23:36:08 EDT