Hello all (and particularly Michael and Dennis),
As promised, welcome your input for the proposed slide deck ahead of the call, if possible. I understand time is rather limited, but if there is any blatant inaccuracy, especially on slide 8, I would appreciate your comment!
https://docs.google.com/presentation/d/1WhHBPGuxEsHU2hPN3HuQaa14rJCNMywwSG4WdMC4yYI/edit#slide=id.g24155cc58c9_0_16
Thank you,
Ariel
On 5/9/23, 2:55 PM, "Ariel Liang" <ariel.liang@icann.org> wrote:
Thanks for the information you shared, Michael. I think I understand more now, and will definitely appreciate that you share the harmonization practice you are familiar with, so the group can gain better understanding when deliberating on the questions.
I will work on a slide that lists the gist, and will welcome your input!
Best Regards,
Ariel
On 5/8/23, 6:02 AM, "Michael Bauland" <Michael.Bauland@knipp.de> wrote:
Hi Ariel,
On 05.05.2023 19:58, Ariel Liang wrote:
> Hello Michael,
>
> Thanks for the explanation. So basically the "canonical form" is not exactly "primary", but an arbitrary designation by the registries based on the code point of the variant label? You mentioned that the canonical code point may not be allowed in
a IDN table, what does it mean?
This just means that the canonical code point may be a code point that
is not among the list of code points for that IDN table.
Take for example a Cyrillic IDN table that of course does not allow any
Latin characters.
That table then has the allowed code point
U+0430 (CYRILLIC SMALL LETTER A)
The canonical code point would be
U+0061 (LATIN SMALL LETTER A).
So the canonical code point for U+0430 is a code point that is not
allowed according to its IDN table. It's nevertheless used to calculate
the canonical form of a label (which can even become a mixed-script
label, but that's no problem, because it's only an internal
representation used for variant checks).
>
> I think this is the type of information that Donna/Justine hope you and others from registries and registrars could share with the EPDP Team, with regard to how IDN tables are used when someone attempts to register an IDN label at the second-level.
We recall you offered to do a small presentation of how Tango (?) implements IDNs at the second-level. Would this presentation that you offered to do be relevant to our discussion of the IDN table harmonization and format?
As I mentioned last week, I found a problem in our internal
harmonisation process. With our current tables it's just a theoretical
problem, but still it's there. Therefore I'm not sure if it's helpful,
that I present how we are dealing with harmonisation, if it's not
working in all cases.
If you still think it's helpful, I can say a few words of what we're doing.
Cheers,
Michael
--
____________________________________________________________________
| |
| knipp | Knipp Medien und Kommunikation GmbH
------- Technologiepark
Martin-Schmeisser-Weg 9
44227 Dortmund
Germany
Dipl.-Informatiker Fon: +49 231 9703-0
Fax: +49 231 9703-200
Dr. Michael Bauland SIP: Michael.Bauland@knipp.de
Software Development E-mail: Michael.Bauland@knipp.de
Register Court:
Amtsgericht Dortmund, HRB 13728
Chief Executive Officers:
Dietmar Knipp, Elmar Knipp