Received: from brn1lxmailin02.vcorp.ad.vrsn.com (10.173.24.37) by brn1wnexcas01.vcorp.ad.vrsn.com (10.173.152.245) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 18 Oct 2017 05:13:41 -0400 Received: from brn1cscoip01.vcorp.ad.vrsn.com ([10.173.25.30]) by brn1lxmailin02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id v9I98FFn020178 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Wed, 18 Oct 2017 09:08:15 GMT X-IronPort-AV: E=Sophos;i="5.43,395,1503360000"; d="scan'208,217";a="4949855" X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Subject: [EXTERNAL] [Latingp] Principles for repertoire and variants - Feedback from IP IronPort-PHdr: =?us-ascii?q?9a23=3A2x46UxR5HuB2vi6entYrOlE/c9psv+yvbD5Q0YIu?= =?us-ascii?q?jvd0So/mwa6zZh2N2/xhgRfzUJnB7Loc0qyN4vCmATRIyK3CmUhKSIZLWR4BhJ?= =?us-ascii?q?detC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TW94jEIBxrwKxd+?= =?us-ascii?q?KPjrFY7OlcS30P2594HObwlSijewZbB/IA+qoQnNq8IbnZZsJqEtxxXTv3BGYf?= =?us-ascii?q?5WxWRmJVKSmxbz+MK994N9/ipTpvws6ddOXb31cKokQ7NYCi8mM30u683wqRbD?= =?us-ascii?q?VwqP6WACXWgQjxFFHhLK7BD+Xpf2ryv6qu9w0zSUMMHqUbw5Xymp4rx1QxH0li?= =?us-ascii?q?gIKz858HnWisNuiqJbvAmhrAF7z4LNfY2ZKOZycqbbcNgHR2ROQ9xRWjRBDI2i?= =?us-ascii?q?c4sBAekPPedXoIfgv1sDrxmwCAaxCO7h1jNHmmT20rMh3uQkDQ3KwBYtE84SvH?= =?us-ascii?q?nWqtj+KaccUfqyzKnN1TjNculZ2S346IfSbx8qvPOCXa9rccrK00YvFgXFhUiX?= =?us-ascii?q?pIz+JTyVzOENvHKG4OZ6VeKvlnUnqxprrTiuwMchkYjJiZ4PxVDC8yV12oE1Jc?= =?us-ascii?q?e3SENiZ9OvDZhetzmCOodrRs4uXXtktDogxrAJuJO3ZisHxIk/yxLCb/GLbZKE?= =?us-ascii?q?7g75WOueIzp0nmxpdbywihqq8EWtxffwW8u33VpQoSdJjsPAum4Q2xHV98OJUO?= =?us-ascii?q?Fy/l271jaKzw3T6v9LIUQzlafDMJ4hx6IwloIPvUjeBCP2mVn5g7WQdkUi4OSo?= =?us-ascii?q?7P7nYrr+qp+dMY97lB3+P7wzlsG7H+g0KBQCU3KU9Om9zrHu/lD1TK1PjvIsk6?= =?us-ascii?q?nZtJ7aJd4cpq68GwJV1pws6wq+Dzeg39QYhWALI0lCeBKaiYjmJ0/BIOvjAPe+?= =?us-ascii?q?n1ujijFrx/bcMr3mGJXNIWDPkK39crZl905c1A0zwMhC6JJIEL4BJu7zVVX3tN?= =?us-ascii?q?PCDR82KRe5w/j5B9Vn14MeQmOPAqCfMK/IrVCI4ecvcKGxYpQIsmP9N+Q9/Kyp?= =?us-ascii?q?yno8314WdK+vm5wNZze9F/ViJkyfJn30ntYGF3xNugMiTerlkA6/VyVObSO3Vq?= =?us-ascii?q?M4+jZpDIu6DIHMXsW3jaWc0TynNpxdb2ZATFeWHiDzao+GVvwQPT+UOdJriTce?= =?us-ascii?q?VLKsGLMmgDWnqA78g5VfZr7Q8zEZs537/Nl+7uvV0xYo+monId6a1jS2Rntxl2?= =?us-ascii?q?9AZyItx6l+pwQp0V6Z1KF0xfxFDsda5vVhUwwzM5iayPZ1XYOhEjndd8uEHQ71?= =?us-ascii?q?Cu6tBis8G5dom4cD?= X-IPAS-Result: =?us-ascii?q?A0GBAABYGudZh1EuAMBcGgEBAQECAQEBAQgBAQEBFQEBAQE?= =?us-ascii?q?CAQEBAQgBAQEBgkRCgRKBAhMHgzBDixOORJJshU+CAA4YAQqESUoDHgaEVEMUA?= =?us-ascii?q?QEBAQEBAQEBAQECEAEBAQoLCQgoL4I4BQIDGgEFCEZYAQEBAQEBIwINYAEEAQE?= =?us-ascii?q?JBgsGChkKHgYIAwECBgIBAQZABAICAgEBIwsmAQQTBQMTB4l+BQuMUo9pAY19g?= =?us-ascii?q?icmixQBAQgCIQWDL4IHgVGBaod6EQGDOYJhBYdJmgKCL4Uwg2ODYYVAgh2Fdos?= =?us-ascii?q?OlXOBb4F9NCEyUYJkglwcgWd2iCMBJjBcAYEQAQEB?= Received: from smtp01.icann.org ([192.0.46.81]) by mail1.verisign.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Oct 2017 09:13:40 +0000 Received: from mm.icann.org (mm.icann.org [192.0.32.100]) by smtp01.icann.org (Postfix) with ESMTP id A1FCBE16F2; Wed, 18 Oct 2017 09:13:39 +0000 (UTC) Received: from mm.icann.org (localhost [127.0.0.1]) by mm.icann.org (Postfix) with ESMTP id 662C972DF19; Wed, 18 Oct 2017 09:13:39 +0000 (UTC) X-Original-To: latingp@mm.icann.org Delivered-To: latingp@mm.icann.org Received: from pechora2.lax.icann.org (pechora2.icann.org [192.0.33.72]) by mm.icann.org (Postfix) with ESMTP id D262F72DF12 for ; Wed, 18 Oct 2017 09:13:38 +0000 (UTC) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by pechora2.lax.icann.org (Postfix) with ESMTPS id BA17A1E00DA for ; Wed, 18 Oct 2017 09:13:38 +0000 (UTC) X-CrossPremisesHeadersFilteredBySendConnector: PMBX112-W1-CA-2.pexch112.icann.org Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 18 Oct 2017 02:13:36 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Wed, 18 Oct 2017 02:13:36 -0700 From: Sarmad Hussain To: Latin GP Thread-Topic: Principles for repertoire and variants - Feedback from IP Thread-Index: AdNH8UZsQjIJcXvvSWmce8OQNlG5HA== Date: Wed, 18 Oct 2017 09:13:35 +0000 Message-ID: <9e049feb2efd41f99315564ad084a551@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.5.16 (pechora2.lax.icann.org [192.0.33.72]); Wed, 18 Oct 2017 09:13:38 +0000 (UTC) X-OrganizationHeadersPreserved: PMBX112-W1-CA-2.pexch112.icann.org X-BeenThere: latingp@icann.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Communication platform - Label Generation Rules List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: Errors-To: latingp-bounces@icann.org Return-Path: latingp-bounces@icann.org X-MS-Exchange-Organization-AuthSource: brn1wnexcas01.vcorp.ad.vrsn.com X-MS-Exchange-Organization-AuthAs: Anonymous Content-Type: multipart/mixed; boundary="B_3597993043_2077910385" MIME-Version: 1.0 --B_3597993043_2077910385 Content-Type: multipart/alternative; boundary="B_3597993043_1373650010" --B_3597993043_1373650010 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear All, =20 Please find input from the Integration Panel in response for the call for c= omments on the principles documents. =20 Regards, Sarmad The Integration Panel (IP) has reviewed "Principles for Inclusion and Exclu= sion of Code Points in Latin Script for the Root Zone (Latin LGR)e" and has = the following comments: The IP congratulates the Latin GP on the formulation of its "Principles for= Inclusion and Exclusion of Code Points in Latin Script for the Root Zone (L= atin LGR)". They appear to cover the important considerations and will likel= y serve the GP well in arriving at at list of proposed candidate code point= s. The IP would like to caution that the final decision on whether to includ= e or exclude a code point may not be possible by rote application of these (= or any other set of) principles, and that additional factors may have to be= considered in individual cases.=20 The IP is looking forward to the next stage of the Latin GP's work and to r= eviewing actual examples of draft code points. Additional notes: The IP would like to note that all entries in an LGR need to be in Unicode = Normalization Form C (see RFC 7940) and further that IDNA requires NFC, even= if it doesn't agree with the native typing order, or conventions regarding = precomposed, decomposed or mixed composed usage. RFC5890 states: "A "U-la= bel" is an IDNA-valid string of Unicode characters, in Normalization Form C = (NFC)". Because entries are normalized dual encoding cannot exist. In creating the repertoire each combining sequence needs to be individually= justified and should be separately enumerated; combining marks should not b= e individually members of the repertoire. In applying these principles, attention must be paid to the foundational do= cuments for this work as summarized in the "Guidelines for Developing Script= -Specific Label Generation Rules for Integration into the Root Zone LGR". Further, the exclusion principles should mention explicitly that the LGR re= pertoire is constrained by MSR: =C2=AB A code point not in the latest version of= the MSR is excluded. If there is a clear need to add one, the GP will conta= ct the Integration Panel to assess the possibility of adding one to the MSR= =C2=BB.=20 The IP has reviewed "Analysis of Variants in the Latin Script for the Root = Zone" and has the following comments: The actual guiding principle (contained in the second paragraph of the docu= ment) appears to cover the important considerations and will likely serve th= e GP well in arriving at at list of proposed candidate variants. The IP woul= d like to caution that the final decision on whether to include or exclude = a variant may not be possible by rote application of this (or any other) pri= nciple, and that additional factors may have to be considered in individual = cases.=20 The IP is looking forward to the next stage of the Latin GP's work and to r= eviewing actual examples of draft variants. Additional notes: The IP has some concerns about the remainder of the document. The procedure sets a very narrow limit on the kinds of cases that can be co= nsidered variants for the Root Zone; this is the basis of the statement by t= he IP that is quoted in a footnote. It might perhaps be better if this state= ment were incorporated into the definition of "scope". In that section, the opening remark about script mixing seem unconnected to= the discussion that follows. A straight listing of which related scripts th= e GP will consider would be more useful. The IP would like to point out that the example given the document of Lati= n =C3=A8 (U+00E8) and Cyrillic =D1=90 (U+0450) may be moot because the final Cyrilli= c repertoire does not contain U+0450. In general, it is expected that the an= alysis of cross-script repertoires remain limited to code points that are i= n the respective scripts' LGRs or draft LGRs. The general discussion of "classes of variants" may be "of interest to the = reader", but it isn't helpful in understanding which principles the Latin GP= will follow in deciding whether something is a variant or not -- most of th= e items discussed are not applicable in the context of the Root Zone LGR.=20 In the context of the Root Zone, the Procedure is quite clear in that it co= nsiders simple similarity of appearance to be outside the scope of the Root = Zone LGR. In admitting exact homoglyphs, the IP has been making the argument= that =E2=80=98e=E2=80=99 in Latin (U+0065) and =E2=80=98=D0=B5=E2=80=99 in Cyrillic(U+0435) are not ju= st visually indistinguishable, but that their distinct code points effective= ly represent a disunification by script property. (A disunification not unli= ke that of 01DD and 0259, which are disunified based on case, or the two se= ts of Arabic digits disunified largely on directional properties). In the context of other script LGRs for the Root Zone, the IP has argued st= rongly against embodying rules intended to deal with spelling issues. Theref= ore, any orthographic variation (spelling differences) would require a very = compelling case being made; the examples given may not rise to that level. = For instance, =E2=80=98ss=E2=80=99 (U+0073 U+0073) and =E2=80=98=C3=9F=E2=80=99 (U+00DF) are separately = available on the second level, in the .de ccTLD (and presumably others). Thi= s would strongly argue against the claim that German usage would require th= em to be variants - in fact the opposite might be concluded. Consideration of established practice in existing Latin-based IDNs ought to= be an important principle. The procedure makes reference to the "Least Asto= nishment Principle". This principle argues against solutions that produce un= expected or surprising behavior. Having the Root Zone exhibit fundamentally= different design decisions with respect to variants than those found on the= second level would have to be justified by strong arguments based on factor= s special to the Root Zone. Absent such factors, the expectation would be t= hat the various levels are more or less compatible in their treatment of IDN= labels for a given script. Finally, the claimed normalization exceptions appear based on a misundersta= nding of the normalization algorithm. In normalizing to precomposed form (No= rmalization Form C), the first step is to fully decompose the input string a= nd then to reorder all combining marks in a canonical order. Because of tha= t, the two examples of e with grave and dot below would become identical at = that stage of normalization. In the final stage of the algorithm, as much of= the sequence as possible is composed. But because both inputs have the sam= e fully decomposed and reordered form, their final NFC form is identical.=20 Or, put differently, only one of the two forms is in NFC, the other is unno= rmalized and as such not admissible in the LGR. =20 --B_3597993043_1373650010 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear All,

 

