[Latingp] ODG: ODG: Variants -- Case for Considering Upper Case

Bill Jouris bill.jouris at insidethestack.com
Tue Jul 10 15:57:11 UTC 2018

My take on the variants task was that we were trying to identify cases which would always be rejected.  So that those cases would not need to go thru the more extensive, time consuming, and labor intensive, process.  If something is always going to be rejected, why expend the time and effort to do so manually? 

Granted, the members of the IP could probably have done the variants task for Latin themselves.  But since the process was defined to cover all of the various scripts for IDN, it got left to us.  We just are subject to more micromanaging because the IP members know more about (some of) our languages.  Bill Jouris
Inside Products
bill.jouris at insidethestack.com
925-855-9512 (direct)

      From: Mats Dufberg <mats.dufberg at iis.se>
 To: Michael Bauland <Michael.Bauland at knipp.de>; Bill Jouris <bill.jouris at insidethestack.com>; Mirjana Tasić <Mirjana.Tasic at rnids.rs>; "latingp at icann.org" <latingp at icann.org> 
 Sent: Tuesday, July 10, 2018 4:50 AM
 Subject: Re: [Latingp] ODG: ODG: Variants -- Case for Considering Upper Case
I have to admit that I find the variant task strange.

Let me first comment the repertoire task. In that we were expected define the criteria for inclusion and exclusion of characters and then evaluate language sources. I think that was a quite reasonable task.

When it comes the variant task we are expected to create variant pairs of the most obvious cases (e.g. LATIN SMALL LETTER A vs CYRILLIC SMALL LETTER A) but we are expected to ignore the more complex cases such as LATIN SMALL LETTER M vs CYRILLIC SMALL LETTER EM via LATIN CAPITAL LETTER M). The rational for that is that there will anyway be a process that will look at similarities between characters or candidate TLDs.

If that process will have the resources to evaluate the more complex similarities without any prework by e.g. the relevant Generation Panel, then it will get all the obvious cases for free.

What is our contribution if we are only to list the obvious cases that the IP already know? I feel it is almost meaningless.


Mats Dufberg
DNS Specialist, IIS
Mobile: +46 73 065 3899

-----Original Message-----
From: Latingp <latingp-bounces at icann.org> on behalf of Michael Bauland <Michael.Bauland at knipp.de>
Date: Tuesday, 10 July 2018 at 10:59
To: Bill Jouris <bill.jouris at insidethestack.com>, Mirjana Tasić <Mirjana.Tasic at rnids.rs>, ICANN Latin GP <latingp at icann.org>
Subject: Re: [Latingp] ODG: ODG: Variants -- Case for Considering Upper Case

Hi Bill,

On 09.07.2018 19:11, Bill Jouris wrote:
> For example, suppose we decide that a Cyrillic Small Letter Em (м
> codepoint 043C) is NOT a variant of a Latin Small Letter M (m codepoint
> 006D).  Then it is possible to create a (Cyrillic) TLD of .сом, because
> the last letter is visibly "different" from that in .com. 

as said earlier, I agree that having a TLD сом is definitely a problem
and should not be allowed. But independent from our variant rules, such
a TLD application would always be rejected.

Therefore I agree with Mirjana: let's first concentrate on the task we
have to do and then later we can look at further work that is nice to have.



    |      |
    | knipp |            Knipp  Medien und Kommunikation GmbH
      -------                    Technologiepark
                                Martin-Schmeisser-Weg 9
                                44227 Dortmund

    Dipl.-Informatiker          Fon:    +49 231 9703-0
                                Fax:    +49 231 9703-200
    Dr. Michael Bauland        SIP:    Michael.Bauland at knipp.de
    Software Development        E-mail: Michael.Bauland at knipp.de

                                Register Court:
                                Amtsgericht Dortmund, HRB 13728

                                Chief Executive Officers:
                                Dietmar Knipp, Elmar Knipp
Latingp mailing list
Latingp at icann.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/latingp/attachments/20180710/9cfd9b5e/attachment.html>

More information about the Latingp mailing list