OK - I've readt the ietf draft. In order to resolve changes must be made
at the application layer or resolver to translate (nameprep) what is
entered in the browser to something the dns interface can understand -
i.e. bq--.
It looks like making changes to the application layer will end up being a
nightmare - so James I think you hit it on the ball here, the changes will
most likely be to the resolver. This means that to do RACE we will have
to upgrade our BIND or patch it.
Frankly I liked the i-dns approach better. It was not great - but it
worked, except in some cases one had to use an addon to change the
application layer in the browser (only with some languages i tested).
Well I think this is a grand experiment and very politically bold. I
bless these waters you walk on James Wood - may they be peaceful so you
don't poison yourself with a java overdose. I think you boys (and the moo
moo girls too) have a big job here.
regards
joe
On Wed, 8 Nov 2000, James Woods wrote:
> Points to Chuck!! He's been listening to my ML rants around the office<g>
> However Joe brings up some great topics that I can shed some light on. And
> maybe shake things up a bit...in a good way.
>
> The registry does have to support ML names in order for them to work
> properly. RACE conversion is one step but there are other considerations
> that have to be taken into account which are not as wide known, namely
> something referred to as "Name Preparation"
>
> Name preparation involves the following steps:
>
> 1. Checking for forbidden characters
> 2. Case Folding
> 3. Canonicalization (Normalization)
> 4. Check characters to ensure that they are valid for a Race conversion
>
> Canonicalization involves transforming the original source into a normalized
> format. Transformations are usually performed before comparisons or sorting
> multilingual strings
>
> It is important to note that VGRS also performs name preparation on domain
> and name server names that they receive in RACE format. VGRS performs name
> prep to ensure that the incoming source matches all name prep criteria.
>
> Therefore, if a de-normalized name is sent to VGRS, the name will be
> rejected.
>
> The name prep document can be found at
> http://www.ietf.org/internet-drafts/draft-ietf-idn-nameprep-02.txt.
>
> The algorithm for canonicalization is described in
> http://www.unicode.org/unicode/reports/tr15/.
>
> As for resolution, so far this has been pure speculation. VGRS has not
> released any documentation whatsoever. I hope to get more clarity on this at
> next weeks ICANN meeting where there will be I expect/hope an equal amount
> of focus on ML names as there will be to new gTLD's.
>
> >From where I sit I see BIND needing a few minor tweaks to make this thing
> work well. Its public knowledge that VGRS has thrown some $$ to Nominum...to
> do what I wonder? Here's a quote from their site (VGRS) regarding this
> phase:
>
> "Phase 3 implements resolution, the process by which a domain name is
> translated into an IP address, allowing Internet users to access a Web site
> using the domain name. Resolution for the Multilingual Domain Names Testbed
> will be conducted in phases, which will allow for appropriate testing of
> software modifications and ensure the continued stability of the 24 million
> names currently in the .com, .net, and .org domains. A detailed plan
> regarding the phases of resolution will be released in the near future."
>
> It's the "software modification" part that leads me to believe that a
> ML-BIND hack is coming. Funny though BIND 9 was just released in early
> October and there is no mention of ML from what I've read
>
> That's tonight's reading assignment, tomorrow I'll talk about UTF-8 RRP 1.2
> vs. 1.1 and how it will make ML names easier to encode to a RACE string. But
> right now I have a final ML-client to document....release...etc.
>
> Ah caffeine...the nectar of weary product managers!
>
> Cheers all,
>
> James
>
> -----Original Message-----
> From: Joe Baptista [mailto:baptista@pccf.net]
> Sent: Wednesday, November 08, 2000 6:27 PM
> To: Charles Daminato
> Cc: Merlin; opensrs-dev; jwoods@tucows.com
> Subject: RE: MLDNs & CA names
>
>
>
> James will know - let's ask him.
>
> But from what i have seen, it's irrelevant weither the registry supports
> RACE, that's irrelevant - if a chinese, japanese or korean name (character
> string) is encoded correctly - you simply stick that string in a zone file
> and it will work.
>
> Unless someone is doing some fancy dns work I have yet to read in the
> techs - it's quite irrelvant what registry you do this with - as long as
> you follow the convention "bq--" plus whatever is a correctly encoded
> RACE, the browser should work. I can't however comment on the browser
> side - what sort of browser is required (if any). But the correct
> encoding is the key - the registry's position on it is not even a
> consideration - as long as you register the correctly encoded string.
>
> James - correct or incorrect. What are we missing here?
>
> joe
>
> On Wed, 8 Nov 2000, Charles Daminato wrote:
>
> > My understanding is MLDNs must be supported by the registry. gTLD
> registry
> > is supporting it (as seen by our working), .ca registry does not.
> >
> > --
> >
> > Charles Daminato
> > Tucows Product Manager (ccTLDs)
> > chuck@tucows.com
> >
> > Matters could get so confusing at work that it is actually laughable.
> > - From National Post Horoscope for Gemini, Nov. 1st 2000
> >
> >
> > -----Original Message-----
> > From: owner-dev-list@opensrs.org [mailto:owner-dev-list@opensrs.org]On
> > Behalf Of Merlin
> > Sent: November 8, 2000 6:11 PM
> > To: opensrs-dev
> > Subject: MLDNs & CA names
> >
> >
> > I note that the Multilingual names interface includes the line
> >
> > Traditional Chinese name. example [yourdomain.com] or
> > [yourdomain.on.ca]
> >
> > as do the other Asian entry points.
> >
> > Now, does this mean that not only com/net/org can use the Aisan encoding?
> > but also .ca's as well?
> >
> > If not, then perhaps this should be changed.
> >
> > bob
> >
>
> --
> Joe Baptista
>
> http://www.dot.god/
> dot.GOD Hostmaster
> +1 (805) 753-8697
>
-- Joe Baptistahttp://www.dot.god/ dot.GOD Hostmaster +1 (805) 753-8697
This archive was generated by hypermail 2.1.3 : Tue Oct 19 2004 - 23:36:03 EDT