Thanks for the queries and comments, Dennis. I have tried to clarify further inline below. We should discuss which of these three aspects should be included in the guidelines. Regards, Sarmad From: Tan Tanaka, Dennis [mailto:dtantanaka@verisign.com] Sent: Saturday, August 06, 2016 1:44 AM To: Sarmad Hussain <sarmad.hussain@icann.org>; idngwg@icann.org Subject: Re: [Idngwg] meeting notes from 14 July 2016 Dear all, A few comments/questions to the new proposed recommendation for ref. second level LGRs “TLD registries should collaborate to review and contribute to the development of reference second level LGRs so that these meet the expectations of the community.” Who is the community and what are these expectations? The Least Astonishment Principle in RFC 6912 could be used to this question: Community: “Every zone administrator should be sensitive to the likely use of a code point to be permitted, particularly taking into account the population likely to use the zone.” Expectations: “Zone administrators should especially consider whether a candidate code point could present difficulty if the code point is encountered outside the usual linguistic circumstances. By the same token, the failure to support a code point that is normal in some linguistic circumstances could be very surprising for users likely to encounter the names in that circumstance.” “The TLD registries are encouraged to adopt these LGRs, because having common LGRs provides a predictable and consistent end-user experience.“ I don’t see how having common LGRs provide a predictable and consistent end-user experience. Registry operators do not control the user experience, registrars do. Registrars can choose which TLDs to offer, whether to offer premium names or not, etc, so potentially two exact same TLDs have different inventory of names depending upon a registrar implementation. Our industry’s distribution model inheritably does not offer a consistent and predictable user experience. The intention here is that if different TLDs use a common LGR for the same community, they create the same valid label space and variant label sets. There could be other differences, as you point out, but the LGR-derived parts would become more predictable (e.g. same set of variants for a given label across different TLDs). “In cases where the TLD registries decide to deviate from these reference second level LGRs to suit the particular needs of their specific communities, they should publish and highlight the deviation from the reference LGRs for the general end-users to better understand any differences in LGRs across the TLDs.” The current IDN guidelines require registry operators to offer IDNs in “strict compliance” of IDNA2008 and Spec 6 of the Registry Agreement also states that registry operators “shall comply” with IDN2008 and its successors. If IDNA2008 already dictates which code points are valid and advices registry operators to “permit character from scripts that are well-understood by the registry or its advisers” why would this working group require registry operators that implement an IDN table that deviates from a LGR (i.e. a reference table), but is in compliance of IDNA2008, to explain the deviations? Furthermore, IDN tables are required to be published at the IANA repository so registrants and the general public can review them at their own convenience. The key part here is to highlight the difference for the general end-user – this points back to the Least Astonishment Principle. It is up to the registry to decide how to publish such details. Publishing with IANA repository does make the LGR public. Some ccTLDs also publish the characters they support and the variants they implement directly, e.g. see Appendix A of the domain name registration policy for Qatar ccTLD <http://www.domains.qa/sites/default/files/Qatar%20Domains%20Registry-Domain%...> . Thanks, -Dennis From: <idngwg-bounces@icann.org> on behalf of Sarmad Hussain <sarmad.hussain@icann.org <mailto:sarmad.hussain@icann.org> > Date: Thursday, July 28, 2016 at 6:30 AM To: "idngwg@icann.org <mailto:idngwg@icann.org> " <idngwg@icann.org <mailto:idngwg@icann.org> > Subject: Re: [Idngwg] meeting notes from 14 July 2016 Thanks Kal. Dear All, Please find attached the updated version of the document for discussion today. Per the tasks from last meeting, edits include: 1. RFC 7940 for LGR 2. Updated Recommendation 6 by Kal, in Section 2.4 3. Updated Recommendation 9, in Section 2.4 4. New recommendation on reference second level LGRs in Section 2.4 In addition to the wording of the recommendation, we also need to define a section in the guidelines where these recommendations should be listed. Regards, Sarmad From: idngwg-bounces@icann.org <mailto:idngwg-bounces@icann.org> [mailto:idngwg-bounces@icann.org] On Behalf Of Feher, Kal Sent: Thursday, July 28, 2016 10:25 AM To: idngwg@icann.org <mailto:idngwg@icann.org> Subject: Re: [Idngwg] meeting notes from 14 July 2016 I've attached the revised recommendation 6 for section 2.4. During the last meeting, I think a few of us felt that this recommendation was an awkward fit for 'Section 2.4 Consistency'. This recommendation, if followed, will improve a user's understanding of the language table and how it is implemented in the registry and DNS. So it is more about education than collaboration/consistency. While I think the recommendation has merit and should remain in the guidelines in some form, it should probably be in a section related to user acceptance or Registrant interaction with IDN based registries. Kal Feher Neustar Inc. / Enterprise Architect Level 8, 10 Queens Road, Melbourne, Australia VIC 3004 Office +61 3 9866 3710 / <mailto:kal.feher@neustar.biz> kal.feher@neustar.biz / <http://www.neustar.biz/> www.neustar.biz Follow Neustar: <http://www.facebook.com/neustarinc> Facebook <http://www.linkedin.com/company/5349> LinkedIn <http://www.twitter.com/neustarinc> Twitter _____ 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@icann.org <mailto:idngwg-bounces@icann.org> > on behalf of Sarmad Hussain <sarmad.hussain@icann.org <mailto:sarmad.hussain@icann.org> > Date: Sunday, 24 July 2016 at 21:14 To: "idngwg@icann.org <mailto:idngwg@icann.org> " <idngwg@icann.org <mailto:idngwg@icann.org> > Subject: Re: [Idngwg] meeting notes from 14 July 2016 Dear All, Wael also attended this meeting. The updated version of the meeting notes has been uploaded at the wiki page. Regards, Sarmad From: idngwg-bounces@icann.org <mailto:idngwg-bounces@icann.org> [mailto:idngwg-bounces@icann.org] On Behalf Of Sarmad Hussain Sent: Sunday, July 24, 2016 1:59 PM To: idngwg@icann.org <mailto:idngwg@icann.org> Subject: [Idngwg] meeting notes from 14 July 2016 Dear All, Please find attached the meeting notes from 14 July 2016. Please let me know in case of any edits or suggestions. We have the following action items: S. No. Action Items Owner 1 Staff to share when RFC on LGRs is published and update document appropriately SH 2 Suggest updated text for current Recommendation 6 in section 2.4 KF 3 Break Recommendation 9 in section 2.4 into multiple recommendations covering the various ideas discussed, including Reference 2nd Level LGRs, more general IDN policy and collaboration in other aspects of IDNs in the future SH for first-cut 4 Review the table with text on IDN Variants and come with suggestion for recommendation(s) for next meeting ALL The attached notes and the recording of the meeting are available at the IDNGWG wiki page at https://community.icann.org/display/IDN/IDN+Implementation+Guidelines. Next meeting will be on 28 July, 11am UTC. Regards, Sarmad
