Dear LD PDP WG, As requested by the WG today (during Meeting #36<https://icann-community.atlassian.net/wiki/x/AYA7PQ>), and to prepare for Meeting #37, please find below the summary of the Public Comment submissions for PR39 below: Preliminary Recommendation 39 Building on an ASCII/Latin diacritic gTLD set as defined in Preliminary Recommendation 1, an ASCII/Latin diacritic domain set is defined to include: 39.1 a label and all its variants within a given TLD, as determined by the second-level LGRs for that given TLD; and 39.2 the same labels and all their variants across all other TLDs within the ASCII/Latin diacritic gTLD set. Public Comment Submissions 1. “Supporting the recommendation as written” Category – in general, these comments are not introduced for discussions during WG meetings; but this one was introduced since ALAC requested the WG’s acknowledgement. * Requestor: ALAC * Request: LD PDP WG to acknowledge the need for an end-user understanding of the second-level. * Problem: Many LD PDP safeguards operate invisibly to end-users, particularly where diacritic domain names are withheld and while often beneficial, the unexplained unavailability may undermine consumer confidence. Clear and accessible explanations are encouraged when domain names are blocked or unavailable due to LD PDP-related rules. * LD PDP WG Action: Awareness only – No action needed at this time. 1. “Support the recommendation with wording change” Category * Requestor: ICANN org * Requests: * Add the term “second-level” before the word “label (to be updated to string)” in the Output language to enhance clarity, rather than relying on footnotes or rationale. * With respect to [Figure 3] in the rationale section<https://gnso.icann.org/sites/default/files/policy/2026/draft/initial-report-...>, add explanatory text to assist readers who may be unfamiliar with the WG’s deliberations regarding the definition of the ASCII/Latin diacritic domain set. * Problem for both requests: Current policy and rationale language need to provide further clarity, especially for those readers who may be unfamiliar with the WG’s intentions and deliberations. * LD PDP WG Action: Consideration and action (revise/add language to provide clarity, if appropriate) required 1. “Significant change required” Category * Requestor: ICANN org * Requests: * WG to consider whether the existing output (together with PR1) aligns with the introduction and management of IDN variant TLDs and the requirements are sufficient to mitigate potential risks effectively. * WG to assess whether the definition and requirement of an ASCII/Latin diacritic domain set needs alignment with the ASCII/Latin diacritic gTLD set, and determine whether additional measures should be developed to mitigate potential registrant and end-user confusion. * Problems: * Both PR1 and PR39 definition may depart from the longstanding principle of introducing and managing the IDN variant TLDs. * Definition and treatment of the ASCII/Latin diacritic labels at the second-level may differ from the top-level – including grouping of the labels as a set which does not exist at the second-level and top-level strings that may not be part of a Variant TLD set – and these differing approaches for the sets at the top and second-levels may cause confusion. Moreover, Case 1.3<https://gnso.icann.org/sites/default/files/policy/2026/draft/initial-report-...> illustrated in the rationale for PR40 needs to be reconsidered (no rules for non-variant second-level labels within the ASCII/Latin diacritic gTLD sets and to leave such decisions to the discretion of the gTLD registry operators). * LD PDP WG Action: Consideration and action (revise/add language to provide clarity, as appropriate, and/or change policy intent, if necessary) required. As shared during the call, please still review the public comments in their entirety through the Public Comment Review Tool<https://docs.google.com/spreadsheets/d/1lsDs0nV1Lh5Tf1CMZXOyxRRdKR0s9GMB-4BE...>, which is also updated each week with WG discussion notes, key outcomes/consensus, and responses to the comments received. The updated language resulting from each meeting can also be accessed here: https://docs.google.com/document/d/1BTAlq9vGEVVeIGv03DRJbcWrX_7WZdk9mgRTzk-E... [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1BTAlq9vGEVVeI...> Thank you all for your thoughtful contribution. Much appreciated, Saewon From: John Emery via Gnso-latin-diacritics <gnso-latin-diacritics@icann.org> Reply-To: John Emery <john.emery@icann.org> Date: Wednesday, May 20, 2026 at 10:31 AM To: "gnso-latin-diacritics@icann.org" <gnso-latin-diacritics@icann.org> Subject: [Gnso-latin-diacritics] Outcomes, Action Items, and Notes from Meeting #36 Dear LD PDP WG, Please find attached the outcomes, action items, and notes from Meeting #36 [OUTCOMES] * Agreement on IG11 to allow for flexibility in timeline and research requirements for ICANN org * WG Agreed on High-Risk Scenario for conservatism principle * PR 7 no objection to being consistent with EPDP-IDNs [ACTION ITEMS] * LD PDP WG to continuously review the Public Comment Review Tool [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1lsDs0nV1L...> and the proposed draft after each WG Meeting and provide input, if any. * Leadership and Staff to update rationale to clarify PR35 and PR36 * Leadership and Staff to update rationale for PR50 work to clarify rationale to cover questions raised by org. * Leadership and Staff to outline options forward for conservatism on proliferation based on the WG votes * WG to review PR1, PR39, PRs40-41. [NOTES] 1. Welcome and SOI Updates 2. Recap of Meeting #35 a. Key Outcomes and Action Items * Reviewed the slides [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/x/AYA7...> for action items and LT/Staff proposed new language for Amadaeu’s suggestion to not allow the coexistence of ASCII and LD gTLDs independently 3. Review of LD PDP Initial Report Public Comment * Reviewed the slides [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/x/AYA7...> to look at PR35 and PR36 discussion of a 10-year cool off period and EBERO discussed. Query to org on problem with these recommendations * Ariel asked about when the 10 year cool off period begins, if it transitioned to EBERO then it will not be applicable, so she is trying to seek clarification on this * PR35/36 Micahel’s clarification As long as the set remains intact there is no need for any cool off period then EBERO is a special RSP, required to handle these TLDs as a set. No new registrations will be possible in EBERO. It was to require the same entity principle across all TLDs. The 10 year cool-off period only applies if one TLD is removed from the Root Zone. If the TLDs remain with EBERO no one could apply for the TLDs as they still technically exist. * IG11 discussed on slide [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/x/AYA7...> 13. Question about the timeline as it has not happened for EPDP-IDNs yet. From ICANN’s perspective the timeframe component expectation and joint research effort. Which of these need to be prioritized? The timeframe or the joint research? * The WG utilized the same timeframes as EPDP-IDNs so they seemed to suggest a sensible path forward to adjust the first timeline for the LD PDP to match EPDP-IDNs then research could be done in parallel. * Agree the flexibility of the wording both in the timeline to align the research and in the requirement that it does not have to be done together, but may be done together if deemed sensible. So, where practical/possible. * PR50 discussed, there was a request for clarification on the rationale on the intended scope of the requirements and level of detail needed. * Ariel added that the question is whether the WG is asking org to explain every single recommendation in the outreach, more focused on the same-entity principle for the necessary outreach. She wanted to make sure they were aligned on the policy position point as it is vague. Essentially, is it a high-level or detailed dive? * Suggestion to have rationale expanded to explain information requirement is bounded by "...and their potential impact on dispute resolution proceedings" and is not completely open-ended. * High Risk Scenario outlined in the slides [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/x/AYA7...> and proposed language from Amadeau outlined as Recommendation X to not permit independent applications. * The intention of the three suggestions are not mutually exclusive, all three can be implemented, none of them, or any combination. All three suggestions can be voted on to allow for the conservatism principle. Support for Amadeau’s suggestion coalesced to not permit independent applications. * Outcomes for conservatism principle: * 1) Rec X: 3 in favor 2 against * 2) Rec language for high-risk: 2 in favor 2 against * 3) Rec language for additional justification 7.5: 1 in favor 3 against * Went through the Public Comment Review Tool [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1lsDs0nV1L...> looking at PR14 looking at .Brand trademark law characteristic for 14.3. A brand should not be required to own a ™ for all variants of its mark. 1) delete the mischaracterized ™ law in the rationale or 2) The EPDP-IDNs language currently in the recommendation * Discussion about PR14 for trademarks and brands and the Rationale language in question: “Thus, under trademark law, the rights are attached to one, distinct mark limited to an exact match.” * the current language could be updated to become as below to be consistent with EPDP-IDNs: “...its applied-for ASCII gTLD and Latin diacritic gTLD(s) that constitute the set are identical considered the same to registered trademarks owned and used by the registry operator or its affiliate.” * Change would be consistent with EPDP-IDNs seems to solve the problem, but suggestion to reach out to IPC. * Proposed work plan outlined on slide [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/x/AYA7...> 20 and asked WG to review PR1, PR39, PRs40-41 * Preview for second level discussion for next week and would be left to the discretion of the registry All the best, John R. Emery, Ph.D. Policy Development Support Senior Specialist Generic Names Supporting Organization (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) www.icann.org<http://www.icann.org>
Thank you for your question, Amadeu. I am not sure whether you mean you were unable to view the figure within the report or it is difficult to understand, but to answer your question, I think the example you have provided is more closely related to Figure 5 in p.71-72<https://gnso.icann.org/sites/default/files/policy/2026/draft/initial-report-...> that illustrates LD PDP’s consensus on the same entity principle at the second-level. In ‘Case 1.3’ (p.73), which was also in relation to a comment raised by ICANN org, there is a brief explanation of how this agreement came into fruition, together with a rationale indicating that similar cases (e.g., test.example vs. tést.example) already exist in TLDs, and that no binding ruling has been issued. Therefore, whether the two (2) domains should be managed by the same entity appears to rest solely with the gTLD registry operators, according to our WG’s agreement (i.e., if considered different domains and hence registered by different registrants in the TLD set – this would be at the discretion of the registry policy) We will need to revisit the comments raised for both Figure 3 (if only to understand and explain it better) and Case 1.3 (if new information, agreements, and insights are brought to the table) and continue this discussion next week at Meeting #37. Thank you for your review and consideration. Much appreciated, Saewon From: "Amadeu Abril i Abril (CORE)" <amadeu.abril@corenic.org> Date: Thursday, May 21, 2026 at 1:44 PM To: Saewon Lee <saewon.lee@icann.org> Cc: "GNSO-Latin-diacritics@icann.org" <GNSO-Latin-diacritics@icann.org> Subject: [Ext] Re: [Gnso-latin-diacritics] Summary of Public Comment Submissions for PR39 Missatge enviat per Saewon Lee via Gnso-latin-diacritics <gnso-latin-diacritics@icann.org> el dia 21 maig 2026 a les 3:21: Dear LD PDP WG, As requested by the WG today (during Meeting #36 [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/x/AYA7...>), and to prepare for Meeting #37, please find below the summary of the Public Comment submissions for PR39 below: Preliminary Recommendation 39 Building on an ASCII/Latin diacritic gTLD set as defined in Preliminary Recommendation 1, an ASCII/Latin diacritic domain set is defined to include: 39.1 a label and all its variants within a given TLD, as determined by the second-level LGRs for that given TLD; and 39.2 the same labels and all their variants across all other TLDs within the ASCII/Latin diacritic gTLD set. Public Comment Submissions 1. “Supporting the recommendation as written” Category – in general, these comments are not introduced for discussions during WG meetings; but this one was introduced since ALAC requested the WG’s acknowledgement. 1. Requestor: ALAC 2. Request: LD PDP WG to acknowledge the need for an end-user understanding of the second-level. 3. Problem: Many LD PDP safeguards operate invisibly to end-users, particularly where diacritic domain names are withheld and while often beneficial, the unexplained unavailability may undermine consumer confidence. Clear and accessible explanations are encouraged when domain names are blocked or unavailable due to LD PDP-related rules. 4. LD PDP WG Action: Awareness only – No action needed at this time. 1. “Support the recommendation with wording change” Category 5. Requestor: ICANN org 6. Requests: 1. Add the term “second-level” before the word “label (to be updated to string)” in the Output language to enhance clarity, rather than relying on footnotes or rationale. 2. With respect to [Figure 3] in the rationale section [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/policy...>, add explanatory text to assist readers who may be unfamiliar with the WG’s deliberations regarding the definition of the ASCII/Latin diacritic domain set. 7. Problem for both requests: Current policy and rationale language need to provide further clarity, especially for those readers who may be unfamiliar with the WG’s intentions and deliberations. 8. LD PDP WG Action: Consideration and action (revise/add language to provide clarity, if appropriate) required 1. “Significant change required” Category 9. Requestor: ICANN org 10. Requests: 1. WG to consider whether the existing output (together with PR1) aligns with the introduction and management of IDN variant TLDs and the requirements are sufficient to mitigate potential risks effectively. 2. WG to assess whether the definition and requirement of an ASCII/Latin diacritic domain set needs alignment with the ASCII/Latin diacritic gTLD set, and determine whether additional measures should be developed to mitigate potential registrant and end-user confusion. 11. Problems: 1. Both PR1 and PR39 definition may depart from the longstanding principle of introducing and managing the IDN variant TLDs. 2. Definition and treatment of the ASCII/Latin diacritic labels at the second-level may differ from the top-level – including grouping of the labels as a set which does not exist at the second-level and top-level strings that may not be part of a Variant TLD set – and these differing approaches for the sets at the top and second-levels may cause confusion. Moreover, Case 1.3 [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/policy...> illustrated in the rationale for PR40 needs to be reconsidered (no rules for non-variant second-level labels within the ASCII/Latin diacritic gTLD sets and to leave such decisions to the discretion of the gTLD registry operators). 12. LD PDP WG Action: Consideration and action (revise/add language to provide clarity, as appropriate, and/or change policy intent, if necessary) required. As shared during the call, please still review the public comments in their entirety through the Public Comment Review Tool [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1lsDs0nV1L...>, which is also updated each week with WG discussion notes, key outcomes/consensus, and responses to the comments received. The updated language resulting from each meeting can also be accessed here: https://docs.google.com/document/d/1BTAlq9vGEVVeIGv03DRJbcWrX_7WZdk9mgRTzk-E... [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1BTAlq9vGEVVeI...> Thank you all for your thoughtful contribution. Much appreciated, Saewon From: John Emery via Gnso-latin-diacritics <gnso-latin-diacritics@icann.org> Reply-To: John Emery <john.emery@icann.org> Date: Wednesday, May 20, 2026 at 10:31 AM To: "gnso-latin-diacritics@icann.org" <gnso-latin-diacritics@icann.org> Subject: [Gnso-latin-diacritics] Outcomes, Action Items, and Notes from Meeting #36 Dear LD PDP WG, Please find attached the outcomes, action items, and notes from Meeting #36 [OUTCOMES] 1. Agreement on IG11 to allow for flexibility in timeline and research requirements for ICANN org 2. WG Agreed on High-Risk Scenario for conservatism principle 3. PR 7 no objection to being consistent with EPDP-IDNs [ACTION ITEMS] 1. LD PDP WG to continuously review the Public Comment Review Tool [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1lsDs0nV1L...> and the proposed draft after each WG Meeting and provide input, if any. 2. Leadership and Staff to update rationale to clarify PR35 and PR36 3. Leadership and Staff to update rationale for PR50 work to clarify rationale to cover questions raised by org. 4. Leadership and Staff to outline options forward for conservatism on proliferation based on the WG votes 5. WG to review PR1, PR39, PRs40-41. [NOTES] 1. Welcome and SOI Updates 2. Recap of Meeting #35 * Key Outcomes and Action Items 1. Reviewed the slides [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/x/AYA7...> for action items and LT/Staff proposed new language for Amadaeu’s suggestion to not allow the coexistence of ASCII and LD gTLDs independently 1. Review of LD PDP Initial Report Public Comment 1. Reviewed the slides [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/x/AYA7...> to look at PR35 and PR36 discussion of a 10-year cool off period and EBERO discussed. Query to org on problem with these recommendations 2. Ariel asked about when the 10 year cool off period begins, if it transitioned to EBERO then it will not be applicable, so she is trying to seek clarification on this 3. PR35/36 Micahel’s clarification As long as the set remains intact there is no need for any cool off period then EBERO is a special RSP, required to handle these TLDs as a set. No new registrations will be possible in EBERO. It was to require the same entity principle across all TLDs. The 10 year cool-off period only applies if one TLD is removed from the Root Zone. If the TLDs remain with EBERO no one could apply for the TLDs as they still technically exist. 4. IG11 discussed on slide [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/x/AYA7...> 13. Question about the timeline as it has not happened for EPDP-IDNs yet. From ICANN’s perspective the timeframe component expectation and joint research effort. Which of these need to be prioritized? The timeframe or the joint research? 5. The WG utilized the same timeframes as EPDP-IDNs so they seemed to suggest a sensible path forward to adjust the first timeline for the LD PDP to match EPDP-IDNs then research could be done in parallel. 6. Agree the flexibility of the wording both in the timeline to align the research and in the requirement that it does not have to be done together, but may be done together if deemed sensible. So, where practical/possible. 7. PR50 discussed, there was a request for clarification on the rationale on the intended scope of the requirements and level of detail needed. 8. Ariel added that the question is whether the WG is asking org to explain every single recommendation in the outreach, more focused on the same-entity principle for the necessary outreach. She wanted to make sure they were aligned on the policy position point as it is vague. Essentially, is it a high-level or detailed dive? 9. Suggestion to have rationale expanded to explain information requirement is bounded by "...and their potential impact on dispute resolution proceedings" and is not completely open-ended. 10. High Risk Scenario outlined in the slides [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/x/AYA7...> and proposed language from Amadeau outlined as Recommendation X to not permit independent applications. 11. The intention of the three suggestions are not mutually exclusive, all three can be implemented, none of them, or any combination. All three suggestions can be voted on to allow for the conservatism principle. Support for Amadeau’s suggestion coalesced to not permit independent applications. 12. Outcomes for conservatism principle: * 1) Rec X: 3 in favor 2 against * 2) Rec language for high-risk: 2 in favor 2 against * 3) Rec language for additional justification 7.5: 1 in favor 3 against 1. Went through the Public Comment Review Tool [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1lsDs0nV1L...> looking at PR14 looking at .Brand trademark law characteristic for 14.3. A brand should not be required to own a ™ for all variants of its mark. 1) delete the mischaracterized ™ law in the rationale or 2) The EPDP-IDNs language currently in the recommendation 2. Discussion about PR14 for trademarks and brands and the Rationale language in question: “Thus, under trademark law, the rights are attached to one, distinct mark limited to an exact match.” 3. the current language could be updated to become as below to be consistent with EPDP-IDNs: “...its applied-for ASCII gTLD and Latin diacritic gTLD(s) that constitute the set are identical considered the same to registered trademarks owned and used by the registry operator or its affiliate.” 4. Change would be consistent with EPDP-IDNs seems to solve the problem, but suggestion to reach out to IPC. 5. Proposed work plan outlined on slide [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/x/AYA7...> 20 and asked WG to review PR1, PR39, PRs40-41 6. Preview for second level discussion for next week and would be left to the discretion of the registry All the best, John R. Emery, Ph.D. Policy Development Support Senior Specialist Generic Names Supporting Organization (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) www.icann.org<http://www.icann.org> _______________________________________________ Gnso-latin-diacritics mailing list -- gnso-latin-diacritics@icann.org To unsubscribe send an email to gnso-latin-diacritics-leave@icann.orgHi all. OK, this is marginal and personal… but I cannot make any sense of the figures used. I am specially interested in understanding the famous Figure 3. From context, I guess that this a figure explaining that while.example and exàmble (ASCII and ASCII + Diacritic TLD) set are the same at TLD level, example.example and exàmple.example (the same labels, but at the second-level domain) can be consdiered different domains and hence registered by different Registrants in the TLD set. Is this what it represents? Thanks and apologies for the question that might seem silly to anyone able to see the figures ;-) Amadeu
Hi Amadeu, as Saewon wrote, the question about handling of diacritics at the second level is indeed pictured in Figure 5. I'll describe a bit more, what is displayed in Figure 3. It tries to explain in more detail how the same entity principle and variant relationship works in our cases. In IDN EPDP, all domains are variants of each other and the variant set covers all TLDs. So a domain under one TLD will be a variant under all other (variant) TLDs. Therefore the same entity requirement is easy there: just require that all domains in the variant set need to belong to the same entity. This does not work in our case. We have no variant relationships crossing the TLD boundary (because the TLDs are not variants of each other). This means instead of having a single variant sent cover all domains in all TLDs, we will need to work with multiple variant sets. Even though we are not working variants at the top level, we still have variant relationships at the second level (defined by the registry's second level LGRs). The graphic then shows different scenarios, depending on which code points are available in the different TLDs. For simplicity, we only work with one ASCII and one LD TLD (it would work analogously with more than one LD TLD): Scenario 1: Both TLDs have the same LGR, i.e., allowing the same repertoire and having the same variant relationships. This is easy, we just have one variant set per TLD. Scenario 2: ASCII domain has the following variant set: example.atld exampleV1.atld exampleV2.atld exampleV3.atld For the LD TLD, the label exampleV2 is not in the repertoire, and therefore not allowed. But instead exampleV4 exists and is a variant of exmapleV3. Then the same entity set contains example.ldtld (because it's the same label) exampleV1.ldtld (because it's the same label) exampleV3.ldtld (because it's the same label) and also exampleV4.ldtld (it's not the same label as in the ASCII set, but it's a variant of one of the labels in the LD TLD). Scenario 3: This is also similar, but the primary domain name from the ASCII TLD's variant set (example.atld) is not part of the repertoire of the LD TLD. But still all labels that exist in the ASCII TLD's variant set and are available in the LD TLD, must belong to the same entity set, plus all variants of those labels. So, the graphic is describing Rec 39 with some examples, how it works and why it's necessary. I hope this helps a bit with understanding this. I know it's a complicated topic and without being able to see the actual examples in the graphic, it makes it even more difficult. Let me know, if there is something unclear and I'll be happy to explain a bit more. 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 Certified according DIN ISO/IEC 27001:2017
Thanks both of you for the explanations. But I am still concerned that we are making this more difficult than it would need to be. We seem to assume that Registries have the option, worse, the right to f… sorry, to make a whole mess when it is not needed at all, for no good reason. More on that before next call. Amadeu
Missatge enviat per Michael Bauland via Gnso-latin-diacritics <gnso-latin-diacritics@icann.org> el dia 22 maig 2026 a les 9:00:
Hi Amadeu,
as Saewon wrote, the question about handling of diacritics at the second level is indeed pictured in Figure 5.
I'll describe a bit more, what is displayed in Figure 3.
It tries to explain in more detail how the same entity principle and variant relationship works in our cases. In IDN EPDP, all domains are variants of each other and the variant set covers all TLDs. So a domain under one TLD will be a variant under all other (variant) TLDs. Therefore the same entity requirement is easy there: just require that all domains in the variant set need to belong to the same entity.
This does not work in our case. We have no variant relationships crossing the TLD boundary (because the TLDs are not variants of each other). This means instead of having a single variant sent cover all domains in all TLDs, we will need to work with multiple variant sets. Even though we are not working variants at the top level, we still have variant relationships at the second level (defined by the registry's second level LGRs).
The graphic then shows different scenarios, depending on which code points are available in the different TLDs. For simplicity, we only work with one ASCII and one LD TLD (it would work analogously with more than one LD TLD): Scenario 1: Both TLDs have the same LGR, i.e., allowing the same repertoire and having the same variant relationships. This is easy, we just have one variant set per TLD.
Scenario 2: ASCII domain has the following variant set: example.atld exampleV1.atld exampleV2.atld exampleV3.atld
For the LD TLD, the label exampleV2 is not in the repertoire, and therefore not allowed. But instead exampleV4 exists and is a variant of exmapleV3. Then the same entity set contains example.ldtld (because it's the same label) exampleV1.ldtld (because it's the same label) exampleV3.ldtld (because it's the same label) and also exampleV4.ldtld (it's not the same label as in the ASCII set, but it's a variant of one of the labels in the LD TLD).
Scenario 3: This is also similar, but the primary domain name from the ASCII TLD's variant set (example.atld) is not part of the repertoire of the LD TLD. But still all labels that exist in the ASCII TLD's variant set and are available in the LD TLD, must belong to the same entity set, plus all variants of those labels.
So, the graphic is describing Rec 39 with some examples, how it works and why it's necessary.
I hope this helps a bit with understanding this. I know it's a complicated topic and without being able to see the actual examples in the graphic, it makes it even more difficult.
Let me know, if there is something unclear and I'll be happy to explain a bit more.
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
Certified according DIN ISO/IEC 27001:2017 _______________________________________________ Gnso-latin-diacritics mailing list -- gnso-latin-diacritics@icann.org To unsubscribe send an email to gnso-latin-diacritics-leave@icann.org
participants (3)
-
Amadeu Abril i Abril (CORE) -
Michael Bauland -
Saewon Lee