- Idngwg - lists.icann.org

Minutes of meeting and AIs from 8 Dec.
by Sarmad Hussain Dec. 12, 2016

Dec. 12, 2016

Dear All, Please find attached summary of the meeting of the WG on 8 Dec. Please let me know if there are any changes or suggestions. The meeting has the following AIs: S. No. Action Items Owner 1 Filter the confusables.txt and intentional.txt to derive a list which does not include code points disallowed in IDNA 2008 for further analysis by the WG SH 2 Update the recommendation on harmonization based on the current discussion MD 3 Update the recommendation on impact of harmonization on existing registrations based on the current discussion KF 4 Review the current discussion on harmonization and continue this discussion further ALL Re-write the recommendation on automatic activation based on the current input for further discussion EC The next meeting is schedule for 15 Dec. 11am UTC. The WG members present in the meeting also suggested a meeting on 22 Dec. 11am UTC. Please let me now if this is not feasible for you. The attached notes of the meeting and the recording of the meeting are available at the IDNGWG wiki page at https://community.icann.org/display/IDN/IDN+Implementation+Guidelines. Regards, Sarmad

1 1

Re: [Idngwg] Minutes of meeting and AIs from 1 Dec.
by Feher, Kal Dec. 8, 2016

Dec. 8, 2016

Please accept my late apologies. A local storm caused power and communications outages only minutes before the call. I'll be sure to review the minutes. Kal Feher From: <idngwg-bounces(a)icann.org<mailto:idngwg-bounces@icann.org>> on behalf of Sarmad Hussain <sarmad.hussain(a)icann.org<mailto:sarmad.hussain@icann.org>> Date: Thursday, 8 December 2016 at 15:57 To: "idngwg(a)icann.org<mailto:idngwg@icann.org>" <idngwg(a)icann.org<mailto:idngwg@icann.org>> Subject: Re: [Idngwg] Minutes of meeting and AIs from 1 Dec. Dear All, Please find attached the updated (cleaned) document, for our call today. I have taken out the summary of comments from ICANN 57, as these were discussed last time. The updated version includes two new recommendations in Section 2.6 and a revision of the recommendation in Section 2.7 for our review and discussion. I have moved the proposed definitions to the relevant appendix (these would need to be discussed as well before finalization). Regards, Sarmad From: idngwg-bounces(a)icann.org<mailto:idngwg-bounces@icann.org> [mailto:idngwg-bounces@icann.org] On Behalf Of Sarmad Hussain Sent: Saturday, December 03, 2016 3:00 AM To: idngwg(a)icann.org<mailto:idngwg@icann.org> Subject: [Idngwg] Minutes of meeting and AIs from 1 Dec. Dear All, Please find attached summary of the meeting of the WG on 1 Dec. Please let me know if there are any changes or suggestions. The meeting had the following AIs: S. No. Action Items Owner 1 Find out if there are existing lists of homoglyphs which can be referenced SH 2 Divide new recommendation on harmonization of LGRs into three recommendations, explaining harmonization, address cross-script homoglyphic variants, and address within-script variants caused by two different LGRs MD 3 Write a new recommendation on how to address existing registrations which are not harmonized, giving flexibility to registries KF 4 Re-write the recommendation on automatic activation based on the current input for further discussion EC The next meeting is schedule for 8 Dec. 11am UTC. The attached notes of the meeting and the recording of the meeting are available at the IDNGWG wiki page at https://community.icann.org/display/IDN/IDN+Implementation+Guidelines. Regards, Sarmad

2 1

Minutes of meeting and AIs from 1 Dec.
by Sarmad Hussain Dec. 8, 2016

Dec. 8, 2016

Dear All, Please find attached summary of the meeting of the WG on 1 Dec. Please let me know if there are any changes or suggestions. The meeting had the following AIs: S. No. Action Items Owner 1 Find out if there are existing lists of homoglyphs which can be referenced SH 2 Divide new recommendation on harmonization of LGRs into three recommendations, explaining harmonization, address cross-script homoglyphic variants, and address within-script variants caused by two different LGRs MD 3 Write a new recommendation on how to address existing registrations which are not harmonized, giving flexibility to registries KF 4 Re-write the recommendation on automatic activation based on the current input for further discussion EC The next meeting is schedule for 8 Dec. 11am UTC. The attached notes of the meeting and the recording of the meeting are available at the IDNGWG wiki page at https://community.icann.org/display/IDN/IDN+Implementation+Guidelines. Regards, Sarmad

1 2

Re: [Idngwg] Minutes of meeting and AIs from 1 Dec.
by Feher, Kal Dec. 7, 2016

Dec. 7, 2016

I've attached my suggested text for a guideline to registry operators that have existing registered domains that do not conform to these guidelines. I've placed the item within the variants section. It seemed the most appropriate location, but we can discuss further on our call tonight. Kal Feher Neustar Inc. / Enterprise Architect Level 8, 10 Queens Road, Melbourne, Australia VIC 3004 Office +61 3 9866 3710 / kal.feher(a)neustar.biz<mailto:kal.feher@neustar.biz> / www.neustar.biz<http://www.neustar.biz/> Follow Neustar: [http://neunet.neustar.biz/sites/default/files/295/New%20Picture.png] Facebook<http://www.facebook.com/neustarinc> [http://neunet.neustar.biz/sites/default/files/295/New%20Picture%20(1)(1).png] LinkedIn<http://www.linkedin.com/company/5349> [http://neunet.neustar.biz/sites/default/files/295/New%20Picture%20(2).png] Twitter<http://www.twitter.com/neustarinc> ________________________________ The information contained in this e-mail message is intended only for the use of the recipient(s) named above and may contain confidential and/or privileged information. If you are not the intended recipient you have received this e-mail message in error and any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately and delete the original message. From: <idngwg-bounces(a)icann.org<mailto:idngwg-bounces@icann.org>> on behalf of Sarmad Hussain <sarmad.hussain(a)icann.org<mailto:sarmad.hussain@icann.org>> Date: Saturday, 3 December 2016 at 08:59 To: "idngwg(a)icann.org<mailto:idngwg@icann.org>" <idngwg(a)icann.org<mailto:idngwg@icann.org>> Subject: [Idngwg] Minutes of meeting and AIs from 1 Dec. Dear All, Please find attached summary of the meeting of the WG on 1 Dec. Please let me know if there are any changes or suggestions. The meeting had the following AIs: S. No. Action Items Owner 1 Find out if there are existing lists of homoglyphs which can be referenced SH 2 Divide new recommendation on harmonization of LGRs into three recommendations, explaining harmonization, address cross-script homoglyphic variants, and address within-script variants caused by two different LGRs MD 3 Write a new recommendation on how to address existing registrations which are not harmonized, giving flexibility to registries KF 4 Re-write the recommendation on automatic activation based on the current input for further discussion EC The next meeting is schedule for 8 Dec. 11am UTC. The attached notes of the meeting and the recording of the meeting are available at the IDNGWG wiki page at https://community.icann.org/display/IDN/IDN+Implementation+Guidelines. Regards, Sarmad

1 0

Re: [Idngwg] Minutes of meeting and AIs from 1 Dec.
by Tan Tanaka, Dennis Dec. 6, 2016

Dec. 6, 2016

