Mapping and Variants

[Tina Dam]

Clarifications in the below...

> On Monday, March 09, 2009 2:43 PM, John C Klensin wrote:
> 
> 
> > --On Monday, March 09, 2009 14:30 -0700 Tina Dam
> > <tina.dam at icann.org> wrote:
> 
> > Hi everybody, sorry for catching up late on this thread. I was
> > a bit occupied last week at the ICANN Mexico meeting.
> >
> > The IDN Guidelines correctly states that mixing of scripts is
> > not allowed at registration time unless there is a linguistic
> > reason for doing so (such as in the case of Japanese). It
> > should further be noted that while the IDN Guidelines are not
> > a requirement for ccTLD operators today (but only for gTLD
> > operators) - it will, looking forward be a requirement for any
> > new TLDs allocated in either the new gTLD Program or the IDN
> > ccTLD Fast Track Program.
> 
> Of course, they are, at best, suggestions for any zone below the
> second level.

Right, but I think it is important that they are required for second or third level (depending on which TLD we are talking about).

> > In these two processes it is also a requirement for applicants
> > to develop and submit their IDN Tables (this is ICANN
> > terminology for where variants are identified). While TLD
> > operators can choose to block, bundle, reserve or otherwise
> > deal with variant strings at registration time, ICANN have
> > proposed one method forward when it comes to the top-level,
> > that is:
> >
> > - strings will be allocated if they have the same meaning as
> > the applied-for string (for example a country name) and
> > otherwise fulfill all the string requirements.
> > - all other variant-strings will be blocked for allocation.
> 
> "Will be allocated" as in "you intend to put more than one entry
> per application into the root zone"?

Whether this will be in the same application or more than one application required is yet to be determine. The proposal I listed above is also, btw, out for public comments and part of the IDN ccTLD fast Track Process. It was received positively by the participants in the Mexico meeting.

 
>  -- If so, do you intend to enter them as delegation records
> (i.e., same entity gets two or more new TLDs)?   If so, what
> requirements do you expect to impose on the relative uses of the
> two (or more) TLDs?

They will have to be treated as aliased TLDs - in other words as "DNAME'd" if DNAME had functioned in the root.

 
>  -- Or do you intend to put DNAME records into the root?

As far as I have understood this does not work, but please correct me if I am wrong.

>  -- Or perhaps associate the extra, variant, labels with DWIM
> records pointing to the applied-for label?   I don't think the
> DWIM record has been entirely defined yet, but I believe that
> DNSEXT should be able to finish it up on the first day of next
> month, after which it should be just a small matter of
> programming.

I have not followed this but will start reading about it right away. Sounds interesting!
 
> > I am wondering if there is anything in these processes or
> > requirements that could be made stronger from a technical
> > standpoint and help the IDNA process forward?
> 
> I think they are just another example of guidance to registries
> with, in this case, ICANN acting both as the generator of the
> guidance and the registry applying it.
> 
> But I am really curious about what the words actually mean.


I hope that helped...

Tina

>       john
> 
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update