Please find input f= rom the Integration Panel in response for the call for comments on the prin= ciples documents.

 

Regards,
Sarmad

The Integration Panel (IP) has reviewed "Principles for Inclusion a= nd Exclusion of Code Points in Latin Script for the Root Zone (Latin LGR)e&= quot; and has the following comments:

The IP congratulates the Latin GP on the formulation of its "Princi= ples for Inclusion and Exclusion of Code Points in Latin Script for the Roo= t Zone (Latin LGR)". They appear to cover the important considerations= and will likely serve the GP well in arriving at at list of proposed candidate code points. The IP would like to caution= that the final decision on whether to include or exclude a code point may = not be possible by rote application of these (or any other set of) principl= es, and that additional factors may have to be considered in individual cases.

The IP is looking forward to the next stage of the Latin GP's work and t= o reviewing actual examples of draft code points.

Additional notes:

The IP would like to note that all entries in an LGR need to be in Unico= de Normalization Form C (see RFC 7940) and further that IDNA requires NFC, = even if it doesn't agree with the native typing order, or conventions regar= ding precomposed, decomposed or mixed composed usage.  RFC5890 states:  "A "U-label&qu= ot; is an IDNA-valid string of Unicode characters, in Normalization Form C = (NFC)". Because entries are normalized dual encoding cannot exist.