Visually similar code points can be homoglyphs using certain type faces, so yes, boundaries are fuzzy. That is why I insist in being clear as to the scope. For the record, I’m not advocating for Latin Digit One and Latin Small Letter L or similar cases to be treated as variants. I was just pointing out a use case that needs to be clearly defined as out of scope. How we do this? I think we will discuss on Thursday. -Dennis From: <idngwg-bounces(a)icann.org> on behalf of Sarmad Hussain <sarmad.hussain(a)icann.org> Date: Monday, December 5, 2016 at 3:37 PM To: "idngwg(a)icann.org" <idngwg(a)icann.org> Subject: [EXTERNAL] Re: [Idngwg] Minutes of meeting and AIs from 1 Dec. Thanks Dennis. Are we talking about three categories here (though sometimes the boundaries are fuzzy)? 1. Homoglyph code points 2. Variant code points (e.g. simplified and traditional Chinese or the recent ڪتاب and کتاب example) (including those which may not be homoglyphs) 3. Visually similar code points (e.g. Latin Digit One (1) and Latin Small Letter L (l)) (excluding variants or homoglyphs) The suggestion was to consider 1. and 2. above in the scope for harmonization. The reason is that if two code points are considered by the community to be same or variants respectively, labels which only differ in such code points should not be registered to different registrants, even if these are generated by different LGRs in the same zone. This is not adding a new requirement, as we have already said in an early recommendation that variant labels should be registered to the same registrant (or blocked). What this suggests is that when an additional LGR is added for the same script, any additional possible variants should be discovered and harmonized to meet this constraint. I did not comment on 3. above, which is a separate case for discussion. Once the WG specifies the scope, we can try to identify the relevant authoritative sources as well. Regards, Sarmad From: Tan Tanaka, Dennis [mailto:dtantanaka@verisign.com] Sent: Monday, December 05, 2016 11:29 PM To: Sarmad Hussain <sarmad.hussain(a)icann.org>; Mats Dufberg <mats.dufberg(a)iis.se>; idngwg(a)icann.org Subject: [EXTERNAL] Re: [Idngwg] Minutes of meeting and AIs from 1 Dec. I cannot help thinking about Latin Digit One (1) and Latin Small Letter L (l) which are considered in the confusables list. Would this recommendation make these two code points “variants” of each other? I don’t think we would want this. I understand the problem statement but I think we need to elaborate a bit more on the scope and the sources of authoritative data we can use as reference. -Dennis From: <idngwg-bounces(a)icann.org<mailto:idngwg-bounces@icann.org>> on behalf of Sarmad Hussain <sarmad.hussain(a)icann.org<mailto:sarmad.hussain@icann.org>> Date: Monday, December 5, 2016 at 1:19 PM To: Mats Dufberg <mats.dufberg(a)iis.se<mailto:mats.dufberg@iis.se>>, "idngwg(a)icann.org<mailto:idngwg@icann.org>" <idngwg(a)icann.org<mailto:idngwg@icann.org>> Subject: [EXTERNAL] Re: [Idngwg] Minutes of meeting and AIs from 1 Dec. Thanks Mats. Kindly note a couple of comments: > An analysis of homoglyphs (*) MUST be executed on the IDN table or tables (LGR or text table) for a specific TLD (or DNS zone). The analysis MUST be done both within each IDN table and between all IDN tables for the TLD (or zone). Homoglyphs can be within a single Unicode script or between different Unicode scripts. The analysis done for the root zone can be a source to discover possible homoglyphs, but it should be noted that character set has been limited to letters and characters equivalent to letters. E.g. digits and punctuations are not permitted in the root zone and therefore excluded from that analysis. Well-known homoglyphs in different Unicode scripts are found in Armenian, Cyrillic, Greek, and Latin scripts. There may be two different cases here, we should consider. (i) cross-script homoglyphs, and (ii) within-script variants (beyond within-script homoglyphs). The example of کتاب presented earlier does indeed only point out to within-script homoglyphs (for Persian and Arabic languages) for Arabic script. However, extending the example further, Arabic script community also considers ڪتاب a variant because Arabic language speakers consider 0643 and 06AA as calligraphic variations, however Sindhi[omniglot.com]<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.omniglot.com_writin…> speakers consider these as two different characters. Such cases should be handled in harmonization as well because if it is possible to register them separately (due to Sindhi), Arabic language users could face (almost) homoglyphic-level confusion which harmonization is seeking to prevent. > If homoglyphs are found, harmonization MUST be performed. The goal of the harmonization is to acheive system where it is not possible to register two domain names, under the same TLD (domain), that are homographs of each other. This is to reach a workable and secure system. Please note that in the case of (ii) above, it may be able to register the two domain labels and even make them active. The condition is that it should not be possible to have two different registrants register such labels. This is already captured by an earlier recommendation we have written which prevents registrations of variants to different registrants, though we can reiterate it if needed. Regards, Sarmad From: Mats Dufberg [mailto:mats.dufberg@iis.se] Sent: Monday, December 05, 2016 10:19 PM To: Sarmad Hussain <sarmad.hussain(a)icann.org<mailto:sarmad.hussain@icann.org>>; idngwg(a)icann.org<mailto:idngwg@icann.org> Subject: [EXTERNAL] Re: [Idngwg] Minutes of meeting and AIs from 1 Dec. Dear all, I will look through Sarmad's report below, and it might affect my text, but since we have meeting soon I send it to you directly, and I might update it later. <AI2> An analysis of homoglyphs (*) MUST be executed on the IDN table or tables (LGR or text table) for a specific TLD (or DNS zone). The analysis MUST be done both within each IDN table and between all IDN tables for the TLD (or zone). Homoglyphs can be within a single Unicode script or between different Unicode scripts. The analysis done for the root zone can be a source to discover possible homoglyphs, but it should be noted that character set has been limited to letters and characters equivalent to letters. E.g. digits and punctuations are not permitted in the root zone and therefore excluded from that analysis. Well-known homoglyphs in different Unicode scripts are found in Armenian, Cyrillic, Greek, and Latin scripts. If homoglyphs are found, harmonization MUST be performed. The goal of the harmonization is to acheive system where it is not possible to register two domain names, under the same TLD (domain), that are homographs of each other. This is to reach a workable and secure system. There are different ways to handle the possible homoglyphs, and decision of which way to go is up to the register of the actual TLD (domain). One possibility is to exclude code points so that there are no homographs. If the state homoglyphs is only reached when the code point is in a certain position of the label or together with some other code point, then contextual rules can be used to prohibit such positions. The third technique is to use blocking variant rules. If the homoglyphs are from different IDN tables, then the variant rules must operate on all the IDN tables. *) "In orthography and typography, a homoglyph is one of two or more graphemes, characters, or glyphs with shapes that appear identical or very similar." (<https://en.wikipedia.org/wiki/Homoglyph[en.wikipedia.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_…>>) **) Reference at Unicode Consortium </AI2> --- Mats Dufberg DNS Specialist, IIS Mobile: +46 73 065 3899 https://www.iis.se/en/[iis.se]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iis.se_en_&d=DgMGa…> From: <idngwg-bounces(a)icann.org<mailto:idngwg-bounces@icann.org>> on behalf of Sarmad Hussain <sarmad.hussain(a)icann.org<mailto:sarmad.hussain@icann.org>> Date: Sunday 4 December 2016 at 03:19 To: idngwg <idngwg(a)icann.org<mailto:idngwg@icann.org>> Subject: Re: [Idngwg] Minutes of meeting and AIs from 1 Dec. Dear All, Regarding the AI1 below, I have inquired about what has been published at it seems there are some sources, which we need to discuss in case we need to refer to them. Here are the options: 1. Some work has come out of Unicode’s Technical Standard 39[unicode.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__unicode.org_reports_tr3…>. There are two files available here[ftp.unicode.org]<https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.unicode.org_Public_s…>: a. Confusables.txt[ftp.unicode.org]<https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.unicode.org_Public_s…> is the larger set, which has the data we need, but much more data, as the definition of confusables is perhaps broader than the strict homoglyphs we may want. b. Intentional.txt[ftp.unicode.org]<https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.unicode.org_Public_s…> is perhaps the subset which we may be looking for, though the list seems ominously short, and would need a more thorough review (which I am happy to perform after our discussion). 2. RFC 5992 has data in its appendices, which also lists confusable code points, but is not restricted to homoglyphs. 3. The Root Zone LGR proposals[icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resource…> will also provide a reasonably comprehensive list (though we already discussed that these may still be limited for the second level). For example, see the list in Section 6 of the Armenian script proposal[icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_en_syste…> already published for a subset. Latin, Greek and Cyrillic GPs are also working on such lists, so we will have a multi-script community confirmation, once we have the other proposals. However, it is interesting to note that this work remains largely limited to Cyrillic, Green and Latin homoglyphs. Analysis is needed for other scripts. We have recently concluded the analysis for Lao, Khmer and Thai scripts as part of the Root Zone LGR work (and the communities have not found significant homoglyph contexts – e.g. see the Khmer and Lao proposals published (Thai on its way soon)). However, there may be some work needed for Neo-Brahmi scripts. Regards, Sarmad From: idngwg-bounces(a)icann.org<mailto:idngwg-bounces@icann.org> [mailto:idngwg-bounces@icann.org] On Behalf Of Sarmad Hussain Sent: Friday, December 02, 2016 2:00 PM To: idngwg(a)icann.org<mailto:idngwg@icann.org> Subject: [Idngwg] Minutes of meeting and AIs from 1 Dec. Dear All, Please find attached summary of the meeting of the WG on 1 Dec. Please let me know if there are any changes or suggestions. The meeting had the following AIs: S. No. Action Items Owner 1 Find out if there are existing lists of homoglyphs which can be referenced SH 2 Divide new recommendation on harmonization of LGRs into three recommendations, explaining harmonization, address cross-script homoglyphic variants, and address within-script variants caused by two different LGRs MD 3 Write a new recommendation on how to address existing registrations which are not harmonized, giving flexibility to registries KF 4 Re-write the recommendation on automatic activation based on the current input for further discussion EC The next meeting is schedule for 8 Dec. 11am UTC. The attached notes of the meeting and the recording of the meeting are available at the IDNGWG wiki page at https://community.icann.org/display/IDN/IDN+Implementation+Guidelines[commu…<https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_di…>. Regards, Sarmad

