Re: [Idngwg] Meeting notes from 13 October
This is my contribution for item 1 (Update the Introduction section to include more context for the reader for the document to be more self-explanatory):
This Guidlines is about the implementation if Internationalized Domains Names (IDN) under Internet domains. IDN is standardized by IETF as an extension to DNS (RFC 5890).
The main target of this document are registries of TLDs that offer or plan to offer registrations of IDN domain names on second level. If the Registry Agreement between ICANN and the Registry Operator for the specific TLD says so, this document is binding for that TLD. For other TLDs this document is the best current practice. This document is also valuable for Registrars offering registration of IDN domain names and domain name owners adding IDN names under its domain. This document consists of a number of recommendations. If it is stated in the recommendations that a certain choice "must" be taken, then there is there is no option to implementing that recommendation. If it states "should" then the registry must have good reason not to implement it. <<< Yours, Mats --- Mats Dufberg DNS Specialist, IIS Mobile: +46 73 065 3899 https://www.iis.se/en/ From: <idngwg-bounces@icann.org> on behalf of Sarmad Hussain <sarmad.hussain@icann.org> Date: Thursday 13 October 2016 at 19:50 To: idngwg <idngwg@icann.org> Subject: [Idngwg] Meeting notes from 13 October Dear All, Kindly note that we have moved to a weekly schedule during October 2016. Please find attached the summary of our meeting on 13 October 2016. Please let me know in case of any changes. We have the following action items: S. No. Action Items Owner 1 Update the Introduction section to include more context for the reader for the document to be more self-explanatory MD 2 Draft a new requirement which requires all variants to be allocated to the same registrant, with a “must” EC 3 Update the terminology list to include the terms identified, and add relevant definitions from existing documents SH The attached notes and the recording of the meeting will soon be available at the IDNGWG wiki page at https://community.icann.org/display/IDN/IDN+Implementation+Guidelines. Next meeting will be on 20 October, 11am UTC. Regards, Sarmad
I generally support this kind of introduction text. Although I think we may need to adjust the language a little. But I'd suggest leaving that until later, since perfecting the introduction is less important than simply having one for context for those in the community that will read this document. One recommendation I'd make that we could introduce straight away is replacing the last paragraph with the following text which regularly appears in ICANN policy introductions (I make no claims of originality): -The terms "MAY", "MUST", "MUST NOT", "REQUIRED", "SHOULD NOT" and "SHOULD" are used to indicate the requirement level in accordance with RFC 2119, which is available at http://www.ietf.org/rfc/rfc2119.txt Also please note my apologies for tonight. I will attend next week's meeting if we choose to have it (noting that it is a week before ICANN 57). Kal Feher Neustar Inc. / Enterprise Architect Level 8, 10 Queens Road, Melbourne, Australia VIC 3004 Office +61 3 9866 3710 / kal.feher@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@icann.org<mailto:idngwg-bounces@icann.org>> on behalf of Mats Dufberg <mats.dufberg@iis.se<mailto:mats.dufberg@iis.se>> Date: Thursday, 20 October 2016 at 21:20 To: Sarmad Hussain <sarmad.hussain@icann.org<mailto:sarmad.hussain@icann.org>>, "idngwg@icann.org<mailto:idngwg@icann.org>" <idngwg@icann.org<mailto:idngwg@icann.org>> Subject: Re: [Idngwg] Meeting notes from 13 October This is my contribution for item 1 (Update the Introduction section to include more context for the reader for the document to be more self-explanatory):
This Guidlines is about the implementation if Internationalized Domains Names (IDN) under Internet domains. IDN is standardized by IETF as an extension to DNS (RFC 5890).
The main target of this document are registries of TLDs that offer or plan to offer registrations of IDN domain names on second level. If the Registry Agreement between ICANN and the Registry Operator for the specific TLD says so, this document is binding for that TLD. For other TLDs this document is the best current practice. This document is also valuable for Registrars offering registration of IDN domain names and domain name owners adding IDN names under its domain. This document consists of a number of recommendations. If it is stated in the recommendations that a certain choice "must" be taken, then there is there is no option to implementing that recommendation. If it states "should" then the registry must have good reason not to implement it. <<< Yours, Mats --- Mats Dufberg DNS Specialist, IIS Mobile: +46 73 065 3899 https://www.iis.se/en/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iis.se_en_&d=DQQGaQ&c=MOptNlVtIETeDALC_lULrw&r=_-v0M-gLiqWrtaHtP66hjSPyu3ePgw9YIihGxxybjqU&m=T0lzo05PgGuUjmQT9FQHeass3nKnabpVMKHPX7Ri9a4&s=WSwvZxYWm408A-ZLTaLU7X0BbEN0jyKSfllEHtBpmB4&e=> 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: Thursday 13 October 2016 at 19:50 To: idngwg <idngwg@icann.org<mailto:idngwg@icann.org>> Subject: [Idngwg] Meeting notes from 13 October Dear All, Kindly note that we have moved to a weekly schedule during October 2016. Please find attached the summary of our meeting on 13 October 2016. Please let me know in case of any changes. We have the following action items: S. No. Action Items Owner 1 Update the Introduction section to include more context for the reader for the document to be more self-explanatory MD 2 Draft a new requirement which requires all variants to be allocated to the same registrant, with a “must” EC 3 Update the terminology list to include the terms identified, and add relevant definitions from existing documents SH The attached notes and the recording of the meeting will soon be available at the IDNGWG wiki page at https://community.icann.org/display/IDN/IDN+Implementation+Guidelines<https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_display_IDN_IDN-26-2343-3BImplementation-26-2343-3BGuidelines&d=DQMGaQ&c=MOptNlVtIETeDALC_lULrw&r=_-v0M-gLiqWrtaHtP66hjSPyu3ePgw9YIihGxxybjqU&m=T0lzo05PgGuUjmQT9FQHeass3nKnabpVMKHPX7Ri9a4&s=qcCpoBOcETjdVXWSSZh4h26yKAbDqoS_p1NFWtQrtRM&e=>. Next meeting will be on 20 October, 11am UTC. Regards, Sarmad
My homework from last week below Rough draft text for 2.6.1 and some proposed definitions to accompany the discussion. Edmon =================================== 2.6.1. Allocation of IDN Variant labels to the same registrant. TLD registries utilizing LGRs that defines IDN Variants must effectively allocate all IDN Variant Labels generated from a Primary IDN to the same registrant. Transfer, deletion, contact and host updates, and renewal (except where allocatable IDN Variants are activated with separate fees), for the Primary IDN must be effected on all its corresponding IDN Variants. =================================== 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. =================================== 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 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 expressed by an LGR. An IDN Variant Label is a string generated from a Primary IDN based on a given LGR. =================================== Primary IDN Primary IDN is the string representing domain name applied for submitted by a registrant =================================== From: idngwg-bounces@icann.org [mailto:idngwg-bounces@icann.org] On Behalf Of Mats Dufberg Sent: Thursday, 20 October 2016 18:20 PM To: Sarmad Hussain <sarmad.hussain@icann.org>; idngwg@icann.org Subject: Re: [Idngwg] Meeting notes from 13 October This is my contribution for item 1 (Update the Introduction section to include more context for the reader for the document to be more self-explanatory):
This Guidlines is about the implementation if Internationalized Domains Names (IDN) under Internet domains. IDN is standardized by IETF as an extension to DNS (RFC 5890). The main target of this document are registries of TLDs that offer or plan to offer registrations of IDN domain names on second level. If the Registry Agreement between ICANN and the Registry Operator for the specific TLD says so, this document is binding for that TLD. For other TLDs this document is the best current practice. This document is also valuable for Registrars offering registration of IDN domain names and domain name owners adding IDN names under its domain. This document consists of a number of recommendations. If it is stated in the recommendations that a certain choice "must" be taken, then there is there is no option to implementing that recommendation. If it states "should" then the registry must have good reason not to implement it. <<< Yours, Mats --- Mats Dufberg DNS Specialist, IIS Mobile: +46 73 065 3899 https://www.iis.se/en/ 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: Thursday 13 October 2016 at 19:50 To: idngwg <idngwg@icann.org <mailto:idngwg@icann.org> > Subject: [Idngwg] Meeting notes from 13 October Dear All, Kindly note that we have moved to a weekly schedule during October 2016. Please find attached the summary of our meeting on 13 October 2016. Please let me know in case of any changes. We have the following action items: S. No. Action Items Owner 1 Update the Introduction section to include more context for the reader for the document to be more self-explanatory MD 2 Draft a new requirement which requires all variants to be allocated to the same registrant, with a “must” EC 3 Update the terminology list to include the terms identified, and add relevant definitions from existing documents SH The attached notes and the recording of the meeting will soon be available at the IDNGWG wiki page at https://community.icann.org/display/IDN/IDN+Implementation+Guidelines. Next meeting will be on 20 October, 11am UTC. Regards, Sarmad
participants (3)
-
Edmon Chung -
Feher, Kal -
Mats Dufberg