In creating the repertoire each combining sequence needs to be individua= lly justified and should be separately enumerated; combining marks should n= ot be individually members of the repertoire.

In applying these pri= nciples, attention must be paid to the foundational documents for this work= as summarized in the "Guidelines for Developing Script-Specific Label= Generation Rules for Integration into the Root Zone LGR".

Further, the exclusion principles should mention exp= licitly that the LGR repertoire is constrained by MSR: =C2=AB A code p= oint not in the latest version of the MSR is excluded. If there is a c= lear need to add one, the GP will contact the Integration Panel to assess the possibility of adding one to the MSR =C2=BB.

The IP has reviewed "Analysis of Variants in the Latin Script for t= he Root Zone" and has the following comments:

The actual guiding principle (contained in the second paragraph of the d= ocument) appears to cover the important considerations and will likely serv= e the GP well in arriving at at list of proposed candidate variants. The IP= would like to caution that the final decision on whether to include or exclude a variant may not be possi= ble by rote application of this (or any other) principle, and that addition= al factors may have to be considered in individual cases.

The IP is looking forward to the next stage of the Latin GP's work and t= o reviewing actual examples of draft variants.

Additional notes:

The IP has some concerns about the remainder of the document.=

The procedure sets a very narrow limit on the kinds of cases that can be= considered variants for the Root Zone; this is the basis of the statement = by the IP that is quoted in a footnote. It might perhaps be better if this = statement were incorporated into the definition of "scope".