1 0

Re: [Idngwg] Minutes of meeting and AIs from 1 Dec.
by Mats Dufberg Dec. 6, 2016

Dec. 6, 2016

Dear all, I will look through Sarmad's report below, and it might affect my text, but since we have meeting soon I send it to you directly, and I might update it later. <AI2> An analysis of homoglyphs (*) MUST be executed on the IDN table or tables (LGR or text table) for a specific TLD (or DNS zone). The analysis MUST be done both within each IDN table and between all IDN tables for the TLD (or zone). Homoglyphs can be within a single Unicode script or between different Unicode scripts. The analysis done for the root zone can be a source to discover possible homoglyphs, but it should be noted that character set has been limited to letters and characters equivalent to letters. E.g. digits and punctuations are not permitted in the root zone and therefore excluded from that analysis. Well-known homoglyphs in different Unicode scripts are found in Armenian, Cyrillic, Greek, and Latin scripts. If homoglyphs are found, harmonization MUST be performed. The goal of the harmonization is to acheive system where it is not possible to register two domain names, under the same TLD (domain), that are homographs of each other. This is to reach a workable and secure system. There are different ways to handle the possible homoglyphs, and decision of which way to go is up to the register of the actual TLD (domain). One possibility is to exclude code points so that there are no homographs. If the state homoglyphs is only reached when the code point is in a certain position of the label or together with some other code point, then contextual rules can be used to prohibit such positions. The third technique is to use blocking variant rules. If the homoglyphs are from different IDN tables, then the variant rules must operate on all the IDN tables. *) "In orthography and typography, a homoglyph is one of two or more graphemes, characters, or glyphs with shapes that appear identical or very similar." (<https://en.wikipedia.org/wiki/Homoglyph>) **) Reference at Unicode Consortium </AI2> --- Mats Dufberg DNS Specialist, IIS Mobile: +46 73 065 3899 https://www.iis.se/en/ From: <idngwg-bounces(a)icann.org> on behalf of Sarmad Hussain <sarmad.hussain(a)icann.org> Date: Sunday 4 December 2016 at 03:19 To: idngwg <idngwg(a)icann.org> Subject: Re: [Idngwg] Minutes of meeting and AIs from 1 Dec. Dear All, Regarding the AI1 below, I have inquired about what has been published at it seems there are some sources, which we need to discuss in case we need to refer to them. Here are the options: 1. Some work has come out of Unicode’s Technical Standard 39<http://unicode.org/reports/tr39/>. There are two files available here<ftp://ftp.unicode.org/Public/security/revision-02>: a. Confusables.txt<ftp://ftp.unicode.org/Public/security/revision-02/confusables.txt> is the larger set, which has the data we need, but much more data, as the definition of confusables is perhaps broader than the strict homoglyphs we may want. b. Intentional.txt<ftp://ftp.unicode.org/Public/security/revision-02/intentional.txt> is perhaps the subset which we may be looking for, though the list seems ominously short, and would need a more thorough review (which I am happy to perform after our discussion). 2. RFC 5992 has data in its appendices, which also lists confusable code points, but is not restricted to homoglyphs. 3. The Root Zone LGR proposals<https://www.icann.org/resources/pages/lgr-proposals-2015-12-01-en> will also provide a reasonably comprehensive list (though we already discussed that these may still be limited for the second level). For example, see the list in Section 6 of the Armenian script proposal<https://www.icann.org/en/system/files/files/armenian-lgr-proposal-05nov15-e…> already published for a subset. Latin, Greek and Cyrillic GPs are also working on such lists, so we will have a multi-script community confirmation, once we have the other proposals. However, it is interesting to note that this work remains largely limited to Cyrillic, Green and Latin homoglyphs. Analysis is needed for other scripts. We have recently concluded the analysis for Lao, Khmer and Thai scripts as part of the Root Zone LGR work (and the communities have not found significant homoglyph contexts – e.g. see the Khmer and Lao proposals published (Thai on its way soon)). However, there may be some work needed for Neo-Brahmi scripts. Regards, Sarmad From: idngwg-bounces(a)icann.org [mailto:idngwg-bounces@icann.org] On Behalf Of Sarmad Hussain Sent: Friday, December 02, 2016 2:00 PM To: idngwg(a)icann.org Subject: [Idngwg] Minutes of meeting and AIs from 1 Dec. Dear All, Please find attached summary of the meeting of the WG on 1 Dec. Please let me know if there are any changes or suggestions. The meeting had the following AIs: S. No. Action Items Owner 1 Find out if there are existing lists of homoglyphs which can be referenced SH 2 Divide new recommendation on harmonization of LGRs into three recommendations, explaining harmonization, address cross-script homoglyphic variants, and address within-script variants caused by two different LGRs MD 3 Write a new recommendation on how to address existing registrations which are not harmonized, giving flexibility to registries KF 4 Re-write the recommendation on automatic activation based on the current input for further discussion EC The next meeting is schedule for 8 Dec. 11am UTC. The attached notes of the meeting and the recording of the meeting are available at the IDNGWG wiki page at https://community.icann.org/display/IDN/IDN+Implementation+Guidelines. Regards, Sarmad

2 2

Re: [Idngwg] Minutes of meeting and AIs from 1 Dec.
by Sarmad Hussain Dec. 5, 2016

Dec. 5, 2016

