[Comments-reference-lgrs-second-level-24aug20] Regarding similar (not exact) looking variants identification

[ThinkTrans Frontdesk]

As an addendum to my earlier comment at: https://mm.icann.org/pipermail/comments-reference-lgrs-second-level-24aug20/2020q4/000005.html
Some of the representative examples of confusingly similar looking variants from Devanagari script are:

Variant group 1:
द्र (U+0926 U+094D U+0930)
द्ग (U+0926 U+094D U+0917)
द्न (U+0926 U+094D U+0928)

Variant group 2:
त (U+0924)
त्त (U+0924 U+094D U+0924)

Variant group 3:
श्व (U+0936 U+094D U+0935)
श्र्व (U+0936 U+094D U+0930 U+094D U+0935)


I am sure there are many such examples in Devanagari and other scripts.

Regards,
Akshat Joshi
Director
ThinkTrans LLP (thinktrans.in) 
Pune, India

>     On 10/14/2020 1:26 PM ThinkTrans Frontdesk <admin at thinktrans.in> wrote:
> 
> 
>     Thank you ICANN Team to undertake this initiative to help registries who are willing to take up IDN registrations. I have one suggestions towards the same.
> 
>     The RZ-LGR procedure which set in place a formal rule-based structure for the IDN labels at the Root Zone, explicitly did not include identification of “similar looking” variants. The reasoning behind this being, the existing procedure involving of “String Similarity Assessment panel”, a panel whose mandate ( I assume ) is to evaluate every incoming label for the Root Zone vis-à-vis all the existing labels in the root zone and take a judgement call whether incoming label is in any way confusingly similar looking with any of the existing label in the root zone.
> 
>     Now, the second level LGR, is an effort to extend the tenets of the RZ-LGR procedure to the possible second (and higher) level domains and help willing registries by way of making them available something that they can use right away. However, not all the environmental conditions present at the Root Zone are as it is applicable to the second and higher level domains. The case in point for this comment being the absence of any formal and known universal structure at the second level similar to string similarity assessment panel.
> 
>     Owing to the above stated absence, it is strongly recommended that ICANN commissions a separate study to evaluate all the instances of similar looking cases across all the possible scripts which may have the problem of confusingly similar looking cases. They all may need to be made part of a blocking variant set.
> 
>     The Dispute Resolution Policies, though present, they come into force once the dispute happens, and damage is done. This is definitely not a desired outcome from the “end-user’s trust in the system of IDN functions” point of view.
> 
>     Regards,
>     Akshat Joshi
>     Director
>     ThinkTrans LLP
>     Pune, India
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/comments-reference-lgrs-second-level-24aug20/attachments/20201014/3d48e9e3/attachment-0001.html>