In that section, the opening remark about script mixing seem unconnected= to the discussion that follows. A straight listing of which related script= s the GP will consider would be more useful.

The IP  would like to point out that the example given the document= of Latin =C3=A8 (U+00E8) and Cyrillic =D1=90 (U+0450) may be moot = because the final Cyrillic repertoire does not contain U+0450. In gener= al, it is expected that the analysis of cross-script repertoires remain limited to code points that are in the respective scripts' LGRs or = draft LGRs.

The general discussion of "classes of variants" may be "o= f interest to the reader", but it isn't helpful in understanding which= principles the Latin GP will follow in deciding whether something is a var= iant or not -- most of the items discussed are not applicable in the context of the Root Zone LGR.

In the context of the Root Zone, the Procedure is quite clear in that it= considers simple similarity of appearance to be outside the scope of the R= oot Zone LGR. In admitting exact homoglyphs, the IP has been making the arg= ument that =E2=80=98e=E2=80=99 in Latin (U+0065) and =E2=80=98=D0=B5=E2=80=99 in Cyrillic(U+0435) are not just visually= indistinguishable, but that their distinct code points effectively represe= nt a disunification by script property. (A disunification not unlike that o= f 01DD and 0259, which are disunified based on case, or the two sets of Arabic digits disunified largely on directional properties).
In the context of other script LGRs for the Root Zone, the IP has argued st= rongly against embodying rules intended to deal with spelling issues. There= fore, any orthographic variation (spelling differences) would require a ver= y compelling case being made; the examples given may not rise to that level. For instance, =E2=80=98ss=E2=80= =99 (U+0073 U+0073) and =E2=80=98=C3=9F=E2=80=99 (U+00DF) are s= eparately available on the second level, in the .de ccTLD (and presumably o= thers). This would strongly argue against the claim that German usage would= require them to be variants - in fact the opposite might be concluded.<= /p>