Thanks Dennis. Are we talking about three categories here (though sometimes the boundaries are fuzzy)? 1. Homoglyph code points 2. Variant code points (e.g. simplified and traditional Chinese or the recent ڪتاب and کتاب example) (including those which may not be homoglyphs) 3. Visually similar code points (e.g. Latin Digit One (1) and Latin Small Letter L (l)) (excluding variants or homoglyphs) The suggestion was to consider 1. and 2. above in the scope for harmonization. The reason is that if two code points are considered by the community to be same or variants respectively, labels which only differ in such code points should not be registered to different registrants, even if these are generated by different LGRs in the same zone. This is not adding a new requirement, as we have already said in an early recommendation that variant labels should be registered to the same registrant (or blocked). What this suggests is that when an additional LGR is added for the same script, any additional possible variants should be discovered and harmonized to meet this constraint. I did not comment on 3. above, which is a separate case for discussion. Once the WG specifies the scope, we can try to identify the relevant authoritative sources as well. Regards, Sarmad From: Tan Tanaka, Dennis [mailto:dtantanaka@verisign.com] Sent: Monday, December 05, 2016 11:29 PM To: Sarmad Hussain <sarmad.hussain(a)icann.org>; Mats Dufberg <mats.dufberg(a)iis.se>; idngwg(a)icann.org Subject: [EXTERNAL] Re: [Idngwg] Minutes of meeting and AIs from 1 Dec. I cannot help thinking about Latin Digit One (1) and Latin Small Letter L (l) which are considered in the confusables list. Would this recommendation make these two code points “variants” of each other? I don’t think we would want this. I understand the problem statement but I think we need to elaborate a bit more on the scope and the sources of authoritative data we can use as reference. -Dennis From: <idngwg-bounces(a)icann.org <mailto:idngwg-bounces@icann.org> > on behalf of Sarmad Hussain <sarmad.hussain(a)icann.org <mailto:sarmad.hussain@icann.org> > Date: Monday, December 5, 2016 at 1:19 PM To: Mats Dufberg <mats.dufberg(a)iis.se <mailto:mats.dufberg@iis.se> >, "idngwg(a)icann.org <mailto:idngwg@icann.org> " <idngwg(a)icann.org <mailto:idngwg@icann.org> > Subject: [EXTERNAL] Re: [Idngwg] Minutes of meeting and AIs from 1 Dec. Thanks Mats. Kindly note a couple of comments: > An analysis of homoglyphs (*) MUST be executed on the IDN table or tables (LGR or text table) for a specific TLD (or DNS zone). The analysis MUST be done both within each IDN table and between all IDN tables for the TLD (or zone). Homoglyphs can be within a single Unicode script or between different Unicode scripts. The analysis done for the root zone can be a source to discover possible homoglyphs, but it should be noted that character set has been limited to letters and characters equivalent to letters. E.g. digits and punctuations are not permitted in the root zone and therefore excluded from that analysis. Well-known homoglyphs in different Unicode scripts are found in Armenian, Cyrillic, Greek, and Latin scripts. There may be two different cases here, we should consider. (i) cross-script homoglyphs, and (ii) within-script variants (beyond within-script homoglyphs). The example of کتاب presented earlier does indeed only point out to within-script homoglyphs (for Persian and Arabic languages) for Arabic script. However, extending the example further, Arabic script community also considers ڪتاب a variant because Arabic language speakers consider 0643 and 06AA as calligraphic variations, however Sindhi[omniglot.com] <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.omniglot.com_writin…> speakers consider these as two different characters. Such cases should be handled in harmonization as well because if it is possible to register them separately (due to Sindhi), Arabic language users could face (almost) homoglyphic-level confusion which harmonization is seeking to prevent. > If homoglyphs are found, harmonization MUST be performed. The goal of the harmonization is to acheive system where it is not possible to register two domain names, under the same TLD (domain), that are homographs of each other. This is to reach a workable and secure system. Please note that in the case of (ii) above, it may be able to register the two domain labels and even make them active. The condition is that it should not be possible to have two different registrants register such labels. This is already captured by an earlier recommendation we have written which prevents registrations of variants to different registrants, though we can reiterate it if needed. Regards, Sarmad From: Mats Dufberg [mailto:mats.dufberg@iis.se] Sent: Monday, December 05, 2016 10:19 PM To: Sarmad Hussain <sarmad.hussain(a)icann.org <mailto:sarmad.hussain@icann.org> >; idngwg(a)icann.org <mailto:idngwg@icann.org> Subject: [EXTERNAL] Re: [Idngwg] Minutes of meeting and AIs from 1 Dec. Dear all, I will look through Sarmad's report below, and it might affect my text, but since we have meeting soon I send it to you directly, and I might update it later. <AI2> An analysis of homoglyphs (*) MUST be executed on the IDN table or tables (LGR or text table) for a specific TLD (or DNS zone). The analysis MUST be done both within each IDN table and between all IDN tables for the TLD (or zone). Homoglyphs can be within a single Unicode script or between different Unicode scripts. The analysis done for the root zone can be a source to discover possible homoglyphs, but it should be noted that character set has been limited to letters and characters equivalent to letters. E.g. digits and punctuations are not permitted in the root zone and therefore excluded from that analysis. Well-known homoglyphs in different Unicode scripts are found in Armenian, Cyrillic, Greek, and Latin scripts. If homoglyphs are found, harmonization MUST be performed. The goal of the harmonization is to acheive system where it is not possible to register two domain names, under the same TLD (domain), that are homographs of each other. This is to reach a workable and secure system. There are different ways to handle the possible homoglyphs, and decision of which way to go is up to the register of the actual TLD (domain). One possibility is to exclude code points so that there are no homographs. If the state homoglyphs is only reached when the code point is in a certain position of the label or together with some other code point, then contextual rules can be used to prohibit such positions. The third technique is to use blocking variant rules. If the homoglyphs are from different IDN tables, then the variant rules must operate on all the IDN tables. *) "In orthography and typography, a homoglyph is one of two or more graphemes, characters, or glyphs with shapes that appear identical or very similar." (<https://en.wikipedia.org/wiki/Homoglyph[en.wikipedia.org] <https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_…> >) **) Reference at Unicode Consortium </AI2> --- Mats Dufberg DNS Specialist, IIS Mobile: +46 73 065 3899 https://www.iis.se/en/[iis.se] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iis.se_en_&d=DgMGa…> From: <idngwg-bounces(a)icann.org <mailto:idngwg-bounces@icann.org> > on behalf of Sarmad Hussain <sarmad.hussain(a)icann.org <mailto:sarmad.hussain@icann.org> > Date: Sunday 4 December 2016 at 03:19 To: idngwg <idngwg(a)icann.org <mailto:idngwg@icann.org> > Subject: Re: [Idngwg] Minutes of meeting and AIs from 1 Dec. Dear All, Regarding the AI1 below, I have inquired about what has been published at it seems there are some sources, which we need to discuss in case we need to refer to them. Here are the options: 1. Some work has come out of Unicode’s Technical Standard 39[unicode.org] <https://urldefense.proofpoint.com/v2/url?u=http-3A__unicode.org_reports_tr3…> . There are two files available here[ftp.unicode.org] <https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.unicode.org_Public_s…> : a. Confusables.txt[ftp.unicode.org] <https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.unicode.org_Public_s…> is the larger set, which has the data we need, but much more data, as the definition of confusables is perhaps broader than the strict homoglyphs we may want. b. Intentional.txt[ftp.unicode.org] <https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.unicode.org_Public_s…> is perhaps the subset which we may be looking for, though the list seems ominously short, and would need a more thorough review (which I am happy to perform after our discussion). 2. RFC 5992 has data in its appendices, which also lists confusable code points, but is not restricted to homoglyphs. 3. The Root Zone LGR proposals[icann.org] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resource…> will also provide a reasonably comprehensive list (though we already discussed that these may still be limited for the second level). For example, see the list in Section 6 of the Armenian script proposal[icann.org] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_en_syste…> already published for a subset. Latin, Greek and Cyrillic GPs are also working on such lists, so we will have a multi-script community confirmation, once we have the other proposals. However, it is interesting to note that this work remains largely limited to Cyrillic, Green and Latin homoglyphs. Analysis is needed for other scripts. We have recently concluded the analysis for Lao, Khmer and Thai scripts as part of the Root Zone LGR work (and the communities have not found significant homoglyph contexts – e.g. see the Khmer and Lao proposals published (Thai on its way soon)). However, there may be some work needed for Neo-Brahmi scripts. Regards, Sarmad From: idngwg-bounces(a)icann.org <mailto:idngwg-bounces@icann.org> [mailto:idngwg-bounces@icann.org] On Behalf Of Sarmad Hussain Sent: Friday, December 02, 2016 2:00 PM To: idngwg(a)icann.org <mailto:idngwg@icann.org> Subject: [Idngwg] Minutes of meeting and AIs from 1 Dec. Dear All, Please find attached summary of the meeting of the WG on 1 Dec. Please let me know if there are any changes or suggestions. The meeting had the following AIs: S. No. Action Items Owner 1 Find out if there are existing lists of homoglyphs which can be referenced SH 2 Divide new recommendation on harmonization of LGRs into three recommendations, explaining harmonization, address cross-script homoglyphic variants, and address within-script variants caused by two different LGRs MD 3 Write a new recommendation on how to address existing registrations which are not harmonized, giving flexibility to registries KF 4 Re-write the recommendation on automatic activation based on the current input for further discussion EC The next meeting is schedule for 8 Dec. 11am UTC. The attached notes of the meeting and the recording of the meeting are available at the IDNGWG wiki page at https://community.icann.org/display/IDN/IDN+Implementation+Guidelines[commu… <https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_di…> . Regards, Sarmad

1 0

Re: [Idngwg] Minutes of meeting and AIs from 1 Dec.
by Tan Tanaka, Dennis Dec. 5, 2016

Dec. 5, 2016