Consideration of established practice in existing Latin-based IDNs ought= to be an important principle. The procedure makes reference to the "L= east Astonishment Principle". This principle argues against solutions = that produce unexpected or surprising behavior. Having the Root Zone exhibit fundamentally different design decisions with= respect to variants than those found on the second level would have to be = justified by strong arguments based on factors special to the Root Zone. Ab= sent such factors, the expectation would be that the various levels are more or less compatible in their trea= tment of IDN labels for a given script.

Finally, the claimed normalization exceptions appear based on a misunder= standing of the normalization algorithm. In normalizing to precomposed form= (Normalization Form C), the first step is to fully decompose the input str= ing and then to reorder all combining marks in a canonical order. Because of that, the two examples of e with gr= ave and dot below would become identical at that stage of normalization. In= the final stage of the algorithm, as much of the sequence as possible is c= omposed. But because both inputs have the same fully decomposed and reordered form, their final NFC form is= identical.

Or, put differently, only one of the two forms is in NFC, the other is u= nnormalized and as such not admissible in the LGR.

 

--B_3597993043_1373650010-- --B_3597993043_2077910385 Content-Type: text/plain; name="ATT00001.txt" Content-ID: Content-Disposition: attachment; filename="ATT00001.txt" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkxhdGluZ3Ag bWFpbGluZyBsaXN0DQpMYXRpbmdwQGljYW5uLm9yZw0KaHR0cHM6Ly9tbS5pY2Fubi5vcmcvbWFp bG1hbi9saXN0aW5mby9sYXRpbmdwDQo= --B_3597993043_2077910385--