I cannot help thinking about Latin Digit One (1) and Latin Small Letter L (l) which are considered in the confusables list. Would this recommendation make these two code points “variants” of each other? I don’t think we would want this. I understand the problem statement but I think we need to elaborate a bit more on the scope and the sources of authoritative data we can use as reference. -Dennis From: <idngwg-bounces(a)icann.org> on behalf of Sarmad Hussain <sarmad.hussain(a)icann.org> Date: Monday, December 5, 2016 at 1:19 PM To: Mats Dufberg <mats.dufberg(a)iis.se>, "idngwg(a)icann.org" <idngwg(a)icann.org> Subject: [EXTERNAL] Re: [Idngwg] Minutes of meeting and AIs from 1 Dec. Thanks Mats. Kindly note a couple of comments: > An analysis of homoglyphs (*) MUST be executed on the IDN table or tables (LGR or text table) for a specific TLD (or DNS zone). The analysis MUST be done both within each IDN table and between all IDN tables for the TLD (or zone). Homoglyphs can be within a single Unicode script or between different Unicode scripts. The analysis done for the root zone can be a source to discover possible homoglyphs, but it should be noted that character set has been limited to letters and characters equivalent to letters. E.g. digits and punctuations are not permitted in the root zone and therefore excluded from that analysis. Well-known homoglyphs in different Unicode scripts are found in Armenian, Cyrillic, Greek, and Latin scripts. There may be two different cases here, we should consider. (i) cross-script homoglyphs, and (ii) within-script variants (beyond within-script homoglyphs). The example of کتاب presented earlier does indeed only point out to within-script homoglyphs (for Persian and Arabic languages) for Arabic script. However, extending the example further, Arabic script community also considers ڪتاب a variant because Arabic language speakers consider 0643 and 06AA as calligraphic variations, however Sindhi<http://www.omniglot.com/writing/sindhi.htm> speakers consider these as two different characters. Such cases should be handled in harmonization as well because if it is possible to register them separately (due to Sindhi), Arabic language users could face (almost) homoglyphic-level confusion which harmonization is seeking to prevent. > If homoglyphs are found, harmonization MUST be performed. The goal of the harmonization is to acheive system where it is not possible to register two domain names, under the same TLD (domain), that are homographs of each other. This is to reach a workable and secure system. Please note that in the case of (ii) above, it may be able to register the two domain labels and even make them active. The condition is that it should not be possible to have two different registrants register such labels. This is already captured by an earlier recommendation we have written which prevents registrations of variants to different registrants, though we can reiterate it if needed. Regards, Sarmad From: Mats Dufberg [mailto:mats.dufberg@iis.se] Sent: Monday, December 05, 2016 10:19 PM To: Sarmad Hussain <sarmad.hussain(a)icann.org>; idngwg(a)icann.org Subject: [EXTERNAL] Re: [Idngwg] Minutes of meeting and AIs from 1 Dec. Dear all, I will look through Sarmad's report below, and it might affect my text, but since we have meeting soon I send it to you directly, and I might update it later. <AI2> An analysis of homoglyphs (*) MUST be executed on the IDN table or tables (LGR or text table) for a specific TLD (or DNS zone). The analysis MUST be done both within each IDN table and between all IDN tables for the TLD (or zone). Homoglyphs can be within a single Unicode script or between different Unicode scripts. The analysis done for the root zone can be a source to discover possible homoglyphs, but it should be noted that character set has been limited to letters and characters equivalent to letters. E.g. digits and punctuations are not permitted in the root zone and therefore excluded from that analysis. Well-known homoglyphs in different Unicode scripts are found in Armenian, Cyrillic, Greek, and Latin scripts. If homoglyphs are found, harmonization MUST be performed. The goal of the harmonization is to acheive system where it is not possible to register two domain names, under the same TLD (domain), that are homographs of each other. This is to reach a workable and secure system. There are different ways to handle the possible homoglyphs, and decision of which way to go is up to the register of the actual TLD (domain). One possibility is to exclude code points so that there are no homographs. If the state homoglyphs is only reached when the code point is in a certain position of the label or together with some other code point, then contextual rules can be used to prohibit such positions. The third technique is to use blocking variant rules. If the homoglyphs are from different IDN tables, then the variant rules must operate on all the IDN tables. *) "In orthography and typography, a homoglyph is one of two or more graphemes, characters, or glyphs with shapes that appear identical or very similar." (<https://en.wikipedia.org/wiki/Homoglyph>) **) Reference at Unicode Consortium </AI2> --- Mats Dufberg DNS Specialist, IIS Mobile: +46 73 065 3899 https://www.iis.se/en/ From: <idngwg-bounces(a)icann.org<mailto:idngwg-bounces@icann.org>> on behalf of Sarmad Hussain <sarmad.hussain(a)icann.org<mailto:sarmad.hussain@icann.org>> Date: Sunday 4 December 2016 at 03:19 To: idngwg <idngwg(a)icann.org<mailto:idngwg@icann.org>> Subject: Re: [Idngwg] Minutes of meeting and AIs from 1 Dec. Dear All, Regarding the AI1 below, I have inquired about what has been published at it seems there are some sources, which we need to discuss in case we need to refer to them. Here are the options: 1. Some work has come out of Unicode’s Technical Standard 39[unicode.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__unicode.org_reports_tr3…>. There are two files available here[ftp.unicode.org]<https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.unicode.org_Public_s…>: a. Confusables.txt[ftp.unicode.org]<https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.unicode.org_Public_s…> is the larger set, which has the data we need, but much more data, as the definition of confusables is perhaps broader than the strict homoglyphs we may want. b. Intentional.txt[ftp.unicode.org]<https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.unicode.org_Public_s…> is perhaps the subset which we may be looking for, though the list seems ominously short, and would need a more thorough review (which I am happy to perform after our discussion). 2. RFC 5992 has data in its appendices, which also lists confusable code points, but is not restricted to homoglyphs. 3. The Root Zone LGR proposals[icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resource…> will also provide a reasonably comprehensive list (though we already discussed that these may still be limited for the second level). For example, see the list in Section 6 of the Armenian script proposal[icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_en_syste…> already published for a subset. Latin, Greek and Cyrillic GPs are also working on such lists, so we will have a multi-script community confirmation, once we have the other proposals. However, it is interesting to note that this work remains largely limited to Cyrillic, Green and Latin homoglyphs. Analysis is needed for other scripts. We have recently concluded the analysis for Lao, Khmer and Thai scripts as part of the Root Zone LGR work (and the communities have not found significant homoglyph contexts – e.g. see the Khmer and Lao proposals published (Thai on its way soon)). However, there may be some work needed for Neo-Brahmi scripts. Regards, Sarmad From: idngwg-bounces(a)icann.org<mailto:idngwg-bounces@icann.org> [mailto:idngwg-bounces@icann.org] On Behalf Of Sarmad Hussain Sent: Friday, December 02, 2016 2:00 PM To: idngwg(a)icann.org<mailto:idngwg@icann.org> Subject: [Idngwg] Minutes of meeting and AIs from 1 Dec. Dear All, Please find attached summary of the meeting of the WG on 1 Dec. Please let me know if there are any changes or suggestions. The meeting had the following AIs: S. No. Action Items Owner 1 Find out if there are existing lists of homoglyphs which can be referenced SH 2 Divide new recommendation on harmonization of LGRs into three recommendations, explaining harmonization, address cross-script homoglyphic variants, and address within-script variants caused by two different LGRs MD 3 Write a new recommendation on how to address existing registrations which are not harmonized, giving flexibility to registries KF 4 Re-write the recommendation on automatic activation based on the current input for further discussion EC The next meeting is schedule for 8 Dec. 11am UTC. The attached notes of the meeting and the recording of the meeting are available at the IDNGWG wiki page at https://community.icann.org/display/IDN/IDN+Implementation+Guidelines[commu…<https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_di…>. Regards, Sarmad

1 0

Re: [Idngwg] Minutes of meeting from 24 Nov.
by Tan Tanaka, Dennis Dec. 1, 2016

Dec. 1, 2016

Dear all, Could someone define what harmonization means in the context of these guidelines? It seems to me that we are talking about homoglyph variants across scripts (e.g. Cyrillic a, Greek alpha and Latin a), so I am a bit confused about the new term. Thanks, Dennis From: <idngwg-bounces(a)icann.org> on behalf of Sarmad Hussain <sarmad.hussain(a)icann.org> Date: Tuesday, November 29, 2016 at 9:43 AM To: "idngwg(a)icann.org" <idngwg(a)icann.org> Subject: Re: [Idngwg] Minutes of meeting from 24 Nov. Dear All, The suggested text for AI 2 below does not address existing cases where harmonization may be needed and also suggests harmonization of existing IDN tables in the future when any changes are made. However, when this harmonization is done, existing registrations which may be affected – e.g. “cox” may be registered both in Latin and Cyrillic scripts at second level under some TLDs, etc. So we need a discussion on how to address such cases. Regards, Sarmad From: idngwg-bounces(a)icann.org [mailto:idngwg-bounces@icann.org] On Behalf Of Sarmad Hussain Sent: Monday, November 28, 2016 3:18 PM To: idngwg(a)icann.org Subject: [Idngwg] Minutes of meeting from 24 Nov. Dear All, Please find attached summary of the meeting of the WG on 24 Nov. Please let me know if there are any changes or suggestions. The meeting had the following AIs: S. No. Action Items Owner 1 Add footnote to refer to “code point sequences” and not add that in the text for readability SH 2 Draft recommendation for harmonization of LGRs to be put in Section 2.7. SH 3 Confirm with WG members if it is ok to move to a weekly schedule SH Here is the suggested text for review and feedback for AI 2 above: If a combination of multiple LGRs and/or IDN tables is used to generate labels for the same zone at the second (or other) level, there are harmonization requirements for a workable and secure system. The harmonization must be performed in cases where there are multiple LGRs and/or IDN tables either (i) from the same script which is known to have variant code points, e.g. based on analysis for the root zone, or (ii) from different scripts which are considered related in the root zone and have homoglyphs, e.g. Armenian, Cyrillic, Greek, and Latin. In such cases, harmonization must be performed when there is either a change in existing LGR or addition of a new LGR. The harmonization must review code point repertoire, variant analysis and whole label evaluation rules to ensure that there are no security and stability issues introduced. Please also note that the WG members in the meeting suggested moving to a weekly schedule to make more progress. Please let us know, if this does not work for you for any reason. Otherwise we will switch to a weekly meetings. The next meeting is schedule for 1 Dec. 11am UTC. The attached notes of the meeting and the recording of the meeting are available at the IDNGWG wiki page at https://community.icann.org/display/IDN/IDN+Implementation+Guidelines. Regards, Sarmad From: idngwg-bounces(a)icann.org<mailto:idngwg-bounces@icann.org> [mailto:idngwg-bounces@icann.org] On Behalf Of Sarmad Hussain Sent: Thursday, November 24, 2016 1:05 AM To: Edmon Chung <edmon(a)registry.asia<mailto:edmon@registry.asia>>; idngwg(a)icann.org<mailto:idngwg@icann.org> Subject: [Idngwg] Updated document for call today (24 Nov.) Thank you Edmon. Dear All, I have added Edmon’s suggestions and summary of comments received during ICANN 57 (circulated earlier) in the attached updated draft. Where it seemed relevant, reference to “code point sequence” in addition to “code point” is also added. We will use this version for our discussion today. Regards, Sarmad From: Edmon Chung [mailto:edmon@registry.asia] Sent: Thursday, November 24, 2016 1:14 PM To: Sarmad Hussain <sarmad.hussain(a)icann.org<mailto:sarmad.hussain@icann.org>>; idngwg(a)icann.org<mailto:idngwg@icann.org> Subject: [EXTERNAL] RE: [Idngwg] ICANN 57 summary and resuming calls for IDNGWG Adding 2.6.2 as discussed at our meeting before the ICANN meetings, and some adjustments to the proposed definitions related to IDN Variants. Edmon =================================== 2.6 IDN Variant Labels (Partially Discussed) 2.6.1 IDN Variant Labels generated by an IDN Table or a LGR must be allocated to the same registrant or blocked. 2.6.2 Only IDN Variant Labels with a disposition of "allocatable" may be included in the DNS. IDN Variant Labels may be automatically delegated by the TLD registry in accordance with RFC 3743 (i.e. Preferred Variants), otherwise IDN Variant Labels may be activated when requested by the Registrant (or through a sponsoring Registrar) of the Primary IDN. =================================== =================================== Proposed Definitions to be included: =================================== Variant The term "variant" is used generally to identify different types of linguistic situations where different words are considered to be the same (i.e. a variant) of another word. Because of the wide-ranging understanding of the term, to avoid confusion more specific terms such as "IDN Variant", "IDN Variant Character" or "IDN Variant Label" should be used. =================================== IDN Variant (IDN Variant Character and IDN Variant Label) IDN Variant is defined by an LGR. The term "IDN Variant" maybe used to reasonably describe an IDN Variant Character (code point or code point sequence) or an IDN Variant Label depending on its context. An IDN Variant character is defined in relation to a base character within an IDN Table, such as expressed by an LGR. An IDN Variant Label is a string generated from a Primary IDN based on a given LGR (or IDN Table and IDN registration rules). =================================== Primary IDN Primary IDN is the string representing the domain name applied for submitted by a registrant. =================================== From: idngwg-bounces(a)icann.org<mailto:idngwg-bounces@icann.org> [mailto:idngwg-bounces@icann.org] On Behalf Of Edmon Chung Sent: Monday, 21 November 2016 20:33 PM To: 'Sarmad Hussain' <sarmad.hussain(a)icann.org<mailto:sarmad.hussain@icann.org>>; idngwg(a)icann.org<mailto:idngwg@icann.org> Subject: Re: [Idngwg] ICANN 57 summary and resuming calls for IDNGWG Thanks Sarmad for the summary. Edmon From: idngwg-bounces(a)icann.org<mailto:idngwg-bounces@icann.org> [mailto:idngwg-bounces@icann.org] On Behalf Of Sarmad Hussain Sent: Sunday, 20 November 2016 16:19 PM To: idngwg(a)icann.org<mailto:idngwg@icann.org> Subject: [Idngwg] ICANN 57 summary and resuming calls for IDNGWG Dear All, For those at ICANN 57, hope you have arrived home safely, rested and caught up with work. We had a good interaction at ICANN 57, where the room was full with community members. Thanks to Edmon for leading the session and for others for attending the session in person and remotely. We received feedback from the community. Here are some salient comments received (for those who attended, please feel free to add further). Please see the attached transcript[schd.ws]<https://urldefense.proofpoint.com/v2/url?u=http-3A__schd.ws_hosted-5Ffiles_…> of the session for details. - Repertoire may contain code points AND code point sequences. So recommendations should be worded accordingly - Align definitions of label dispositions with those in RFC 7940 and clarify the label disposition state changes - Use of LGR (as a black box) should be explained in the guidelines to generate disposition and variants of a label - The relationship to root zone LGR and scope of guidelines may be clarified. Can anything be said for root zone LGR, i.e. how second level and root level LGRs are same or different? o We clarify how a particular point may be different at second level, from the root zone, in order to actually clarify the second level handling of that issue. o And if there are two LGRs that are in the same zone, even if it’s in the second level, they may have some harmonization requirements that are not really optional for a workable and secure system, which is different from parallel TLDs; Definition of a variant of a code point is unique and shared across all LGRs within a zone (within a single TLD) We would now like to resume our calls. I will schedule on for the coming week. Regards, Sarmad From: idngwg-bounces(a)icann.org<mailto:idngwg-bounces@icann.org> [mailto:idngwg-bounces@icann.org] On Behalf Of Sarmad Hussain Sent: Wednesday, November 02, 2016 11:47 PM To: idngwg(a)icann.org<mailto:idngwg@icann.org> Subject: [Idngwg] IMPORTAN: ICANN 57 presentation and working draft document available for circulation Dear All, The updated document[community.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_di…> has been uploaded to the IDNGWG wiki page[community.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_di…> and the presentation[schd.ws]<https://urldefense.proofpoint.com/v2/url?u=http-3A__schd.ws_hosted-5Ffiles_…> has been uploaded in the ICANN 57 schedule page for this session[icann572016.sched.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__icann572016.sched.org_…>. Please share with your colleagues and encourage them to come attend the session[icann572016.sched.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__icann572016.sched.org_…> and provide feedback. Regards, Sarmad From: idngwg-bounces(a)icann.org<mailto:idngwg-bounces@icann.org> [mailto:idngwg-bounces@icann.org] On Behalf Of Sarmad Hussain Sent: Wednesday, November 02, 2016 10:58 PM To: Tan Tanaka, Dennis <dtantanaka(a)verisign.com<mailto:dtantanaka@verisign.com>>; idngwg(a)icann.org<mailto:idngwg@icann.org> Subject: Re: [Idngwg] FEEDBACK REQUESTED: IDNGWG meeting notes 27 Oct. 2016 + ICANN 57 presentations Dear All, As there is no additional feedback, we will finalize the document based on Dennis’ comments and upload to the wiki page for sharing with community members. Regards, Sarmad From: idngwg-bounces(a)icann.org<mailto:idngwg-bounces@icann.org> [mailto:idngwg-bounces@icann.org] On Behalf Of Sarmad Hussain Sent: Saturday, October 29, 2016 9:46 AM To: Tan Tanaka, Dennis <dtantanaka(a)verisign.com<mailto:dtantanaka@verisign.com>>; idngwg(a)icann.org<mailto:idngwg@icann.org> Subject: Re: [Idngwg] FEEDBACK REQUESTED: IDNGWG meeting notes 27 Oct. 2016 + ICANN 57 presentations Dear Dennis, thank you for your detailed feedback and suggestions. “Cont.” means “continued”. I put that in as we have partially discussed (and have one recommendation) on IDN Variant Labels and may do further work on this topic. For other topics, not yet discussed, I have put in “TBD”. We do not have a target date at this time, but that is something we can discuss and decide. Dear all, please use the document with the edits by Dennis for any further suggestions. Regards, Sarmad From: Tan Tanaka, Dennis [mailto:dtantanaka@verisign.com] Sent: Saturday, October 29, 2016 1:56 AM To: Sarmad Hussain <sarmad.hussain(a)icann.org<mailto:sarmad.hussain@icann.org>>; idngwg(a)icann.org<mailto:idngwg@icann.org> Subject: Re: [Idngwg] FEEDBACK REQUESTED: IDNGWG meeting notes 27 Oct. 2016 + ICANN 57 presentations Sarmad, et al Please find enclosed proposed edits and questions. Good work! -Dennis From: <idngwg-bounces(a)icann.org<mailto:idngwg-bounces@icann.org>> on behalf of Sarmad Hussain <sarmad.hussain(a)icann.org<mailto:sarmad.hussain@icann.org>> Date: Friday, October 28, 2016 at 12:17 PM To: "idngwg(a)icann.org<mailto:idngwg@icann.org>" <idngwg(a)icann.org<mailto:idngwg@icann.org>> Subject: [Idngwg] FEEDBACK REQUESTED: IDNGWG meeting notes 27 Oct. 2016 + ICANN 57 presentations Dear All, Your feedback is requested especially on items 2 and 3 below by 1 Nov. before posting and circulating for ICANN 57. Please find attached the following: 1. Summary of our meeting on 27 October 2016 (docx + pdf). Please let me know in case of any changes. 2. Updated Guidelines document (docx + pdf), also published at our wiki page (to be circulated to the community on 2 Nov.) 3. The two updated presentations based on the discussion during the call (please see the attached meeting notes for the changes made) From the meeting, we have the following action items: S. No. Action Items Owner 1 Review updated recommendation 12 on IDN Variant Labels ALL 2 Update the ICANN 57 presentations and share with the IDNGWG for finalization SH The attached notes of the meeting, the recording of the meeting and the Guidelines document are available at the IDNGWG wiki page at https://community.icann.org/display/IDN/IDN+Implementation+Guidelines[commu…<https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_di…>. Our next meetings are planned during ICANN 57, per the following details: There is a 1hr15min face to face meeting of IDNGWG as per the following schedule: · Sat, 5 Nov., 1100-1215, Granite (Novotel): IDN Impl. Guidelines WG Meeting (https://icann572016.sched.org/event/8cwK/internationalized-domain-name-impl…<https://urldefense.proofpoint.com/v2/url?u=https-3A__icann572016.sched.org_…>) In addition, there is a 7 minute update by IDNGWG during the IDN Program Update session, as per the following details: · Sun, 6 Nov., 0830-0945, MR 1.02: IDN Program Update (7 min update by IDNGWG) (https://icann572016.sched.org/event/8dPX/internationalized-domain-name-prog…<https://urldefense.proofpoint.com/v2/url?u=https-3A__icann572016.sched.org_…>) o IDN Program – Overview and Progress - 15 mins o Update by Integration Panel – 10 mins o Update on IDN Implementation Guideline - 7 mins o Community Update § Ethiopic GP Update – 7 mins § Georgian GP Update – 7 mins § Neo-Brahmi GP Update – 7 mins § Thai GP Update – 7 mins o Q/A – 15 mins Regards, Sarmad

3 3

Minutes of meeting from 24 Nov.
by Sarmad Hussain Nov. 29, 2016

Nov. 29, 2016

Dear All, Please find attached summary of the meeting of the WG on 24 Nov. Please let me know if there are any changes or suggestions. The meeting had the following AIs: S. No. Action Items Owner 1 Add footnote to refer to “code point sequences” and not add that in the text for readability SH 2 Draft recommendation for harmonization of LGRs to be put in Section 2.7. SH 3 Confirm with WG members if it is ok to move to a weekly schedule SH Here is the suggested text for review and feedback for AI 2 above: If a combination of multiple LGRs and/or IDN tables is used to generate labels for the same zone at the second (or other) level, there are harmonization requirements for a workable and secure system. The harmonization must be performed in cases where there are multiple LGRs and/or IDN tables either (i) from the same script which is known to have variant code points, e.g. based on analysis for the root zone, or (ii) from different scripts which are considered related in the root zone and have homoglyphs, e.g. Armenian, Cyrillic, Greek, and Latin. In such cases, harmonization must be performed when there is either a change in existing LGR or addition of a new LGR. The harmonization must review code point repertoire, variant analysis and whole label evaluation rules to ensure that there are no security and stability issues introduced. Please also note that the WG members in the meeting suggested moving to a weekly schedule to make more progress. Please let us know, if this does not work for you for any reason. Otherwise we will switch to a weekly meetings. The next meeting is schedule for 1 Dec. 11am UTC. The attached notes of the meeting and the recording of the meeting are available at the IDNGWG wiki page at https://community.icann.org/display/IDN/IDN+Implementation+Guidelines. Regards, Sarmad From: idngwg-bounces(a)icann.org [mailto:idngwg-bounces@icann.org] On Behalf Of Sarmad Hussain Sent: Thursday, November 24, 2016 1:05 AM To: Edmon Chung <edmon(a)registry.asia>; idngwg(a)icann.org Subject: [Idngwg] Updated document for call today (24 Nov.) Thank you Edmon. Dear All, I have added Edmon’s suggestions and summary of comments received during ICANN 57 (circulated earlier) in the attached updated draft. Where it seemed relevant, reference to “code point sequence” in addition to “code point” is also added. We will use this version for our discussion today. Regards, Sarmad From: Edmon Chung [mailto:edmon@registry.asia] Sent: Thursday, November 24, 2016 1:14 PM To: Sarmad Hussain <sarmad.hussain(a)icann.org <mailto:sarmad.hussain@icann.org> >; idngwg(a)icann.org <mailto:idngwg@icann.org> Subject: [EXTERNAL] RE: [Idngwg] ICANN 57 summary and resuming calls for IDNGWG Adding 2.6.2 as discussed at our meeting before the ICANN meetings, and some adjustments to the proposed definitions related to IDN Variants. Edmon =================================== 2.6 IDN Variant Labels (Partially Discussed) 2.6.1 IDN Variant Labels generated by an IDN Table or a LGR must be allocated to the same registrant or blocked. 2.6.2 Only IDN Variant Labels with a disposition of "allocatable" may be included in the DNS. IDN Variant Labels may be automatically delegated by the TLD registry in accordance with RFC 3743 (i.e. Preferred Variants), otherwise IDN Variant Labels may be activated when requested by the Registrant (or through a sponsoring Registrar) of the Primary IDN. =================================== =================================== Proposed Definitions to be included: =================================== Variant The term "variant" is used generally to identify different types of linguistic situations where different words are considered to be the same (i.e. a variant) of another word. Because of the wide-ranging understanding of the term, to avoid confusion more specific terms such as "IDN Variant", "IDN Variant Character" or "IDN Variant Label" should be used. =================================== IDN Variant (IDN Variant Character and IDN Variant Label) IDN Variant is defined by an LGR. The term "IDN Variant" maybe used to reasonably describe an IDN Variant Character (code point or code point sequence) or an IDN Variant Label depending on its context. An IDN Variant character is defined in relation to a base character within an IDN Table, such as expressed by an LGR. An IDN Variant Label is a string generated from a Primary IDN based on a given LGR (or IDN Table and IDN registration rules). =================================== Primary IDN Primary IDN is the string representing the domain name applied for submitted by a registrant. =================================== From: idngwg-bounces(a)icann.org <mailto:idngwg-bounces@icann.org> [mailto:idngwg-bounces@icann.org] On Behalf Of Edmon Chung Sent: Monday, 21 November 2016 20:33 PM To: 'Sarmad Hussain' <sarmad.hussain(a)icann.org <mailto:sarmad.hussain@icann.org> >; idngwg(a)icann.org <mailto:idngwg@icann.org> Subject: Re: [Idngwg] ICANN 57 summary and resuming calls for IDNGWG Thanks Sarmad for the summary. Edmon From: idngwg-bounces(a)icann.org <mailto:idngwg-bounces@icann.org> [mailto:idngwg-bounces@icann.org] On Behalf Of Sarmad Hussain Sent: Sunday, 20 November 2016 16:19 PM To: idngwg(a)icann.org <mailto:idngwg@icann.org> Subject: [Idngwg] ICANN 57 summary and resuming calls for IDNGWG Dear All, For those at ICANN 57, hope you have arrived home safely, rested and caught up with work. We had a good interaction at ICANN 57, where the room was full with community members. Thanks to Edmon for leading the session and for others for attending the session in person and remotely. We received feedback from the community. Here are some salient comments received (for those who attended, please feel free to add further). Please see the attached transcript[schd.ws] <https://urldefense.proofpoint.com/v2/url?u=http-3A__schd.ws_hosted-5Ffiles_…> of the session for details. - Repertoire may contain code points AND code point sequences. So recommendations should be worded accordingly - Align definitions of label dispositions with those in RFC 7940 and clarify the label disposition state changes - Use of LGR (as a black box) should be explained in the guidelines to generate disposition and variants of a label - The relationship to root zone LGR and scope of guidelines may be clarified. Can anything be said for root zone LGR, i.e. how second level and root level LGRs are same or different? o We clarify how a particular point may be different at second level, from the root zone, in order to actually clarify the second level handling of that issue. o And if there are two LGRs that are in the same zone, even if it’s in the second level, they may have some harmonization requirements that are not really optional for a workable and secure system, which is different from parallel TLDs; Definition of a variant of a code point is unique and shared across all LGRs within a zone (within a single TLD) We would now like to resume our calls. I will schedule on for the coming week. Regards, Sarmad From: idngwg-bounces(a)icann.org <mailto:idngwg-bounces@icann.org> [mailto:idngwg-bounces@icann.org] On Behalf Of Sarmad Hussain Sent: Wednesday, November 02, 2016 11:47 PM To: idngwg(a)icann.org <mailto:idngwg@icann.org> Subject: [Idngwg] IMPORTAN: ICANN 57 presentation and working draft document available for circulation Dear All, The updated document[community.icann.org] <https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_di…> has been uploaded to the IDNGWG wiki page[community.icann.org] <https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_di…> and the presentation[schd.ws] <https://urldefense.proofpoint.com/v2/url?u=http-3A__schd.ws_hosted-5Ffiles_…> has been uploaded in the ICANN 57 schedule page for this session[icann572016.sched.org] <https://urldefense.proofpoint.com/v2/url?u=https-3A__icann572016.sched.org_…> . Please share with your colleagues and encourage them to come attend the session[icann572016.sched.org] <https://urldefense.proofpoint.com/v2/url?u=https-3A__icann572016.sched.org_…> and provide feedback. Regards, Sarmad From: idngwg-bounces(a)icann.org <mailto:idngwg-bounces@icann.org> [mailto:idngwg-bounces@icann.org] On Behalf Of Sarmad Hussain Sent: Wednesday, November 02, 2016 10:58 PM To: Tan Tanaka, Dennis <dtantanaka(a)verisign.com <mailto:dtantanaka@verisign.com> >; idngwg(a)icann.org <mailto:idngwg@icann.org> Subject: Re: [Idngwg] FEEDBACK REQUESTED: IDNGWG meeting notes 27 Oct. 2016 + ICANN 57 presentations Dear All, As there is no additional feedback, we will finalize the document based on Dennis’ comments and upload to the wiki page for sharing with community members. Regards, Sarmad From: idngwg-bounces(a)icann.org <mailto:idngwg-bounces@icann.org> [mailto:idngwg-bounces@icann.org] On Behalf Of Sarmad Hussain Sent: Saturday, October 29, 2016 9:46 AM To: Tan Tanaka, Dennis <dtantanaka(a)verisign.com <mailto:dtantanaka@verisign.com> >; idngwg(a)icann.org <mailto:idngwg@icann.org> Subject: Re: [Idngwg] FEEDBACK REQUESTED: IDNGWG meeting notes 27 Oct. 2016 + ICANN 57 presentations Dear Dennis, thank you for your detailed feedback and suggestions. “Cont.” means “continued”. I put that in as we have partially discussed (and have one recommendation) on IDN Variant Labels and may do further work on this topic. For other topics, not yet discussed, I have put in “TBD”. We do not have a target date at this time, but that is something we can discuss and decide. Dear all, please use the document with the edits by Dennis for any further suggestions. Regards, Sarmad From: Tan Tanaka, Dennis [mailto:dtantanaka@verisign.com] Sent: Saturday, October 29, 2016 1:56 AM To: Sarmad Hussain <sarmad.hussain(a)icann.org <mailto:sarmad.hussain@icann.org> >; idngwg(a)icann.org <mailto:idngwg@icann.org> Subject: Re: [Idngwg] FEEDBACK REQUESTED: IDNGWG meeting notes 27 Oct. 2016 + ICANN 57 presentations Sarmad, et al Please find enclosed proposed edits and questions. Good work! -Dennis From: <idngwg-bounces(a)icann.org <mailto:idngwg-bounces@icann.org> > on behalf of Sarmad Hussain <sarmad.hussain(a)icann.org <mailto:sarmad.hussain@icann.org> > Date: Friday, October 28, 2016 at 12:17 PM To: "idngwg(a)icann.org <mailto:idngwg@icann.org> " <idngwg(a)icann.org <mailto:idngwg@icann.org> > Subject: [Idngwg] FEEDBACK REQUESTED: IDNGWG meeting notes 27 Oct. 2016 + ICANN 57 presentations Dear All, Your feedback is requested especially on items 2 and 3 below by 1 Nov. before posting and circulating for ICANN 57. Please find attached the following: 1. Summary of our meeting on 27 October 2016 (docx + pdf). Please let me know in case of any changes. 2. Updated Guidelines document (docx + pdf), also published at our wiki page (to be circulated to the community on 2 Nov.) 3. The two updated presentations based on the discussion during the call (please see the attached meeting notes for the changes made) >From the meeting, we have the following action items: S. No. Action Items Owner 1 Review updated recommendation 12 on IDN Variant Labels ALL 2 Update the ICANN 57 presentations and share with the IDNGWG for finalization SH The attached notes of the meeting, the recording of the meeting and the Guidelines document are available at the IDNGWG wiki page at https://community.icann.org/display/IDN/IDN+Implementation+Guidelines[commu… <https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_di…> . Our next meetings are planned during ICANN 57, per the following details: There is a 1hr15min face to face meeting of IDNGWG as per the following schedule: * Sat, 5 Nov., 1100-1215, Granite (Novotel): IDN Impl. Guidelines WG Meeting (https://icann572016.sched.org/event/8cwK/internationalized-domain-name-impl… <https://urldefense.proofpoint.com/v2/url?u=https-3A__icann572016.sched.org_…> ) In addition, there is a 7 minute update by IDNGWG during the IDN Program Update session, as per the following details: * Sun, 6 Nov., 0830-0945, MR 1.02: IDN Program Update (7 min update by IDNGWG) (https://icann572016.sched.org/event/8dPX/internationalized-domain-name-prog… <https://urldefense.proofpoint.com/v2/url?u=https-3A__icann572016.sched.org_…> ) o IDN Program – Overview and Progress - 15 mins o Update by Integration Panel – 10 mins o Update on IDN Implementation Guideline - 7 mins o Community Update * Ethiopic GP Update – 7 mins * Georgian GP Update – 7 mins * Neo-Brahmi GP Update – 7 mins * Thai GP Update – 7 mins o Q/A – 15 mins Regards, Sarmad

1 1