From nobody Thu Mar 1 10:18:00 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8375312EC7A for ; Thu, 1 Mar 2018 10:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.332 X-Spam-Level: X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pt37QUoemw1 for ; Thu, 1 Mar 2018 10:17:43 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9229312EC7B for ; Thu, 1 Mar 2018 10:17:42 -0800 (PST) Received: by mork.alvestrand.no (Postfix) id 0EAFE7C3B7D; Thu, 1 Mar 2018 19:17:41 +0100 (CET) Delivered-To: idna-update@alvestrand.no Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 00DDC7C3B32 for ; Thu, 1 Mar 2018 19:17:41 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Authentication-Results: mork.alvestrand.no (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjwDYXzmv8Ft for ; Thu, 1 Mar 2018 19:17:38 +0100 (CET) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4003:c06::242; helo=mail-oi0-x242.google.com; envelope-from=ted.ietf@gmail.com; receiver=idna-update@alvestrand.no Received: from mail-oi0-x242.google.com (mail-oi0-x242.google.com [IPv6:2607:f8b0:4003:c06::242]) by mork.alvestrand.no (Postfix) with ESMTPS id 821C97C355C for ; Thu, 1 Mar 2018 19:17:38 +0100 (CET) Received: by mail-oi0-x242.google.com with SMTP id j81so5192735oia.0 for ; Thu, 01 Mar 2018 10:17:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=zraqIuNwRhcvoH+cP+mjcDb38Qs5/F+qDFmRTJExsgw=; b=TK+z1gbeZYZtG48Jg/J6nabjKWwmNqPPihT5KSrYG/a6mE/cCy/1em6oRCBUQZMkIs fM6D/H2oSJqT/5DzWfffbo7Y9CH2A6eEEb+tAzv76oT4FTmVB/QoBrS/zjsk3w3fuPoU qp8Ae6/fFCmekFIt6t0zVTuT3ycOca0wpsTiV0uLRwAuQl9C9WCj8aupcMZIPltEXywt 9UQQ57kbHnh6KvWDa011I0DdKiexQ6jPbRAGaBK5bwMiDHI2f0tMLfej8qHgLlSk1Jkf ffOjb7Ny1MCBNcK1Pok64PRF1i4JztrqK5JvnUArJKB5O0FAMM5Q78vcKTIRMr2+gbw7 iwSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=zraqIuNwRhcvoH+cP+mjcDb38Qs5/F+qDFmRTJExsgw=; b=eQV+Umh83p7v6JAHAlCIEtuF2ZPdhSVr2XJjmkVgosgAvIwCjmzqWgbPXIm/fZXTnf AiqZ7BIsISJ3dxePXFBx/4hqVtMa5mjPDkHMKpInub4LUzMeLYOlXa0VnxEenBed/Tgn 4nhUxV7r4DARjWRzif/DHzsYQjs5PRJD4q1zAo2BaFj+689fYYGsvz+zz8VJI1SAk/Fx x/nmbh9ZoV6Qfj1kwGiuZ+MZi3RX6meT7gdqT+JgSFewDndfyyCseCH4X968lfAoNjqO ssi+dsndt196ZyJp6hfAfaLcNMy69lHDUqoBhEeY4NatZfuQnfE3OOiiwcdBgEVQRUSq p97w== X-Gm-Message-State: AElRT7Fo71OtrWIRQDvVs6xQacMxY9IRJrLgswzY4KUYu5OLwlI6ItPI kg8gblzcKEsxfP6lVi2kPpk4UoIO8ZLlwFMGVV5x5Q== X-Google-Smtp-Source: AG47ELtwor6+epNJNYgXzWI7Axc7oziRqHxFYrYon/AzQb1Xo9ibc8JXOFCDU8rkTvytfkCwBU0AJm6AupgRl0k4rQc= X-Received: by 10.202.189.133 with SMTP id n127mr1830719oif.103.1519926871400; Thu, 01 Mar 2018 09:54:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.7.27 with HTTP; Thu, 1 Mar 2018 09:54:01 -0800 (PST) From: Ted Hardie Date: Thu, 1 Mar 2018 09:54:01 -0800 Message-ID: To: idna-update@alvestrand.no Content-Type: multipart/alternative; boundary="001a113dd464414b9705665d8d39" Archived-At: Subject: [Idna-update] IAB seeks volunteer to serve on ICANN study group for root zone label generation X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 18:17:47 -0000 --001a113dd464414b9705665d8d39 Content-Type: text/plain; charset="UTF-8" Greetings, As part of their work on the deployment of IDNs in the root zone, ICANN plans to convene a technical study group on the application of root zone label generation rules . They have the asked the IAB to assist in the nomination of experts to this panel, and the IAB has agreed. We are therefore seeking community volunteers to assist with this work. The technical experts are expected to be familiar with the technical standards and the issues relevant to these ICANN activities, primarily DNS and IDNA2008 standards and DNS registry operational practices. See the link above for additional background and applicable areas of expertise. If you are interested, please send a short email message to iab-chair@iab.org with a copy to execd@iab.org with your motivation and information concerning your familiarity with the IETF and ICANN. The deadline for volunteering is March 16, 2018. Thanks, Ted Hardie for the IAB --001a113dd464414b9705665d8d39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= div>

Greetings,

As part of the= ir work on the deployment of IDNs in the root zone, ICANN plans to convene a techn= ical study group on the application of root zone label generation rules .=C2=A0 They have the asked the IAB to assist in the nomination of experts= =20 to this panel, and the IAB has agreed.=C2=A0 We are therefore seeking=20 community volunteers to assist with this work. =C2=A0

The tech= nical experts are expected=20 to be familiar with the technical standards and the issues relevant to these ICANN act= ivities, primarily DNS and=20 IDNA2008 standards and DNS registry operational practices. See the link=20 above for additional background and applicable areas of expertise.

If you = are interested, please send a short email=20 message to iab-chair= @iab.org with a copy to execd@iab.org with your=20 motivation and information concerning your familiarity with the IETF and ICANN.=C2=A0 Th= e deadline for volunteering is March 16, 2018.

Tha= nks,

Ted Hardie
for the IAB
=

--001a113dd464414b9705665d8d39-- From nobody Mon Mar 5 06:18:29 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59DD612D96C for ; Mon, 5 Mar 2018 06:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXP7CIvqquIk for ; Mon, 5 Mar 2018 06:18:20 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 317AE12DA6F for ; Mon, 5 Mar 2018 06:18:20 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1esqwV-000FJu-6U for idna-update@ietf.org; Mon, 05 Mar 2018 09:18:19 -0500 Date: Mon, 05 Mar 2018 09:18:13 -0500 From: John C Klensin To: idna-update@ietf.org Message-ID: <0AAE384126E73857E6EEC32C@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [Idna-update] FWD: Expiration impending: X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 14:18:28 -0000 Hi. Given that there has been no discussion of this draft in the last few months, that there seems to be no interest in it in the IESG (although we have not pressed hard on it specifically), and that the possibly-complementary draft-freytag-troublesome-characters draft has already expired, I'm just going to let this expire unless someone gives me a good reason why not in the next few minutes (if a revision is not posted today, the draft will expire because, without special permission, nothing can be posted between tomorrow and the start of IETF). I hope no one interprets this as complete lack of interest in pursuing IDN issues, or even clarification of the IDNA standards, in the IETF. john ---------- Forwarded Message ---------- Date: Monday, March 5, 2018 04:42 -0800 From: IETF Secretariat To: draft-klensin-idna-rfc5891bis@ietf.org Cc: ben@nostrum.com, adam@nostrum.com, aamelnikov@fastmail.fm Subject: Expiration impending: The following draft will expire soon: Name: draft-klensin-idna-rfc5891bis Title: Internationalized Domain Names in Applications (IDNA): Registry Restrictions and Recommendations State: AD is watching Expires: 2018-03-16 (in 1=C2=A0week, 3=C2=A0days) ---------- End Forwarded Message ---------- From nobody Mon Mar 5 11:15:36 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDAFF12DA6B for ; Mon, 5 Mar 2018 11:15:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcQ7RlwTg4u3 for ; Mon, 5 Mar 2018 11:15:33 -0800 (PST) Received: from smtp01.icann.org (smtp01.icann.org [192.0.46.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BEC312DA69 for ; Mon, 5 Mar 2018 11:15:33 -0800 (PST) Received: from KIDA-6861.local (unknown [10.32.60.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp01.icann.org (Postfix) with ESMTPS id 69F8BE0469; Mon, 5 Mar 2018 19:15:32 +0000 (UTC) Date: Mon, 5 Mar 2018 11:15:29 -0800 From: Kim Davies To: John C Klensin Cc: idna-update@ietf.org Message-ID: <20180305191527.GA99731@KIDA-6861.local> References: <0AAE384126E73857E6EEC32C@PSB> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0AAE384126E73857E6EEC32C@PSB> User-Agent: Mutt/1.9.3 (2018-01-21) Archived-At: Subject: Re: [Idna-update] [Ext] FWD: Expiration impending: X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 19:15:35 -0000 Quoting John C Klensin on Monday March 05, 2018: > > Given that there has been no discussion of this draft in the > last few months, that there seems to be no interest in it in the > IESG (although we have not pressed hard on it specifically), and > that the possibly-complementary > draft-freytag-troublesome-characters draft has already expired, > I'm just going to let this expire unless someone gives me a good > reason why not in the next few minutes (if a revision is not > posted today, the draft will expire because, without special > permission, nothing can be posted between tomorrow and the start > of IETF). > > I hope no one interprets this as complete lack of interest in > pursuing IDN issues, or even clarification of the IDNA > standards, in the IETF. With the expiry of these efforts, I am concerned more generally that the standing IAB guidance in https://www.iab.org/documents/correspondence-reports-documents/2015-2/iab-statement-on-identifiers-and-unicode-7-0-0/ has kept the pre-computed IDNA tables published at IANA downgraded to Unicode 6.3.0 for a number of years. It seems appropriate to revisit publishing tables against contemporary Unicode editions if there is no active work on publishing clarifying RFCs in this regard. kim From nobody Mon Mar 5 11:38:51 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC8B212E8D3 for ; Mon, 5 Mar 2018 11:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4SiBKt2JS1z for ; Mon, 5 Mar 2018 11:38:35 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEAC312D7F6 for ; Mon, 5 Mar 2018 11:38:29 -0800 (PST) Received: from [192.168.10.145] (c-8cb1d954.028-114-73746f27.cust.bredbandsbolaget.se [84.217.177.140]) by mail.frobbit.se (Postfix) with ESMTPSA id 1063C26BAC; Mon, 5 Mar 2018 20:38:26 +0100 (CET) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "Kim Davies" Cc: "John C Klensin" , idna-update@ietf.org Date: Mon, 05 Mar 2018 20:38:26 +0100 X-Mailer: MailMate (2.0BETAr6104) Message-ID: <822FD6FA-4FA5-449D-9491-01315DB57A9E@frobbit.se> In-Reply-To: <20180305191527.GA99731@KIDA-6861.local> References: <0AAE384126E73857E6EEC32C@PSB> <20180305191527.GA99731@KIDA-6861.local> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_97D28139-A4E1-4906-BF0E-578325A2B324_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [Idna-update] [Ext] FWD: Expiration impending: X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 19:38:41 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_97D28139-A4E1-4906-BF0E-578325A2B324_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 5 Mar 2018, at 20:15, Kim Davies wrote: > Quoting John C Klensin on Monday March 05, 2018: > >> Given that there has been no discussion of this draft in the >> last few months, that there seems to be no interest in it in the >> IESG (although we have not pressed hard on it specifically), and >> that the possibly-complementary >> draft-freytag-troublesome-characters draft has already expired, >> I'm just going to let this expire unless someone gives me a good >> reason why not in the next few minutes (if a revision is not >> posted today, the draft will expire because, without special >> permission, nothing can be posted between tomorrow and the start >> of IETF). >> >> I hope no one interprets this as complete lack of interest in >> pursuing IDN issues, or even clarification of the IDNA >> standards, in the IETF. > > > With the expiry of these efforts, I am concerned more generally that th= e standing IAB guidance in > https://www.iab.org/documents/correspondence-reports-documents/2015-2/i= ab-statement-on-identifiers-and-unicode-7-0-0/ > has kept the pre-computed IDNA tables published at IANA downgraded to U= nicode 6.3.0 for a number of years. It seems appropriate to revisit publi= shing tables against contemporary Unicode editions if there is no active = work on publishing clarifying RFCs in this regard. Speaking as the by IAB appointed expert that do approve new tables, I sim= ply can not unless there are some guidance and agreement in the IETF on h= ow to move forward. The few people involved that spend time on these issues makes it hard to = draw conclusions on "the right path forward". This given the situation we= are in, as described by John. Patrik --=_MailMate_97D28139-A4E1-4906-BF0E-578325A2B324_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iG0EARECAC0WIQRUH/cJI8i4DDUU3qWsxpsaC4jXzQUCWp2csg8ccGFmQGZyb2Ji aXQuc2UACgkQrMabGguI1800SQCggZBbXPP0EsJADI9OgtEy4jd+gk0An0ubH423 B7m5vnIzLEqKMcJn1Dwk =PI77 -----END PGP SIGNATURE----- --=_MailMate_97D28139-A4E1-4906-BF0E-578325A2B324_=-- From nobody Mon Mar 5 12:03:28 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B322A1205D3 for ; Mon, 5 Mar 2018 12:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=jMpp98Kl; dkim=pass (1024-bit key) header.d=yitter.info header.b=JS29S1Dd Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMgG-TXgALOO for ; Mon, 5 Mar 2018 12:03:14 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 966A812EAA5 for ; Mon, 5 Mar 2018 12:03:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id D7A60BE778; Mon, 5 Mar 2018 20:02:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1520280159; bh=bpbrqc/YnvnuFAm+zw2bq2Y8QkXCEbzJEXitqwXPNHY=; h=From:To:CC:Date:In-Reply-To:References:Subject:From; b=jMpp98KleLvq1hXlp5ebGZ9sVG49VSKD936Q71Irs9hsjfi7Zn4YEEfRc2NIg77ar mMNuSWlmEPskKJKKO3F/CHCCgGOLqhnkENuCa102et1LlpE1n55a6d8yy1eeyP04F9 c4t51L3r5ON0HdJGpGzwRFMVFIOZpfMEXaoQGIyI= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3j5EzXOLSd5y; Mon, 5 Mar 2018 20:02:38 +0000 (UTC) From: Andrew Sullivan DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1520280158; bh=bpbrqc/YnvnuFAm+zw2bq2Y8QkXCEbzJEXitqwXPNHY=; h=From:To:CC:Date:In-Reply-To:References:Subject:From; b=JS29S1DdR84XQV22lo76UAobmgekNGFxXcToldcKCoWwhyb6aumDqOfaI2/c0BsSF WQLINf4TTt8nKCs5QazwPsBwHRfX63rtxds1lF6+Y9CIpqtwVkX/2SwIbNUr1rj8R7 D/iP32OE2eNnGmHjFEmZeRhb/Ccb91l77uY/ptCA= To: =?utf-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= , Kim Davies CC: John C Klensin , Date: Mon, 05 Mar 2018 15:02:36 -0500 Message-ID: <161f7c23760.2772.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com> In-Reply-To: <822FD6FA-4FA5-449D-9491-01315DB57A9E@frobbit.se> References: <0AAE384126E73857E6EEC32C@PSB> <20180305191527.GA99731@KIDA-6861.local> <822FD6FA-4FA5-449D-9491-01315DB57A9E@frobbit.se> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8" Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Idna-update] [Ext] FWD: Expiration impending: X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 20:03:18 -0000 Does the IAB know that, and have an opinion? A -- Please excuse my clumbsy thums ---------- On March 5, 2018 14:38:48 Patrik Fältström wrote: > On 5 Mar 2018, at 20:15, Kim Davies wrote: > >> Quoting John C Klensin on Monday March 05, 2018: >> >>> Given that there has been no discussion of this draft in the >>> last few months, that there seems to be no interest in it in the >>> IESG (although we have not pressed hard on it specifically), and >>> that the possibly-complementary >>> draft-freytag-troublesome-characters draft has already expired, >>> I'm just going to let this expire unless someone gives me a good >>> reason why not in the next few minutes (if a revision is not >>> posted today, the draft will expire because, without special >>> permission, nothing can be posted between tomorrow and the start >>> of IETF). >>> >>> I hope no one interprets this as complete lack of interest in >>> pursuing IDN issues, or even clarification of the IDNA >>> standards, in the IETF. >> >> >> With the expiry of these efforts, I am concerned more generally that the >> standing IAB guidance in >> https://www.iab.org/documents/correspondence-reports-documents/2015-2/iab-statement-on-identifiers-and-unicode-7-0-0/ >> has kept the pre-computed IDNA tables published at IANA downgraded to >> Unicode 6.3.0 for a number of years. It seems appropriate to revisit >> publishing tables against contemporary Unicode editions if there is no >> active work on publishing clarifying RFCs in this regard. > > Speaking as the by IAB appointed expert that do approve new tables, I > simply can not unless there are some guidance and agreement in the IETF on > how to move forward. > > The few people involved that spend time on these issues makes it hard to > draw conclusions on "the right path forward". This given the situation we > are in, as described by John. > > Patrik > > > > ---------- > _______________________________________________ > IDNA-UPDATE mailing list > IDNA-UPDATE@ietf.org > https://www.ietf.org/mailman/listinfo/idna-update > From nobody Mon Mar 5 12:09:23 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC3912E8B1 for ; Mon, 5 Mar 2018 12:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yT9NbSToDSpX for ; Mon, 5 Mar 2018 12:09:14 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E185312DB71 for ; Mon, 5 Mar 2018 12:09:11 -0800 (PST) Received: from [192.168.10.145] (c-8cb1d954.028-114-73746f27.cust.bredbandsbolaget.se [84.217.177.140]) by mail.frobbit.se (Postfix) with ESMTPSA id AD1651FE80; Mon, 5 Mar 2018 21:09:08 +0100 (CET) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "Andrew Sullivan" Cc: "Kim Davies" , "John C Klensin" , idna-update@ietf.org Date: Mon, 05 Mar 2018 21:09:08 +0100 X-Mailer: MailMate (2.0BETAr6104) Message-ID: <9BA1DCD7-F981-461A-9D4B-EF5B0E6A8FEE@frobbit.se> In-Reply-To: <161f7c23760.2772.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com> References: <0AAE384126E73857E6EEC32C@PSB> <20180305191527.GA99731@KIDA-6861.local> <822FD6FA-4FA5-449D-9491-01315DB57A9E@frobbit.se> <161f7c23760.2772.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_7602E980-9FBA-43FA-9233-7241CDC628E8_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [Idna-update] [Ext] FWD: Expiration impending: X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 20:09:21 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_7602E980-9FBA-43FA-9233-7241CDC628E8_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I hope they know, at least I have the view I have reported we have a stal= l. I have not heard any opinion part from more architectural questions an= d ideas on "what should we do in general as this is a hard question". Whi= ch is not answering this specific question. Patrik On 5 Mar 2018, at 21:02, Andrew Sullivan wrote: > Does the IAB know that, and have an opinion? > > A > > -- = > Please excuse my clumbsy thums > > > > ---------- > On March 5, 2018 14:38:48 Patrik F=C3=A4ltstr=C3=B6m w= rote: > >> On 5 Mar 2018, at 20:15, Kim Davies wrote: >> >>> Quoting John C Klensin on Monday March 05, 2018: >>> >>>> Given that there has been no discussion of this draft in the >>>> last few months, that there seems to be no interest in it in the >>>> IESG (although we have not pressed hard on it specifically), and >>>> that the possibly-complementary >>>> draft-freytag-troublesome-characters draft has already expired, >>>> I'm just going to let this expire unless someone gives me a good >>>> reason why not in the next few minutes (if a revision is not >>>> posted today, the draft will expire because, without special >>>> permission, nothing can be posted between tomorrow and the start >>>> of IETF). >>>> >>>> I hope no one interprets this as complete lack of interest in >>>> pursuing IDN issues, or even clarification of the IDNA >>>> standards, in the IETF. >>> >>> >>> With the expiry of these efforts, I am concerned more generally that = the standing IAB guidance in >>> https://www.iab.org/documents/correspondence-reports-documents/2015-2= /iab-statement-on-identifiers-and-unicode-7-0-0/ >>> has kept the pre-computed IDNA tables published at IANA downgraded to= Unicode 6.3.0 for a number of years. It seems appropriate to revisit pub= lishing tables against contemporary Unicode editions if there is no activ= e work on publishing clarifying RFCs in this regard. >> >> Speaking as the by IAB appointed expert that do approve new tables, I = simply can not unless there are some guidance and agreement in the IETF o= n how to move forward. >> >> The few people involved that spend time on these issues makes it hard = to draw conclusions on "the right path forward". This given the situation= we are in, as described by John. >> >> Patrik >> >> >> >> ---------- >> _______________________________________________ >> IDNA-UPDATE mailing list >> IDNA-UPDATE@ietf.org >> https://www.ietf.org/mailman/listinfo/idna-update >> > > > _______________________________________________ > IDNA-UPDATE mailing list > IDNA-UPDATE@ietf.org > https://www.ietf.org/mailman/listinfo/idna-update --=_MailMate_7602E980-9FBA-43FA-9233-7241CDC628E8_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iG0EARECAC0WIQRUH/cJI8i4DDUU3qWsxpsaC4jXzQUCWp2j5A8ccGFmQGZyb2Ji aXQuc2UACgkQrMabGguI183IUwCgibzkhCckrodBTC21Ca90umXAKPIAni3B0Cq6 A9EoVEs0mqFnkSMQYqAE =yoGu -----END PGP SIGNATURE----- --=_MailMate_7602E980-9FBA-43FA-9233-7241CDC628E8_=-- From nobody Mon Mar 5 12:22:38 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D6B127419 for ; Mon, 5 Mar 2018 12:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHdeVF1HVbOg for ; Mon, 5 Mar 2018 12:22:32 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2487212DA6D for ; Mon, 5 Mar 2018 12:22:25 -0800 (PST) Received: from [192.168.10.145] (c-8cb1d954.028-114-73746f27.cust.bredbandsbolaget.se [84.217.177.140]) by mail.frobbit.se (Postfix) with ESMTPSA id D8B6C284A3; Mon, 5 Mar 2018 21:22:21 +0100 (CET) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "Andrew Sullivan" Cc: "Kim Davies" , "John C Klensin" , idna-update@ietf.org Date: Mon, 05 Mar 2018 21:22:22 +0100 X-Mailer: MailMate (2.0BETAr6104) Message-ID: <9A04CF8C-DF86-4562-8AC0-21EF0FF539FF@frobbit.se> In-Reply-To: <161f7c23760.2772.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com> References: <0AAE384126E73857E6EEC32C@PSB> <20180305191527.GA99731@KIDA-6861.local> <822FD6FA-4FA5-449D-9491-01315DB57A9E@frobbit.se> <161f7c23760.2772.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_99AAD35F-9AF3-4563-8EEF-887ED72B0611_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [Idna-update] [Ext] FWD: Expiration impending: X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 20:22:35 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_99AAD35F-9AF3-4563-8EEF-887ED72B0611_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I did send the question, and gave choices, to IAB on July 9 2014. Message-Id: <93768164-79F7-443D-8A7F-0411661B6EF9@frobbit.se> Since then the question has been stalled waiting for consensus on how to = move forward. Patrik On 5 Mar 2018, at 21:02, Andrew Sullivan wrote: > Does the IAB know that, and have an opinion? > > A > > -- = > Please excuse my clumbsy thums > > > > ---------- > On March 5, 2018 14:38:48 Patrik F=C3=A4ltstr=C3=B6m w= rote: > >> On 5 Mar 2018, at 20:15, Kim Davies wrote: >> >>> Quoting John C Klensin on Monday March 05, 2018: >>> >>>> Given that there has been no discussion of this draft in the >>>> last few months, that there seems to be no interest in it in the >>>> IESG (although we have not pressed hard on it specifically), and >>>> that the possibly-complementary >>>> draft-freytag-troublesome-characters draft has already expired, >>>> I'm just going to let this expire unless someone gives me a good >>>> reason why not in the next few minutes (if a revision is not >>>> posted today, the draft will expire because, without special >>>> permission, nothing can be posted between tomorrow and the start >>>> of IETF). >>>> >>>> I hope no one interprets this as complete lack of interest in >>>> pursuing IDN issues, or even clarification of the IDNA >>>> standards, in the IETF. >>> >>> >>> With the expiry of these efforts, I am concerned more generally that = the standing IAB guidance in >>> https://www.iab.org/documents/correspondence-reports-documents/2015-2= /iab-statement-on-identifiers-and-unicode-7-0-0/ >>> has kept the pre-computed IDNA tables published at IANA downgraded to= Unicode 6.3.0 for a number of years. It seems appropriate to revisit pub= lishing tables against contemporary Unicode editions if there is no activ= e work on publishing clarifying RFCs in this regard. >> >> Speaking as the by IAB appointed expert that do approve new tables, I = simply can not unless there are some guidance and agreement in the IETF o= n how to move forward. >> >> The few people involved that spend time on these issues makes it hard = to draw conclusions on "the right path forward". This given the situation= we are in, as described by John. >> >> Patrik >> >> >> >> ---------- >> _______________________________________________ >> IDNA-UPDATE mailing list >> IDNA-UPDATE@ietf.org >> https://www.ietf.org/mailman/listinfo/idna-update >> --=_MailMate_99AAD35F-9AF3-4563-8EEF-887ED72B0611_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iG0EARECAC0WIQRUH/cJI8i4DDUU3qWsxpsaC4jXzQUCWp2m/g8ccGFmQGZyb2Ji aXQuc2UACgkQrMabGguI182TTQCeMvJXuZNpnM/CYjzjbHpd8JA1HY8An1HBlW0r /FXpsYKCTH5/ezCcSRWy =BUYk -----END PGP SIGNATURE----- --=_MailMate_99AAD35F-9AF3-4563-8EEF-887ED72B0611_=-- From nobody Mon Mar 5 12:40:31 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99244126D85 for ; Mon, 5 Mar 2018 12:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wb2lPBo3QYHv for ; Mon, 5 Mar 2018 12:40:26 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B4C5124B18 for ; Mon, 5 Mar 2018 12:40:26 -0800 (PST) Received: (qmail 79128 invoked from network); 5 Mar 2018 20:40:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=13515.5a9dab39.k1803; bh=yBqrq78RHy1L6UvP3MHKvTnKr8fjJqheGsbgiQm92+A=; b=FhQnCDnDsE212GcC4tl+/8Gp+arS42AXF9TA+dr2iaE+VtKHQvoPffAMHM6dW0meR9WvjZrAt68o5BOaMxCteuYII2OpRP72uglxf2QD+Ac3IRJDt0HxO9WQ5bnFGgWUorT8/3EpKJAWB3ysT4CJQi94ZaClcn6MANryckFJxHki5c9M1P3K5Csa3fz0001Vrmw/mTKwb13BrlVis879R1Iu/ju8VxX1mVZJAm0nK3DvEZ+KLRIgdIhYiq5NgJlK Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 05 Mar 2018 20:40:25 -0000 Date: 5 Mar 2018 15:40:24 -0500 Message-ID: From: "John R. Levine" To: "=?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?=" Cc: idna-update@ietf.org In-Reply-To: <822FD6FA-4FA5-449D-9491-01315DB57A9E@frobbit.se> References: <0AAE384126E73857E6EEC32C@PSB> <20180305191527.GA99731@KIDA-6861.local> <822FD6FA-4FA5-449D-9491-01315DB57A9E@frobbit.se> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-739887416-1520282425=:69202" Archived-At: Subject: Re: [Idna-update] [Ext] FWD: Expiration impending: X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 20:40:30 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-739887416-1520282425=:69202 Content-Type: text/plain; format=flowed; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Mon, 5 Mar 2018, Patrik Fältström wrote: > The few people involved that spend time on these issues makes it hard to draw conclusions on "the right path forward". This given the situation we are in, as described by John. I am certainly interested in this stuff, but the only language I speak fluently is English so my knowledge of the topic is largely theoretical, a problem that I'd guess a lot of IETFers have. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly --0-739887416-1520282425=:69202-- From nobody Mon Mar 5 13:23:58 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E56EE124B17 for ; Mon, 5 Mar 2018 13:23:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8T87xm4DkE1X for ; Mon, 5 Mar 2018 13:23:54 -0800 (PST) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 895C11204DA for ; Mon, 5 Mar 2018 13:23:54 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id r16so22127141qtm.4 for ; Mon, 05 Mar 2018 13:23:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=1Lua9uRdvJEPDvy/XFJv49MuqQZ2oeo8q/2vxyps470=; b=dyFeaBOH4yNW1ekeos+ASRjuzFK8bv1VgMfW/hixAYL5DroU+meiYjf77672FYoAxH UlfbA0qHH518Uz5zFVVoEW4A+1gCn9Fpq3ZMaZ4hSskIbvLjN87Nm+2d5i8yhsYv9HVY R2uU+ranOBBsUuC644FHBv2soMq68qHc9SvvS8yi69c49WgYUFykzmYU1nxvig6s4bui 3qLqFgrhdTYLtSH8iRuworQk8PrhYmLWZUQfOOjui8as7iJA6ibUvEREaA6jyQ2QTQkL AzE5ACNdzvNJ3zlKje8ewwjoov3ymJo2VGvR6eZfijM3Zq8NV9JXdxTHqfu75hd5SymD GOjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=1Lua9uRdvJEPDvy/XFJv49MuqQZ2oeo8q/2vxyps470=; b=IHGwVQj5ViCBags2AOM4tFAIv0cA5wr4GzVdnjhXdYr40cv8Xnl4nJ/bCZ6taK+f9T Ptb5Njc0nC4stsvkB05oimn7z+0IB5d/K13gXz5vIi+lULn/gowTkvbiXI2tEPJNquv6 ra89l2MVlSVvYr6F72xJbuihwfBcMYjJpxjOda4OemipWmLYKnYZb9vOZ7lM8JFhzcZX k0UuCxIv8XXvnjpnS/Bjpc6YuQCILu7+VBvCcH7ndGev/WJYhwAS4SNK3GkyZKyJ/D+Z wfkpbl957FZRBGnPzHWZqB09jR+FgrdGowpwBWNozmTZJkYc93ee7Hs1uGujSWekwP7A j5Xg== X-Gm-Message-State: AElRT7FQfvczeuC3t6nqAaxC/bh/Ev9NGdoj6Swk7gxX8tiwq3WnD5kk +JcVcDIIzOA+VdC2tlBxec4= X-Google-Smtp-Source: AG47ELveyG9/G8Y7wIJw46qqly/vha2neSiC0b6fI+LIYx3+TUHTJCoklSBXf1FfaMiL5/7+d9xEZw== X-Received: by 10.200.50.251 with SMTP id a56mr25036812qtb.13.1520285033624; Mon, 05 Mar 2018 13:23:53 -0800 (PST) Received: from ?IPv6:2601:181:c381:c20:248f:5283:7528:5f8b? ([2601:181:c381:c20:248f:5283:7528:5f8b]) by smtp.gmail.com with ESMTPSA id y62sm8720543qkb.80.2018.03.05.13.23.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Mar 2018 13:23:52 -0800 (PST) From: Suzanne Woolf Message-Id: <7BE50D38-969D-422A-AF0F-C58B442472FE@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4ECB21D0-DFD5-491D-8ECD-3E4BD69B54ED" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 5 Mar 2018 16:23:51 -0500 In-Reply-To: <9A04CF8C-DF86-4562-8AC0-21EF0FF539FF@frobbit.se> Cc: Andrew Sullivan , John C Klensin , idna-update@ietf.org, Kim Davies To: =?utf-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= References: <0AAE384126E73857E6EEC32C@PSB> <20180305191527.GA99731@KIDA-6861.local> <822FD6FA-4FA5-449D-9491-01315DB57A9E@frobbit.se> <161f7c23760.2772.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com> <9A04CF8C-DF86-4562-8AC0-21EF0FF539FF@frobbit.se> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Idna-update] [Ext] FWD: Expiration impending: X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 21:23:57 -0000 --Apple-Mail=_4ECB21D0-DFD5-491D-8ECD-3E4BD69B54ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Patrik, That was before my time on the IAB, sorry. But as it happens, I=E2=80=99m looking at an update to the IAB = statement, so have been pondering this very question. Do you think that = https://www.ietf.org/id/draft-klensin-idna-5892upd-unicode70-05.txt = = covers the options reasonably well?=20 Thanks, Suzanne ("member of, not speaking for, the IAB") > On Mar 5, 2018, at 3:22 PM, Patrik F=C3=A4ltstr=C3=B6m = wrote: >=20 > I did send the question, and gave choices, to IAB on July 9 2014. >=20 > Message-Id: <93768164-79F7-443D-8A7F-0411661B6EF9@frobbit.se> >=20 > Since then the question has been stalled waiting for consensus on how = to move forward. >=20 > Patrik >=20 > On 5 Mar 2018, at 21:02, Andrew Sullivan wrote: >=20 >> Does the IAB know that, and have an opinion? >>=20 >> A >>=20 >> --=20 >> Please excuse my clumbsy thums >>=20 >>=20 >>=20 >> ---------- >> On March 5, 2018 14:38:48 Patrik F=C3=A4ltstr=C3=B6m = wrote: >>=20 >>> On 5 Mar 2018, at 20:15, Kim Davies wrote: >>>=20 >>>> Quoting John C Klensin on Monday March 05, 2018: >>>>=20 >>>>> Given that there has been no discussion of this draft in the >>>>> last few months, that there seems to be no interest in it in the >>>>> IESG (although we have not pressed hard on it specifically), and >>>>> that the possibly-complementary >>>>> draft-freytag-troublesome-characters draft has already expired, >>>>> I'm just going to let this expire unless someone gives me a good >>>>> reason why not in the next few minutes (if a revision is not >>>>> posted today, the draft will expire because, without special >>>>> permission, nothing can be posted between tomorrow and the start >>>>> of IETF). >>>>>=20 >>>>> I hope no one interprets this as complete lack of interest in >>>>> pursuing IDN issues, or even clarification of the IDNA >>>>> standards, in the IETF. >>>>=20 >>>>=20 >>>> With the expiry of these efforts, I am concerned more generally = that the standing IAB guidance in >>>> = https://www.iab.org/documents/correspondence-reports-documents/2015-2/iab-= statement-on-identifiers-and-unicode-7-0-0/ >>>> has kept the pre-computed IDNA tables published at IANA downgraded = to Unicode 6.3.0 for a number of years. It seems appropriate to revisit = publishing tables against contemporary Unicode editions if there is no = active work on publishing clarifying RFCs in this regard. >>>=20 >>> Speaking as the by IAB appointed expert that do approve new tables, = I simply can not unless there are some guidance and agreement in the = IETF on how to move forward. >>>=20 >>> The few people involved that spend time on these issues makes it = hard to draw conclusions on "the right path forward". This given the = situation we are in, as described by John. >>>=20 >>> Patrik >>>=20 >>>=20 >>>=20 >>> ---------- >>> _______________________________________________ >>> IDNA-UPDATE mailing list >>> IDNA-UPDATE@ietf.org >>> https://www.ietf.org/mailman/listinfo/idna-update >>>=20 > _______________________________________________ > IDNA-UPDATE mailing list > IDNA-UPDATE@ietf.org > https://www.ietf.org/mailman/listinfo/idna-update --Apple-Mail=_4ECB21D0-DFD5-491D-8ECD-3E4BD69B54ED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Patrik,

That was before my time on the IAB, sorry.

But as it happens, I=E2=80= =99m looking at an update to the IAB statement, so have been pondering = this very question. Do you think that https://www.ietf.org/id/draft-klensin-idna-5892upd-unicode70-05= .txt covers the options reasonably well? 


Thanks,
Suzanne
("member of, not speaking for, the IAB")

On Mar 5, 2018, at 3:22 PM, Patrik F=C3=A4ltstr=C3=B6m <paf@frobbit.se> = wrote:

I did send the question, and gave choices, to IAB on July 9 = 2014.

Message-Id: <93768164-79F7-443D-8A7F-0411661B6EF9@frobbit.se>

Since then the question has been stalled = waiting for consensus on how to move forward.

  Patrik

On 5 Mar = 2018, at 21:02, Andrew Sullivan wrote:

Does the IAB know that, = and have an opinion?

A

--
Please excuse my clumbsy thums



----------
On March 5, 2018 14:38:48 Patrik F=C3=A4ltstr=C3=B6m <paf@frobbit.se> = wrote:

On 5 Mar 2018, at 20:15, Kim Davies wrote:

Quoting John C Klensin = on Monday March 05, 2018:

Given that there has been no discussion of this = draft in the
last few months, that there seems to be no = interest in it in the
IESG (although we have not pressed = hard on it specifically), and
that the = possibly-complementary
draft-freytag-troublesome-characters = draft has already expired,
I'm just going to let this = expire unless someone gives me a good
reason why not in = the next few minutes (if a revision is not
posted today, = the draft will expire because, without special
permission, = nothing can be posted between tomorrow and the start
of = IETF).

I hope no one interprets this as = complete lack of interest in
pursuing IDN issues, or even = clarification of the IDNA
standards, in the IETF.


With the expiry of = these efforts, I am concerned more generally that the standing IAB = guidance in
https://www.iab.org/documents/correspondence-reports-documents/= 2015-2/iab-statement-on-identifiers-and-unicode-7-0-0/
has kept the pre-computed IDNA tables published at IANA = downgraded to Unicode 6.3.0 for a number of years. It seems appropriate = to revisit publishing tables against contemporary Unicode editions if = there is no active work on publishing clarifying RFCs in this regard.

Speaking as the by IAB appointed = expert that do approve new tables, I simply can not unless there are = some guidance and agreement in the IETF on how to move forward.

The few people involved that spend time on = these issues makes it hard to draw conclusions on "the right path = forward". This given the situation we are in, as described by John.

  Patrik



----------
_______________________________________________
IDNA-UPDATE mailing list
IDNA-UPDATE@ietf.org
https://www.ietf.org/mailman/listinfo/idna-update

_____________________________________= __________
IDNA-UPDATE mailing list
IDNA-UPDATE@ietf.org
https://www.ietf.org/mailman/listinfo/idna-update

= --Apple-Mail=_4ECB21D0-DFD5-491D-8ECD-3E4BD69B54ED-- From nobody Mon Mar 5 13:26:44 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 600BF1204DA for ; Mon, 5 Mar 2018 13:26:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=UxkRSSgE; dkim=pass (1024-bit key) header.d=yitter.info header.b=TQnaYWkn Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POvdu8EfyVgO for ; Mon, 5 Mar 2018 13:26:42 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F58A124B17 for ; Mon, 5 Mar 2018 13:26:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 77E6ABE777 for ; Mon, 5 Mar 2018 21:26:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1520285171; bh=VUjEBy3HLp6zP+ozyNKwer7X3bXJCNUahyZCle7Q5ng=; h=Date:From:To:Subject:References:In-Reply-To:From; b=UxkRSSgExx4cUM10Zx6SvxvVf2z57CX+TM+y6BI2gw/UmMaOt37wq9i9db2KNI9Q0 GNjcfs6Jlrzsna/H88KX5VSJKnIeZ2bhgcI+3ytyw3WAwCy/VCIAf020ZVKDtrTjxM cdLhgyHE2aIEEW+Bm32Gt7yZak99xQgqq1O7gXH4= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImMtH4G-0pG3 for ; Mon, 5 Mar 2018 21:26:10 +0000 (UTC) Date: Mon, 5 Mar 2018 16:26:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1520285170; bh=VUjEBy3HLp6zP+ozyNKwer7X3bXJCNUahyZCle7Q5ng=; h=Date:From:To:Subject:References:In-Reply-To:From; b=TQnaYWknFhCBNaR4ZvyQcOj5+zfdtfiXcdfccy9yCaDDm8Qqavj9KTojNM0zhxcar fETLpvEVejS8BlmXoHybGc8K7J8eZarCmbnO0wiJfc1X4YqMrnW5AoriTtapi3CFaX UF0uLzNZCE+4zN0JHgDV90I0v1kMHarzVMGoaHJ8= From: Andrew Sullivan To: idna-update@ietf.org Message-ID: <20180305212608.bj4gdtuj3kefzvae@mx4.yitter.info> References: <0AAE384126E73857E6EEC32C@PSB> <20180305191527.GA99731@KIDA-6861.local> <822FD6FA-4FA5-449D-9491-01315DB57A9E@frobbit.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Idna-update] [Ext] FWD: Expiration impending: X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 21:26:43 -0000 On Mon, Mar 05, 2018 at 03:40:24PM -0500, John R. Levine wrote: > > I am certainly interested in this stuff, but the only language I speak > fluently is English so my knowledge of the topic is largely theoretical, a > problem that I'd guess a lot of IETFers have. The problem is worse than that, in that the problem for speakers whose first or only language is _not_ English is also largely theoretical. Writing sytems are way harder than one might think from being familiar with any of them. One important input to the IAB might be an observation by IANA that it thinks it needs more guidance given the state of affairs. I wish I had any evidence that there were any good answers here. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Mar 5 14:12:32 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102D512E8EC for ; Mon, 5 Mar 2018 14:12:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ix.netcom.com; domainkeys=pass (2048-bit key) header.from=asmusf@ix.netcom.com header.d=ix.netcom.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6u03Ri7O325 for ; Mon, 5 Mar 2018 14:12:26 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C2FE12EA76 for ; Mon, 5 Mar 2018 14:12:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ix.netcom.com; s=dk12062016; t=1520287946; bh=jAxFP5VZ1Z4Hw5WmthHLlo4AsKH3WG1AQ1Yd vYf61iM=; h=Received:Subject:To:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Content-Language:X-ELNK-Trace: X-Originating-IP; b=JHPE4jXyzOh+Du71vR62Sfb9K3pUNj8et28Fa0lOqq/VDf 3Ge/T7nAut7c2058mQGsYmq0b+Lghnb6jb9l9AidetTVPbY5C35ISxeCjf8h4OW+RAJ skOTh7fm2o+Sjni4Ec0xtJIQU+g33ZgdjbccjC2+bcd3JByCyn1SekCR9vxD06gPV53 lJRXeMtKAR3RLribnSQ2XsBguiPqEGRuubXWyBAt0lR9rbEbRiCBH6GuaL1VcZpaAO2 D3e8NrTMqLlUjTO3dOyV4KC7zo1jaHy7c/U1f9OZ1XPZBUnp0xda6JcbkGAJ2t87xMO 818MbjA+E3kDx+6k2lGbd3jHqvZw== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=ix.netcom.com; b=A+aynFkvTNYmPhzR0Tk6HqPMrhNhRSz0CbfpCzzV9F2d+dkM85MO7CGdxshGXKDN3qkdHT9IcbV4aSAk5CUdxjJdCYVG14WBMST5TeDGOOFfADs6xSBcy7hYeg6IaHNyXbF49XZeGqBs73YWMDhaHpDBZjoCAFtXBTpNnKhTc2gxXa3FAZ6dGHy1yX5wRAcU+UgJP2zOLC3kY/h0H6lf12lfdpJMXUCN32LS+owWMnrY89L5VTldsDeIe0rLVa7j8jiZI4ZBCAEtGR8zjEKXiVn1k5bjQp4B+aNl2Z/BX6cTtGnBqXEURZ07OKZOBfLMmxatUeqnydDnAbz2Bzx2Iw==; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [71.35.186.204] (helo=[192.168.0.5]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1esyLI-000Ek1-5r for idna-update@ietf.org; Mon, 05 Mar 2018 17:12:24 -0500 To: idna-update@ietf.org References: <0AAE384126E73857E6EEC32C@PSB> <20180305191527.GA99731@KIDA-6861.local> From: Asmus Freytag Message-ID: <7909391c-8311-9550-0e66-f877280df058@ix.netcom.com> Date: Mon, 5 Mar 2018 14:12:24 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180305191527.GA99731@KIDA-6861.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-ELNK-Trace: 464f085de979d7246f36dc87813833b2c1627926350bb93f351e8eaba47257ae272af7d4eaf34f1c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.35.186.204 Archived-At: Subject: Re: [Idna-update] [Ext] FWD: Expiration impending: X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 22:12:32 -0000 The emerging conclusion after a lot of back-and-forth among people with deep and very deep expertise in this area was the that the issue that caused the stall wasn't really new; that there are, sprinkled through the writing systems, a number of cases of characters of identical appearance that are not covered by normalization (with and without involving combining marks); that some of these cannot be easily mitigated by simple repertoire restrictions; and that, ultimately, there is a need to do additional due diligence at the registry policy level (or LGR level). In many cases, using the variant mechanism (blocked variants) would be the appropriate remedy - but this is a tool not available to the IANA review. In any case, there is little benefit in keeping the IANA tables stuck at Unicode 6.3.0 -- the number of pre-existing cases (going as far back as the earliest Unicode version covered by IDNA2008) definitely exceeds the expected incremental addition from pending versions of Unicode. And a comprehensive solution lies outside the methodology of property-based inclusion; however, the property-based IANA tables would make a solid base on which to implement additional mitigation. Therefore, the rationale to maintain this process in a stalled state is tenuous at best. What is needed is for someone to summarize the state of the discussion and give a public signal that updating the IANA tables is not causing irreparable harm and can therefore move forward. Secondary to that is finding a way to communicate the to consumers of these tables that simply allowing all PVALID code points isn't a robust solution for many writing systems and additional due diligence needs to be preformed - for example along the same lines as is being done now for the Root Zone (which is quickly defining the state of the art in that respect). A./ On 3/5/2018 11:15 AM, Kim Davies wrote: > Quoting John C Klensin on Monday March 05, 2018: >> Given that there has been no discussion of this draft in the >> last few months, that there seems to be no interest in it in the >> IESG (although we have not pressed hard on it specifically), and >> that the possibly-complementary >> draft-freytag-troublesome-characters draft has already expired, >> I'm just going to let this expire unless someone gives me a good >> reason why not in the next few minutes (if a revision is not >> posted today, the draft will expire because, without special >> permission, nothing can be posted between tomorrow and the start >> of IETF). >> >> I hope no one interprets this as complete lack of interest in >> pursuing IDN issues, or even clarification of the IDNA >> standards, in the IETF. > With the expiry of these efforts, I am concerned more generally that > the standing IAB guidance in > https://www.iab.org/documents/correspondence-reports-documents/2015-2/iab-statement-on-identifiers-and-unicode-7-0-0/ > has kept the pre-computed IDNA tables published at IANA downgraded > to Unicode 6.3.0 for a number of years. It seems appropriate to revisit > publishing tables against contemporary Unicode editions if there is no > active work on publishing clarifying RFCs in this regard. > > kim > > _______________________________________________ > IDNA-UPDATE mailing list > IDNA-UPDATE@ietf.org > https://www.ietf.org/mailman/listinfo/idna-update > From nobody Mon Mar 5 14:22:32 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE5F126DD9 for ; Mon, 5 Mar 2018 14:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vF6JleIMskyF for ; Mon, 5 Mar 2018 14:22:29 -0800 (PST) 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 ietfa.amsl.com (Postfix) with ESMTPS id AAEC4126DC2 for ; Mon, 5 Mar 2018 14:22:29 -0800 (PST) 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 Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 5 Mar 2018 14:22:27 -0800 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; Mon, 5 Mar 2018 14:22:27 -0800 From: Francisco Arias To: "idna-update@ietf.org" Thread-Topic: [Idna-update] FWD: Expiration impending: Thread-Index: AQHTtNBx9CxAKIMD2U6V+1Z2uLNpDw== Date: Mon, 5 Mar 2018 22:22:26 +0000 Message-ID: <091044BC-5FE8-4050-911F-DACB83A4DDD4@icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.a.0.180210 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Idna-update] FWD: Expiration impending: X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 22:22:31 -0000 Rm9sbG93aW5nIG9uIEFzbXVzJyBjb21tZW50IGJlbG93LCBwZXJoYXBzIHRoZSBJRE4gSW1wbGVt ZW50YXRpb24gR3VpZGVsaW5lcyBjb3VsZCBoZWxwIGFzIGEgd2F5IHRvIHJlYWNoIG91dCB0byBU TEQgcmVnaXN0cmllcz8NCg0KaHR0cHM6Ly93d3cuaWNhbm4ub3JnL3Jlc291cmNlcy9wYWdlcy9p bXBsZW1lbnRhdGlvbi1ndWlkZWxpbmVzLTIwMTItMDItMjUtZW4NCg0KSSBiZWxpZXZlIHRoZSBw cm9jZXNzIHRvIHVwZGF0ZSB0aGVtIGlzIG9uZ29pbmcgaHR0cHM6Ly9jb21tdW5pdHkuaWNhbm4u b3JnL2Rpc3BsYXkvSUROL0lETitJbXBsZW1lbnRhdGlvbitHdWlkZWxpbmVzDQoNClJlZ2FyZHMs DQoNCi0tIA0KRnJhbmNpc2NvDQoNCu+7v09uIDMvNS8xOCwgMjoxMiBQTSwgIklETkEtVVBEQVRF IG9uIGJlaGFsZiBvZiBBc211cyBGcmV5dGFnIiA8aWRuYS11cGRhdGUtYm91bmNlc0BpZXRmLm9y ZyBvbiBiZWhhbGYgb2YgYXNtdXNmQGl4Lm5ldGNvbS5jb20+IHdyb3RlOg0KDQogICAgU2Vjb25k YXJ5IHRvIHRoYXQgaXMgZmluZGluZyBhIHdheSB0byBjb21tdW5pY2F0ZSB0aGUgdG8gY29uc3Vt ZXJzIG9mIA0KICAgIHRoZXNlIHRhYmxlcyB0aGF0IHNpbXBseSBhbGxvd2luZyBhbGwgUFZBTElE IGNvZGUgcG9pbnRzIGlzbid0IGEgcm9idXN0IA0KICAgIHNvbHV0aW9uIGZvciBtYW55IHdyaXRp bmcgc3lzdGVtcyBhbmQgYWRkaXRpb25hbCBkdWUgZGlsaWdlbmNlIG5lZWRzIHRvIA0KICAgIGJl IHByZWZvcm1lZCAtIGZvciBleGFtcGxlIGFsb25nIHRoZSBzYW1lIGxpbmVzIGFzIGlzIGJlaW5n IGRvbmUgbm93IGZvciANCiAgICB0aGUgUm9vdCBab25lICh3aGljaCBpcyBxdWlja2x5IGRlZmlu aW5nIHRoZSBzdGF0ZSBvZiB0aGUgYXJ0IGluIHRoYXQgDQogICAgcmVzcGVjdCkuDQoNCg0K From nobody Mon Mar 5 15:26:25 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6789C126DEE for ; Mon, 5 Mar 2018 15:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eknNo0MQYiYO for ; Mon, 5 Mar 2018 15:26:21 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20AB8120227 for ; Mon, 5 Mar 2018 15:26:21 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1eszUb-000Gk7-Gm; Mon, 05 Mar 2018 18:26:05 -0500 Date: Mon, 05 Mar 2018 18:25:59 -0500 From: John C Klensin To: Suzanne Woolf , Kim Davies cc: Andrew Sullivan , =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= , idna-update@ietf.org Message-ID: In-Reply-To: <7BE50D38-969D-422A-AF0F-C58B442472FE@gmail.com> References: <0AAE384126E73857E6EEC32C@PSB> <20180305191527.GA99731@KIDA-6861.local> <822FD6FA-4FA5-449D-9491-01315DB57A9E@frobbit.se> <161f7c23760.2772.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com> <9A04CF8C-DF86-4562-8AC0-21EF0FF539FF@frobbit.se> <7BE50D38-969D-422A-AF0F-C58B442472FE@gmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Idna-update] [Ext] FWD: Expiration impending: X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 23:26:23 -0000 --On Monday, March 5, 2018 16:23 -0500 Suzanne Woolf wrote: > Patrik, > > That was before my time on the IAB, sorry. > > But as it happens, I'm looking at an update to the IAB > statement, so have been pondering this very question. Do you > think that > https://www.ietf.org/id/draft-klensin-idna-5892upd-unicode70-0 > 5.txt > covers the options reasonably well? Suzanne, Patrik may have a different answer, but, as the author of that document, let me provide two opinions: (1) No. There is a newer version that covers more of the issues and has a better discussion of options, but I have no intention of posting it before there is a plan about how the document will be processed. I believe I told the IAB that while Andrew was still Chair and told the late and lamented IAB I18N Program that while Andrew was still chairing it. I do have some ideas about how it, and some other relevant documents might be processed, but, until there is evidence that someone in "the leadership" is interested, it has seemed to me that trying to write those things down (or, e.g., flying to London to try to discuss the issues and possibilities) would be a waste of time My amusement level is decreasing rapidly about the IAB's going off and discussing issues like this internally without making any attempt to involve members of the community who have actual expertise and a history of doing most of the work. In recent months, I've been reminded by four well-known colleagues (two of them former IAB Chairs) that the IAB got itself into a situation in the early 1990s in which the community concluded that it had gotten out of touch, thought its opinions were sufficient onto themselves, and that wasn't interested in listening to experts in the community who were not on the IAB. Whether that characterization was accurate or not and whatever one things of the outcomes of the changes that followed, the results clearly did not go well for the IAB or much of its then-membership. (2) As much to Kim as to you... Although the IAB statement was based on a limited understanding of only part of the problem, the underlying problems, as described in the unposted draft-klensin-idna-5892upd-unicode70-06.txt and, to a considerable degree, in the expired but available draft-klensin-idna-5892upd-unicode70-05.txt, are unchanged. Given some of the behavior being exhibited by selected TLD registries (I note from recent news that one of them is not only selling names that are invalid under IDNA2008 (and that would remain invalid if the tables were updated to Unicode 10.0 without changes being made to the Standard itself) but that their record-keep systems are weak enough that they managed to sell the same invalid strings multiple times and had to withdraw the sales and that they are apparently also running a futures market in such names using graphemes that are expected to be assigned as code points in Unicode 11 and 12. There is another issue with Unicode 7 onward as far as domain names are concerned. Most, if not all, of the scripts that are used for contemporary, widely-used, languages that are well-represented on the Internet were coded long before now. As a result, most of the characters added in Unicode 7 and later fall into one of three categories: (i) Scripts that are less well-known in the Internet community and which therefore carry even greater risk of "surprises" (including but certainly not limited to, confusion with other code points, issues with combining characters and what normalization does or does not do, and special rendering issues) if used in domain names. Andrew's comment about this being hard apply much more strongly to such scripts than to better-known ones. (ii) Letter- or digit-like characters added to existing scripts. These potentially raise all of the issues listed above but, if added to replace or supplement characters or character sequences that are in use already, the may raise issues similar to the relationship between Traditional and Simplified Chinese. (iii) Characters (or, more precisely code points) that would not qualify for use in domain name labels because of the properties Unicode assigned to them. That list includes emoji (because they are symbols) but is definitely not limited to them. Now, there are constituencies within ICANN would would like all of those characters added and to start selling them. But it would be irresponsible (at best) on the IETF's part (or that of ICANN) to encourage such things. john From nobody Mon Mar 5 19:34:42 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B380412EA81 for ; Mon, 5 Mar 2018 19:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ix.netcom.com; domainkeys=pass (2048-bit key) header.from=asmusf@ix.netcom.com header.d=ix.netcom.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWjbd6moRTTG for ; Mon, 5 Mar 2018 19:34:25 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F308212E87F for ; Mon, 5 Mar 2018 19:34:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ix.netcom.com; s=dk12062016; t=1520307265; bh=wyGkRUsIRCMC7ZwEdu8LYK9ZLMFng5J4dkl+ 7uzzeec=; h=Received:Subject:To:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Content-Language:X-ELNK-Trace: X-Originating-IP; b=EqJbJEYwvbwdqQVnbrk0TzhWeP2lz1iZGAo01n8v4ZWCVx Ik6A/gdZKDYvvetlCSxENnQm7EqvtpV9gSguMuubTrxSeMpE2W4pD3M1S2Ic3M16MBa 4WQRnGi9TQfO8ez40YYyKqgm9MiloYxGlUxGDM12sXlgT6iuie92nV8BTkwVDSG/fPV KzzjghL2es9k5D69SY/5EszIoqLZOLEuTWWbHZfNQiyhwvoOcTC0wNVdnuSJhfh1R+N AtaXcppNVHQTF9sXPr0rJdUnztvZ5xedKbBqJCjaNAsldvhV2ks5HG/DlErlRqmbbm7 SRpOIYRpr+n/9dzy/S5FhjU6fk8Q== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=ix.netcom.com; b=XTS/MjR5Yy7kUmqJFqKBc0r8jLFfR+zW3An/5KQTTQN646+ysjcHIWcHOSjpFSKcQH/1/amtvdFSas16Yj3eDqsaU5fwEwebUQ9oE+51n9lo8jMwCZRLCTZwenDv6R4008CsXpM9/x1VJRhDIxfVybeLfB46uJ5fmEhzDOjojb6e0pJZLiPue1mUj49Uzj0que9GWppWiPVtWNeLn8ti3bUJ0TNy4CB1ZPkza0mQpKY7FeXyz3fwB/h1NJ7LihiZlkAaQFCmVyZo+fy2+qdQBGWGR6ev1rT2I0fJZetx8wbNreih75z9qeCb3sHfB+jly4B2UPdZ3ri+dvn+xFokTw==; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [71.35.186.204] (helo=[192.168.0.5]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1et3Ms-000E5X-7l; Mon, 05 Mar 2018 22:34:22 -0500 To: idna-update@ietf.org, Suzanne Woolf References: <0AAE384126E73857E6EEC32C@PSB> <20180305191527.GA99731@KIDA-6861.local> <822FD6FA-4FA5-449D-9491-01315DB57A9E@frobbit.se> <161f7c23760.2772.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com> <9A04CF8C-DF86-4562-8AC0-21EF0FF539FF@frobbit.se> <7BE50D38-969D-422A-AF0F-C58B442472FE@gmail.com> From: Asmus Freytag Message-ID: <8c3ecdc9-c885-b408-011b-29d971236858@ix.netcom.com> Date: Mon, 5 Mar 2018 19:34:22 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-ELNK-Trace: 464f085de979d7246f36dc87813833b2c1627926350bb93fc2a71e5d5f1c1e3c2c4b5281f3ca7b41350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.35.186.204 Archived-At: Subject: Re: [Idna-update] [Ext] FWD: Expiration impending: X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 03:34:32 -0000 Last summer, I spent some time doing a detailed analysis of modern scripts (the ones that the lion's share of IDNs, other than some vanity ones, will be sold in), and limited to the current approved subset (Unicode 6.3.0). This survey surfaced a considerable fraction of potentially "troublesome" characters; fundamentally not different from the one that caused the halt in updating the IDNA208 tables. This survey benefited from input beyond my own personal experience, including input and data both from Unicode experts engaged in reviewing Unicode's tables of code intentionally identical code points as well as expertise and data generated as part of ICANN's Root Zone LGR project. A draft version of the survey was made public as ID https://datatracker.ietf.org/doc/draft-freytag-troublesome-characters/ The results were discussed ad-hoc with IETF and IAB experts at various occasions and by e-mail. These discussions lead to some conclusions. The following points are worth noting: (1) A small, but significant number of both *existing* code points and combining sequences exhibit the same issues as the code point that lead to the IAB recommendation to halt the update of IDNA2008 tables. This problem can be characterized as code points having identical (or near identical) appearance with the code point differences not folded by normalization. (The problem case found in 2015 only had "near identical" appearance.) (2) Objectively, halting the process did and does nothing about existing "troublesome characters". Common to all is the issue that disallowing repertoire elements is generally a poor way of mitigating the issues - mainly because doing so would arbitrarily favor letters over digits, or one language or writing system over another. The exception is that disallowing some combining marks intended for more technical purposes would prioritize regular text, and that would address a subset of these cases. All others require different mitigation approaches well within the scope of registration policies. (3) For existing scripts, the pending additions are not expected to significantly add to the existing problem. Compared to the number of existing cases, the pending additions are few, and would be addressed with the same mitigation approaches. (Pending additions are not predominantly identical to existing code points; the vast majority are added because they are, in fact, different, isolated exceptions notwithstanding). (4) For new scripts, John's observation that they are mostly not modern-use means that problems are inherently limited by several factors. Most of these scripts do not represent useful markets, as few people can read them. The exception are decorative scripts like hieroglyphics, which in turn have distinct appearance. For non-decorative ones, some may exhibit code points that are accidentally close in appearance to code points in other scripts. Whether there would be font resources to present code points in these obsolete scripts is doubtful; other attack vectors would promise easier success. (User agents flagging unusual obsolete scripts would not create many false positives.) (5) The issue of non-normalized identical appearance pales in significance compared to other issues with existing code points for modern, widely used scripts. For Chinese and Arabic, not implementing variants is arguably not state of the art; doing so allows unregulated registration of confusing labels on a large scale. For all South East Asian / Indic scripts, not implementing context rules for a good portion (about a third) of the characters for each script is not state of the art; doing so would allow labels that can't be interpreted by either layout engines or readers, as in these scripts, characters do not exist in isolation. For zones implementing multiple scripts, not blocking cross-script homoglyphs is arguably also not state of the art; doing so leads to whole-label confusables that are impossible to detect by inspection. (6) By freezing the update of IDNA2008 tables, IAB effectively declares that IDNA2008 is "stuck in the past". This incrementally increases the pressure on / temptation for various operators to unilaterally move beyond IDNA2008. If such "wild catting" can cloak itself in the moral mantle of support for some minority languages, it provides cover for those cynically selling emoji labels. (7) The only way forward is to re-synchronize the updates with the current version of Unicode (11.0 is being readied and there will be a new version every year). This must be coupled with simultaneously addressing the gaps between "PVALID" and the state of the art. (8) The ability to define blocked variants (code points that can be substituted for each other by an unsuspecting user) and to robustly exclude later registrations differing only by such a variant from an earlier registration can take care of nearly all of the troublesome characters, as well as of the problem of cross-script homoglyphs. This is currently being implemented in the Root Zone for a growing list of modern scripts (eventually 28 of them). Other zones can build on that work (for example by integrating digits and hyphen, and optionally by extending that analysis to scripts that "look alike" some modern ones). (9) The security implications of not defining context rules for the South East Asian/Indic scripts need to be publicized in a way that non-specialists can understand the need and know where to look for examples (such as the Root Zone LGRs) that successfully implement these. (While IDNA2008 provides context rules for some special code points the protocol level may not be the most appropriate place for general context rules; some rules could be made stricter/looser for zones that are limited to specific scripts/languages). (10) The security implications of emoji are not understood and need to be publicized in ways that is accessible to those that might be tempted to flout the rules to get a "cute" label. There is enormous public interest in emoji and it is spread across users of nearly all modern scripts. Given the enormous pressure driving demand for these it is frankly surprising how limited the wild catting has been up to now. The concern would be that simply pointing to an existing standard (especially one that artificially limits itself the the past - that is Unicode 6.3.0) may not prove sufficient counter; there is a chance that a clear explanation why emoji labels cannot be made secure, might give at least some users pause. (11) Finally, none of the issues discussed here exist in isolation. The next layer of the onion is "similarity" or plain "confusable" labels. In an environment where .com and .corn or apple.com and app1e.com may legitimately coexist (as far as the protocol is concerned) and where that situation is much worse in many scripts, it is simply questionable that an action as drastic as anchoring the IDNA2008 protocol at an arbitrary and (as we have seen) not problem-free point is justified or in proportion. This reality calls for a layered approach where each layer takes care of its slice of the problem: (a) The protocol takes care of all cases that can be remedied by property-based inclusion applicable to all languages, and the occasional context rule of global applicability. RFC 5891, 5892 etc. (b) The next layer out consists of some tailoring of the repertoire for each zone, but importantly, also implementing the state of the art when it comes to blocking identical variants. This would rely on the technology around LGRs and RFCs 7940 and 8228 (c) The outer layer would finally address the issue of the halo of "confusables". There's room for new technologies allowing automated string similarity scoring and review. A./ On 3/5/2018 3:25 PM, John C Klensin wrote: > > --On Monday, March 5, 2018 16:23 -0500 Suzanne Woolf > wrote: > >> Patrik, >> >> That was before my time on the IAB, sorry. >> >> But as it happens, I'm looking at an update to the IAB >> statement, so have been pondering this very question. Do you >> think that >> https://www.ietf.org/id/draft-klensin-idna-5892upd-unicode70-0 >> 5.txt >> covers the options reasonably well? > Suzanne, > > Patrik may have a different answer, but, as the author of that > document, let me provide two opinions: > > (1) No. There is a newer version that covers more of the issues > and has a better discussion of options, but I have no intention > of posting it before there is a plan about how the document will > be processed. I believe I told the IAB that while Andrew was > still Chair and told the late and lamented IAB I18N Program that > while Andrew was still chairing it. I do have some ideas about > how it, and some other relevant documents might be processed, > but, until there is evidence that someone in "the leadership" is > interested, it has seemed to me that trying to write those > things down (or, e.g., flying to London to try to discuss the > issues and possibilities) would be a waste of time > > My amusement level is decreasing rapidly about the IAB's going > off and discussing issues like this internally without making > any attempt to involve members of the community who have actual > expertise and a history of doing most of the work. In recent > months, I've been reminded by four well-known colleagues (two of > them former IAB Chairs) that the IAB got itself into a situation > in the early 1990s in which the community concluded that it had > gotten out of touch, thought its opinions were sufficient onto > themselves, and that wasn't interested in listening to experts > in the community who were not on the IAB. Whether that > characterization was accurate or not and whatever one things of > the outcomes of the changes that followed, the results clearly > did not go well for the IAB or much of its then-membership. > > (2) As much to Kim as to you... Although the IAB statement was > based on a limited understanding of only part of the problem, > the underlying problems, as described in the unposted > draft-klensin-idna-5892upd-unicode70-06.txt and, to a > considerable degree, in the expired but available > draft-klensin-idna-5892upd-unicode70-05.txt, are unchanged. > Given some of the behavior being exhibited by selected TLD > registries (I note from recent news that one of them is not only > selling names that are invalid under IDNA2008 (and that would > remain invalid if the tables were updated to Unicode 10.0 > without changes being made to the Standard itself) but that > their record-keep systems are weak enough that they managed to > sell the same invalid strings multiple times and had to withdraw > the sales and that they are apparently also running a futures > market in such names using graphemes that are expected to be > assigned as code points in Unicode 11 and 12. > > There is another issue with Unicode 7 onward as far as domain > names are concerned. Most, if not all, of the scripts that are > used for contemporary, widely-used, languages that are > well-represented on the Internet were coded long before now. As > a result, most of the characters added in Unicode 7 and later > fall into one of three categories: > > (i) Scripts that are less well-known in the Internet community > and which therefore carry even greater risk of "surprises" > (including but certainly not limited to, confusion with other > code points, issues with combining characters and what > normalization does or does not do, and special rendering issues) > if used in domain names. Andrew's comment about this being > hard apply much more strongly to such scripts than to > better-known ones. > > (ii) Letter- or digit-like characters added to existing scripts. > These potentially raise all of the issues listed above but, if > added to replace or supplement characters or character sequences > that are in use already, the may raise issues similar to the > relationship between Traditional and Simplified Chinese. > > (iii) Characters (or, more precisely code points) that would not > qualify for use in domain name labels because of the properties > Unicode assigned to them. That list includes emoji (because > they are symbols) but is definitely not limited to them. > > Now, there are constituencies within ICANN would would like all > of those characters added and to start selling them. But it > would be irresponsible (at best) on the IETF's part (or that of > ICANN) to encourage such things. > > john > > _______________________________________________ > IDNA-UPDATE mailing list > IDNA-UPDATE@ietf.org > https://www.ietf.org/mailman/listinfo/idna-update > From nobody Mon Mar 5 19:57:16 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E610B12E8A4 for ; Mon, 5 Mar 2018 19:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=apJsvGiu; dkim=pass (1024-bit key) header.d=yitter.info header.b=B/J7etU2 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Pn0txp1lOJO for ; Mon, 5 Mar 2018 19:57:13 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FC7012E034 for ; Mon, 5 Mar 2018 19:57:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id A5339BE780 for ; Tue, 6 Mar 2018 03:56:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1520308602; bh=U3xXFgxpyfdBte2cJBCzXwOWNvOtIAI/aV9fWiCLZeY=; h=Date:From:To:Subject:References:In-Reply-To:From; b=apJsvGiuqkQj+aWHuL2rok6L/YN09e2hAug/73/sMe6hqZRp0nJl2kqa2qtu36hlB xGIGPNj3XYXkuzNyx2dzbTUAy12Lzeb4infvf5sahJzUdYxBrty+JKSeITNufVN7pz AmtiTcJZ4K6Td/XPQnPgh5CBaVTAmpWhGTMGlw2E= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4A6_IGjFHuXx for ; Tue, 6 Mar 2018 03:56:41 +0000 (UTC) Date: Mon, 5 Mar 2018 22:56:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1520308600; bh=U3xXFgxpyfdBte2cJBCzXwOWNvOtIAI/aV9fWiCLZeY=; h=Date:From:To:Subject:References:In-Reply-To:From; b=B/J7etU29gWNiCBWG9OieIvyfQu3AJU/Zaxa2xhd6LXEq5D/CuJr4K4QKGVNqgPUS 0+sH7seEkDoTmdw6EEdiOugVF2eFsXCFJ6j9xdZJYvahq5waHuDHnazh1+0m5qJFwi djq+a8RhWiP+xqykyctJ7tAspqF1phuMJwIjPeaI= From: Andrew Sullivan To: idna-update@ietf.org Message-ID: <20180306035638.asghcr5zawsyp55o@mx4.yitter.info> References: <0AAE384126E73857E6EEC32C@PSB> <20180305191527.GA99731@KIDA-6861.local> <822FD6FA-4FA5-449D-9491-01315DB57A9E@frobbit.se> <161f7c23760.2772.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com> <9A04CF8C-DF86-4562-8AC0-21EF0FF539FF@frobbit.se> <7BE50D38-969D-422A-AF0F-C58B442472FE@gmail.com> <8c3ecdc9-c885-b408-011b-29d971236858@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8c3ecdc9-c885-b408-011b-29d971236858@ix.netcom.com> Archived-At: Subject: Re: [Idna-update] [Ext] FWD: Expiration impending: X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 03:57:15 -0000 Hi, Having failed to hold up my end of the log on this work, I guess I should say something here. Also, I was on the IAB for some of this and lead on the i18n program(s) during some of it, so I should take some blame. On Mon, Mar 05, 2018 at 07:34:22PM -0800, Asmus Freytag wrote: > (1) A small, but significant number of both *existing* code points and > combining sequences exhibit the same issues as the code point that lead to > the IAB recommendation to halt the update of IDNA2008 tables. Yes. Note the IAB couldn't actually halt anything (Asmus didn't suggest we at the time did, but I want to make that clear). What the IAB did was ask IANA not to do more updates until there was some consensus. > (2) Objectively, halting the process did and does nothing about existing > "troublesome characters". Sure, but I don't think anyone thought it did. I think the idea was that the IAB observed a problem that it believed had been solved by IDNA2008, but which had not been. That problem remains unsolved. > repertoire elements is generally a poor way of mitigating the issues - > mainly because doing so would arbitrarily favor letters over digits, or one > language or writing system over another. I am not sure I am prepared to concede that such limitations is "generally poor", since in fact general arbitrary limitations are what we have in the "host name" or "LDH" rules, historically. STD13 is at some pains to point that out, so I don't think it is controversial. The problem is when that arbitrariness rubs up against both commercial and political realities. > require different mitigation approaches well within the scope of > registration policies. But registration policies are not uniform and can't be assured. This is how the "DNS is distributed" and "everyone should be safe" principles come into conflict. > (6) By freezing the update of IDNA2008 tables, IAB effectively declares that > IDNA2008 is "stuck in the past". This incrementally increases the pressure > on / temptation for various operators to unilaterally move beyond IDNA2008. > If such "wild catting" can cloak itself in the moral mantle of support for > some minority languages, it provides cover for those cynically selling emoji > labels. Worse, of course, IDNA2003 provides no principled reason _not_ to add emojis, and I think this argument from Asmus is an important (and too-overlooked) point. Even if IDNA2008 draws the line imperfectly, the identifier/non-identifier code point line is _way clearer_ in it than in IDNA2003. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Mar 5 22:04:36 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155B5124217 for ; Mon, 5 Mar 2018 22:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KBQSfdViN2r for ; Mon, 5 Mar 2018 22:04:33 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81C41124B0A for ; Mon, 5 Mar 2018 22:04:33 -0800 (PST) Received: from [192.168.10.145] (c-8cb1d954.028-114-73746f27.cust.bredbandsbolaget.se [84.217.177.140]) by mail.frobbit.se (Postfix) with ESMTPSA id CCAD323547; Tue, 6 Mar 2018 07:04:29 +0100 (CET) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "Andrew Sullivan" Cc: idna-update@ietf.org Date: Tue, 06 Mar 2018 07:04:28 +0100 X-Mailer: MailMate (2.0BETAr6104) Message-ID: <1F607648-64F7-4684-88C3-965B19058065@frobbit.se> In-Reply-To: <20180305212608.bj4gdtuj3kefzvae@mx4.yitter.info> References: <0AAE384126E73857E6EEC32C@PSB> <20180305191527.GA99731@KIDA-6861.local> <822FD6FA-4FA5-449D-9491-01315DB57A9E@frobbit.se> <20180305212608.bj4gdtuj3kefzvae@mx4.yitter.info> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_00D4A02D-C9DD-4D86-BB04-18A19304C61C_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [Idna-update] [Ext] FWD: Expiration impending: X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 06:04:35 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_00D4A02D-C9DD-4D86-BB04-18A19304C61C_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 5 Mar 2018, at 22:26, Andrew Sullivan wrote: > On Mon, Mar 05, 2018 at 03:40:24PM -0500, John R. Levine wrote: >> >> I am certainly interested in this stuff, but the only language I speak= >> fluently is English so my knowledge of the topic is largely theoretica= l, a >> problem that I'd guess a lot of IETFers have. > > The problem is worse than that, in that the problem for speakers whose = first or only language is _not_ English is also largely theoretical. > Writing sytems are way harder than one might think from being familiar = with any of them. > > One important input to the IAB might be an observation by IANA that it = thinks it needs more guidance given the state of affairs. Exactly, and sometimes just understanding that there IS a problem might b= e very very good things to understand. So for me, just because one know o= ne language only, and it is english, one might still suit in a group/disc= ussion like the one described. Knowing that one only know one language is= in certain cases a strength and not what everyone understands... :-) To some degree the problem collapses to: - List the number of difficult incompatible paths forward, each one in is= olation being hard - Choose one - Implement, move in that direction, execute > I wish I had any evidence that there were any good answers here. Agree. Completely agree. paf --=_MailMate_00D4A02D-C9DD-4D86-BB04-18A19304C61C_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iG0EARECAC0WIQRUH/cJI8i4DDUU3qWsxpsaC4jXzQUCWp4vbA8ccGFmQGZyb2Ji aXQuc2UACgkQrMabGguI1834YgCfUedrKhL2bPYj148nYyFJEU3jRtQAoJEmpxbH XU/iEurPgLXG+j8pBsjQ =AZEV -----END PGP SIGNATURE----- --=_MailMate_00D4A02D-C9DD-4D86-BB04-18A19304C61C_=-- From nobody Mon Mar 5 23:45:50 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE668124217 for ; Mon, 5 Mar 2018 23:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ix.netcom.com; domainkeys=pass (2048-bit key) header.from=asmusf@ix.netcom.com header.d=ix.netcom.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRbAoB3AaEvJ for ; Mon, 5 Mar 2018 23:45:43 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B998126C89 for ; Mon, 5 Mar 2018 23:45:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ix.netcom.com; s=dk12062016; t=1520322343; bh=oQUaADcVMfgf5Ps26ibe6tEHjem6yMMJ8SBn uvke6UA=; h=Received:Subject:To:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language: X-ELNK-Trace:X-Originating-IP; b=eSrJy3hL8T3nWheDy2xvA7pi9y7tL8P3k ZRIVeWHSkUhu4hXYQwMbP0R40s7Urt0UdGzTOF6ADFcqNJhblUa61dSIcUGb5A3cZkQ K+uxemFgjI51f9kJVXJ0ev2CL/IbmVVnsoum3ZMc0vxkNA8paVBYyIUP6+uWe3crhFT wz1D8Y0DnG7eoVkvU4uELrQWEttX0xXjCkyIjhpPt7MjblGcS4QlVhZjfst2lqTMhez Q2C2xBm2rEahY8Z3wdiFXabv8bbAdLaVvcCfsZSCyhbta7i/qfZR4zFvMqNVQH7YpMr mnQME2B+psXfHE9Eb6SKmKhrRmu05rRZsm6WYpWFQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=ix.netcom.com; b=d1B78cCpcAOmy+j58V7qvskjqc5DqtabZ81nZeo7AWw7XljJp0VSN7eqTAFpD6x0x+ci4bhpO3wohs1v7BBuGGSStSByVI4ssttet4SlXTJgcBgoUKyrss2tWlzni49s/hKL4DlcZuMwEQnOCqWLN94b4607myrK/PSnzo2/kQz2P/Di9sKkJiGOC36Fsvf7okuGn2rwbh2K10yNb1onYUyspvtCtRPuTCgzZgys9T7JhMql+JLc1SwmEW1lz4gGmWzTGN3iSyQToeqP3X2N6v+3hEr4/OtoZvQ1w66qUmA1JJdqg80Xa+SoHB0FswiWGEUnNy3Jia0kcVk+29O2LQ==; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [71.35.186.204] (helo=[192.168.0.5]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1et7I4-000Eua-To for idna-update@ietf.org; Tue, 06 Mar 2018 02:45:41 -0500 To: idna-update@ietf.org References: <0AAE384126E73857E6EEC32C@PSB> <20180305191527.GA99731@KIDA-6861.local> <822FD6FA-4FA5-449D-9491-01315DB57A9E@frobbit.se> <161f7c23760.2772.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com> <9A04CF8C-DF86-4562-8AC0-21EF0FF539FF@frobbit.se> <7BE50D38-969D-422A-AF0F-C58B442472FE@gmail.com> From: Asmus Freytag Message-ID: <36497509-9b33-7996-c322-efb1862d9695@ix.netcom.com> Date: Mon, 5 Mar 2018 23:45:41 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <7BE50D38-969D-422A-AF0F-C58B442472FE@gmail.com> Content-Type: multipart/alternative; boundary="------------FD139A9ED89CAC9CD63546C9" Content-Language: en-US X-ELNK-Trace: 464f085de979d7246f36dc87813833b2c1627926350bb93fae72648617988c31bbb110dbefe2e643350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.35.186.204 Archived-At: Subject: Re: [Idna-update] [Ext] FWD: Expiration impending: X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 07:45:47 -0000 This is a multi-part message in MIME format. --------------FD139A9ED89CAC9CD63546C9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 3/5/2018 1:23 PM, Suzanne Woolf wrote: > Patrik, > > That was before my time on the IAB, sorry. > > But as it happens, I’m looking at an update to the IAB statement, so > have been pondering this very question. Do you think that > https://www.ietf.org/id/draft-klensin-idna-5892upd-unicode70-05.txt covers > the options reasonably well? There is one statement here (and it's the premise of the whole affair) that is actually not 100% correct: Unicode 7.0.0 introduces the new code point U+08A1, ARABIC LETTER BEH WITH HAMZA ABOVE. As can be deduced from the name, it is/*visually identical*/ to the glyph that can be formed from a combining sequence consisting of the code point for ARABIC LETTER BEH (U+0628) and the code point for Combining Hamza Above (U+0654). (/*emphasis */added) In fact, in many (all?) fonts that do support this code point, there's a noticeable difference between the combining sequence and the precomposed character. Here is one example: similar systematic differences, although slight, obtain in many cases of combining sequences that /appear at first to be identical/ to precomposed Latin code points without being normalized: where the right side is 'o' + 0x0337   [this case has been in Unicode since IDNA2008 first started] Obviously much depends on the font, but because the entire premise rests on the *absolute identical appearance* of the sequences to the code points in question, I think we need to take a step back here. Perhaps, one difference since the time this was first raised is that the code point 08A1 is now supported in a number of fonts, which may not have been the case immediately after Unicode 7.0 was released and it may not have been apparent that the precomposed code point would be treated differently from a sequence that was so apparently made up from the same elements. To put this into perspective: there are thousands of PVALID Chinese characters for which the distinctions are equally subtle, just saying. (And no, for the most part, they are not variants of each other). Yet this didn't stop IDNA from tracking many thousands of Han additions over the years. I think the best thing for the IAB is to find a way to climb down from seeing this as an earth-shattering crisis and accepting such near similarities as unavoidable consequences of trying to implement mnemonic identifiers that are readable to the world population. The right way forward is simply not to leap to the assumption that action on the protocol level is called for for these cases, but that they are in some ways the end points of a continuum that includes cases like .com/.corn and apple.com/app1e.com. The right way forward also means that one cannot blithely assume that identifiers are always made from a small set of very distinct shapes (like most of the Latin alphabet) and to perhaps find ways to mitigate the worst cases. A./ > > > Thanks, > Suzanne > ("member of, not speaking for, the IAB") > >> On Mar 5, 2018, at 3:22 PM, Patrik Fältström > > wrote: >> >> I did send the question, and gave choices, to IAB on July 9 2014. >> >> Message-Id: <93768164-79F7-443D-8A7F-0411661B6EF9@frobbit.se >> > >> >> Since then the question has been stalled waiting for consensus on how >> to move forward. >> >>   Patrik >> >> On 5 Mar 2018, at 21:02, Andrew Sullivan wrote: >> >>> Does the IAB know that, and have an opinion? >>> >>> A >>> >>> -- >>> Please excuse my clumbsy thums >>> >>> >>> >>> ---------- >>> On March 5, 2018 14:38:48 Patrik Fältström >> > wrote: >>> >>>> On 5 Mar 2018, at 20:15, Kim Davies wrote: >>>> >>>>> Quoting John C Klensin on Monday March 05, 2018: >>>>> >>>>>> Given that there has been no discussion of this draft in the >>>>>> last few months, that there seems to be no interest in it in the >>>>>> IESG (although we have not pressed hard on it specifically), and >>>>>> that the possibly-complementary >>>>>> draft-freytag-troublesome-characters draft has already expired, >>>>>> I'm just going to let this expire unless someone gives me a good >>>>>> reason why not in the next few minutes (if a revision is not >>>>>> posted today, the draft will expire because, without special >>>>>> permission, nothing can be posted between tomorrow and the start >>>>>> of IETF). >>>>>> >>>>>> I hope no one interprets this as complete lack of interest in >>>>>> pursuing IDN issues, or even clarification of the IDNA >>>>>> standards, in the IETF. >>>>> >>>>> >>>>> With the expiry of these efforts, I am concerned more generally >>>>> that the standing IAB guidance in >>>>> https://www.iab.org/documents/correspondence-reports-documents/2015-2/iab-statement-on-identifiers-and-unicode-7-0-0/ >>>>> has kept the pre-computed IDNA tables published at IANA downgraded >>>>> to Unicode 6.3.0 for a number of years. It seems appropriate to >>>>> revisit publishing tables against contemporary Unicode editions if >>>>> there is no active work on publishing clarifying RFCs in this regard. >>>> >>>> Speaking as the by IAB appointed expert that do approve new tables, >>>> I simply can not unless there are some guidance and agreement in >>>> the IETF on how to move forward. >>>> >>>> The few people involved that spend time on these issues makes it >>>> hard to draw conclusions on "the right path forward". This given >>>> the situation we are in, as described by John. >>>> >>>>   Patrik >>>> >>>> >>>> >>>> ---------- >>>> _______________________________________________ >>>> IDNA-UPDATE mailing list >>>> IDNA-UPDATE@ietf.org >>>> https://www.ietf.org/mailman/listinfo/idna-update >>>> >> _______________________________________________ >> IDNA-UPDATE mailing list >> IDNA-UPDATE@ietf.org >> https://www.ietf.org/mailman/listinfo/idna-update > > > > _______________________________________________ > IDNA-UPDATE mailing list > IDNA-UPDATE@ietf.org > https://www.ietf.org/mailman/listinfo/idna-update --------------FD139A9ED89CAC9CD63546C9 Content-Type: multipart/related; boundary="------------5E226301CFB749F99B14B899" --------------5E226301CFB749F99B14B899 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 3/5/2018 1:23 PM, Suzanne Woolf wrote:
Patrik,

That was before my time on the IAB, sorry.

But as it happens, I’m looking at an update to the IAB statement, so have been pondering this very question. Do you think that https://www.ietf.org/id/draft-klensin-idna-5892upd-unicode70-05.txt covers the options reasonably well?

There is one statement here (and it's the premise of the whole affair) that is actually not 100% correct:

   Unicode 7.0.0 introduces the new code point U+08A1, ARABIC LETTER BEH
   WITH HAMZA ABOVE.  As can be deduced from the name, it is visually
   identical to the glyph that can be formed from a combining sequence
   consisting of the code point for ARABIC LETTER BEH (U+0628) and the
   code point for Combining Hamza Above (U+0654). 

(emphasis added)
In fact, in many (all?) fonts that do support this code point, there's a noticeable difference between the combining sequence and the precomposed character. Here is one example:



similar systematic differences, although slight, obtain in many cases of combining sequences that appear at first to be identical to precomposed Latin code points without being normalized:


where the right side is 'o' + 0x0337   [this case has been in Unicode since IDNA2008 first started]

Obviously much depends on the font, but because the entire premise rests on the absolute identical appearance of the sequences to the code points in question, I think we need to take a step back here.

Perhaps, one difference since the time this was first raised is that the code point 08A1 is now supported in a number of fonts, which may not have been the case immediately after Unicode 7.0 was released and it may not have been apparent that the precomposed code point would be treated differently from a sequence that was so apparently made up from the same elements.

To put this into perspective: there are thousands of PVALID Chinese characters for which the distinctions are equally subtle, just saying. (And no, for the most part, they are not variants of each other). Yet this didn't stop IDNA from tracking many thousands of Han additions over the years.

I think the best thing for the IAB is to find a way to climb down from seeing this as an earth-shattering crisis and accepting such near similarities as unavoidable consequences of trying to implement mnemonic identifiers that are readable to the world population.

The right way forward is simply not to leap to the assumption that action on the protocol level is called for for these cases, but that they are in some ways the end points of a continuum that includes cases like .com/.corn and apple.com/app1e.com.

The right way forward also means that one cannot blithely assume that identifiers are always made from a small set of very distinct shapes (like most of the Latin alphabet) and to perhaps find ways to mitigate the worst cases.

A./




Thanks,
Suzanne
("member of, not speaking for, the IAB")

On Mar 5, 2018, at 3:22 PM, Patrik Fältström <paf@frobbit.se> wrote:

I did send the question, and gave choices, to IAB on July 9 2014.

Message-Id: <93768164-79F7-443D-8A7F-0411661B6EF9@frobbit.se>

Since then the question has been stalled waiting for consensus on how to move forward.

  Patrik

On 5 Mar 2018, at 21:02, Andrew Sullivan wrote:

Does the IAB know that, and have an opinion?

A

--
Please excuse my clumbsy thums



----------
On March 5, 2018 14:38:48 Patrik Fältström <paf@frobbit.se> wrote:

On 5 Mar 2018, at 20:15, Kim Davies wrote:

Quoting John C Klensin on Monday March 05, 2018:

Given that there has been no discussion of this draft in the
last few months, that there seems to be no interest in it in the
IESG (although we have not pressed hard on it specifically), and
that the possibly-complementary
draft-freytag-troublesome-characters draft has already expired,
I'm just going to let this expire unless someone gives me a good
reason why not in the next few minutes (if a revision is not
posted today, the draft will expire because, without special
permission, nothing can be posted between tomorrow and the start
of IETF).

I hope no one interprets this as complete lack of interest in
pursuing IDN issues, or even clarification of the IDNA
standards, in the IETF.


With the expiry of these efforts, I am concerned more generally that the standing IAB guidance in
https://www.iab.org/documents/correspondence-reports-documents/2015-2/iab-statement-on-identifiers-and-unicode-7-0-0/
has kept the pre-computed IDNA tables published at IANA downgraded to Unicode 6.3.0 for a number of years. It seems appropriate to revisit publishing tables against contemporary Unicode editions if there is no active work on publishing clarifying RFCs in this regard.

Speaking as the by IAB appointed expert that do approve new tables, I simply can not unless there are some guidance and agreement in the IETF on how to move forward.

The few people involved that spend time on these issues makes it hard to draw conclusions on "the right path forward". This given the situation we are in, as described by John.

  Patrik



----------
_______________________________________________
IDNA-UPDATE mailing list
IDNA-UPDATE@ietf.org
https://www.ietf.org/mailman/listinfo/idna-update

_______________________________________________
IDNA-UPDATE mailing list
IDNA-UPDATE@ietf.org
https://www.ietf.org/mailman/listinfo/idna-update



_______________________________________________
IDNA-UPDATE mailing list
IDNA-UPDATE@ietf.org
https://www.ietf.org/mailman/listinfo/idna-update


--------------5E226301CFB749F99B14B899 Content-Type: image/png; name="pmecoopnijcecdfj.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="pmecoopnijcecdfj.png" iVBORw0KGgoAAAANSUhEUgAAAUcAAAAnCAIAAAATqB3SAAAJ7ElEQVR4nO1cK4O0LBQ+/4Kf YDQajUSj0Wg0+hOIRqKRaDQSiUYikWgk+gW8gLeZ3Z19d3c+nigK5/bA4cAMTAEBAe8F+GkB AgICXozA6oCAd0NgdUDAuyGwOiDg3RBYHRDwbgisDgh4NwRWBwS8GwKrAwLeDYHVAQHvhsDq fw9jflqC3wPVVVnZ6Z8W480QWP3vYLRgdR4jIOKnRfkdGLu6qElVMfXTkrwZAqv/GUatNK9j gMBqC82yKGt6qaQYdMhfXojA6n8LXgdWr9AsB4hwSbkKpH4l9qweBSVMBht/FwRxWK060vD/ 7Z7SDB0TL1mjVUcoH1/Q0V+EOWGsy2oj2wITESj9jfBYPU1G0iJrhi+a3Izj/9Zpmte4+J9v zDWvsrJT24ON1YrlKGu3prm2kzM9jYLmMQIAlFbOtDDKnpY4ypg2si0iAJSv5tW8KTBO0zRG ES5b4c2kRrIqz8uaVFkc42o302jeFHlZkyqPozivO7d1G3KaVFfhCAAgyuhgpskRM3b8/FiP uWdW50VF6hJHES6pv4Zq3hRFTQipqzwrcuzm0KNkdY7TNE0iFOd1r7x+V3VIVaQFbcp9Bq5Y HuEvEFuxHAFU/GMd6K7KcJqmaZrm9aqs5rQucJqV1qCTkawuypoQUpdZXmQl+12ZhREkiWtP 9TtPPXDVKFmVY5ymaZokedM2WUTENE2aU1JmaZqmS7Ve82Y2Hx2e6d4J21GyKp1jsPPHf0yL a0YJkiQbsWF7CkmzimiU4KxKACBrO1qQXmo1sDpFAChnepomPXDeEQwAGW1p07E6RRBZCytW FOv8oNoMwOnbCJIka0Ygabp2aRvTaJsbRk4SgOXtUQreNxkAZJRR0go1jlo0GABiwjpin6i+ SgCg6Man9LAysiLaZJpUmyN3ilItTqlcXdRXaI0VI0hGluzP8DoGQGU3bh3nCK+fGkESOO6r JcWAPkrLGUNTtmrU+jOZrKQYADKfqZJmi6sMr1yxJMXZr2K1YjlyjT3deuqBqxTLo5yuRLJz 5eYpw6udrSRN/bTrqvtRrjFIWVM2vdRadlUCntNvaXHPqEVABEuoWVYPTbLwwMHQRABR0W5z huEVAojX/gSBY1yMXYHcuLUGmTUwgsTeSEMTAyzvD03i9D53Bu6IViV3frbdp2Rb7cauBHf1 eqTH2JVop/3QxOvMMJm+9KWSlIr1PU9762o8O0CzbLeKapadVMsMr9DneG1EkyIU52WZ77dO 5vGxuDWDp/nQ5Gv0SJp4jYbTf8TqJ2S3Xot3oX3tqXtXqRaDMx1MSxBtnhJkF+k7V95Hgv3c DVvVZlvcP6DFLaOcEfEyIEyLc49BdVBkmiZBEGz6n72hWQ4oTh0k0cp9wysAN8+fnF2hlSPf zxElOOpbY3pDHoXYPXmgh2qxO4CFpfX8kaQJQFJ2hyqiIAiixNU1RttiPDTxQZ3dvtoT5zCt PobuigSXtJeHL8eufKK/oYmd0JsMr5y1b+xLBAg34sNifRHPyK5aDDsiTjeeunfV0MSHCNh5 6gGr7yNhNrQXg+5pyC0t7hnlQLNsXqpgYX55NOMZG/wp7Jwvx/FWSJpet9rpreZnT9dvXsTq TY85t/JNOj/dqtWsiAAAxXnTq9VQmmU3x1Sn6/IFqy99sHttEF68GnNZJpM02c8oZ1At9pIW f243gqQIACJcteKLy/Re9hs8IbukKexX6mmarjx17yrV7mNq+iCr7yPh7HOv/1ta3DPKxWoU uMoKTyXZCXPJ6svijSDouC56jecz0MtZvemhWX6y1503F+5TzZssAgBA6ZztapadrBd+DztL XLD6OkpdDIxdjHUCw+tniltjVyzJnGbliQBreQeir9SaXyz7qU8XHD117ypB4Nj4cVZfRsKp vG7/t7S4Z5SLdW2Aedt5ZqBTy/HaySrP3rAb/YMQSohxodBBfd338phsz20s+4YM3NHDS7b9 PmZFx3HLSkWD0aKftSLea2OEsJl9BgemXrH6cmr1vj0MdY1R0qJ+Zqe+bq5VW17lgNOkujJx 94kfxYtlt+WWo7muPHXvKuupXab0IVbfR8LZ517/t7S4Z5SHZZSHa/WuYWjcXf0pXyxLkso9 G1LLMqBaDN4RmNt4KI3ZMbyiyGdZfaOHVxpzh1keidYNZs2yJbznecipnU6TEaSy39l+Y6+M 9YW1WrN8N9QJzKiGjpY4Rr6N72A313le7TYAmrXcE/1QfbneAHy37Bdr9aWn7l1lPeWR0vT7 ahny92l+Dfw+Eh6x+p4W94xy4K7V9/tqb3o2vEJuRV2Qk8XVVicBAKUF7TjvaIlj9+wqAQCI spr1nPesxpF3vuAbz/AKJS4vbA3cVcgazPXmKatv9LAyuRVKSbFjYkFQ1Y/Ox9vMOTQJbOr0 rM7jNetbDJFU/SzKvOKlzbC7N/LUvlrb0xYU47JuO+6gawmpirmIYvfBH7kgaOuFh8VAs8wN dElT14jWaOiJvft3yH4xC9546tZVdmWDpLTHpbJrSOWvdZa2uBnGaZrGoW3qKgWAgqnZlbeR cEzydwc197S4ZdSJUeA4gGMiAEjzoqjannPe0QLndFn1jRo6WiQAAAjXzK/CzrdSFj+5h0rT NKlu3qjByVm8kaxKEUoL2vWMFDh37lSOsm/LBAAgKWg3KOMIkZRtPz8hGC1P5PhIjxl2KxZl Neu7tsr9yBJNXpZZ0XTz1/Otl+XLetUGUFp711dWQ6A4TdOcDj2ZKzlyl+6hZyoiZpiv0Zwj SrKSfOYW5tgVJwdrmlVlVWRVa8Msw56rbOYOybOJ9YtlH5r4JGe99dStq5w227LPqoxolheS kkmjWWYvsa+uvOh+F5KDMqPsWY3RTB0xX4J/QIs7Rs3jr3tVsAKT+ORgZVvyjJZiUB+8lmhG NfCrr24b7YBC6tdchHxaj0dCjWq4aJ3lPf/QjGpYGkd1PIT66Hm10VLwnlFCCCGU9ZzzQX3t 0qhR6npGMVoOp7qN8krlu75eJPt2jnMyyrWn7lzlOup0r+Rawih11sltJDzEfQTet6oWL7sI 927ZfrN/W2f8Q/jteqgWP53JBmxQLEefvZP3GFcVkF8Kwyu03sJc74Hv7mpO0+9nw7P43XqM XelXDj6G3Q3gP4Uvy7676ftS/C1WD03iFIK832wNDXZ/Z8BrgOOtkL+H36yHYgUmX/gVoVGs iL5vwfpWvER21ZX4OyY1Wz/7xHW/H4ARxP/d2v731ZrXFVOTbIti+U0PzoqvxN2P4nfrobq6 /pur7K+CkW3VvHLBdqIGZ0XRPn995gdgRFPua79n/4XiHOUHfCNMsPPr8H/9iflpEIV/OAoI eDcEVgcEvBsCqwMC3g2B1QEB74bA6oCAd0NgdUDAuyGwOiDg3fAfaNG9/1iHBI4AAAAASUVO RK5CYII= --------------5E226301CFB749F99B14B899 Content-Type: image/png; name="inapdillbnjhombg.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="inapdillbnjhombg.png" iVBORw0KGgoAAAANSUhEUgAAAG0AAAAfCAIAAABicNTLAAADmElEQVRoge1YLc+cQBCeP9Fs qiqRyJUrMU0QFaQK1ZAqkhp+wsqTyJVITBMkciUSuRKJRFKxH7csHwccb9o0PPI4ZnaeeWZ2 BhhvXAH42wf4T3DzeA1uHq/BzeM1uHm8BjeP1+Dm8Rp8BI8Dp2FStP0HmP5n8QaPvahYGhMf AQAA8kmcskr0fZ35ACgpX/DYlzEAAPiPZvkPzcOfPe9FlSeh9gkeJnFW8O58EC46XtAkxN7T fsrqbnj53kkeuzojKpYlYMpfux7qFK0TqZ8GTOhfmkew4hOn9ftcDi2LvWX7KHjwbVmc4XHg FEvzJGVcJWvo2ooGym1UiD12Noic0Thw6suQaC16laVBVCqfKCreY1IUkUySFz5qYexzlirB bGvjOI86IAjzdmJYhw6wp6zHcTSliyh3ndQpAADExgynCACA5K3z164IYfnJAQgmJeBn9ezc w+8fn+XDDSYP86gjdEUk84kpe8gThbv00eYEAACl9eSEunda2eBUJiit3EAFCz1MSPxoXveS Fah8Wml7Wi8TbOrbOaaFwzwqXUxplJUuy1mw0OVgA0oIUyIVjZMf+ypRakd+lBVcnCZtDi3p 2ZFFITsm/vnj03LhaBzlccmlYVEqUClnZ51p6VmcKR+uSHVQpnf4UVbUV4xXWusTloY2j5C8 Y5pBh73ahc/y+HSpC9r0DnUqWM3dFLMaVhJdun36tsxC905FfpDkb93X6sRWK9KzAYrkJaDD Xu1Wb+pRXd2hGU6ep1qdC13o+0k1pw0a9QsdL7LId2agXbPWMhw99rWcR7zYjB067NUGebg/ 1tmTJbstGrwsgRkmRKqWH9iZWXuva0qWxnpo3vXOImxxdHWKAQBwUlrW7KgXcZjHvkykSVow p6AnZzo0hijy4rJfoXFo85gQ7C1aHerMP9JJVv3Dt1/f5b0ynet1ot2ObeHE/GiNiRA4cZlp dt/YY6ACSSglVolb0OnBS4pY2iCPQc+PAPCJOMowa8eW/bf2GfAT1kz2GbVr79tnbFiBLI9M Jn0ooFVrNt5BcKYGvGlO9W23V6RGAV++WvtM1xQftc9YLheBk6I90fD1tb1ePRv7LyBCnUXk KI+b9r0wv3y/lnN2kLfTby/IJ2GSV+fHOU3k+qw7juPY8SKLifngo7yKudfjPMpTtHZQHg4T uut70nEe+5bF8eG6/d9xfw+/BjeP1+Dm8RrcPF6Dm8drcPN4Df4ATBAqgjPOKk0AAAAASUVO RK5CYII= --------------5E226301CFB749F99B14B899-- --------------FD139A9ED89CAC9CD63546C9-- From nobody Tue Mar 6 02:31:09 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A22A4126CF6 for ; Tue, 6 Mar 2018 02:31:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEwNpH54KyPa for ; Tue, 6 Mar 2018 02:31:04 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A546126FDC for ; Tue, 6 Mar 2018 02:31:03 -0800 (PST) Received: from [172.20.10.2] (unknown [IPv6:2a02:aa1:1002:1a12:2165:4e06:865b:c89e]) by mail.frobbit.se (Postfix) with ESMTPSA id 1E90022971; Tue, 6 Mar 2018 11:31:00 +0100 (CET) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "Suzanne Woolf" Cc: "Andrew Sullivan" , "John C Klensin" , idna-update@ietf.org, "Kim Davies" Date: Tue, 06 Mar 2018 11:30:58 +0100 X-Mailer: MailMate (2.0BETAr6104) Message-ID: <692038A9-6BDE-43FF-BFAE-03C9A320731D@frobbit.se> In-Reply-To: <7BE50D38-969D-422A-AF0F-C58B442472FE@gmail.com> References: <0AAE384126E73857E6EEC32C@PSB> <20180305191527.GA99731@KIDA-6861.local> <822FD6FA-4FA5-449D-9491-01315DB57A9E@frobbit.se> <161f7c23760.2772.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com> <9A04CF8C-DF86-4562-8AC0-21EF0FF539FF@frobbit.se> <7BE50D38-969D-422A-AF0F-C58B442472FE@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_8451FF48-B164-4707-89E0-B222F52DFD17_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [Idna-update] [Ext] FWD: Expiration impending: X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 10:31:08 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_8451FF48-B164-4707-89E0-B222F52DFD17_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Suzanne, others, In general I agree with the comments from John. Here is the mail I did send (scroll down to see my comments today): Forwarded message: > From: Patrik F=C3=A4ltstr=C3=B6m > To: Internet Architecture Board , i18n@iab.org, John Klens= in , Pete Resnick , Andrew Su= llivan > Subject: Fwd: PRELIMINARY APPEAL -- Re: [i18n] Exper Review - New Rele= ase of the Unicode Standard, Version 7.0.0 > Date: Wed, 9 Jul 2014 06:03:57 +0200 > > As the appointed expert for this IANA registry I reacted by pulling the= hand brake when John sent his email. > > I have also clarified with IANA what that implied, i.e. nothing more th= an that I did "revoke" my earlier decision and that they should wait for = me to give them more clear instructions. See below. > > I have myself had a discussion with John on the matter and I do underst= and his point. I have recommended him to propose something concrete in th= e form of an I-D that explain the issue and the concrete actions (which s= hould be to add a contextual rule, exceptions in the form of Disallowing = certain code points, or both) that can be discussed. Consensus on such an= I-D say what to do. > > Unfortunately we are in the quiet period of I-D due to the upcoming IET= F meeting, so the I-D might take a few weeks (I am unclear on todays rule= s). > > If IAB do want some other action, do not hesitate contacting me to disc= uss the issue. > > To summarize: > > - Unicode has released a new version, 7.0.0, of the Unicode Code Points= =2E > > - When applying the algorithm in the current RFCs of IDNA to the new ta= ble, myself and IANA did reach the same result. > > - When inspecting the set of valid and non valid code points, no proble= matic backward compatibility is found. > > - Because of this, the derived property values could be released as cal= culated. > > - BUT, what is found is that there is (at least) one new code point (U+= 08A1) added that also can be represented by two other code points (U+0628= and U+0621), but no normalization rule is added for them. Equivalence ru= les exists for other such triples, for example U+0623, U+0627 and U+0254 = (below from Unicode 7.0.0): > > 0621;ARABIC LETTER HAMZA;Lo;0;AL;;;;;N;ARABIC LETTER HAMZAH;;;; > 0623;ARABIC LETTER ALEF WITH HAMZA ABOVE;Lo;0;AL;0627 0654;;;;N;ARABIC = LETTER HAMZAH ON ALEF;;;; > 0627;ARABIC LETTER ALEF;Lo;0;AL;;;;;N;;;;; > 0654;ARABIC HAMZA ABOVE;Mn;230;NSM;;;;;N;;;;; > 08A1;ARABIC LETTER BEH WITH HAMZA ABOVE;Lo;0;AL;;;;;N;;;;; > > - Unicode consortium refer to explanation of Hamza in the "Combining Ha= mza Above" subsection, pp. 263-264 in (version 7.0.0 of this is not released yet) and in p= articular, Table 8-11. They say that U+08A1 will be added to that table e= xplicitly in the Unicode 7.0 version of the core specification. > > - Question for IETF is whether this addition of U+08A1 should result in= : > > 1. No action > > 2. Addition of U+08A1 to the list of exceptions with derived property v= alue DISALLOWED > > 3. A contextual rule implementing the so far non-existing table that ex= plains use of Hamza, which is in table 8-11 in Unicode 6.2.0. > > I am waiting for a consensus call on this, and do only see this being p= ossible by having John Klensin proposing an I-D that is explaining the si= tuation and suggesting one outcome (possibly 2). I have myself requested = to be co-author of this I-D for conformity to the set of RFCs that do des= cribe the algorithm for the derived property value. > > - In the mean time I have asked IANA to wait for me to give them furthe= r instructions. If IAB do believe some IANA action should happen already = now, please let me know. > > Patrik > > Begin forwarded message: > >> From: Patrik F=C3=A4ltstr=C3=B6m >> Subject: Re: PRELIMINARY APPEAL -- Re: [i18n] Exper Review - New Relea= se of the Unicode Standard, Version 7.0.0 >> Date: 8 juli 2014 22:54:33 CEST >> To: Pearl Liang >> Cc: Michelle Cotton >> >> You only have to send it to me. What I do is to inform IAB and i18n li= st. In this case they did pull the hand brake. Not your problem. They pul= led, and I informed you to stop the process (revoked my earlier decision)= =2E You should just wait for me (again). >> >> We might get an I-D with proposal on what to do, but we are due to the= IETF in a silent period for new drafts. :-( >> >> Patrik >> >> On 8 jul 2014, at 22:35, Pearl Liang wrote: >> >>> Further, I wonder if this "additional" review will become part of the= >>> "expert review" from now on before we can post a new unicode version.= As >>> now, I only need to send the request to Patrik for approval. >>> >>> Thanks, >>> ~pl >>> >>> >>> On 7/8/14 12:24 PM, "Michelle Cotton" wro= te: >>> >>>> Patrik, >>>> What do we need to do here? >>>> We will wait to make any changes until this is sorted out. Is that >>>> correct? Let us know. >>>> Thanks, Michelle >>>> >>>> Sent from my iPhone >>>> >>>>> On Jul 8, 2014, at 9:22 AM, "Pearl Liang" w= rote: >>>>> >>>>> Michelle, >>>>> >>>>> Cc: Patrik >>>>> >>>>> FYI, John escalated this. >>>>> >>>>> So, our main table is still with version 6.3.0. >>>>> >>>>> Thanks, >>>>> ~pl >>>>> >>>>> >>>>> >>>>> >>>>>> On 7/7/14 3:22 PM, "John C Klensin" wrote: >>>>>> >>>>>> Attention AppsADs and IANA: Please treat this as a preliminary >>>>>> appeal of Patrik's decision to allow the IANA tables to be >>>>>> updated. I will formalize that with a note to Jari if necessary >>>>>> after we have the discussion suggested below. >>>>>> >>>>>> --On Monday, July 07, 2014 20:54 +0200 Patrik F=C3=A4ltstr=C3=B6m >>>>>> wrote: >>>>>> >>>>>>> From Ken: >>>>>>>> Patrik, >>>>>>>> >>>>>>>> O.k. The hamza above is an explicit edge case, where a >>>>>>>> determination needs to be made in each instance. >>>>>>>> >>>>>>>> See the "Combining Hamza Above" subsection, pp. 263-264 in: >>>>>>>> >>>>>>>> http://www.unicode.org/versions/Unicode6.2.0/ch08.pdf >>>>>>>> >>>>>>>> and in particular, Table 8-11. U+08A1 will be added to that >>>>>>>> table explicitly in the Unicode 7.0 version of the core >>>>>>>> specification. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> --Ken >>>>>>> >>>>>>> I read Ken's response as if we already have such situations >>>>>>> for Hamza. >>>>>>> >>>>>>> If an exception is to be added, that requires RFC action. >>>>>> >>>>>> Ok. In the absence of other information, I think Ken is >>>>>> referring to something called the Normalization Stability Rule. >>>>>> To review earlier notes that none of this contradicts, part of >>>>>> that rule, as I understand it, requires that, if a new >>>>>> precomposed abstract character is added that previously could >>>>>> have been assembled with a base character and a combining one, >>>>>> NFC of the new character is required to decompose back the prior >>>>>> sequence. The other part of that rule is the one I think Mark >>>>>> refers to: if the combining sequence normalized to itself in >>>>>> version N, it cannot normalize to anything else (and, in >>>>>> particular, the new precomposed character) in version N+1. >>>>>> >>>>>> Now, let's call that second part "normalization stability", >>>>>> i.e., once a code point or sequence exists and has a >>>>>> normalization the latter doesn't change. That is elementary and >>>>>> not at issue here. And, of course, unassigned code points don't >>>>>> have normalizations (or much of any other properties) -- that >>>>>> was precisely the reason why IDNA2008 couldn't allow them to be >>>>>> processed or looked up. >>>>>> >>>>>> The first part, however, is about "keeping normalization working >>>>>> consistently". The main purpose of normalization is to allow >>>>>> different ways to represent "the same string" to compare equal >>>>>> (and collate in similar ways, etc., but that is secondary). If >>>>>> a precomposed character and a combining sequence represent the >>>>>> same abstract character and they don't both normalize to the >>>>>> same thing (same thing under NFC, same thing under NFD, even >>>>>> though those two sets of results may be different), then >>>>>> normmalization does not work consistently for its intended >>>>>> purpose, i.e., fails in that case. >>>>>> >>>>>> And there are a whole series of late-added precomposed >>>>>> characters in earlier versions of Unicode where precisely that >>>>>> "decompose the new precomposed character back to the sequence" >>>>>> rule was included in NFC, so this case is neither new nor >>>>>> theoretical. >>>>>> >>>>>> Now, I don't know what gets Ken to "edge case". No special >>>>>> treatment would be needed if the [new] precomposed character >>>>>> always looked different from the combining sequence. The choice >>>>>> of name for the precomposed character would be stupid, but that >>>>>> would be the _only_ problem. But I've checked with a couple of >>>>>> users of Arabic script and they assure me that, as far as they >>>>>> know/ can tell, the two forms will normally yield exactly the >>>>>> same printed results. We'd have an edge case if, for example, >>>>>> the considerable rendering differences between Arabic Script as >>>>>> used in Arabic language and Arabic Script as used in >>>>>> Perso-Arabic languages produced a rendering difference. Again, >>>>>> I don't even pretend to be an Arabic expert, but that would >>>>>> constitute an edge case of the "sometimes" variety and, to me, >>>>>> it would be lots safer to apply the "decompose the new >>>>>> precomposed character" rule than not. More on that below. >>>>>> >>>>>> >>>>>> --On Monday, July 07, 2014 21:21 +0200 Patrik F=C3=A4ltstr=C3=B6m >>>>>> wrote: >>>>>> >>>>>>>> Well, yes, but it also reads as though U+0654 should have >>>>>>>> required a contextual rule or something. At least, it does >>>>>>>> to me. >>>>>> >>>>>> Again, I am not an Arabic script expert and won't even pretend, >>>>>> but this seems to me to have nothing to do with contextual >>>>>> rules. We use those rules to restrict the use of characters to >>>>>> some specific script context when they might plausibly be >>>>>> applied elsewhere or look like something used elsewhere. I >>>>>> suppose we could use a contextual rule to prevent the use of a >>>>>> combining Hamza with Latin or Han script, but we tend to assume >>>>>> that things like that would look so stupid and out of place that >>>>>> no such precautions are needed. In either event, it wouldn't >>>>>> help with this case which is, as explained above, entirely about >>>>>> normalization stablility and predictability. >>>>>> >>>>>> There is a possible exception under which we could use a >>>>>> combining rule, but I think it would be bad news and a horrible >>>>>> kludge (see [1] below). >>>>>> >>>>>>> Yes, that was my point. What has happened in 7.0.0 is not a >>>>>>> new situation. It might be that we missed the Hamza when >>>>>>> discussing the contextual rule(s) and if that is the case, a >>>>>>> contextual rule is what we should add (should have added). Not >>>>>>> exception rule. >>>>>> >>>>>> It is not a new situation and it is not, as discussed above, a >>>>>> contextual rule one either. The only thing that is different is >>>>>> that UTC has decided to not apply their existing/historical >>>>>> "make normalization keep working right rule". If we do nothing >>>>>> and unless _every_ valid rendering of the new precomposed >>>>>> character will look significantly different from _every_ valid >>>>>> rendering of the combining sequence, their failure to apply that >>>>>> rule means that we could have two perfectly valid and >>>>>> identical-looking DNS labels, in the same script, etc., that do >>>>>> not compare equal. IDNA was designed to avoid that case and >>>>>> categories F (Section 2.6 of RFC 5892) and G (Section 2.7) are >>>>>> there precisely to deal with the "Unicode messed up and we need >>>>>> to apply a different rule than their properties alone would give >>>>>> us" cases. In this case, the only rules that don't cause other >>>>>> problems would be to either ban the use of the newly-added >>>>>> precomposed character(s) (I can't remember from April whether >>>>>> there is more than one) entirely or to >>>>>> ban the combining sequences. The disadvantage of the first is >>>>>> that it will cause some inconvenience going forward; of the >>>>>> second that it might make a now-valid label invalid, something >>>>>> that we promised to not do again. >>>>>> >>>>>> There is a small procedural problem, which is that Category G, >>>>>> where I think this really belongs, says "changes in property >>>>>> values" rather than "changes in property values or normalization >>>>>> screwups". To make that a little more complicated, should we >>>>>> want to pick the second options, I don't believe we have >>>>>> anywhere that we ban a particular combining sequence without >>>>>> completely banning the use of one or more of the characters that >>>>>> make it up [1]. But nothing would prevent our writing a new >>>>>> document that updates 5892 by adding this (these) new >>>>>> precomposed characters to the Category F "Disallowed" list, >>>>>> using the discussion above as a basis. >>>>>> >>>>>> If that is what we want to do, I'm willing to write the I-D. If >>>>>> not, I see no way to forestall this action other than to >>>>>> generate a formal appeal, one that would necessarily call for >>>>>> changes in the review process for these revisions and tables. >>>>>> >>>>>> regretfully, but I think the precedent here is really important. >>>>>> >>>>>> john >>>>>> >>>>>> >>>>>> >> So, where are we and what to do? I think: 1. A decision "JUST" must be made regarding 7.0.0 according to my email a= bove. Of course updated to the situation today (as John wrote) and findin= gs by others (as Asmus said) that though are just "different positions" a= nd one of the reasons I see "it is hard to find consensus". And THAT is u= ltimately what IAB must make a very very very careful decision about. 2. ICANN Board finally made a decision to be strict regarding IDNA2008, b= ut the question then ends up being "how to ensure it is implemented"? ICA= NN Board have now reached out to IAB (and a few others -- SSAC included) = and I saw IAB asked for people a few days ago. I will present the issue w= ith ccTLDs (and emojis) that John explained where ultimately who controls= a ccTLD is the hidden question. I think, if IAB *DO* believe (at least until we have something better), t= hey: A. MUST make a recommendation/decision regarding how to move forward with= IDNA2008/Unicode B. MUST take the flag and advocate with other players (W3C, ICANN etc) st= rict implementation of IDNA2008 And if IAB do not want to take this decision "just like that" because of = risks John lay out between the lines (no new Kobe) then IAB I think shoul= d discuss carefully, now with the help of ICANN, "how to move forward". M= aybe the group ICANN Board asked for might help? I do not know. But the situation is pretty serious. For many reasons. And I must say (po= sitively) that the last couple of messages in this thread lay out the iss= ue in a relative good way. Patrik On 5 Mar 2018, at 22:23, Suzanne Woolf wrote: > Patrik, > > That was before my time on the IAB, sorry. > > But as it happens, I=E2=80=99m looking at an update to the IAB statemen= t, so have been pondering this very question. Do you think that https://w= ww.ietf.org/id/draft-klensin-idna-5892upd-unicode70-05.txt covers the option= s reasonably well? > > > Thanks, > Suzanne > ("member of, not speaking for, the IAB") > >> On Mar 5, 2018, at 3:22 PM, Patrik F=C3=A4ltstr=C3=B6m wrote: >> >> I did send the question, and gave choices, to IAB on July 9 2014. >> >> Message-Id: <93768164-79F7-443D-8A7F-0411661B6EF9@frobbit.se> >> >> Since then the question has been stalled waiting for consensus on how = to move forward. >> >> Patrik >> >> On 5 Mar 2018, at 21:02, Andrew Sullivan wrote: >> >>> Does the IAB know that, and have an opinion? >>> >>> A >>> >>> -- = >>> Please excuse my clumbsy thums >>> >>> >>> >>> ---------- >>> On March 5, 2018 14:38:48 Patrik F=C3=A4ltstr=C3=B6m = wrote: >>> >>>> On 5 Mar 2018, at 20:15, Kim Davies wrote: >>>> >>>>> Quoting John C Klensin on Monday March 05, 2018: >>>>> >>>>>> Given that there has been no discussion of this draft in the >>>>>> last few months, that there seems to be no interest in it in the >>>>>> IESG (although we have not pressed hard on it specifically), and >>>>>> that the possibly-complementary >>>>>> draft-freytag-troublesome-characters draft has already expired, >>>>>> I'm just going to let this expire unless someone gives me a good >>>>>> reason why not in the next few minutes (if a revision is not >>>>>> posted today, the draft will expire because, without special >>>>>> permission, nothing can be posted between tomorrow and the start >>>>>> of IETF). >>>>>> >>>>>> I hope no one interprets this as complete lack of interest in >>>>>> pursuing IDN issues, or even clarification of the IDNA >>>>>> standards, in the IETF. >>>>> >>>>> >>>>> With the expiry of these efforts, I am concerned more generally tha= t the standing IAB guidance in >>>>> https://www.iab.org/documents/correspondence-reports-documents/2015= -2/iab-statement-on-identifiers-and-unicode-7-0-0/ >>>>> has kept the pre-computed IDNA tables published at IANA downgraded = to Unicode 6.3.0 for a number of years. It seems appropriate to revisit p= ublishing tables against contemporary Unicode editions if there is no act= ive work on publishing clarifying RFCs in this regard. >>>> >>>> Speaking as the by IAB appointed expert that do approve new tables, = I simply can not unless there are some guidance and agreement in the IETF= on how to move forward. >>>> >>>> The few people involved that spend time on these issues makes it har= d to draw conclusions on "the right path forward". This given the situati= on we are in, as described by John. >>>> >>>> Patrik >>>> >>>> >>>> >>>> ---------- >>>> _______________________________________________ >>>> IDNA-UPDATE mailing list >>>> IDNA-UPDATE@ietf.org >>>> https://www.ietf.org/mailman/listinfo/idna-update >>>> >> _______________________________________________ >> IDNA-UPDATE mailing list >> IDNA-UPDATE@ietf.org >> https://www.ietf.org/mailman/listinfo/idna-update --=_MailMate_8451FF48-B164-4707-89E0-B222F52DFD17_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iG0EARECAC0WIQRUH/cJI8i4DDUU3qWsxpsaC4jXzQUCWp5t4g8ccGFmQGZyb2Ji aXQuc2UACgkQrMabGguI182dMwCfTNqFtP6x542F6fx+JitzpioIioEAn15UbWfY w2BUxvPEPSIXrrbSQLUC =6vv2 -----END PGP SIGNATURE----- --=_MailMate_8451FF48-B164-4707-89E0-B222F52DFD17_=-- From nobody Tue Mar 6 02:31:46 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3BF127078 for ; Tue, 6 Mar 2018 02:31:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQHiarX1RDIY for ; Tue, 6 Mar 2018 02:31:43 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F29C8127137 for ; Tue, 6 Mar 2018 02:31:42 -0800 (PST) Received: from [172.20.10.2] (unknown [IPv6:2a02:aa1:1002:1a12:2165:4e06:865b:c89e]) by mail.frobbit.se (Postfix) with ESMTPSA id A30FA22AD0; Tue, 6 Mar 2018 11:31:40 +0100 (CET) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "Francisco Arias" Cc: idna-update@ietf.org Date: Tue, 06 Mar 2018 11:31:39 +0100 X-Mailer: MailMate (2.0BETAr6104) Message-ID: <0FB6F961-41C2-42EB-8713-C5B2F2CA83FD@frobbit.se> In-Reply-To: <091044BC-5FE8-4050-911F-DACB83A4DDD4@icann.org> References: <091044BC-5FE8-4050-911F-DACB83A4DDD4@icann.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_192C9D8B-4A6E-4137-A2B1-A9248F55FAE0_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [Idna-update] Expiration impending: X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 10:31:45 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_192C9D8B-4A6E-4137-A2B1-A9248F55FAE0_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable How do you believe this is to be implemented in all TLDs? I.e. what do yo= u believe is the enforcement mechanism? Patrik On 5 Mar 2018, at 23:22, Francisco Arias wrote: > Following on Asmus' comment below, perhaps the IDN Implementation Guide= lines could help as a way to reach out to TLD registries? > > https://www.icann.org/resources/pages/implementation-guidelines-2012-02= -25-en > > I believe the process to update them is ongoing https://community.icann= =2Eorg/display/IDN/IDN+Implementation+Guidelines > > Regards, > > -- = > Francisco > > =EF=BB=BFOn 3/5/18, 2:12 PM, "IDNA-UPDATE on behalf of Asmus Freytag" <= idna-update-bounces@ietf.org on behalf of asmusf@ix.netcom.com> wrote: > > Secondary to that is finding a way to communicate the to consumers = of > these tables that simply allowing all PVALID code points isn't a ro= bust > solution for many writing systems and additional due diligence need= s to > be preformed - for example along the same lines as is being done no= w for > the Root Zone (which is quickly defining the state of the art in th= at > respect). > > > _______________________________________________ > IDNA-UPDATE mailing list > IDNA-UPDATE@ietf.org > https://www.ietf.org/mailman/listinfo/idna-update --=_MailMate_192C9D8B-4A6E-4137-A2B1-A9248F55FAE0_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iG0EARECAC0WIQRUH/cJI8i4DDUU3qWsxpsaC4jXzQUCWp5uCw8ccGFmQGZyb2Ji aXQuc2UACgkQrMabGguI181G9wCfeoyK4nTKQQAlPQVmWbWp6nuq1PcAnjB7QOmf uRyD8sYaG32Lf17KDo9q =yyfd -----END PGP SIGNATURE----- --=_MailMate_192C9D8B-4A6E-4137-A2B1-A9248F55FAE0_=-- From nobody Tue Mar 6 15:06:58 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD431200FC for ; Tue, 6 Mar 2018 15:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5fI7ZxrMHd5 for ; Tue, 6 Mar 2018 15:06:51 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E2C7126C0F for ; Tue, 6 Mar 2018 15:06:51 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1etLfM-000KlZ-JU for idna-update@ietf.org; Tue, 06 Mar 2018 18:06:40 -0500 Date: Tue, 06 Mar 2018 18:06:33 -0500 From: John C Klensin To: idna-update@ietf.org Message-ID: <3CE2979FE460587F4D1FC3EE@PSB> In-Reply-To: <0FB6F961-41C2-42EB-8713-C5B2F2CA83FD@frobbit.se> References: <091044BC-5FE8-4050-911F-DACB83A4DDD4@icann.org> <0FB6F961-41C2-42EB-8713-C5B2F2CA83FD@frobbit.se> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Idna-update] Expiration impending: X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 23:06:56 -0000 Hi. I have been mostly offline after sending my note a bit before 23:30 UTC yesterday and am going to try to address several issues in one response. I'm going to try to write this quickly, so apologies if I miss something important. (1) First, I think there are a few major principles that separate IDNA2008 from IDNA2003. They are: (i) Moving away from the design of tables of permitted and not permitted code points (including some transformations expressed in the same tables) to principles about code point inclusion and exclusion expressed primarily in rules about Unicode properties. The IDNA2003 model requires revisions with every version of Unicode to stay current. The IDNA2008 model prefers a review with each new version of Unicode but, in principle (and probably in practice if we got the rules right) does not. (ii) Clarifying responsibility for the protocol to work correctly. IDNA2003 put almost all of the responsibility on the registration side of things by having only very weak checks on lookup -- in essence, if one could find the name, it was ok. That model, btw, exists in the UTR#46 and closely-related WHATWG recommendations. IDNA2008 requires lookup-time checks for at some minimal level of validity, a change that not only makes the protocol work better but that provides something of a check on abusive and/or non-conforming registration processes at all levels of the DNS tree (see below for more about that). At the same time, IDNA2008 clarifies the responsibility of registries to know what they are doing in allowing a string to be registered. draft-klensin-idna-rfc5891bis-01 essentially reinforces and restates that requirement without changing anything. It may also be helpful to remember that requirements that registries understand what they are doing and act in a responsible fashion predate IDNs, and ICANN, and even the "trustee" language of RFC 1591. Enforcement is, of course, not the IETF's problem. See below. (iii) What is normative and what is just helpful. It is important to note that it is the rules of IDNA2008 that are normative. The derived tables (including the ones in the IANA databases) are an important response to those who "just want to be told what to do" or who don't have the time and resources to do the calculations, but they are not part of the standard or, as far as that standard is concerned, particularly important. Of course, those table do not remove the obligation to be informed and careful from anyone, but it is good to be realistic, especially in the current ICANN climate. Of course, users of the standard may treat tables more authoritatively. That is fine as long as the tables for one year do not treat previously disallowed characters as PVALID or vice versa without careful explanation and documentation .. see below. (iv) Permissiveness and conservatism. Depending on how one reads IDNA2003, this may not be a difference, but, while one of the IDNA2008 design principles is to extend the LDH "preferred syntax" rules to non-ASCII characters, it is ultimately very permissive, with few restrictions other than those motivated by having the protocol work. It is about specifying things that allow reasonable parties to create mnemonic labels using characters that they understand (see (ii) above and comments below) and not about trying to guard against bad behavior except in the most problematic circumstances. In particular, there are no rules requiring that labels make linguistic sense, no rules against archaic scripts, no rules prohibiting mixed-script labels or mixing, e.g., digit types within a label, any of which rules might be reasonable for a registry to impose. (v) Finally and driven strongly by user experience and reports, IDNA2008 attempts to be sure that the round trip between a label as expressed by the user and the label as stored in the DNS is an identity relationship. The restrictions on mapping and case folding (especially the latter) have other motivations as well, but are primarily just corollaries of the U-label <-> A-label requirements. The principle implies other requirements that we haven't talked much about. One is that using a non-ASCII string in the domain context of a URI is a really bad idea (it wasn't a good idea under IDNA2003, but the issues are now more clear). Another is that names in reference or identifier contexts (including but not limited to URIs) should probably be final names (in more or less the same sense as the use of that term for MX DATA (targets)). What the user sees or can type are other matters, but implementations should be designed so that users do not enter or see one string and get an error (or other) message about some other one. IMO and in retrospect, we did not do a nearly good enough job of explaining those issues in the IDNA2008 documents; if there were energy to do the writing (there probably is) and to review (we have evidence that there is not) explanatory and clarifying materials would probably be helpful. (2) Whether the issues that we uncovered when we reviewed the changes in Unicode 7.0 were "new" or not depends on definitions and that is, IMO, not particularly important. I've been told that there were significant debates fairly early in Unicode's history about whether normalization should be restricted to a very small number of methods or whether there should be options or variations for different circumstances, the latter partially to address some of these issues. What is clear is that we not only didn't know about those cases when the design of IDNA2008 was being sorted out but that we asked explicitly about relationships going forward and got answers that persuaded us that additional rules were unnecessary and that gave us no hint (at least that we understood) that we should look more deeply into the existing cases. It is clear to me that, had we known about the situation in the 2006-2008 period, we would have attempted to include rules to deal with it in IDNA2008. That is not to claim that we would have been successful in developing such rules, but I believe the specs would have at least included stronger warnings. (3) One key principle that is shared by IDNA2003 (and Stringprep more specifically) and IDNA2008 is that the IETF has strong consensus on avoiding getting into the business of going through Unicode one code point at a time and making our own classifications on an individual code point basis. We haven't wanted to delegate that job to an individual or small expert committee, especially ones we don't know how to sustain long-term. That possibility has been examined multiple times, in multiple IETF WGs and in the IAB, and the conclusion has always been, at least AFAIK, the same. (4) ICANN's relationship to this situation require some sort of shared understanding of their role, something I'm not sure we have even today. There is general agreement that they can and should make rules for labels that can appear in the root zone and nearly as general agreement that those rules should be very, very, conservative -- much more narrow than what is allowed by IDNA2008 with regard to what code points can be used. Whether they have, or should have, authority over second-level labels that conform to IDNA2008 (or even those that don't) has been hotly debated. Even ignoring the consequences of the "distributed administrative hierarchy" principle, the empirical evidence has been that they are powerless in practice and hence that debating applicability of rules developed for the root (or even modified versions of such rules) to second level labels and below is a waste of time. There have been discussions about the importance of different rules at the second and third level (and beyond) since the earliest attempts by ICANN to define IDN policy. Those discussions (which occurred before anyone started talking seriously about IDNs in the root) included, for example, the clear understanding that labels using archaic scripts might be very useful and appropriate within the DNS trees of particular institutions or enterprises even if they were not appropriate at the second level. With the introduction of IDN TLDs and the general flattening of the DNS and the root, the same arguments may apply at the second level within an appropriately-defined TLD. (5) As implied above, I think it is important to distinguish between efforts designed to help well-intentioned people, and registries who are willing to invest resources into doing the right thing, and efforts about preventing confusion, especially confusion created by those who have either evil intentions or who don't care about the use of DNS names as identifiers. That distinction is particularly important when suggestions are made about rules to be defined on the basis of what "most fonts" do with particular code points. At least until there are changes in how generic presentation software (such as web browsers and IM programs) works -- changes to which there appears to be considerable resistance -- "most fonts" is not helpful because malicious characters can not only select their own preferred fonts but, if something like CSS is in use, they can even overlay graphemes that were never intended to be overlaid, making, among other things, concerns about normalization almost trivial. That does not mean we should give up, but it does imply, at least to me, that we need to be very careful about our expectations and promises, even if registries get smart enough to require the malicious actors to turn things up a notch. (6) Now, a few observations on some of Asmus's comments, and then I will come back to ICANN and the IANA tables at the end of this section. >... > In many cases, using the variant mechanism (blocked variants) > would be the appropriate remedy - but this is a tool not > available to the IANA review. It is also not a tool that is part of IDNA (either version), except insofar as it is part of the "registries must take responsibility for what they choose to register, including the scripts and characters involved" model. While I think identifying variants and blocking them is a useful tool (and that has been proven to be the case in some domains), the identification process itself requires considerable effort and knowledge. At least outside the root and especially if less well-known scripts are involved, it is not going to be 100% reliable except for dichotomous pairs of characters (e.g., for Simplified and Traditional Chinese) and the implications of missing a string that should be treated as a variant (particularly relative to invitations to bad actors) should be thoroughly understood and accepted (by lawyers as well as from a technical standpoint). We also have significant empirical evidence that almost every effort to define variants and then block them has rapidly led to some party who claims that they want to/ need to/ have the right to/ are entitled to have some of those variants delegated. And then often get their wishes. So, for the root where the resources to do the analyses are available and we can at least hope that a "no delegated variants" rule can hold, I think blocked variants are a fine idea. I do note however that the so-called ccTLD Fast Track apparently allowed some variants to be delegated and that "it is unfair to allow those who got in line first to get something that is now barred to us" and "we are being put at a competitive disadvantage" have often been persuasive argument to ICANN in the past. Below the top level, where such a system has to depend on registries investing significant resources to identify and block names, I think it is just unrealistic. Some registries may comply, but experience indicates that, faced with a choice of registering and delegating a name and thereby producing revenue and investing significant effort to avoid delegating such names (and therefore not making the money) in an environment in which there are no effective sanctions if they register the name(s), I am pessimistic about its being very effective. I do think that blocked variants are a useful tool, but that their being effective requires registries to be very responsible, including seeking out and blocking questionable cases. To the extent to which that behavior not only costs them money but that, in the absence of clear rules that do not require subjective judgment, might possibly subject them to litigation, I think expectations should be kept low. > In any case, there is little benefit in keeping the IANA > tables stuck at Unicode 6.3.0 -- the number of pre-existing > cases (going as far back as the earliest Unicode version > covered by IDNA2008) definitely exceeds the expected > incremental addition from pending versions of Unicode. I'd love to know how you quantify the latter going forward, especially in an environment in which the Unicode Consortium has apparently decided to treat additional characters and code points (via the "adopt a character" program) as a profit center. If one were to follow the proposed rules for the root and exclude archaic characters and other characters that would be disallowed for other (non-IDNA2008) reasons (neither of which I think you have proposed), the size of the expected incremental additions gets even smaller. > And a > comprehensive solution lies outside the methodology of > property-based inclusion; however, the property-based IANA > tables would make a solid base on which to implement > additional mitigation. > > Therefore, the rationale to maintain this process in a stalled > state is tenuous at best. Now let's return to my comment near the beginning. The IANA tables are not normative. They are published as a guideline and convenience for those who want and appreciate such things. If ICANN, as the registrar for the root zone, decided to make its own calculation of a base code point repertoire from the IDNA2008 rule set and use that repertoire as input to the LGR process for the root zone, not only is there no one to stop them, but their doing that is perfectly conformant to IDNA2008. I don't think it would even violate the IAB statement as I read it. But the purpose of that IANA table as I have understood it since we created the registry is, again, to help out the less wary, less informed and knowledgeable, and, frankly, the more lazy. The mere existence of that population is probably a sign that the IDNA2008 requirement that registries not register strings that they do not thoroughly understand (even if those strings are otherwise IDNA2008-conformant and might be acceptable if registered in a different zone) is not working well. For them, I think there has been no case made that holding off on revising the tables is a cause of significant harm.. and some argument that it just represents a very conservative list, albeit not as conservative as the list would be if similar-looking strings within the same script were identified and somehow excluded (and not as conservative as the lists that will presumably be the result of the LGR process). That is an issue with the "troublesome character" list as well. If it is taken as one person's informative catalogue of code points that even the most careful and informed of registries should be extra-careful about, I think it provides a useful service. If, as has been the case with "whatever is allowed by IDNA2003", "whatever is allowed by IDNA2008", or even "whatever is allowed by UTR#46", regardless of what those documents actually say, it is interpreted as "the IETF and/or ICANN say that anything allowed by IDAN2008 and not on this list is safe to register", then it becomes a problem... as well as colliding with the principle described in (3) above. >... > Secondary to that is finding a way to communicate the to > consumers of these tables that simply allowing all PVALID code > points isn't a robust solution for many writing systems and > additional due diligence needs to be preformed - for example > along the same lines as is being done now for the Root Zone > (which is quickly defining the state of the art in that > respect). Well, IDNA2008 says that additional due diligence is required and that registries need to do it. draft-klensin-idna-rfc5891bis-01 says it more clearly and forcefully but can't seem to get processed in the IETF (which is where this thread started). ICANN has been asked, more than once, to make some clear statements about registry responsibility and to work on a plan to enforce that principle (including a plan to have the GAC work out a plan for ccTLDs if that is required). Those suggestions are not proceeding any faster than X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0847E126DED for ; Tue, 6 Mar 2018 18:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5lhF1GgEw7O for ; Tue, 6 Mar 2018 18:06:31 -0800 (PST) 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 ietfa.amsl.com (Postfix) with ESMTPS id AE342126C22 for ; Tue, 6 Mar 2018 18:06:31 -0800 (PST) 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 Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 6 Mar 2018 18:06:30 -0800 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; Tue, 6 Mar 2018 18:06:30 -0800 From: Francisco Arias To: =?utf-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= CC: "idna-update@ietf.org" Thread-Topic: [Idna-update] Expiration impending: Thread-Index: AQHTtbjnUspdeDYi60ykI4/pYHdd+g== Date: Wed, 7 Mar 2018 02:06:29 +0000 Message-ID: <78F09330-4B36-4AC5-9AFD-DF89EE2C75BA@icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.a.0.180210 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: text/plain; charset="utf-8" Content-ID: <35FCD2A894799940871EBE89E712E5B8@pexch112.icann.org> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Idna-update] Expiration impending: X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2018 02:06:33 -0000 RXhjZXB0IGZvciBhIGNvdXBsZSBvZiBsZWdhY3kgZ1RMRHMgdGhhdCBkbyBub3QgeWV0IGhhdmUg dGhhdCByZXF1aXJlbWVudCwgZm9yIHRoZSB2YXN0IG1ham9yaXR5IG9mIHRoZSBnVExEcywgY29t cGxpYW5jZSB3aXRoIHRoZSBJRE4gSW1wbGVtZW50YXRpb24gR3VpZGVsaW5lcyBpcyBtYW5kYXRv cnkuDQoNCklmIHRoZXJlIHdlcmUgYSByZXF1aXJlbWVudCBvbiB0aGlzIHJlZ2FyZCBpbiB0aGUg Z3VpZGVsaW5lcywgY29tcGxpYW5jZSBjb3VsZCBiZSBjaGVja2VkIHdoZW4gbmV3IHRhYmxlcyBh cmUgc3VibWl0dGVkIHRvIElDQU5OIGZvciBhcHByb3ZhbC4gSWYgbmVlZGVkLCBhbiBhY3RpdmUg bW9uaXRvcmluZyBjb3VsZCBhbHNvIGJlIGRvbmUuDQoNCi0tIA0KRnJhbmNpc2NvDQoNCu+7v09u IDMvNi8xOCwgMjozMiBBTSwgIklETkEtVVBEQVRFIG9uIGJlaGFsZiBvZiBQYXRyaWsgRsOkbHRz dHLDtm0iIDxpZG5hLXVwZGF0ZS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBwYWZAZnJv YmJpdC5zZT4gd3JvdGU6DQoNCiAgICBIb3cgZG8geW91IGJlbGlldmUgdGhpcyBpcyB0byBiZSBp bXBsZW1lbnRlZCBpbiBhbGwgVExEcz8gSS5lLiB3aGF0IGRvIHlvdSBiZWxpZXZlIGlzIHRoZSBl bmZvcmNlbWVudCBtZWNoYW5pc20/DQogICAgDQogICAgICAgUGF0cmlrDQogICAgDQogICAgT24g NSBNYXIgMjAxOCwgYXQgMjM6MjIsIEZyYW5jaXNjbyBBcmlhcyB3cm90ZToNCiAgICANCiAgICA+ IEZvbGxvd2luZyBvbiBBc211cycgY29tbWVudCBiZWxvdywgcGVyaGFwcyB0aGUgSUROIEltcGxl bWVudGF0aW9uIEd1aWRlbGluZXMgY291bGQgaGVscCBhcyBhIHdheSB0byByZWFjaCBvdXQgdG8g VExEIHJlZ2lzdHJpZXM/DQogICAgPg0KICAgID4gaHR0cHM6Ly93d3cuaWNhbm4ub3JnL3Jlc291 cmNlcy9wYWdlcy9pbXBsZW1lbnRhdGlvbi1ndWlkZWxpbmVzLTIwMTItMDItMjUtZW4NCiAgICA+ DQogICAgPiBJIGJlbGlldmUgdGhlIHByb2Nlc3MgdG8gdXBkYXRlIHRoZW0gaXMgb25nb2luZyBo dHRwczovL2NvbW11bml0eS5pY2Fubi5vcmcvZGlzcGxheS9JRE4vSUROK0ltcGxlbWVudGF0aW9u K0d1aWRlbGluZXMNCiAgICA+DQogICAgPiBSZWdhcmRzLA0KICAgID4NCiAgICA+IC0tIA0KICAg ID4gRnJhbmNpc2NvDQogICAgPg0KICAgID4gT24gMy81LzE4LCAyOjEyIFBNLCAiSUROQS1VUERB VEUgb24gYmVoYWxmIG9mIEFzbXVzIEZyZXl0YWciIDxpZG5hLXVwZGF0ZS1ib3VuY2VzQGlldGYu b3JnIG9uIGJlaGFsZiBvZiBhc211c2ZAaXgubmV0Y29tLmNvbT4gd3JvdGU6DQogICAgPg0KICAg ID4gICAgIFNlY29uZGFyeSB0byB0aGF0IGlzIGZpbmRpbmcgYSB3YXkgdG8gY29tbXVuaWNhdGUg dGhlIHRvIGNvbnN1bWVycyBvZg0KICAgID4gICAgIHRoZXNlIHRhYmxlcyB0aGF0IHNpbXBseSBh bGxvd2luZyBhbGwgUFZBTElEIGNvZGUgcG9pbnRzIGlzbid0IGEgcm9idXN0DQogICAgPiAgICAg c29sdXRpb24gZm9yIG1hbnkgd3JpdGluZyBzeXN0ZW1zIGFuZCBhZGRpdGlvbmFsIGR1ZSBkaWxp Z2VuY2UgbmVlZHMgdG8NCiAgICA+ICAgICBiZSBwcmVmb3JtZWQgLSBmb3IgZXhhbXBsZSBhbG9u ZyB0aGUgc2FtZSBsaW5lcyBhcyBpcyBiZWluZyBkb25lIG5vdyBmb3INCiAgICA+ICAgICB0aGUg Um9vdCBab25lICh3aGljaCBpcyBxdWlja2x5IGRlZmluaW5nIHRoZSBzdGF0ZSBvZiB0aGUgYXJ0 IGluIHRoYXQNCiAgICA+ICAgICByZXNwZWN0KS4NCiAgICA+DQogICAgPg0KICAgID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+IElETkEtVVBE QVRFIG1haWxpbmcgbGlzdA0KICAgID4gSUROQS1VUERBVEVAaWV0Zi5vcmcNCiAgICA+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRuYS11cGRhdGUNCiAgICANCg0K From nobody Tue Mar 6 22:34:54 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3AC6124BE8 for ; Tue, 6 Mar 2018 22:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PE19lACWYtI for ; Tue, 6 Mar 2018 22:34:50 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5386812426E for ; Tue, 6 Mar 2018 22:34:49 -0800 (PST) Received: from [192.168.10.145] (c-8cb1d954.028-114-73746f27.cust.bredbandsbolaget.se [84.217.177.140]) by mail.frobbit.se (Postfix) with ESMTPSA id E5B80206B8; Wed, 7 Mar 2018 07:34:46 +0100 (CET) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "Francisco Arias" Cc: idna-update@ietf.org Date: Wed, 07 Mar 2018 07:34:46 +0100 X-Mailer: MailMate (2.0BETAr6104) Message-ID: <63CA41DC-283A-48B7-A735-CF436D24FEBD@frobbit.se> In-Reply-To: <78F09330-4B36-4AC5-9AFD-DF89EE2C75BA@icann.org> References: <78F09330-4B36-4AC5-9AFD-DF89EE2C75BA@icann.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_EC7C832C-8F88-4A99-8769-053F5B9C1545_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [Idna-update] Expiration impending: X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2018 06:34:53 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_EC7C832C-8F88-4A99-8769-053F5B9C1545_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Francisco, I see a few problems with your note, and will summarize them here. I will= tomorrow start travelling to Puerto Rico and am happy to talk more about= it there. - The question is not whether "a vast majority" or "almost all" or such i= mplement the guidelines. The fact is that not every registry do. And we d= o not only talk about gTLDs, we talk about TLD registries. And as long as= one registry do, and on top of that show they "sell" code points not onl= y violating IDNA2008 and because of that the ICANN recommendations, but a= lso do sell code points not yet allocated to Unicode and worse, they fail= to run a clean process and sell the same 2nd level domain to multiple pa= rties -- that not only is evidence there is a market, but also broken mar= ket regarding IDN. And as you see below, ICANN Board have now asked the c= ommunity (in plain english): "What are you doing about it?". I could tran= slate the words I read into much more clear language but prefer as a swed= e saying such things and not typing it. - The issues have once again brought light onto the question whether ICAN= N is only a home for the processes related to contracted parties or if IC= ANN also deal with non-contracted parties like ccTLDs. And if ccNSO or GA= C control ccTLDs. And of course at the moment in UN due to PP18 elevated = to the question why GAC exists and not the role of GAC is a body of ITU-T= =2E This can kind of quickly evolve to questions who decides what goes in= to the root zone, wether the ccNSO and the ASO should be part of ICANN or= not. Remember we already closed the PSO. - ICANN Board have (finally) on 2nd of November 2017 taken this seriously= by asking ccNSO and GNSO to take the issues on board. and I quote: > Resolved (2017.11.02.09), the Board hereby directs that conformance to = IDNA2008 and its successor will continue to be a necessary condition to d= etermine valid IDN TLD labels. > > Resolved (2017.11.02.10), the Board requests that the Country Code Name= s Supporting Organization (ccNSO) and the Generic Names Supporting Organi= zation (GNSO) engage with the SSAC to more fully understand the risks and= consequences of using a domain name that includes emoji in any of its la= bels, and inform their respective communities about these risks. > > Resolved (2017.11.02.11), the Board requests that the ccNSO and GNSO in= tegrate conformance with IDNA2008 and its successor into their relevant p= olicies so as to safeguard security, stability, resiliency and interopera= bility of domain names. > > Resolved (2017.11.02.12), the Board directs the ICANN CEO, or his desig= nee(s), to engage with gTLD and ccTLD communities on the findings and rec= ommendations in SAC095. - SSAC will via myself initiate work with ccNSO already in Puerto Rico, I= CANN has reached out to IAB that do take this very seriously (as it seems= -- and this discussion and active participation by IAB members is to me = a sign of this). Exactly how GNSO will take this on board I do not know b= ut will as the person in SSAC that holds the flag will investigate this n= ext week. - You are ICANN Staff, and having you choose the words the way you did is= to me troublesome, specifically in the light of what I explain above. I = hope I misunderstand you. Explaining the compliance process is one thing,= but whether it should be executed or not is a decision by the policy tha= t is to be implemented, and if you as ICANN Staff do believe the policy i= s not clear enough it should be bounced back to the community. Something = I (see above) believe ICANN Board just did. Once again, I hope I misread your words, and I am happy to talk about thi= s in Puerto Rico. This is serious. Patrik On 7 Mar 2018, at 3:06, Francisco Arias wrote: > Except for a couple of legacy gTLDs that do not yet have that requireme= nt, for the vast majority of the gTLDs, compliance with the IDN Implement= ation Guidelines is mandatory. > > If there were a requirement on this regard in the guidelines, complianc= e could be checked when new tables are submitted to ICANN for approval. I= f needed, an active monitoring could also be done. > > -- = > Francisco > > =EF=BB=BFOn 3/6/18, 2:32 AM, "IDNA-UPDATE on behalf of Patrik F=C3=A4lt= str=C3=B6m" wr= ote: > > How do you believe this is to be implemented in all TLDs? I.e. what= do you believe is the enforcement mechanism? > > Patrik > > On 5 Mar 2018, at 23:22, Francisco Arias wrote: > > > Following on Asmus' comment below, perhaps the IDN Implementation= Guidelines could help as a way to reach out to TLD registries? > > > > https://www.icann.org/resources/pages/implementation-guidelines-2= 012-02-25-en > > > > I believe the process to update them is ongoing https://community= =2Eicann.org/display/IDN/IDN+Implementation+Guidelines > > > > Regards, > > > > -- > > Francisco > > > > On 3/5/18, 2:12 PM, "IDNA-UPDATE on behalf of Asmus Freytag" wrote: > > > > Secondary to that is finding a way to communicate the to cons= umers of > > these tables that simply allowing all PVALID code points isn'= t a robust > > solution for many writing systems and additional due diligenc= e needs to > > be preformed - for example along the same lines as is being d= one now for > > the Root Zone (which is quickly defining the state of the art= in that > > respect). > > > > > > _______________________________________________ > > IDNA-UPDATE mailing list > > IDNA-UPDATE@ietf.org > > https://www.ietf.org/mailman/listinfo/idna-update > > > _______________________________________________ > IDNA-UPDATE mailing list > IDNA-UPDATE@ietf.org > https://www.ietf.org/mailman/listinfo/idna-update --=_MailMate_EC7C832C-8F88-4A99-8769-053F5B9C1545_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iG0EARECAC0WIQRUH/cJI8i4DDUU3qWsxpsaC4jXzQUCWp+IBg8ccGFmQGZyb2Ji aXQuc2UACgkQrMabGguI183T9QCdH9W0ze2n5QKLH+3a1jlEEbgskToAn2OQbQc2 wuZtAOdlnl1OmvX1q4I0 =a4m+ -----END PGP SIGNATURE----- --=_MailMate_EC7C832C-8F88-4A99-8769-053F5B9C1545_=-- From nobody Thu Mar 8 09:12:00 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6057E1270A7 for ; Thu, 8 Mar 2018 09:11:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9A6HYpW2tc5b for ; Thu, 8 Mar 2018 09:11:57 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03CCE12702E for ; Thu, 8 Mar 2018 09:11:56 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1etz58-0000yJ-F9 for idna-update@ietf.org; Thu, 08 Mar 2018 12:11:54 -0500 Date: Thu, 08 Mar 2018 12:11:48 -0500 From: John C Klensin To: idna-update@ietf.org Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Idna-update] Expiration impending: X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2018 17:11:58 -0000 One more thought about something it may be helpful to remind ourselves periodically. One of the notions floated when IDNs were first being discussed and raised a few times after that was to simply ban combining forms of all types. The theory was that there was no entitlement to write any character form (e.g., any "word") in DNS labels, that those labels were all about mnemonics and nothing but mnemonics, and that a "no combining sequences" rule would eliminate most issues about normalization and grapheme clusters and make everything a lot easier to explain to implementers and others who wanted to conform but were not willing to make the investment to actually understand all of the complex issues and rules with which we are now dealing. If that were the rule and someone really, really, wanted a grapheme that could only be formed in Unicode with a combining sequence, it would be up to them to convince the Unicode Consortium that their favorite character (grapheme) needed to be added to Unicode as a single code point. However hard that might be, it would not be our problem. FWIW, a "nothing but precombined characters" rule is essentially the recommendation for Arabic IDNs in RFC 5564 and, I understand, in the emerging Arabic script rules for the root zone. We didn't go down that path, not only because of impassioned pleas for some of the character forms that might be excluded but because of precisely the reassurance that arguably led to the non-decomposing characters thread -- assurances that no new code points would be added to Unicode if there were already a combining sequence that could reasonably substitute for it in the same script except under very unusual circumstances and, when those circumstances occurred, the new code points would decompose to those sequences. I don't suggest that we try to reverse that decision at this point. I assume that, if nothing else, it would just be too disruptive. However, it is worth pointing out that a "no combining sequences" rule would eliminate the non-decomposing character problem and at least a few other potential spoofing and related cases. It might also be worth examining as a guideline or advice for registries who are interesting in raising the safety level of what they allow to be registered without having to understand the underlying issues more deeply. best, john From nobody Thu Mar 8 09:47:43 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB9F6127775 for ; Thu, 8 Mar 2018 09:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=eJgS0eKZ; dkim=pass (1024-bit key) header.d=yitter.info header.b=nqJAzsTS Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5tOAFbrKtA4 for ; Thu, 8 Mar 2018 09:47:40 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BFC1127522 for ; Thu, 8 Mar 2018 09:47:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 3F5FABE780 for ; Thu, 8 Mar 2018 17:47:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1520531229; bh=HGL6LnAZIPbQBnW4OuMP71W2vyHaTm+MK6UXalaspYU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=eJgS0eKZNXxeZIQwmlN8FT7znQyQLBdYpXUYNJmEkNxUkbRq2HBfaSa8wiHFnlh5A cPT0aXLrUMH7FsjBBcwjOPrwTxktvmlK57T0OGiA9VjV5d9L4yTzZutSZgpHvw7piF AvpFzErt7W31diITw5vhXsj5WSohsHMSheLafAIw= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpRe2ZODVi_y for ; Thu, 8 Mar 2018 17:47:07 +0000 (UTC) Date: Thu, 8 Mar 2018 12:47:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1520531227; bh=HGL6LnAZIPbQBnW4OuMP71W2vyHaTm+MK6UXalaspYU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=nqJAzsTSZpmQcZjg/cLRD4IuAjRpULOmnOLqj+EBseoFgfolO4mP1d2zjD4GJjTl5 37JnB1mScgCsXMz3uzDH7kJ48FFhweIH8KY62SF0GQYqL8vFtGTnihBxY5EhI7R6eP xtDgNtz//LJnJYw5IiU04f+9kkrmbSBv/dyHlOsQ= From: Andrew Sullivan To: idna-update@ietf.org Message-ID: <20180308174703.q3bffw7anrvjwzym@mx4.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Idna-update] Expiration impending: X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2018 17:47:42 -0000 On Thu, Mar 08, 2018 at 12:11:48PM -0500, John C Klensin wrote: > If that were the rule and someone really, really, wanted a > grapheme that could only be formed in Unicode with a combining > sequence, it would be up to them to convince the Unicode > Consortium that their favorite character (grapheme) needed to be > added to Unicode as a single code point. However hard that > might be, it would not be our problem. I thought the argument at the time was not just that it was safe, but that some characters (in conceptual sense that Unicode uses it) were necessarily made of combining characters. This was also I guess the reason that the two joiners ended up in under context rules, I think, yes? Moreover, there was the principle that we didn't want to make restrictions low in the tree even if we thought they were mostly a bad idea near the top (this was literally the reasoning for including hieroglyphs as I recall). A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Thu Mar 8 11:11:35 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C13D3127076 for ; Thu, 8 Mar 2018 11:11:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JBX_Vf0dms5 for ; Thu, 8 Mar 2018 11:11:32 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE1861270AC for ; Thu, 8 Mar 2018 11:11:28 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1eu0wp-000194-Ca; Thu, 08 Mar 2018 14:11:27 -0500 Date: Thu, 08 Mar 2018 14:11:21 -0500 From: John C Klensin To: Andrew Sullivan , idna-update@ietf.org Message-ID: <2D4E04E4B3BB56404560C142@PSB> In-Reply-To: <20180308174703.q3bffw7anrvjwzym@mx4.yitter.info> References: <20180308174703.q3bffw7anrvjwzym@mx4.yitter.info> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Idna-update] Expiration impending: X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2018 19:11:34 -0000 --On Thursday, March 8, 2018 12:47 -0500 Andrew Sullivan wrote: > On Thu, Mar 08, 2018 at 12:11:48PM -0500, John C Klensin wrote: >> If that were the rule and someone really, really, wanted a >> grapheme that could only be formed in Unicode with a combining >> sequence, it would be up to them to convince the Unicode >> Consortium that their favorite character (grapheme) needed to >> be added to Unicode as a single code point. However hard >> that might be, it would not be our problem. > > I thought the argument at the time was not just that it was > safe, but that some characters (in conceptual sense that > Unicode uses it) were necessarily made of combining > characters. This was also I guess the reason that the two > joiners ended up in under context rules, I think, yes? Yes. The joiners normally (and pre-emoji) had more to do with what would ordinarily be considered phrase or sentence construction than with character formation, but, yes, they were included because of strong arguments that the use of some scripts (at least with some languages) was impossible without them. The distinction is, IMO, worth making only because it would have been plausible to prohibit combining sequences and allow ZWJ and ZWNJ (with or without contextual conditions)anyway == really separate issues. > Moreover, there was the principle that we didn't want to make > restrictions low in the tree even if we thought they were > mostly a bad idea near the top (this was literally the > reasoning for including hieroglyphs as I recall). Certainly it was a key part of the reasoning for allowing archaic scripts. Whether hieroglyphs were the critical issue or merely a common example probably depends on who you ask. I should stress that I'm not at all convinced that we made the wrong decision about combining sequences, nor that we would have made a different decision had we had access to better and more accurate information. I would feel better now if we could look back at the decision and its consequences and say "there was an informed discussion based on full information and we decided to do it and accept the consequential risks" -- just as we did with, e.g., the characters that were classified as valid (PVALID or CONTEXTx) in IDNA2008 but mapped to something or discarded in IDNA2003. On the other hand, the same kind of thinking that argues for a "troublesome characters" list (at least as I've understood it) -- more "you SHOULD NOT use these unless you are extra-sure you know what you are doing and what the implications might be" than any sort of absolute prohibition -- might imply a similar statement about combining sequences. In other words, whether they are prohibited by the requirement that putative labels be in NFC form or not (and many are), one should not be using them without really good reason. Not a protocol prohibition, but an extra layer of protection against edge cases and some potentially-malicious behavior. best, john From nobody Thu Mar 8 11:37:51 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B5D1270AC for ; Thu, 8 Mar 2018 11:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=NfsnEu+m; dkim=pass (1024-bit key) header.d=yitter.info header.b=T6gHk/uB Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INivmLTTXoYV for ; Thu, 8 Mar 2018 11:37:49 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42536124BFA for ; Thu, 8 Mar 2018 11:37:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 83923BE780 for ; Thu, 8 Mar 2018 19:37:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1520537868; bh=7m+XafCaaXrXV1p81Wt91NC59TrcSlIGmkrDN29+Jos=; h=Date:From:To:Subject:References:In-Reply-To:From; b=NfsnEu+mvRc2zn74Wf4UJ/7N2xLfD7VkJywJ5IAj9HxtQ1Xt9xEkn54NAWDyKJxck ATxgmh9uk5p0g8t9+nXm/ddN3zOP7aalgJPK3u49E9jbKpFcUerQvPkbi09VLCQ/Gs pAt6gNSydkL3Ol/fCvq2JdTI5lG6Hh/IMJbLpyFo= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTyrRHuJ7dtq for ; Thu, 8 Mar 2018 19:37:47 +0000 (UTC) Date: Thu, 8 Mar 2018 14:37:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1520537867; bh=7m+XafCaaXrXV1p81Wt91NC59TrcSlIGmkrDN29+Jos=; h=Date:From:To:Subject:References:In-Reply-To:From; b=T6gHk/uBCsDajjnjeNfsNGlL4lbBkUdtXZipGJg3ND2F8RadmZL44luhM0s79rhnf WTxaIGCyhO5G/5WbuGSFuJEM1+HeaC8QO4YhGQ66BQuHidocKPq2IpNR+b6m3y1/VQ l9p/QnXMf9jArEjCKLlSQ3YHxAjOtU+OiBbPklB8= From: Andrew Sullivan To: idna-update@ietf.org Message-ID: <20180308193744.rkyyz3omuxyd7ehg@mx4.yitter.info> References: <20180308174703.q3bffw7anrvjwzym@mx4.yitter.info> <2D4E04E4B3BB56404560C142@PSB> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D4E04E4B3BB56404560C142@PSB> Archived-At: Subject: Re: [Idna-update] Expiration impending: X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2018 19:37:50 -0000 On Thu, Mar 08, 2018 at 02:11:21PM -0500, John C Klensin wrote: > > On the other hand, the same kind of thinking that argues for a > "troublesome characters" list (at least as I've understood it) > -- more "you SHOULD NOT use these unless you are extra-sure you > know what you are doing and what the implications might be" than > any sort of absolute prohibition -- might imply a similar > statement about combining sequences. That actually doesn't seem like a terrible idea to me. Of course, that was _supposed_ to be the point of the general exhortation to have a clue about the code points you were putting in a zone. And that doesn't seem to have panned out :-/ A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Thu Mar 8 12:02:56 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2AC120721 for ; Thu, 8 Mar 2018 12:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ix.netcom.com; domainkeys=pass (2048-bit key) header.from=asmusf@ix.netcom.com header.d=ix.netcom.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZt6Kq6y3N9z for ; Thu, 8 Mar 2018 12:02:52 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03DEB1250B8 for ; Thu, 8 Mar 2018 12:02:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ix.netcom.com; s=dk12062016; t=1520539370; bh=iBi9FuJtIImrZR2bOMtVy/143lpX+5Yhter+ hfOEL38=; h=Received:Subject:To:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Content-Language:X-ELNK-Trace: X-Originating-IP; b=WHWxRvflgvcDsN7yY8655sgQmV0Hg0PM3LUd459xeYktaF h/3jAQS4H5N2iaEp3g6p79otIvfTcb/v4hPZbTjnw5r7Cbm5pFM1EIWBsBr7as5kBlu F8BArcyOhr62U3mmw9rB1kpJdUhHbhPGu8Chw92+iaDUuZoG4NCZDEV8N7/UIjNR9kz CBKd/PAAC4ugy8BY+sXRm6kV09a6yvtxrxtD9GN9S8wxnR/jwcB4RoCe3Tnkt3l2P2c EAth7FTkSYppZvIaSSy4mCo5nEMv2Qp+KFrWOBSvAbVnD0PxNbSu54RqgiIuq2CoXlt 7Q2+GzWXmmW+vbKt36H7qx5UKs0w== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=ix.netcom.com; b=DZSlPTrjEUafs0vbEgaAkjp9X5R5VIUJ1DAJff4/mXLIQP7aml8ziOnpI0n2KjEd8YnP90lOWCbSh+sY9FD0qd/lo19U6wd9VmPqeh87RoNk2lGrrt9ydw00e8BU7tFOAQQUrczq20hhX2sEyEtIP8Zfipxf+HGCsAMuIktybunEFGDYXlYiXmQZI8woGKpaQ5AuRpD9zvwkaNYCnMEQlhE9EuW7yV1Tw6Tc7MjpAopfga+XaWHRJvZSDWbhbFePBRN7BMSXBNk0UNkkoP4sVtdmjdvgHqYUNCBDRJK7+WDXJR9/UW4cNDrh/1a3p8PKk75HPAxvhLADvXOLTARXNA==; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [71.35.186.204] (helo=[192.168.1.103]) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1eu1kV-0002m9-UU for idna-update@ietf.org; Thu, 08 Mar 2018 15:02:48 -0500 To: idna-update@ietf.org References: From: Asmus Freytag Message-ID: <02c29140-29f1-cc81-8c4f-8249d0f23b2c@ix.netcom.com> Date: Thu, 8 Mar 2018 12:02:52 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-ELNK-Trace: 464f085de979d7246f36dc87813833b2c1627926350bb93f5c24928e240690f528ed23686566b73f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.35.186.204 Archived-At: Subject: Re: [Idna-update] Expiration impending: X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2018 20:02:55 -0000 On 3/8/2018 9:11 AM, John C Klensin wrote: > One more thought about something it may be helpful to remind > ourselves periodically. > > One of the notions floated when IDNs were first being discussed > and raised a few times after that was to simply ban combining > forms of all types. The theory was that there was no > entitlement to write any character form (e.g., any "word") in > DNS labels, that those labels were all about mnemonics and > nothing but mnemonics, and that a "no combining sequences" rule > would eliminate most issues about normalization and grapheme > clusters and make everything a lot easier to explain to > implementers and others who wanted to conform but were not > willing to make the investment to actually understand all of the > complex issues and rules with which we are now dealing. It would also very  nicely prevent IDNs on the entire Indian Subcontinent. Ironically, it is Arabic, where most (all) of the combining can safely be excluded from IDNs. This is being done for the Root Zone, for example, as you acknowledge below. The reason is that in Arabic, these marks are generally optional and/or used for specific purposes in specialized text. Therefore, leaving them out is not detrimental to the usability of IDNs and the Root Zone will not allow them (extending the set of prohibited ones from RFC 5564) Therefore, in the Root Zone the Unicode 7 addition of the U+08A1 would not be an issue. > > If that were the rule and someone really, really, wanted a > grapheme that could only be formed in Unicode with a combining > sequence, it would be up to them to convince the Unicode > Consortium that their favorite character (grapheme) needed to be > added to Unicode as a single code point. However hard that > might be, it would not be our problem. Well, we see what happens if someone does get Unicode to add a pre- composed form: the entire process is derailed. That's what happened with the addition of U+08A1 even though it is NOT the case that this is a true "precomposed" form - while the same graphical elements are involved, the result does not look identical. There is a strong similarity of course, but despite what people read into the Unicode character name, this is not a case of an exact homoglyph. > > FWIW, a "nothing but precombined characters" rule is essentially > the recommendation for Arabic IDNs in RFC 5564 and, I > understand, in the emerging Arabic script rules for the root > zone. That is because of the way these function in Arabic. Unicode could not generally add precomposed forms of, say, Latin code points, say a new letter with a dot above, because of normalization stability. In the Latin script, a combining dot above and a precomposed dot above are identical. However, even there you have a number of combining marks that are not considered as part of possible decompositions: they are the code points for various (stroke) overlays and some attached extenders. Like the Arabic combining marks, they could (and should) be disallowed from LGRs. (The Latin LGR for the Root Zone will not allow combining marks other than in enumerated combinations - that's something that works for Latin, Greek, Cyrillic and practically all scripts that are not South or South East Asian complex scripts. > > We didn't go down that path, not only because of impassioned > pleas for some of the character forms that might be excluded but > because of precisely the reassurance that arguably led to the > non-decomposing characters thread -- assurances that no new code > points would be added to Unicode if there were already a > combining sequence that could reasonably substitute for it in > the same script except under very unusual circumstances and, > when those circumstances occurred, the new code points would > decompose to those sequences. Other participants in that discussion remember this claim differently. Unicode Normalization forms C and D were never about "reasonable substitutions" but about "exact equivalents" or "the same thing, except for the encoding". As there is generally no benefit in encoding another representation of "the same thing", Unicode does not allow addition of precomposed code points that can be decomposed into something that is the exact equivalent. > > I don't suggest that we try to reverse that decision at this > point. I assume that, if nothing else, it would just be too > disruptive. However, it is worth pointing out that a "no > combining sequences" rule would eliminate the non-decomposing > character problem and at least a few other potential spoofing > and related cases. It might also be worth examining as a > guideline or advice for registries who are interesting in > raising the safety level of what they allow to be registered > without having to understand the underlying issues more deeply. A useful set of recommendation for handling combining marks safely in LGRs would consist of: 1) in all non-complex scripts: allow only fixed enumerations of base code point and combining marks. (The number of required combinations is small, even for a sprawling script like Latin). 2) in all complex scripts (where the number of combinations is too large), provide context rules that assure combining marks are not placed in the wrong part of a syllable (such wrong contexts cannot be "read" by humans and not rendered correctly by machines). The Root LGR presents suitable examples of this for SEA scripts, Indic scripts in preparation. 3) in scripts where combining marks express optional elements (vowels, etc.) disallow all of them. (Arabic, see Root Zone LGR for example) 4) in scripts where combining marks are used for historical/ special purposes disallow those (diacritics for classical Greek, stroke overlays and other marks for linguistics). 5) in LGRs supporting variants, consider mutually blocking labels that vary only in the presence or absence of some combining diacritic; some diacritics are not reliably distinguished from each other (comma below, cedilla) or from an undecorated base character (forms with/without Nukta). What is a complex script: a good approximation is whether it contains a code point with ccc=virama, plus Thaana, which isn't really complex but has mandatory vowels classed as combining marks. Effectively all South and South East Asian scripts that are abugidas. In addition, you will want recommendations that actually address the homoglyph issues: there are a fair number of non-combining mark exact visual duplicates in Unicode. These are not exact equivalents, because Unicode does not treat code points that differ in script, case or digit/letter properties as equivalent. A./ > > best, > john > > > > _______________________________________________ > IDNA-UPDATE mailing list > IDNA-UPDATE@ietf.org > https://www.ietf.org/mailman/listinfo/idna-update > From nobody Thu Mar 8 12:26:45 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E27C12762F for ; Thu, 8 Mar 2018 12:26:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ix.netcom.com; domainkeys=pass (2048-bit key) header.from=asmusf@ix.netcom.com header.d=ix.netcom.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZBAAluk-MiP for ; Thu, 8 Mar 2018 12:26:42 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0F151271DF for ; Thu, 8 Mar 2018 12:26:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ix.netcom.com; s=dk12062016; t=1520540802; bh=8JIPUfgg5FAAGkxxcARyBUBSHSBu9bUQX3Vu QNunjc8=; h=Received:Subject:To:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Content-Language:X-ELNK-Trace: X-Originating-IP; b=QwFmj+vKkKi+fLLo1MYeaKX7nXbtf5ITfkT3g3lSun50fg bzSD6R2OJUiUlHd42LCE+1s7QmrTBeTtFwewsXABpLlHW9PkPOX9T43iOS1FU8enKeT YKSNWQb4fAb03qsAKuchBGBjbD6LKqhYWn3Ctkjg/b+OvDNGJ06WREAO/Ry/9blTGdx VvxTjnI7IxIx5QdNoA/IEV5ZuXFxdJ+W9CavW02zak0W5kjJQsztqc0WNkK6OGyk0fO 73QjpGSo0fcTggtlRhCiZFYv7DMsNENlbQIqZqY3ieb8A12SWano++IRw055JPYBNb4 bMhtEVfzPTLAKnddkpoSTMxJcQkg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=ix.netcom.com; b=sfOFGwJZ6AFG0/tvR3puMdcGKCMd1pDbF+kygptHNUb36U6ZOO3MlVwCs97G5EgNf7aiiAsIlWNJ1+xnCx+x1UqEHqAGPkc99avhPDTvk8EjNH/TEMrU9JAZICUR5RCrze4jI4JVwvyMg8c+f5hVMo4+9wTiOIqvXE0OrWHQFG34L1MBYvb+AJutAsYOgSIiDIau4koRjVunTgMX6IaTf+RRUpNTfAJ4J8uYht5C/3V9w28v8iR/hSkjw0g7DFXnPj+nq3u86iJAzyFDZLz+wKMjcBL3FavlLTwu55z12RGLFrc3bwKjjgBdAj6yoLUaI0b2291SBIvAA/BTcBqDbg==; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [71.35.186.204] (helo=[192.168.1.103]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1eu27d-000DgS-FY for idna-update@ietf.org; Thu, 08 Mar 2018 15:26:41 -0500 To: idna-update@ietf.org References: <20180308174703.q3bffw7anrvjwzym@mx4.yitter.info> <2D4E04E4B3BB56404560C142@PSB> <20180308193744.rkyyz3omuxyd7ehg@mx4.yitter.info> From: Asmus Freytag Message-ID: <22f7d869-a7e4-c426-d05d-5f50ec2f3d90@ix.netcom.com> Date: Thu, 8 Mar 2018 12:26:45 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180308193744.rkyyz3omuxyd7ehg@mx4.yitter.info> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-ELNK-Trace: 464f085de979d7246f36dc87813833b2c1627926350bb93f520b9d088908472705bfc77d7bdbfc27350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.35.186.204 Archived-At: Subject: Re: [Idna-update] Expiration impending: X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2018 20:26:43 -0000 On 3/8/2018 11:37 AM, Andrew Sullivan wrote: > On Thu, Mar 08, 2018 at 02:11:21PM -0500, John C Klensin wrote: >> On the other hand, the same kind of thinking that argues for a >> "troublesome characters" list (at least as I've understood it) >> -- more "you SHOULD NOT use these unless you are extra-sure you >> know what you are doing and what the implications might be" than >> any sort of absolute prohibition -- might imply a similar >> statement about combining sequences. > That actually doesn't seem like a terrible idea to me. Of course, > that was _supposed_ to be the point of the general exhortation to have > a clue about the code points you were putting in a zone. And that > doesn't seem to have panned out :-/ A general exhortation ("know what you are doing") is too vague to be helpful. Something on the level of what I just sent out as "recommendations" for safe use of combining marks is much more specific and actionable. I think it might be close enough to something that could become part of an enforceable policy. A./ > > A From nobody Fri Mar 9 08:27:37 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B039D12D7F9 for ; Fri, 9 Mar 2018 08:27:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwJFn1ygyiuL for ; Fri, 9 Mar 2018 08:27:34 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E55612D7F2 for ; Fri, 9 Mar 2018 08:27:33 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1euKrk-0003y3-92; Fri, 09 Mar 2018 11:27:32 -0500 Date: Fri, 09 Mar 2018 11:27:25 -0500 From: John C Klensin To: Asmus Freytag , idna-update@ietf.org Message-ID: <1E562CDE39B4224F227E765D@PSB> In-Reply-To: <02c29140-29f1-cc81-8c4f-8249d0f23b2c@ix.netcom.com> References: <02c29140-29f1-cc81-8c4f-8249d0f23b2c@ix.netcom.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [Idna-update] IDNA and combining sequences (was: Re: Expiration impending: ) X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2018 16:27:37 -0000 Asmus, Thanks for the more detailed explanation. I don't think we really disagree. Three observations: * The Unicode Standard is very clear that code points are assigned to abstract characters and not to particular fonts, type styles, or type families. While it specifies rendering rules for particular scripts (and, if I recall without going back and checking, sometimes even particular languages0, those rules are much more readily applied to actual blocks of text than to relatively short mnemonic strings that may not obey the word or phrase formation rules of the writing system for some human language. We've also seen applications and implementations that are trying to do as little as possible (or, stated a bit more positively, to incorporate as little code that is exercised only for very specific cases as possible) and hence are unlikely to carefully apply rendering rules to strings even if they support the fonts needed to display the code points in those strings. There are also applications and formats out there that allow incorporating fonts of the author's choice, rather than picking from those we, or a different application implementer, might consider optional. Because of those factors and because users will often see what they expect to see, I think we need to be very careful when making statements about what might or might not look like something else. =20 * In retrospect, we missed an important opportunity when the "preferred syntax" rules were written into RFC 1034 and its predecessors. It would have been possible at some time decades ago to specify a rule for combining words for the purpose mnemonics to form DNS labels. porky-pig or porkypig, usc-isi or uscisi, etc. For those old enough to remember the host table and NIC-approved names, we actually had such a convention, but it was, at least as far as I can remember, never written down... and it certainly did not make it to RFC 1034. So we now have internetsociety.org and not internet-society.org, but, if one wants to have a discussion about confusion, remember which of those two labels is being used is at least as confusing to a typical user as any of the more subtle character or character-representation issues we have been discussing (if there is anyone reading this with an inclination toward evil or chaos, it might be interesting to see if internet-society.org could be registered and, if so, whether it would cause any interesting havoc). Noting that, like so many other things, IDNs don't create new problems but may make old ones more complex, I observe that, AFAIK, ICANN has never seriously discussed a guideline prohibiting having both porky-pig and porkyig as labels in the same zone, a situation that adds to my skepticism about blocked variants as a major part of any solution. All of that aside, had there been a discussion in RFC 1034 about the relationship between, e.g., "xerox-copier" and "xeroxcopier", it certainly would have been reflected in the extrapolations that generated most of the rules of IDNA2008. * Your explanation below is very helpful, at least to me. I am confident that, if it was what we were given when we started the IDNA2008 design, some of the rules would have reflected it. We were given a different explanation and answer to our questions, one much closer to "there is no problem and will be no problem in the future, so don't worry - no special rules are needed". =20 The question is what to do now. If we were to decide that your discussion would made a good addition to the protocol, we would run into at least two problems. One is that we promised the registry community that there would be no more disruptive changes and, at least as important, the Unicode Consortium outrage at our altering the way a handful of code points were treated would presumably be much greater if we were to make a change that would invalidate a large number of labels that might now be registered and in use somewhere in the tree. Another is the problem that started this thread -- there appears to be no energy in the IETF to consider and process changes to IDNA, even fairly trivial clarifications. See my next note for a different aspect of this. best, john --On Thursday, March 8, 2018 12:02 -0800 Asmus Freytag wrote: > On 3/8/2018 9:11 AM, John C Klensin wrote: >> One more thought about something it may be helpful to remind >> ourselves periodically. >>=20 >> One of the notions floated when IDNs were first being >> discussed and raised a few times after that was to simply ban >> combining forms of all types. The theory was that there was >> no entitlement to write any character form (e.g., any "word") >> in DNS labels, that those labels were all about mnemonics and >> nothing but mnemonics, and that a "no combining sequences" >> rule would eliminate most issues about normalization and >> grapheme clusters and make everything a lot easier to explain >> to implementers and others who wanted to conform but were not >> willing to make the investment to actually understand all of >> the complex issues and rules with which we are now dealing. >=20 > It would also very=C2=A0 nicely prevent IDNs on the entire = Indian > Subcontinent. >=20 > Ironically, it is Arabic, where most (all) of the combining > can safely be > excluded from IDNs. This is being done for the Root Zone, for > example, > as you acknowledge below. >=20 > The reason is that in Arabic, these marks are generally > optional and/or > used for specific purposes in specialized text. Therefore, > leaving them > out is not detrimental to the usability of IDNs and the Root > Zone will > not allow them (extending the set of prohibited ones from RFC > 5564) >=20 > Therefore, in the Root Zone the Unicode 7 addition of the > U+08A1 would > not be an issue. >>=20 >> If that were the rule and someone really, really, wanted a >> grapheme that could only be formed in Unicode with a = combining >> sequence, it would be up to them to convince the Unicode >> Consortium that their favorite character (grapheme) needed to >> be added to Unicode as a single code point. However hard >> that might be, it would not be our problem. >=20 > Well, we see what happens if someone does get Unicode to add a > pre- > composed form: the entire process is derailed. That's what > happened > with the addition of U+08A1 even though it is NOT the case > that this is > a true "precomposed" form - while the same graphical elements > are > involved, the result does not look identical. There is a > strong similarity > of course, but despite what people read into the Unicode > character > name, this is not a case of an exact homoglyph. >>=20 >> FWIW, a "nothing but precombined characters" rule is >> essentially the recommendation for Arabic IDNs in RFC 5564 >> and, I understand, in the emerging Arabic script rules for >> the root zone. >=20 > That is because of the way these function in Arabic. >=20 > Unicode could not generally add precomposed forms of, say, > Latin code > points, say a new letter with a dot above, because of > normalization > stability. In the Latin script, a combining dot above and a > precomposed > dot above are identical. >=20 > However, even there you have a number of combining marks that > are > not considered as part of possible decompositions: they are > the code > points for various (stroke) overlays and some attached > extenders. >=20 > Like the Arabic combining marks, they could (and should) be > disallowed > from LGRs. (The Latin LGR for the Root Zone will not allow > combining > marks other than in enumerated combinations - that's something > that > works for Latin, Greek, Cyrillic and practically all scripts > that are not > South or South East Asian complex scripts. >>=20 >> We didn't go down that path, not only because of impassioned >> pleas for some of the character forms that might be excluded >> but because of precisely the reassurance that arguably led to >> the non-decomposing characters thread -- assurances that no >> new code points would be added to Unicode if there were >> already a combining sequence that could reasonably substitute >> for it in the same script except under very unusual >> circumstances and, when those circumstances occurred, the new >> code points would decompose to those sequences. >=20 > Other participants in that discussion remember this claim > differently. > Unicode Normalization forms C and D were never about > "reasonable > substitutions" but about "exact equivalents" or "the same > thing, > except for the encoding". >=20 > As there is generally no benefit in encoding another > representation of > "the same thing", Unicode does not allow addition of > precomposed > code points that can be decomposed into something that is the > exact equivalent. >=20 >>=20 >> I don't suggest that we try to reverse that decision at this >> point. I assume that, if nothing else, it would just be too >> disruptive. However, it is worth pointing out that a "no >> combining sequences" rule would eliminate the non-decomposing >> character problem and at least a few other potential spoofing >> and related cases. It might also be worth examining as a >> guideline or advice for registries who are interesting in >> raising the safety level of what they allow to be registered >> without having to understand the underlying issues more >> deeply. >=20 > A useful set of recommendation for handling combining marks > safely in LGRs > would consist of: >=20 > 1) in all non-complex scripts: allow only fixed enumerations > of base code point > and combining marks. (The number of required combinations is > small, even > for a sprawling script like Latin). >=20 > 2) in all complex scripts (where the number of combinations is > too large), > provide context rules that assure combining marks are not > placed in the > wrong part of a syllable (such wrong contexts cannot be "read" > by humans > and not rendered correctly by machines). The Root LGR presents > suitable > examples of this for SEA scripts, Indic scripts in = preparation. >=20 > 3) in scripts where combining marks express optional elements > (vowels, etc.) > disallow all of them. (Arabic, see Root Zone LGR for example) >=20 > 4) in scripts where combining marks are used for historical/ > special purposes > disallow those (diacritics for classical Greek, stroke > overlays and other marks > for linguistics). >=20 > 5) in LGRs supporting variants, consider mutually blocking > labels that vary > only in the presence or absence of some combining diacritic; > some diacritics > are not reliably distinguished from each other (comma below, > cedilla) or from > an undecorated base character (forms with/without Nukta). >=20 > What is a complex script: a good approximation is whether it > contains a code > point with ccc=3Dvirama, plus Thaana, which isn't really = complex > but has mandatory > vowels classed as combining marks. Effectively all South and > South East Asian > scripts that are abugidas. >=20 > In addition, you will want recommendations that actually > address the homoglyph > issues: there are a fair number of non-combining mark exact > visual duplicates in > Unicode. These are not exact equivalents, because Unicode does > not treat > code points that differ in script, case or digit/letter > properties as equivalent. >=20 > A./ >=20 >=20 >>=20 >> best, >> john >>=20 >>=20 >>=20 >> _______________________________________________ >> IDNA-UPDATE mailing list >> IDNA-UPDATE@ietf.org >> https://www.ietf.org/mailman/listinfo/idna-update >>=20 >=20 > _______________________________________________ > IDNA-UPDATE mailing list > IDNA-UPDATE@ietf.org > https://www.ietf.org/mailman/listinfo/idna-update From nobody Fri Mar 9 09:13:17 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87BA7126DFB for ; Fri, 9 Mar 2018 09:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxcQaoMMaOF9 for ; Fri, 9 Mar 2018 09:13:15 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD0DC126DD9 for ; Fri, 9 Mar 2018 09:13:14 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1euLZx-00041o-36; Fri, 09 Mar 2018 12:13:13 -0500 Date: Fri, 09 Mar 2018 12:13:06 -0500 From: John C Klensin To: Andrew Sullivan cc: idna-update@ietf.org Message-ID: In-Reply-To: <20180308193744.rkyyz3omuxyd7ehg@mx4.yitter.info> References: <20180308174703.q3bffw7anrvjwzym@mx4.yitter.info> <2D4E04E4B3BB56404560C142@PSB> <20180308193744.rkyyz3omuxyd7ehg@mx4.yitter.info> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Idna-update] Expiration impending: X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2018 17:13:16 -0000 --On Thursday, March 8, 2018 14:37 -0500 Andrew Sullivan wrote: > On Thu, Mar 08, 2018 at 02:11:21PM -0500, John C Klensin wrote: >> >> On the other hand, the same kind of thinking that argues for >> a "troublesome characters" list (at least as I've understood >> it) -- more "you SHOULD NOT use these unless you are >> extra-sure you know what you are doing and what the >> implications might be" than any sort of absolute prohibition >> -- might imply a similar statement about combining sequences. > > That actually doesn't seem like a terrible idea to me. Of > course, that was _supposed_ to be the point of the general > exhortation to have a clue about the code points you were > putting in a zone. And that doesn't seem to have panned out > :-/ Well, and this may apply to Asmus's recent notes (including a more nuanced view of combining sequences) too, I'm trying to think in terms of, and maybe adjust, a distinction that goes back to at least the earliest discussions of IDNs and IDN policies. The distinction is arguably closely related to the difference between RFCs 1034/1035 and a number of subsequent "this is how we are actually going to do this" statements, of which RFC 1591 may be a high point. The version that might be relevant today is that there are three (or four) levels or layers of IDNA-related rules affecting what domain names can be registered: (0) Nothing gets to violate the fundamental architecture of the DNS, e.g., one doesn't get to have two labels that compare equal in the same zone and it really is a tree. By and large, we expect this set of rules to be self-enforcing: it is hard to even think about ways to break those rules and still have anything work (although we've seen some speculation and wishful thinking about aliases that would interleave branches of the tree and that would therefore come close). (1) The IDNA protocol collection specifies what is and is not allowed and what operations work and how, and what is and is not valid, at a fundamental level. That isn't just registration-time requirements. IDNA2008 specifies checks to be done at lookup time and we expect systems looking up names to reject at least a subset of invalid strings before looking them up. There is some implementation flexibility there: while we don't require, e.g., contextual checks at lookup time, I don't imagine anyone would severely criticize an implementation for rejecting a string outright that didn't conform to those rules because, if lookup succeeded, the application would be safe in concluding that either something was broken or that it was likely that something malicious was going on. That is true even of IDNA2003, which effectively has no lookup-time requirements: to take an extreme example, if an implementation were given something in ACE (aka presumably "Puncode encoded") form; decided to convert it back to native characters to be sure it could generate native-character error messages if needed; discovered it wouldn't convert or converted to something that required mapping; and then generated an error message rather than trying to look the thing up, I don't imagine anyone would complain (other than perhaps a registrant who had bought such a string in its Punycode encoded from -- something many registries won't allow). The important thing about these protocol requirements is that no sane person should expect the problem domain name or label to actually work, or work predictably, for what we normally consider DNS functions such as doing name to address translation. If someone were buying labels as trophies in the hope that their trophy-value would increases over time that would be another matter but I'm not sure that, from a protocol standpoint, we really need to care. (2) Advice, guidelines, or policy requirements applicable to a broad variety of domains. Unless we are going to have chaos, such guidelines must allow only a subset of what is allowed under the protocol limitations above. For zones that are well and carefully run, with name use and the best interests of Internet users in mind, it is reasonable to expect that well-designed guidelines will be followed, as least unless the zone administrators understand things well enough to carefully allow exceptions. The meta-rule that zones are required to understand what they are doing is one such guideline and, at least to a first approximation, I think most registries (including zones below the second level that are using IDNs) try. For those who are not inclined (for business or other reasons), to follow such guidelines, the guidelines are only as good as the existence of someone who is willing and able to enforce them or otherwise discourage bad behavior. What has not panned out is the assumption that ICANN would make at least some serious effort to either persuade or induce registries, even second-level entities under contracted TLD registries, to follow those guidelines, especially with regard to taking active responsibility for what they are doing. But that doesn't make establishing the guidelines a bad idea. I'm not aware of it having happened yet with IDNs, but there is precedent for people who are harmed by someone else's bad behavior to cite violation of widely-accepted guidelines as evidence that the behavior was bad or negligent. (3) The rules that are used by the operator/ administrator of a particular registry to determine what can or will be allowed in that zone. Noting that the rules for the root (including the LGR rules but not limited to them, at least yet) are just a special case of this category, all that is necessary to application and enforcement of the rules is that the registry decide to do so... and that the rules that are chosen be sufficiently acceptable to whatever community(ies) are in a position to hold the registry accountable that they don't either turn into a source of never-ending strife or change often enough to cause perceived instability. I think some of our discussions have confused the first two and last two categories and then gone on to confuse the third (general guidelines for the second level and below) and fourth (registry-specific rules), assuming, for example, that what is suitable for one registry should be applicable, either as a guideline or as a protocol changes, to the others. best, john From nobody Sat Mar 10 05:06:20 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782A9129C6D for ; Sat, 10 Mar 2018 05:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s38LAyVW23gn for ; Sat, 10 Mar 2018 05:06:17 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E51CD126BF0 for ; Sat, 10 Mar 2018 05:06:16 -0800 (PST) Received: from [10.196.199.114] (unknown [IPv6:2620:f:8000:210:8d4:be63:a857:690]) by mail.frobbit.se (Postfix) with ESMTPSA id 4E403232A5; Sat, 10 Mar 2018 14:06:13 +0100 (CET) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "John C Klensin" Cc: "Asmus Freytag" , idna-update@ietf.org Date: Sat, 10 Mar 2018 09:06:09 -0400 X-Mailer: MailMate (2.0BETAr6104) Message-ID: <516E58F3-015D-4AD7-A3FD-0749A6890245@frobbit.se> In-Reply-To: <1E562CDE39B4224F227E765D@PSB> References: <02c29140-29f1-cc81-8c4f-8249d0f23b2c@ix.netcom.com> <1E562CDE39B4224F227E765D@PSB> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_4BDAA92C-525B-4EF7-ADC9-527C83B57AF4_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [Idna-update] IDNA and combining sequences (was: Re: Expiration impending: ) X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2018 13:06:18 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_4BDAA92C-525B-4EF7-ADC9-527C83B57AF4_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 9 Mar 2018, at 12:27, John C Klensin wrote: > * Your explanation below is very helpful, at least to me. Me too. > I am > confident that, if it was what we were given when we started the IDNA20= 08 design, some of the rules would have reflected it. We were given a d= ifferent explanation and answer to our questions, one much closer to "the= re is no problem and will be no problem in the future, so don't worry - = no special rules are needed". Correct. Being on the receiving side of the messages, and one of the pers= ons that asked the questions, yes, we asked, they responded... > The question is what to do now. If we were to decide that your discuss= ion would made a good addition to the protocol, we would run into at leas= t two problems. One is that we promised the registry community that ther= e would be no more disruptive > changes and, at least as important, the Unicode Consortium > outrage at our altering the way a handful of code points were treated w= ould presumably be much greater if we were to make a change that would in= validate a large number of labels that might now be registered and in use= somewhere in the tree. Another is the problem that started this thread = -- there appears to be no energy in the IETF to consider and process chan= ges to IDNA, even fairly trivial clarifications. I think we should do some scenario planning here. Remember that we do not= have a world where IDNA2008 based on Unicode 6.x is what people use. Peo= ple use all different kind of mix between IDNA2008, IDNA2003 and Unicode = versions. I have myself worked with the curl library (that uses libidn) a= nd to be honest, I do not think people KNOW what they use. Or they know, = and they know they violate the rules. For the contracted parties, they ha= ve the LGR coming down the road anyways, so... And *if* we go down this path, is it "enough" to do in the LGR (i.e. ICAN= N) or should IETF do some adoption (and W3C?), or should IETF say "we can= move forward in a more safe way AS WE KNOW ICANN DO LGR"... Or... Patrik --=_MailMate_4BDAA92C-525B-4EF7-ADC9-527C83B57AF4_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iG0EARECAC0WIQRUH/cJI8i4DDUU3qWsxpsaC4jXzQUCWqPYQQ8ccGFmQGZyb2Ji aXQuc2UACgkQrMabGguI180AmACfdUx9qx1Abnc4Zc9U4MPDra9PFyUAn1/FoV8t R53uazCol2/J0+wsQVch =kF02 -----END PGP SIGNATURE----- --=_MailMate_4BDAA92C-525B-4EF7-ADC9-527C83B57AF4_=-- From nobody Sat Mar 10 05:51:47 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B5C124D37 for ; Sat, 10 Mar 2018 05:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UO8SGwjAWtYM for ; Sat, 10 Mar 2018 05:51:44 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 530561205F0 for ; Sat, 10 Mar 2018 05:51:44 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1eueuR-0006XF-Vh; Sat, 10 Mar 2018 08:51:39 -0500 Date: Sat, 10 Mar 2018 08:51:34 -0500 From: John C Klensin To: =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= cc: Asmus Freytag , idna-update@ietf.org Message-ID: In-Reply-To: <516E58F3-015D-4AD7-A3FD-0749A6890245@frobbit.se> References: <02c29140-29f1-cc81-8c4f-8249d0f23b2c@ix.netcom.com> <1E562CDE39B4224F227E765D@PSB> <516E58F3-015D-4AD7-A3FD-0749A6890245@frobbit.se> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Idna-update] IDNA and combining sequences (was: Re: Expiration impending: ) X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2018 13:51:46 -0000 --On Saturday, March 10, 2018 09:06 -0400 Patrik = F=C3=A4ltstr=C3=B6m wrote: > I think we should do some scenario planning here. Remember > that we do not have a world where IDNA2008 based on Unicode > 6.x is what people use. People use all different kind of mix > between IDNA2008, IDNA2003 and Unicode versions. I have myself > worked with the curl library (that uses libidn) and to be > honest, I do not think people KNOW what they use. Or they > know, and they know they violate the rules. For the contracted > parties, they have the LGR coming down the road anyways, so... >=20 > And *if* we go down this path, is it "enough" to do in the LGR > (i.e. ICANN) or should IETF do some adoption (and W3C?), or > should IETF say "we can move forward in a more safe way AS WE > KNOW ICANN DO LGR"... As I said at far more length in another note, the LGR is (at least by its charter/ Procedure) designed for, and applicable only to, the root. While those code points would probably be safe to use in any zone, trying to apply them globally would be unduly restrictive, would violate the "administratively distributed hierarchy" principle, and, IMO, just wouldn't fly.. The latter would probably quickly reach the point that attempts to apply the LGR to labels at the second level and beyond would encourage non-compliance and daring ICANN to do anything about it. =20 As an example of the overly restrictive part, I assume that the LGR rules, like the ccTLD Fast Track Procedures, would prohibit the use of "=D1=83=D1=80" (U+0443 U+0440) or other permutations = of those characters) in to root on the grounds of either intrinsic confusability or the potential conflict with the 3166-1 alpha-2 list. However, if we accept the logic that justifies IDN TLDs, that sequuence would be acceptable in a subtree of a domain whose TLD label was in Cyrillic and that published and applied a policy that its subdomains were entirely Cyrillic. > Or... I think the above puts us well into the "or..." range. best, john From nobody Sat Mar 10 08:24:48 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E31A126C26 for ; Sat, 10 Mar 2018 08:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.408 X-Spam-Level: X-Spam-Status: No, score=-0.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com header.b=iBxBoCrS; dkim=pass (2048-bit key) header.d=macchiato-com.20150623.gappssmtp.com header.b=rZteaDDF Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvTcAp83nIoB for ; Sat, 10 Mar 2018 08:24:44 -0800 (PST) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D08C7126B7E for ; Sat, 10 Mar 2018 08:24:43 -0800 (PST) Received: by mail-ot0-x234.google.com with SMTP id h8so11491960oti.6 for ; Sat, 10 Mar 2018 08:24:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=HDhoGoxFGFEB3ccIMYGPDQYBwjQ4dnkLmrLHcs5dEd4=; b=iBxBoCrSqKPP7hhyGOYJcr34ZxrvnYOEjDGjaC0Qo/KVFWPbAU3SaWLQDfVLAHyYXB Imb0zVnOf/YZlgd7QEm0pJa1ZSwaMaKyrvtm06CrIWDDM5ihJn+PB82s9gQ/iMEvZqEd MurGVa7MBLXS/qdh7OLdvNCeKKD4Uv0T1zMsY0XuopA3zx8zi+EuwTfgXsc/Rgq3Hwn3 YgEgeAJp+XtwFX346qevqPxnqpqhgpdCraOiUk90NsGlbJqcOYPVBVdUO01N1wgN8VAo 3JNuLcunDOdqWvmvzIrRhth9c0nYRVtJLZ6xdTz30/gv0R0B6+ApkMNitD5MO9uuGVDb iTmA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=macchiato-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=HDhoGoxFGFEB3ccIMYGPDQYBwjQ4dnkLmrLHcs5dEd4=; b=rZteaDDFOx2CJdIKrKHvg9LKNOXOPPQyHBtMBq9vrBSMMty/LlTnI7i9Zx8he65hcm jggQCEeFkkjhDjRYigdrKkKXRHbv9J3pbUN12hdCpV7KoNcACV71BKnTpmSL2NQxq3Se F3liWRQo+tob0dlo9oa9Ygl1HZIcfBQo3tlxoGpBhkzMqU/fsGXyxzvImWn/LHRkRCvu tKWcNtI656vJZkvBkWt4243Ege9yaM8/0lq3oIg5G7LCS9ayu4Inm0iU73uSVZLQuwCK IJgKrcw97pL9xCd9itDj2fdpGgcII5QXFFhs+JCXl+1GX1e6ZneeoeZA3wtLmEMPw17J lMRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=HDhoGoxFGFEB3ccIMYGPDQYBwjQ4dnkLmrLHcs5dEd4=; b=AuSRi8gpMsj3Xu4aDdicptrWkMujYSiXhGvIx7a4WrVzM8fiaelqK2MdaEQ6t1A9wX iW+LAddFoY+fJu3drLytdzBziVQbN+OeE5g0FBIMraIKGFaOBRVblxKBga6N8C51VfH3 8foNa0xDT4KIao/YN7OSVWAq22jJC8qtMjZXk1Gt50gcmtb/8cWgxhZN9+xpryQ24Nej Fw3wg2/cQK7r/+BSyCOmWT7qiEiMcFPXgYGmNsk8mGWmvBI8tD//i6rOev2fORXNyhNM PlNkVcqU/JjLLGCUshn2WPseHwISzJbEnLeEmjwqE6nP9MNv7dOoV4vWIIce59Tsf0dX Na0Q== X-Gm-Message-State: AElRT7Ek2k6M/s928g/d1FTcSmUmX6GYYI4LlQbNzwMwkCo0JVu4s62p DemCzkJMzGHydzSosp6sIyRkOU3eoKNx1YvzxQg= X-Google-Smtp-Source: AG47ELvyziE4BSHDDg0noN5Klh1qmxHWbf8NDUEh/teCnER7jrIbwRBRXU8DAspEJE54Ftn7wW+Nf9olWbhhezHQCn4= X-Received: by 10.157.38.175 with SMTP id l44mr1608467otb.217.1520699082984; Sat, 10 Mar 2018 08:24:42 -0800 (PST) MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 2002:a9d:7385:0:0:0:0:0 with HTTP; Sat, 10 Mar 2018 08:24:22 -0800 (PST) In-Reply-To: <516E58F3-015D-4AD7-A3FD-0749A6890245@frobbit.se> References: <02c29140-29f1-cc81-8c4f-8249d0f23b2c@ix.netcom.com> <1E562CDE39B4224F227E765D@PSB> <516E58F3-015D-4AD7-A3FD-0749A6890245@frobbit.se> From: =?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?= Date: Sat, 10 Mar 2018 17:24:22 +0100 X-Google-Sender-Auth: pbE3cw203YzNWXz372F9gsUG-UE Message-ID: To: =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= Cc: John C Klensin , idna-update@ietf.org, Asmus Freytag Content-Type: multipart/alternative; boundary="001a113ec6d8a6d3aa0567115804" Archived-At: Subject: Re: [Idna-update] IDNA and combining sequences (was: Re: Expiration impending: ) X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2018 16:24:46 -0000 --001a113ec6d8a6d3aa0567115804 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >> We were given a different explanation and answer to our questions, one much closer to "there is no problem and will be no problem in the future, so don't worry - no special rules are needed". > Correct. Being on the receiving side of the messages, and one of the persons that asked the questions, yes, we asked, they responded... I'm mystified as to who exactly you think said "there is no problem and will be no problem in the future" (or words to that effect), since I can't imagine any Unicode expert saying that NFC, NFKC, or the then-proposed IDNA 2008 solves the problem of visually visually indistinguishable or confusing characters. In fact, there are many emails on https://mailarchive.ietf.org/arch/search/?email_list=3Didna-update NFKC making it clear that NFKC reduces, but does not close to solving that issue. And the same for the then-proposed context rules. So I'm guessing that there was a misunderstanding as to the problem being discussed. Can you point to the email(s) on this list from a Unicode expert that you would characterize as responding that "there is no problem and will be no problem in the future, so don't worry - no special rules are needed" ? (Of course, it needn't be those exact words =E2=80=94 I just want to figure out= what was the foundation for your statement.) Mark On Sat, Mar 10, 2018 at 2:06 PM, Patrik F=C3=A4ltstr=C3=B6m wrote: > On 9 Mar 2018, at 12:27, John C Klensin wrote: > > > * Your explanation below is very helpful, at least to me. > > Me too. > > > I am > > confident that, if it was what we were given when we started the > IDNA2008 design, some of the rules would have reflected it. We were giv= en > a different explanation and answer to our questions, one much closer to > "there is no problem and will be no problem in the future, so don't worr= y > - no special rules are needed". > > Correct. Being on the receiving side of the messages, and one of the > persons that asked the questions, yes, we asked, they responded... > > > The question is what to do now. If we were to decide that your > discussion would made a good addition to the protocol, we would run into = at > least two problems. One is that we promised the registry community that > there would be no more disruptive > > changes and, at least as important, the Unicode Consortium > > outrage at our altering the way a handful of code points were treated > would presumably be much greater if we were to make a change that would > invalidate a large number of labels that might now be registered and in u= se > somewhere in the tree. Another is the problem that started this thread -= - > there appears to be no energy in the IETF to consider and process changes > to IDNA, even fairly trivial clarifications. > > I think we should do some scenario planning here. Remember that we do not > have a world where IDNA2008 based on Unicode 6.x is what people use. Peop= le > use all different kind of mix between IDNA2008, IDNA2003 and Unicode > versions. I have myself worked with the curl library (that uses libidn) a= nd > to be honest, I do not think people KNOW what they use. Or they know, and > they know they violate the rules. For the contracted parties, they have t= he > LGR coming down the road anyways, so... > > And *if* we go down this path, is it "enough" to do in the LGR (i.e. > ICANN) or should IETF do some adoption (and W3C?), or should IETF say "we > can move forward in a more safe way AS WE KNOW ICANN DO LGR"... > > Or... > > Patrik > > _______________________________________________ > IDNA-UPDATE mailing list > IDNA-UPDATE@ietf.org > https://www.ietf.org/mailman/listinfo/idna-update > > --001a113ec6d8a6d3aa0567115804 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>>=C2=A0We were given a= different explanation and answer to our questions, one much closer to &quo= t;there is no problem and will be no problem in=C2=A0 the future, so don= 9;t worry - no special rules are needed".
> Correct. Being on the receiving side of the messages, and one= of the persons that asked the questions, yes, we asked, they responded...<= /span>

= I'm mystified as to who exactly you think sa= id "there is no problem and will be no problem in the future" (or= words to that effect), since I can't imagine any Unicode expert saying= that NFC, NFKC, or the then-proposed IDNA 2008 solves the problem of visua= lly=C2=A0visually indistinguishable or confusing= characters. In fact, there are many emails on <= a href=3D"https://mailarchive.ietf.org/arch/search/?email_list=3Didna-updat= e">https://mailarchive.ietf.org/arch/search/?email_list=3Didna-update= =C2=A0NFKC making it clear that NF= KC reduces, but does not close to solving that issue. And the same for the = then-proposed context rules.

So I'm guessing that = there was a misunderstanding as to the problem being discussed.

Can you point to the email(s) on this list from a Unicode expert=C2=A0that you = would characterize as responding that "there= is no problem and will be no problem in=C2=A0 the future, so don't wor= ry - no special rules are needed"=C2=A0? (Of course, it needn&#= 39;t be those exact words =E2=80=94 I just want to figure out what was the = foundation for your statement.)


<= div>
<= div style=3D"background-color:transparent;margin-top:0px;margin-left:0px;ma= rgin-bottom:0px;margin-right:0px">Mark
<= /i>

On Sat, Mar 10, 2018 at 2:06 PM, Patrik F=C3= =A4ltstr=C3=B6m <paf@frobbit.se> wrote:
On 9 Mar 2018, at 12:27, John C Klensin wrote:<= br>
> * Your explanation below is very helpful, at least to me.

Me too.

> I am
> confident that, if it was what we were given when we started the IDNA2= 008 design, some of the rules would have reflected it.=C2=A0 =C2=A0We were = given a different explanation and answer to our questions, one much closer = to "there is no problem and will be no problem in=C2=A0 the future, so= don't worry - no special rules are needed".

Correct. Being on the receiving side of the messages, and one of the= persons that asked the questions, yes, we asked, they responded...

> The question is what to do now.=C2=A0 If we were to decide that your d= iscussion would made a good addition to the protocol, we would run into at = least two problems.=C2=A0 One is that we promised the registry community th= at there would be no more disruptive
> changes and, at least as important, the Unicode Consortium
> outrage at our altering the way a handful of code points were treated = would presumably be much greater if we were to make a change that would inv= alidate a large number of labels that might now be registered and in use so= mewhere in the tree.=C2=A0 Another is the problem that started this thread = -- there appears to be no energy in the IETF to consider and process change= s to IDNA, even fairly trivial clarifications.

I think we should do some scenario planning here. Remember that we d= o not have a world where IDNA2008 based on Unicode 6.x is what people use. = People use all different kind of mix between IDNA2008, IDNA2003 and Unicode= versions. I have myself worked with the curl library (that uses libidn) an= d to be honest, I do not think people KNOW what they use. Or they know, and= they know they violate the rules. For the contracted parties, they have th= e LGR coming down the road anyways, so...

And *if* we go down this path, is it "enough" to do in the LGR (i= .e. ICANN) or should IETF do some adoption (and W3C?), or should IETF say &= quot;we can move forward in a more safe way AS WE KNOW ICANN DO LGR"..= .

Or...

=C2=A0 =C2=A0Patrik

_______________________________________________
IDNA-UPDATE mailing list
IDNA-UPDATE@ietf.org
https://www.ietf.org/mailman/listinfo/idna-upd= ate


--001a113ec6d8a6d3aa0567115804-- From nobody Sat Mar 10 10:08:13 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65E9126DD9 for ; Sat, 10 Mar 2018 10:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ix.netcom.com; domainkeys=pass (2048-bit key) header.from=asmusf@ix.netcom.com header.d=ix.netcom.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKBSbt8vrjmN for ; Sat, 10 Mar 2018 10:08:09 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9F39124D68 for ; Sat, 10 Mar 2018 10:08:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ix.netcom.com; s=dk12062016; t=1520705289; bh=e7I57hpCQOnLFhgTEQ20VNprFkXjECtW9sjT 2RCV5FI=; h=Received:Subject:To:Cc:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Content-Language:X-ELNK-Trace: X-Originating-IP; b=RH0Pjf+f2iNJot0KYguT2J1LJe9x2RsEBFNXb3aWsucFi2 ZpfPbHJ8B6wf76D5CRUk3Sec63AFJBUzd946ptGHjf5u6VaVAwOBO68CjUZH/2GZQRA KwMuugq+tXmX2kLgWCvcCVO0NdqZdBOqW04wrtxgqDb1wRlSigINFuoKgZ51rKkLs6W HZcLG8+YQvKcX4YKF929vBXmaJosmIUrK/p1gx8BLryNhxgM5GX0x6UwU0gl4AAKbdk muTEavkaizZwOy7fdwIFoJVAItRMEnBGQgiP8GHoOX26+m8RMR4LpHtfmbeOYWx+GZz 8056wayb7HDKU+tCjv7uMZqOW49w== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=ix.netcom.com; b=hWipInacNINjTmaxaSxpyAEPgbFwDmMtW46D41UQhrKKmDmU7KpQYwJbZ3AdFDL2n4XImBjbVq0R1fmdul/NVuoJYBvoxX92Pc58MHlqCMhkGGh6fJx7EUnowTwar4mmJN2SJKKRk/I8Ic2OCfyiNFiKRBuCKZLLiQ2/ZLBh3z3mGhC1sB59ClJwP/CXLc0KJVKb2zhuTR7n3nE7c6cxgoSvBo6voSUz0Ilki/SxIdiSlbYuJzSQpo2bYeJF+tAFZ+Eh+9YZEKuLab4n5e/Po7o0R6E+hIYekbJDScyUeWGGXoJqex3+iky3KXvJ1RroZdL8i+gKhCBEZIBQo9q4mQ==; h=Received:Subject:To:Cc:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [46.21.151.107] (helo=[10.4.47.190]) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1euiub-00070i-UQ; Sat, 10 Mar 2018 13:08:06 -0500 To: John C Klensin , =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= Cc: idna-update@ietf.org References: <02c29140-29f1-cc81-8c4f-8249d0f23b2c@ix.netcom.com> <1E562CDE39B4224F227E765D@PSB> <516E58F3-015D-4AD7-A3FD-0749A6890245@frobbit.se> From: "Asmus Freytag (c)" Message-ID: <70445d5e-6294-26f5-50b8-cb9ae7345c56@ix.netcom.com> Date: Sat, 10 Mar 2018 10:08:08 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-ELNK-Trace: 464f085de979d7246f36dc87813833b2c1627926350bb93fe0b4bf86a1aafe751d858ffcef8ab932350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 46.21.151.107 Archived-At: Subject: Re: [Idna-update] IDNA and combining sequences X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2018 18:08:12 -0000 Patrik asked, where do we go from here. Let me propose something, but first some response to John. On 3/10/2018 5:51 AM, John C Klensin wrote: > > --On Saturday, March 10, 2018 09:06 -0400 Patrik Fältström > wrote: > >> I think we should do some scenario planning here. Remember >> that we do not have a world where IDNA2008 based on Unicode >> 6.x is what people use. People use all different kind of mix >> between IDNA2008, IDNA2003 and Unicode versions. I have myself >> worked with the curl library (that uses libidn) and to be >> honest, I do not think people KNOW what they use. Or they >> know, and they know they violate the rules. For the contracted >> parties, they have the LGR coming down the road anyways, so... Correct, and it doesn't stop there: some parties are off the reservation doing emoji... >> >> And *if* we go down this path, is it "enough" to do in the LGR >> (i.e. ICANN) or should IETF do some adoption (and W3C?), or >> should IETF say "we can move forward in a more safe way AS WE >> KNOW ICANN DO LGR"... > As I said at far more length in another note, the LGR is (at > least by its charter/ Procedure) designed for, and applicable > only to, the root. While those code points would probably be > safe to use in any zone, trying to apply them globally would be > unduly restrictive, would violate the "administratively > distributed hierarchy" principle, and, IMO, just wouldn't fly.. > The latter would probably quickly reach the point that attempts > to apply the LGR to labels at the second level and beyond would > encourage non-compliance and daring ICANN to do anything about > it. Totally agree. There's no benefit in "imposing" the RZ-LGR on other zones. However, the various script LGRs can serve both as examples and as starting points. They do contain (or are about to contain) worked examples of repertoire context rules and or variant rules applicable to modern users of each script. They are also heavily documented, so that anybody can understand the "why" behind their design. That makes them useful as a starting point as well, to which you can add features as needed. One thing almost anyone will want to add outside the root zone is digits (and the hyphen). That's why I have consistently argued that the RZ-LGR is a useful example and starting point. > > As an example of the overly restrictive part, I assume that the > LGR rules, like the ccTLD Fast Track Procedures, would prohibit > the use of "ур" (U+0443 U+0440) or other permutations of those > characters) in to root on the grounds of either intrinsic > confusability or the potential conflict with the 3166-1 alpha-2 > list. The LGR does not have to "prohibit" these. Instead, they are recognized as so-called cross-script variants of the Latin letter. Meaning, if you have a label containing Latin "yp" in the root, then you do not get to use Cyrillic "ур"in some other label, if the two would otherwise be (or look) the same. However, you remain free to use Cyrillic "ур" in any label that does not collide with some Latin label, either because no homograph label exists, or because yours has some specific Cyrillic code point in it that would distinguish it. The ability to use the variant mechanism for such cases is  the main difference between using LGRs (aka idn tables) compared to the protocol in enforcing restrictions. The cross-script variant mechanism is a more appropriate method to address issues like that, because it doesn't blindly ban perfectly acceptable uses of code points, but instead resolves any conflicts in favor of the first mover. This reflects linguistic reality - in most cases, cross-script labels that are homographs would look more than a bit "contrived", such the licence plate with the Russian expletive AXY HEXO that some Unicoder had for a while - it makes no sense in English, and passed the DMV. At one point, we did some research in one of the scripts and found that defining even a substantial numbers of such variants had little impact on blocking legitimate words. Had a similar number of code points been banned, the utility of the IDN labels would have been seriously compromised. For that reason alone, simply banning code points is more restrictive than necessary. > However, if we accept the logic that justifies IDN TLDs, > that sequuence would be acceptable in a subtree of a domain > whose TLD label was in Cyrillic and that published and applied a > policy that its subdomains were entirely Cyrillic. There are other RZ restrictions (no digits, no hyphen) that aren't appropriate for zones lower down the tree. And there are a few cases where it wasn't possible to cater to all languages in a given script simultaneously, as some had conflicting conventions (for complex scripts). Such cases, while rare, are another good reason to use the Root Zone as a starting point (and not the end-point) of LGR design for other Zones. However,  the audience of 90%+ of existing zones would have been served equally well had their idntables and policies been based on nothing more than the RZ-LGR plus digits and hyphen. The stuff that the Root Zone restricts is very often simply not in use. > >> Or... > I think the above puts us well into the "or..." range. > I think we've come to that conclusion before - and we keep revisiting ground that I thought had somewhat settled. We had been working on a two-prong approach, of which your ID was one of the prongs: 1) to reiterate that the "raw" protocol doesn't by itself design useful and secure LGRs (aka. idn tables/policies), but requires conscious selection (and other decisions). 2) to give guidance as to what the issues are and how to address them. Now, we thought that the best approach for the second prong was to create a registry of "troublesome" code points. That turned out to be more challenging than anticipated. Not because it is difficult to come up with a list. That's actually not as difficult as it looks - for modern scripts. No, the issue is that the code points, like your example of "yp" are not problematic in isolation. What then should get listed? If we list just the Cyrillic code points, then people creating a Cyrillic zone will complain loudly that the entry is unjustified. If we list both the Latin and the Cyrillic code point, on the basis that their interaction is problematic, we get that reaction from two groups. However, in the RZ effort, both groups were perfectly happy defining mutually blocked variants - in fact, we had to stop them from going overboard. . . . Where to we need to go? We need some recommendation that goes beyond "know what you are doing" (while true, it's too vague to be helpful). We need a set of recommendations that is more or less like the example I wrote down for the combining marks. Something that's specific enough that people can act on it, but also can be adjusted to fit circumstances. In writing recommendations for (more) "secure" IDNs, it's important to make a distinction between modern-use scripts and the vast number of historical scripts and technical (phonetic) notations. The latter are really not well suited to secure use in public zones. (The protocol must cater for non-public zones as well). Now, one option would be to create something like a "profile" on IDNA2008 for "(more) secure IDNs for public zone." Doing that would sidestep the issue of backwards compatibility because you could be more restrictive; however, there's the same issue that any enumerated restrictions would run into the same issues of changes in usage (spelling reforms) or changes in encoding. However, qualitative descriptions wouldn't suffer as much from that issue; I think they would add value, whether as recommendation or as "profile". A./ From nobody Sat Mar 10 10:29:12 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B555F124E15 for ; Sat, 10 Mar 2018 10:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.761 X-Spam-Level: X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=LTXopEXC; dkim=pass (1536-bit key) header.d=taugh.com header.b=Ov48At4J Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tE78hgZc5BO for ; Sat, 10 Mar 2018 10:29:10 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA081124235 for ; Sat, 10 Mar 2018 10:29:09 -0800 (PST) Received: (qmail 26384 invoked from network); 10 Mar 2018 18:29:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=670e.5aa423f4.k1803; bh=QZOIgitTWW2Fb2W0lVzhzC31HbSwM7OKpc89gaaTzLY=; b=LTXopEXCl6Hjni4pBiUhavhYELznxYZP2jb2YIDvQjvBLNfhukgfDhu/XHT2il2kGGEXOF3W263Q9FC0K2FQU144seVlfDgotVWMRSyJr8AKzAOW2Q0g8aRzkQIFT1WJYb9rzjeGs6sKaNxGWaimvrOzGEy77GdW6Yptm51CY2VSIMAhKMoSOmSgPywedzMWHBAR8YTDFU0cAQp/ezaTb9W8t2Sj/el0vMP0ZDe/5Ixi8yEv/wh1RwOwyWbAdMUl DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=670e.5aa423f4.k1803; bh=QZOIgitTWW2Fb2W0lVzhzC31HbSwM7OKpc89gaaTzLY=; b=Ov48At4J/IKL5CWWAUUU5o3ZpO1t4QPWQVDdFhqS2zALg//uJD2VUVxBrEggcO303lGvyf2QRb0raSxO9Ou4pBQgsIKGvVVS2t8TXSjzTpwy6M3KlqWgOFBVw/t203vlPBWRaPKkD2zgmAVylHr9ukM4JKAlemfIfjW+61b6NlWxhwl+kNdo56IJC2dDXLhJ1/KmuzTACjXkyKnb/ZnBFsoVAzXj5GLU87BZi/KNef5azln76jLM34zhqpuVaY6q Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 10 Mar 2018 18:29:08 -0000 Received: by ary.qy (Postfix, from userid 501) id 56AE82216259; Sat, 10 Mar 2018 13:29:07 -0500 (EST) Date: 10 Mar 2018 13:29:07 -0500 Message-Id: <20180310182908.56AE82216259@ary.qy> From: "John Levine" To: idna-update@ietf.org Cc: john-ietf@jck.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Idna-update] IDNA and combining sequences (was: Re: Expiration impending: ) X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2018 18:29:11 -0000 In article you write: >The latter would probably quickly reach the point that attempts >to apply the LGR to labels at the second level and beyond would >encourage non-compliance and daring ICANN to do anything about >it. I'm confused. Every gTLD and many ccTLDS have language and script rules that limit what 2LDs they will accept. When I was looking at gTLD applications, the rules all looked pretty reasonable, give or take what you think is a reasonable approach to handling variants. What am I missing? I realize that below the 2LDs anything goes. R's, John From nobody Sat Mar 10 21:57:48 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3F71277BB for ; Sat, 10 Mar 2018 21:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.729 X-Spam-Level: X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ix.netcom.com; domainkeys=pass (2048-bit key) header.from=asmusf@ix.netcom.com header.d=ix.netcom.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KcGqFTtoBIF for ; Sat, 10 Mar 2018 21:57:44 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22B76126B6E for ; Sat, 10 Mar 2018 21:57:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ix.netcom.com; s=dk12062016; t=1520747864; bh=bbtaITmx2iZZCfO+afAqqiGE4iTvqNRPE1D1 vZim7Wc=; h=Received:Subject:To:Cc:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language: X-ELNK-Trace:X-Originating-IP; b=phXenqrYdKupfb/ZcU5n6/55A9BxfOHgO xQ8hLqzKfkZ5ADlbXPagXZgfipmLcYLyeTQgvX26eQHTR9Q5hXbR9CneCjRCA3Vnf/d eC0xRT51cZ+nd1IRqcAtiaWuck7hieTCcrTkttq00b0PsclJMmFBtYtiVDT5zS8CNKC uHYdMLX1AAfC5WjqZJeP5hnPUyIzAKo8p142kWvPFsDHviBW19ueO9uhgRMz36HaXEN kr/YI5tETXEV9OQCArfBQHS4HpUCcCCR536ni3+RDTmk2zPppVsP1iX0fyy8WXbQKfl WINxQp9Ci77ZfoSOdluNIYNR244Le+IJiA4IMbLEQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=ix.netcom.com; b=EtnFqBNbDk82i0FPLhixxJJuKFr3j0mV3BrBXFIFjDlb1xaA0+NkOJwqQO4V544qb2bELftlp2qHIEX5nljlsVd8JE/Pjeh2WCOl3eMgrQwA5vpG+3yjFRfEgSIz5Z6enKoeLi1kL3nUaqhk36lxADqB80nEjF19OP3nx5LidI/GNCmi/VFINX34BBqaksJTOGm+i6x+tZR2StqKC1q1kx75uPiyVsH4dOw4v9lrbTN8LyRWjIF2QTySxNdDsnvJ2wgl7DcAO5jBUkf4K97oh5yD4AChhLPGuk97i1QTn5fjBsJC88Kssu+k1uM4qOrm9YA0cWbtY9gUuJ1rb7yfWQ==; h=Received:Subject:To:Cc:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [46.21.151.107] (helo=[10.4.47.190]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1eutzI-0008Ux-A1; Sun, 11 Mar 2018 00:57:40 -0500 To: =?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?= , =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= Cc: John C Klensin , idna-update@ietf.org References: <02c29140-29f1-cc81-8c4f-8249d0f23b2c@ix.netcom.com> <1E562CDE39B4224F227E765D@PSB> <516E58F3-015D-4AD7-A3FD-0749A6890245@frobbit.se> From: "Asmus Freytag (c)" Message-ID: Date: Sat, 10 Mar 2018 21:57:47 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4B9D00D0C882988F503E9467" Content-Language: en-US X-ELNK-Trace: 464f085de979d7246f36dc87813833b2c1627926350bb93f6410fd31f8a042f3b9038d14ca5c4f0e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 46.21.151.107 Archived-At: Subject: Re: [Idna-update] IDNA and combining sequences X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2018 05:57:46 -0000 This is a multi-part message in MIME format. --------------4B9D00D0C882988F503E9467 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I was not centrally involved in these discussions, but knowing a bit about the different backgrounds and frames of reference of the participants I would not be surprised to learn that there was a certain amount of miscommunication leading to some fundamental disconnect in understanding.... However, independent of the details of what may have been exchanged a decade ago, I strongly  suspect that going over that ground is going to do little in terms of helping to make progress forward. Instead, the sole question we should be asking is what can we do to effectively improve the experience involving IDNs. A./ On 3/10/2018 8:24 AM, Mark Davis ☕️ wrote: > >> We were given a different explanation and answer to our questions, > one much closer to "there is no problem and will be no problem in  the > future, so don't worry - no special rules are needed". > > Correct. Being on the receiving side of the messages, and one of the > persons that asked the questions, yes, we asked, they responded... > > I'm mystified as to who exactly you think said "there is no problem > and will be no problem in the future" (or words to that effect), since > I can't imagine any Unicode expert saying that NFC, NFKC, or the > then-proposed IDNA 2008 solves the problem of visually visually > indistinguishable or confusing characters. In fact, there are many > emails on > https://mailarchive.ietf.org/arch/search/?email_list=idna-update NFKC > making it clear that NFKC reduces, but does not close to solving that > issue. And the same for the then-proposed context rules. > > So I'm guessing that there was a misunderstanding as to the problem > being discussed. > > Can you point to the email(s) on this list from a Unicode expertthat > you would characterize as responding that "there is no problem and > will be no problem in  the future, so don't worry - no special rules > are needed" ? (Of course, it needn't be those exact words — I just > want to figure out what was the foundation for your statement.) > > > Mark > // > > On Sat, Mar 10, 2018 at 2:06 PM, Patrik Fältström > wrote: > > On 9 Mar 2018, at 12:27, John C Klensin wrote: > > > * Your explanation below is very helpful, at least to me. > > Me too. > > > I am > > confident that, if it was what we were given when we started the > IDNA2008 design, some of the rules would have reflected it.   We > were given a different explanation and answer to our questions, > one much closer to "there is no problem and will be no problem in  > the future, so don't worry - no special rules are needed". > > Correct. Being on the receiving side of the messages, and one of > the persons that asked the questions, yes, we asked, they responded... > > > The question is what to do now.  If we were to decide that your > discussion would made a good addition to the protocol, we would > run into at least two problems.  One is that we promised the > registry community that there would be no more disruptive > > changes and, at least as important, the Unicode Consortium > > outrage at our altering the way a handful of code points were > treated would presumably be much greater if we were to make a > change that would invalidate a large number of labels that might > now be registered and in use somewhere in the tree.  Another is > the problem that started this thread -- there appears to be no > energy in the IETF to consider and process changes to IDNA, even > fairly trivial clarifications. > > I think we should do some scenario planning here. Remember that we > do not have a world where IDNA2008 based on Unicode 6.x is what > people use. People use all different kind of mix between IDNA2008, > IDNA2003 and Unicode versions. I have myself worked with the curl > library (that uses libidn) and to be honest, I do not think people > KNOW what they use. Or they know, and they know they violate the > rules. For the contracted parties, they have the LGR coming down > the road anyways, so... > > And *if* we go down this path, is it "enough" to do in the LGR > (i.e. ICANN) or should IETF do some adoption (and W3C?), or should > IETF say "we can move forward in a more safe way AS WE KNOW ICANN > DO LGR"... > > Or... > >    Patrik > > _______________________________________________ > IDNA-UPDATE mailing list > IDNA-UPDATE@ietf.org > https://www.ietf.org/mailman/listinfo/idna-update > > > --------------4B9D00D0C882988F503E9467 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
I was not centrally involved in these discussions, but knowing a bit about the different backgrounds and frames of reference of the participants I would not be surprised to learn that there was a certain amount of miscommunication leading to some fundamental disconnect in understanding....

However, independent of the details of what may have been exchanged a decade ago, I strongly  suspect that going over that ground is going to do little in terms of helping to make progress forward.

Instead, the sole question we should be asking is what can we do to effectively improve the experience involving IDNs.

A./

On 3/10/2018 8:24 AM, Mark Davis ☕️ wrote:
>> We were given a different explanation and answer to our questions, one much closer to "there is no problem and will be no problem in  the future, so don't worry - no special rules are needed".
> Correct. Being on the receiving side of the messages, and one of the persons that asked the questions, yes, we asked, they responded...

I'm mystified as to who exactly you think said "there is no problem and will be no problem in the future" (or words to that effect), since I can't imagine any Unicode expert saying that NFC, NFKC, or the then-proposed IDNA 2008 solves the problem of visually visually indistinguishable or confusing characters. In fact, there are many emails on https://mailarchive.ietf.org/arch/search/?email_list=idna-update NFKC making it clear that NFKC reduces, but does not close to solving that issue. And the same for the then-proposed context rules.

So I'm guessing that there was a misunderstanding as to the problem being discussed.

Can you point to the email(s) on this list from a Unicode expert that you would characterize as responding that "there is no problem and will be no problem in  the future, so don't worry - no special rules are needed" ? (Of course, it needn't be those exact words — I just want to figure out what was the foundation for your statement.)


Mark

On Sat, Mar 10, 2018 at 2:06 PM, Patrik Fältström <paf@frobbit.se> wrote:
On 9 Mar 2018, at 12:27, John C Klensin wrote:

> * Your explanation below is very helpful, at least to me.

Me too.

> I am
> confident that, if it was what we were given when we started the IDNA2008 design, some of the rules would have reflected it.   We were given a different explanation and answer to our questions, one much closer to "there is no problem and will be no problem in  the future, so don't worry - no special rules are needed".

Correct. Being on the receiving side of the messages, and one of the persons that asked the questions, yes, we asked, they responded...

> The question is what to do now.  If we were to decide that your discussion would made a good addition to the protocol, we would run into at least two problems.  One is that we promised the registry community that there would be no more disruptive
> changes and, at least as important, the Unicode Consortium
> outrage at our altering the way a handful of code points were treated would presumably be much greater if we were to make a change that would invalidate a large number of labels that might now be registered and in use somewhere in the tree.  Another is the problem that started this thread -- there appears to be no energy in the IETF to consider and process changes to IDNA, even fairly trivial clarifications.

I think we should do some scenario planning here. Remember that we do not have a world where IDNA2008 based on Unicode 6.x is what people use. People use all different kind of mix between IDNA2008, IDNA2003 and Unicode versions. I have myself worked with the curl library (that uses libidn) and to be honest, I do not think people KNOW what they use. Or they know, and they know they violate the rules. For the contracted parties, they have the LGR coming down the road anyways, so...

And *if* we go down this path, is it "enough" to do in the LGR (i.e. ICANN) or should IETF do some adoption (and W3C?), or should IETF say "we can move forward in a more safe way AS WE KNOW ICANN DO LGR"...

Or...

   Patrik

_______________________________________________
IDNA-UPDATE mailing list
IDNA-UPDATE@ietf.org
https://www.ietf.org/mailman/listinfo/idna-update



--------------4B9D00D0C882988F503E9467-- From nobody Sat Mar 10 23:28:49 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E713E1200F1 for ; Sat, 10 Mar 2018 23:28:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ix.netcom.com; domainkeys=pass (2048-bit key) header.from=asmusf@ix.netcom.com header.d=ix.netcom.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHQYTgyDlbv9 for ; Sat, 10 Mar 2018 23:28:45 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C91C8120227 for ; Sat, 10 Mar 2018 23:28:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ix.netcom.com; s=dk12062016; t=1520753325; bh=/HLhBylQqifRhBQbmNCWvwRjnA4n6Non3Wgu Wyy1Mxc=; h=Received:Subject:To:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Content-Language:X-ELNK-Trace: X-Originating-IP; b=AXeK9NRVuYzzFSrdjzJpJuZvrHoNYJlG+j5EhiUHodEgCM tmPWdOZ0UEfbpw5/Gxc+ZllZwRQyC5EjKc45lrU638+IV42EUipH28iN/LWus96TL+E oG2IoDUNQerN2+KurPK91gbbp0dCTpRP9NX8Nd+xgKICf5/V4ulalWW+RfwudQzePlY 1sUvTBPr1gv4jWgeaFHaAzBqPKmdSIhzCx27fd/1Tcw/b+MWvr9lv+PiWLVf4q0tM00 enyWunmqUpfD873jkGRcTzmVoKTH8R4xsOk/Gk/O/mDEUduTILbhRkxyKvh/O2e5/oH BZjcgwTjnXXMpHl389bT8TbAVH+A== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=ix.netcom.com; b=E+3AuN4/Lh4VIZlk1DZrnEl8RKacCedVhNsSFI948Z0/P3oGnlswJFiIibJk13GM/b4ngH3bFyMSRs1l3SzUGhb/AOE1yQJ4PKScBxxCGQQFHsls1nS6nm73LY016qyMoYQYFycdaMRRrNrqrzUcqIQwW4B+Vb0FlEpD7CZW7yIaaCLLwun1QcvyhKmYWd8nCrk/g8xbToWQ4S+58FV84pJ++AIJ8/3BibwP9DWgDOVyguJXgD0e+C+gznIbBZq2GnsNxQfjVInaTbZ1q/bJnAY1/o3NZuQx5biiaehqThy7BqySs0+Hrv+P0xCUwiQJqEhLX0B02g0ZkByn/3rSpg==; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [46.21.151.107] (helo=[10.4.47.190]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1euvPP-000EqH-AG for idna-update@ietf.org; Sun, 11 Mar 2018 03:28:44 -0400 To: idna-update@ietf.org References: <20180308174703.q3bffw7anrvjwzym@mx4.yitter.info> <2D4E04E4B3BB56404560C142@PSB> <20180308193744.rkyyz3omuxyd7ehg@mx4.yitter.info> From: Asmus Freytag Message-ID: Date: Sat, 10 Mar 2018 23:28:51 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-ELNK-Trace: 464f085de979d7246f36dc87813833b2c1627926350bb93f524352281340815f899841cc275f10cf350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 46.21.151.107 Archived-At: Subject: Re: [Idna-update] Expiration impending: X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2018 07:28:48 -0000 On 3/9/2018 9:13 AM, John C Klensin wrote: > > --On Thursday, March 8, 2018 14:37 -0500 Andrew Sullivan > wrote: > >> On Thu, Mar 08, 2018 at 02:11:21PM -0500, John C Klensin wrote: >>> On the other hand, the same kind of thinking that argues for >>> a "troublesome characters" list (at least as I've understood >>> it) -- more "you SHOULD NOT use these unless you are >>> extra-sure you know what you are doing and what the >>> implications might be" than any sort of absolute prohibition >>> -- might imply a similar statement about combining sequences. >> That actually doesn't seem like a terrible idea to me. Of >> course, that was _supposed_ to be the point of the general >> exhortation to have a clue about the code points you were >> putting in a zone. And that doesn't seem to have panned out >> :-/ > Well, and this may apply to Asmus's recent notes (including a > more nuanced view of combining sequences) too, I'm trying to > think in terms of, and maybe adjust, a distinction that goes > back to at least the earliest discussions of IDNs and IDN > policies. ... eliding discussion of elements of the protocol and stipulating for the remainder of the discussion that protocol and its requirements are assumed to be met. > > (2) Advice, guidelines, or policy requirements applicable to a > broad variety of domains. May not need to define precisely what the limits of that variety is, but should note that zones where all labels are owned by the same entity may already be restrictive in other ways, whereas zones that not only are "public" but also support users of more than one script (and by extension multiple languages are perhaps most in need of these). > Unless we are going to have chaos, > such guidelines must allow only a subset of what is allowed > under the protocol limitations above. Agreed. > For zones that are well > and carefully run, with name use and the best interests of > Internet users in mind, it is reasonable to expect that > well-designed guidelines will be followed, as least unless the > zone administrators understand things well enough to carefully > allow exceptions. These zones will take active steps to mitigate issues caused by the fact that IDNs are necessarily reflective of f the writing systems involved - including their comparative complexity vis a vis the basic Latin alphabet. > The meta-rule that zones are required to > understand what they are doing is one such guideline and, at > least to a first approximation, I think most registries > (including zones below the second level that are using IDNs) > try. Not my impression at all. For anything other than very simple scripts, the IDNtables that can be easily inspected because they are available online as tables are not reflective of a deeper understanding of the writing system, beyond the most basic limitation of the repertoire to a given script. > For those who are not inclined (for business or other > reasons), to follow such guidelines, the guidelines are only as > good as the existence of someone who is willing and able to > enforce them or otherwise discourage bad behavior. "willing" registries might benefit from more detailed guidelines that would give them a metric of how successful their "attempts" turned out to be. I think at least some of them might be surprised at the result. > > What has not panned out is the assumption that ICANN would make > at least some serious effort to either persuade or induce > registries, even second-level entities under contracted TLD > registries, to follow those guidelines, especially with > regard to taking active responsibility for what they are doing. This is an empty letter as long as no guidelines exist that establish meaningful metrics allowing to tell apart successful mitigation from simply copying some basically insufficient IDN table from some other zone. > But that doesn't make establishing the guidelines a bad idea. > I'm not aware of it having happened yet with IDNs, but there is > precedent for people who are harmed by someone else's bad > behavior to cite violation of widely-accepted guidelines as > evidence that the behavior was bad or negligent. This would be a beneficial use of guidelines that actually cover meaningful best-practice. > > (3) The rules that are used by the operator/ administrator of a > particular registry to determine what can or will be allowed in > that zone. Note that for many zones what is allowed is not static, but depends on what is already delegated. The rules effectively describe what is allowed next, given a status quo. This approach is something that is useful (or should be understood as useful) for the majority of zones: in all zones registrants compete for available labels, but in some zones, a delegated label does not only prevent the same label, but also certain related labels from being registered. Such related labels are called variants -- but the use of the term variants does not necessary imply that more than one label gets to be allocated. On the contrary, our experience in Root Zone has shown that blocked variants are by far more common and useful tool. > Noting that the rules for the root (including the > LGR rules but not limited to them, at least yet) are just a > special case of this category, all that is necessary to > application and enforcement of the rules is that the registry > decide to do so... and that the rules that are chosen be > sufficiently acceptable to whatever community(ies) are in a > position to hold the registry accountable that they don't either > turn into a source of never-ending strife or change often enough > to cause perceived instability. Again, the Root Zone project is informative. So far, a single proposed script LGR has proven contentious -- with the wider community objecting to it being too permissive, rather than the other way around. As this has not reached the stage where an LGR has been submitted, the community may yet come to some agreement. Generally, the drafting panels appear to have been well anchored in their respective communities and their submitted proposals perform well when tested against lists of putative labels while mitigating known issues. > > I think some of our discussions have confused the first two and > last two categories and then gone on to confuse the third > (general guidelines for the second level and below) and fourth > (registry-specific rules), assuming, for example, that what is > suitable for one registry should be applicable, either as a > guideline or as a protocol changes, to the others. Very cogent observation. I'm certainly keenly aware of the difference between the RZ-LGR project which effectively results in registry-specific rules (for the root) and general guidelines that can be used to define registry-specific rules on other levels. The RZ-LGR is purposefully limited to the modern-use subset of modern- use scripts. (It also includes hyphen and digits). It further makes the assump- tion that the zone is shared by users of multiple scripts - and users of "all" languages - at least those that are widely written for everyday purposes. The individual script LGRs are also accompanied by very detailed description and references to source materials. That allows them to serve as examples/starting point for defining registry- specific rules for other zones. The closer these zones match the other assumptions for the RZ project, the closer to the RZ-LGR their eventual rules would be expected to end up - unless the RZ-LGR erred in how to account for the risks inherent in multi-script/multi-zone domains. This simplifies the task of the guideline writer, without reducing the task to simply imposing the RZ-LGR unexamined everywhere. If I were to be asked by a registry to develop policy for the second level, I might proceed as follows: (0) Start with the RZ-LGR s for all the scripts to be supported in the new zone. (1) Add all digits and the hyphen (1a) Mitigate the issue of homoglyph digits (Arabic) by making them blocked         in-script variants (1b) Mitigate the issue of some digits being homglyphs of letters by making        these blocked in-script variants (2) Retain cross-script variants from RZ-LGR for all scripts in the new zone (3) Optional, if a feature (restriction) in the RZ-LGR is documented as being       motivated by the need to be particularly restrictive for the root,       investigate the cost/benefit of removing the restriction. (If in doubt       keep the restriction). (4) If the zone is limited to certain languages, remove features (restrictions)       documented as being necessary in a multilingual zone (4a) investigate the cost/benefit of adding language-specific support for any        language that isn't well-supported due to RZ restrictions. (5) Make sure LGR follows guidelines on combining marks; (like the ones       we discussed under separate cover. (6) Make sure LGR follows guidelines on repertoire (TBD). (7) Make sure WLE rules and context rules continue to work if repertoire      expanded     (7a) It may be appropriate to relax / tighten some of these rules if      the mix of languages to be supported requires that or benefits from it. and so on. The guidelines would effectively focus on well-understood modern-use script, because that's what is addressed by the RZ-LGR. Because (most) historical scripts are supremely ill-understood and have not had the benefit of any deeper analysis for IDN purposes, a general guideline would strongly recommend against including them. Some lesser-used and/or emerging scripts (with modern user communities) would benefit from their communities following the RZ-LGR procedure with appropriate adaptations. Some very limited zones, e.g. Cyrillic only, or Polynesian only, might come under pressure to support code points for characters that look like punctuation marks; these code points were not ruled out in IDNA, but are considered deeply troublesome (not least by RFC 6912) -- actual guidelines would have to be written so as to settle the question whether "secure" LGRs should always eschew them, or whether limited exceptions are to be seen as justified. The issues facing the various scripts are diverse enough that trying to write fully general guidelines gets either meaningless (too vague) or bewilderingly complex in no time. That's the reason I keep coming back to the use of the RZ-LGR as a non-binding starting point. A./ From nobody Sun Mar 11 03:57:42 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD952124B0A for ; Sun, 11 Mar 2018 03:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaN3uX_6x_1v for ; Sun, 11 Mar 2018 03:57:40 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D6781201FA for ; Sun, 11 Mar 2018 03:57:40 -0700 (PDT) Received: from [172.20.5.159] (unknown [67.203.214.34]) by mail.frobbit.se (Postfix) with ESMTPSA id 293B6200CC; Sun, 11 Mar 2018 11:57:35 +0100 (CET) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "Asmus Freytag" Cc: "Mark Davis =?utf-8?b?4piV77iP?=" , "John C Klensin" , idna-update@ietf.org Date: Sun, 11 Mar 2018 06:57:32 -0400 X-Mailer: MailMate (2.0BETAr6104) Message-ID: <2243242A-C30E-48E4-9E75-4CCBB56E0B91@frobbit.se> In-Reply-To: References: <02c29140-29f1-cc81-8c4f-8249d0f23b2c@ix.netcom.com> <1E562CDE39B4224F227E765D@PSB> <516E58F3-015D-4AD7-A3FD-0749A6890245@frobbit.se> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_DEFA96A9-5246-4CD2-B169-3C7E15132876_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [Idna-update] IDNA and combining sequences X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2018 10:57:42 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_DEFA96A9-5246-4CD2-B169-3C7E15132876_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11 Mar 2018, at 1:57, Asmus Freytag (c) wrote: > However, independent of the details of what may have been exchanged a d= ecade ago, I strongly=C2=A0 suspect that going over that ground is going = to do little in terms of helping to make progress forward. > > Instead, the sole question we should be asking is what can we do to eff= ectively improve the experience involving IDNs. +1 Thanks Asmus. paf --=_MailMate_DEFA96A9-5246-4CD2-B169-3C7E15132876_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iG0EARECAC0WIQRUH/cJI8i4DDUU3qWsxpsaC4jXzQUCWqULnA8ccGFmQGZyb2Ji aXQuc2UACgkQrMabGguI183d/gCfT5gIBdV779NlK27WGzc4AJ6GC/UAmQFA8qif 0eXMz0xd7xIaNREQZRRQ =+1qm -----END PGP SIGNATURE----- --=_MailMate_DEFA96A9-5246-4CD2-B169-3C7E15132876_=-- From nobody Sun Mar 11 06:43:36 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5E9126D05 for ; Sun, 11 Mar 2018 06:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiHu6h91-O8K for ; Sun, 11 Mar 2018 06:43:33 -0700 (PDT) Received: from bsa3.jck.com (unknown [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 712831201FA for ; Sun, 11 Mar 2018 06:43:33 -0700 (PDT) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ev1G0-0004Bb-Sv; Sun, 11 Mar 2018 09:43:24 -0400 Date: Sun, 11 Mar 2018 09:43:19 -0400 From: John C Klensin To: "Asmus Freytag (c)" cc: =?UTF-8?Q?Mark_Davis_=E2=98=95=EF=B8=8F?= , =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= , idna-update@ietf.org Message-ID: In-Reply-To: References: <02c29140-29f1-cc81-8c4f-8249d0f23b2c@ix.netcom.com> <1E562CDE39B4224F227E765D@PSB> <516E58F3-015D-4AD7-A3FD-0749A6890245@frobbit.se> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Archived-At: Subject: Re: [Idna-update] IDNA and combining sequences X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2018 13:43:35 -0000 --On Saturday, 10 March, 2018 21:57 -0800 "Asmus Freytag (c)" wrote: >... > However, independent of the details of what may have been > exchanged a decade ago, I strongly=C2=A0 suspect that going = over > that ground is going to do little in terms of helping to make > progress forward. >=20 > Instead, the sole question we should be asking is what can we > do to effectively improve the experience involving IDNs. I concur. The history is not, however, completely irrelevant. It can be important to avoid repeating prior mistakes and, perhaps, to calibrate some proposals going forward. =20 In particular, there is some non-technical history that may constrain what we can consider today. In addition to a change of model, IDNA2008 included a few changes that invalidated some labels that were possibly in use ("possibly" because I'm talking about the whole DNS now, not just the root zone or second-level names) and changed the interpretation of others. Those changes were controversial and arguably remain so, but there was broad consensus in the registry community that they were worth it if (and perhaps only if) that type of change never occurred again. If we take that as a constraint today, a guideline that says "don't do so-and-so unless you have a very good reason" would still allow registries to "grandfather" existing names or make other rules about them as needed. A protocol change, especially one with lookup-time implications, would not have that property. That is one of several reasons why the three-level distinction I tried to make in my earlier note is important. best, john From nobody Sun Mar 11 07:45:09 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1434126CC4 for ; Sun, 11 Mar 2018 07:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nJ0jNQu_hSt for ; Sun, 11 Mar 2018 07:45:06 -0700 (PDT) Received: from bsa3.jck.com (unknown [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 621F7126BF0 for ; Sun, 11 Mar 2018 07:45:06 -0700 (PDT) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ev2Dd-0004F2-HC; Sun, 11 Mar 2018 10:45:01 -0400 Date: Sun, 11 Mar 2018 10:44:56 -0400 From: John C Klensin To: John Levine cc: idna-update@ietf.org Message-ID: <6FAA2D68A20DF091B0E0086B@JcK-HP5.jck.com> In-Reply-To: <20180310182908.56AE82216259@ary.qy> References: <20180310182908.56AE82216259@ary.qy> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Archived-At: Subject: Re: [Idna-update] IDNA and combining sequences (was: Re: Expiration impending: ) X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2018 14:45:08 -0000 --On Saturday, 10 March, 2018 13:29 -0500 John Levine wrote: > In article you write: >> The latter would probably quickly reach the point that >> attempts to apply the LGR to labels at the second level and >> beyond would encourage non-compliance and daring ICANN to do >> anything about it. > > I'm confused. Every gTLD and many ccTLDS have language and > script rules that limit what 2LDs they will accept. When I > was looking at gTLD applications, the rules all looked pretty > reasonable, give or take what you think is a reasonable > approach to handling variants. > > What am I missing? I realize that below the 2LDs anything > goes. This may not be worth beleaguering, but you are missing, or, more likely, not looking hard enough, at least four things: (1) Some of those rules have, at least historically, been no more restrictive than "what IDNA2008 allows" and even (although the new Board resolutions may gradually change that too) "what IDNA2003 allows". And, fwiw, lists of permitted code points have been common; actual stated/specific rules much less so. IIR, the latter were not even provided for in the initial request for "character" (code point and code point sequence) lists. (2) Those tables started out as indications of intention, and advice to others about what they might do or think about. They were not even intended as constraints on what the registering zone was going to do. Even though it was generally assumed that a registry would not allow labels that did not conform to the labels it registered, that was never a requirement that anyone expected to be enforced at least up to the time those tables got entangled with the new gTLD program. (3) Perhaps in part because the tables that were registered with IANA were optional, not "rules", there is a history of names being registered as 2LDs that do not conform to the published tables. The distinction becomes important the moment the term "variant" is mentioned, even as a blocking mechanism, because even a simple FCFS rule such as "if you have 'google' registered as an SLD, 'goog1e' is not allowed" is a rule with which an allowed character list won't help. That is actually an area in which something could, in principle, be done immediately and without any need to sort out the IETF review issues: ICANN could update the general guidelines with advice to block additional registrations in a given zone that reflect that sort of relationship, using whatever information can be gleaned from the LGR process, Asmus's efforts, and whatever else we know and not excluding any scripts (as the example and dozens like it indicate, this is not just an IDN problem). I note that variations on this idea have been proposed, several times, by Andrew and others --I'm not inventing anything in this note. For those of you who are spending the next several days in Puerto Rico, that is probably a worthy discussion topic. Going into that discussion, you should, however, remember that rules that are ultimately based on FCFS --preference for first party to register a name from a set -- have had a rough history in ICANN, setting off either claims of unfairness or unpleasant "land rush" behavior or both. (4) I don't know if you are "missing" it or not, but we need to keep in mind that efforts to promote the use of DNAME records in the root, at the second level, and elsewhere, have potential bad side-effects. If I have a zone "foo" at some level of the DNS with an associated set of rules or policies, and nodes owned by "bar" and "foobar" with DNAME records pointing at "foo", it is not clear whether there is a reasonable expectation the foo's rules will apply if bar and foobar can have their own rules or no rules at all. It is fairly clear, at least to me, what the rules should be if the DNS RRSETs for foo, bar, and foobar all exist at the same level in the same zone, e.g., no arrangements like $ORIGIN zork. foo IN ... foobar.baz IN DNAME foo.zork. but, as I trust everyone reading this understands, there is no such requirement on DNAME -- there can, in principle, be a record with RRTYPE DNAME pointing to "foo" from any zone and any level of the DNS tree (and, btw, with any owner/registrant). The rather unfortunate relationship between DNAME records in arbitrary zone and DNSSEC doesn't help much here. That is, again, one of those "if we had known then what we know now" bits of history: when DNAME was first designed and deployed, it was intended for temporary, transitional, use and DNSSEC was not even something that people were dreaming about. Its evolution into a variant mechanism that is intended to be stable (even if not "permanent") suggests the need for some additional constraints but, even if we could introduce a new RRTYPE with those constraints, we almost certainly could not make DDNAME go away. best, john From nobody Mon Mar 12 08:04:00 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8422126D05 for ; Mon, 12 Mar 2018 08:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=qTZsn8zy; dkim=pass (1536-bit key) header.d=taugh.com header.b=D1h5hBRA Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MktmdDy4fAl for ; Mon, 12 Mar 2018 08:03:57 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AE51124217 for ; Mon, 12 Mar 2018 08:03:57 -0700 (PDT) Received: (qmail 54916 invoked from network); 12 Mar 2018 15:03:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=d682.5aa696dc.k1803; bh=oXHvhIVbCZy+ZMa7zdV+dnSQprSWJ3e+idzyn4C/adk=; b=qTZsn8zy8NohJTTTR+KBd03NEx/nJYicodW10oKg+ks5AmPoWXtcqEcBiPZnYpHkg2SXfYcWh2A5yw1dGZeYy0X/x5BQ3qIpgRcs9yQ9XsEEey6MdpXeCoQpYbUyvdtYvCJXCcFZ5ElL73GGirTRXRrp5XU2WzDoO4B06rRGmsVf4cPoezojBdqeRyHu2UxLHI8BfnhZbXRRWuCcnInAm557Ep1W5zo3Ks2jQTaX/WNIGX31n5TtzvecXtBmdG3y DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=d682.5aa696dc.k1803; bh=oXHvhIVbCZy+ZMa7zdV+dnSQprSWJ3e+idzyn4C/adk=; b=D1h5hBRA2taRZoL0WFhbsidRKTnXk918tn0BsZ1JC30RO6T48ux8FnkRMsUfUSH+5TzcISChN5IcsEOGw8G+Zr/XCyrjHrcw7MWffuOJDQHyxrYANVDK5YKMeTdrDkgqbq+4xZlotOogngtZVdkonbmDT9rcdCuKrnDdgmWfmkPB+Zo3lO78w7b/j0E9S57PrfDWNlqY5KyUaVBkcOpILd8IBEb8JCjL6Nc3btFttwEzz1OHF8tba8zn3rt+U2f2 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 12 Mar 2018 15:03:55 -0000 Date: 12 Mar 2018 11:03:54 -0400 Message-ID: From: "John R Levine" To: "John C Klensin" Cc: idna-update@ietf.org In-Reply-To: <6FAA2D68A20DF091B0E0086B@JcK-HP5.jck.com> References: <20180310182908.56AE82216259@ary.qy> <6FAA2D68A20DF091B0E0086B@JcK-HP5.jck.com> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Idna-update] IDNA and combining sequences (was: Re: Expiration impending: ) X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 15:03:59 -0000 > Even though it was generally assumed that > a registry would not allow labels that did not conform to the > labels it registered, that was never a requirement that anyone > expected to be enforced at least up to the time those tables got > entangled with the new gTLD program. I've tried some experiments and it appears that gTLDs now enforce the script rules. It is certainly true that there is some grandfathered garbage from before the IDNA rules, and ccTLDs do what they do. > (4) I don't know if you are "missing" it or not, but we need to > keep in mind that efforts to promote the use of DNAME records in > the root, at the second level, and elsewhere, have potential bad > side-effects. No kidding. DNAME at the second level was so bad that .cat stopped doing it. There is one DNAME at the root, for the two versions of Taiwan in Chinese which as far as I can tell nobody has noticed. But that seems like a separate can of worms. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Mar 12 09:48:27 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3ABA127735 for ; Mon, 12 Mar 2018 09:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ix.netcom.com; domainkeys=pass (2048-bit key) header.from=asmusf@ix.netcom.com header.d=ix.netcom.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYrKBpqJNz06 for ; Mon, 12 Mar 2018 09:48:24 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0B5F127601 for ; Mon, 12 Mar 2018 09:48:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ix.netcom.com; s=dk12062016; t=1520873304; bh=Ct3hYjAnxd8Sfav/Er/TOQkkMrcmLuaKZyFS 3YiQuJI=; h=Received:To:From:Subject:Message-ID:Date:User-Agent: MIME-Version:Content-Type:Content-Language:X-ELNK-Trace: X-Originating-IP; b=W4dYcOIjZkOTY7GOpB0d9ZN+ndcAM6b8/PQ6sohYHMBwWh xEesibwku3QphAIH+adKEW8+pjJxYtY2XtPj8MRhdHblteR8IQpjXS8bNl9kcRjnOE3 /0lQql4mq5/XQ5SeAqRnY/MrgLCTZz49srrh0Pgbca7lj6zmQs976eaBX4UMMCNE2PE u/DWpwblrCm7/AyuNEqJizaB11HzgLBvX7G2bY6z0/VtriY1FOF4wC64q45KfbMPn4c 8ksft+K/FrKHPGCZATeAUL/n9eWJnDL9b0MRanHf66febtXDzUS+EySXg9bFGuDGus+ AtrZeHsRYDIz4nM4gWZA0ZUWfgXg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=ix.netcom.com; b=o1ZXLeqYcVJ8c3kEGm0SRD382QzTNk3O6U0SgYbUI8R6D8DKvIN6I7UCwG7g2l4xU3CVeV1R0x3WF9nmo7zmzB0JhIzG8TTuQTPglTq39T8HCFZEmUf+jkaN49Fq/nttBopUrYD+a0ipK3vAddTzmndWmlwj4GkhYSuqhBf38botyFqHtXtAu8smZSX2qtOwpViDYpkzNaNdoiQk4SgMmBaneQUFVaEGn9g9xmQ6TYHa6vJa+hHU1eTGNVfu8RilUoeDrKdM3KkfZLZOPfeQIDFMz2ZNjwz9Pr4uL7jXnLgHyxEN8+EaPNAqX32K3vKToeamjoDhyz9zcQWuCZGELw==; h=Received:To:From:Subject:Message-ID:Date:User-Agent:MIME-Version:Content-Type:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [71.35.186.204] (helo=[192.168.0.5]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1evQcY-000DgD-Be for idna-update@ietf.org; Mon, 12 Mar 2018 12:48:22 -0400 To: idna-update@ietf.org From: Asmus Freytag Message-ID: <533bb471-da9b-64d0-76aa-a8a1251d256b@ix.netcom.com> Date: Mon, 12 Mar 2018 09:48:23 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------1BF18281E82C8D4F3C9ED790" Content-Language: en-US X-ELNK-Trace: 464f085de979d7246f36dc87813833b2c1627926350bb93f01db8aa79b8972de68f5421875f59e27350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.35.186.204 Archived-At: Subject: [Idna-update] emoji and security X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 16:48:26 -0000 This is a multi-part message in MIME format. --------------1BF18281E82C8D4F3C9ED790 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit All, there's a general consensus that emoji and secure IDNs do not go together. This is clearly not something that's taken for granted by others. Read down a few messages in this thread on the Unicode list: https://www.unicode.org/mail-arch/unicode-ml/y2018-m03/0075.html to find the suggestion of translating security hash codes into strings of emoji ostensible for easier verification: "So that makes me wonder which one would be quicker for a human to verify on average? Also, which one is more accurate for a human to verify? I have no idea. For accuracy, it seems like a lot of thought was put into the visual uniqueness of Unicode emojis. " Discuss. A./ PS: the reason I forwarded this is that many people find something familiar and  accessible about emoji and will not understand why there should be more security concerns about them than about a bunch of bewilderingly similar and complex Chinese ideographs or a bunch of "dawn-of-time-emoji" aka Hieroglyphics, both of which are PVALID. --------------1BF18281E82C8D4F3C9ED790 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

All,

there's a general consensus that emoji and secure IDNs do not go together.

This is clearly not something that's taken for granted by others.

Read down a few messages in this thread on the Unicode list:

https://www.unicode.org/mail-arch/unicode-ml/y2018-m03/0075.html

to find the suggestion of translating security hash codes into strings
of emoji ostensible for easier verification:

"So that makes
me wonder which one would be quicker for a human to verify on average?
Also, which one is more accurate for a human to verify? I have no idea. For
accuracy, it seems like a lot of thought was put into the visual uniqueness
of Unicode emojis. "

Discuss.

A./

PS: the reason I forwarded this is that many people find something
familiar and  accessible about emoji and will not understand why there
should be more security concerns about them than about a bunch
of bewilderingly similar and complex Chinese ideographs or a bunch
of "dawn-of-time-emoji" aka Hieroglyphics, both of which are PVALID.


--------------1BF18281E82C8D4F3C9ED790-- From nobody Mon Mar 12 11:21:32 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C95126B7E for ; Mon, 12 Mar 2018 11:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=suignard.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzL9ZN7ZiQgL for ; Mon, 12 Mar 2018 11:21:27 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0071.outbound.protection.outlook.com [104.47.34.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 940A61200F1 for ; Mon, 12 Mar 2018 11:21:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suignard.onmicrosoft.com; s=selector1-suignard-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TfYGEEcq6g5ZykGHyD5M5j7xTkh1j/PxcgrLRViClCA=; b=sF/AmWEwYtKSo92XxutsaLCw20QXnxyV08xJ27XUzypQ7ru/23hYlEIFY98iDRlO8rIuoaw4kiBDc1qLro67B3VGh10+UvGQq9GVEK8B70LoOSv17wjROHOcRAenhMphTiw3ubWve4ty8vw7JM9bpWCVkRszT/NAOXaW6PA4+aw= Received: from DM5PR1901MB2197.namprd19.prod.outlook.com (52.132.131.160) by DM5PR1901MB2005.namprd19.prod.outlook.com (52.132.132.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.548.13; Mon, 12 Mar 2018 18:21:25 +0000 Received: from DM5PR1901MB2197.namprd19.prod.outlook.com ([fe80::4c67:e6ac:d64e:4930]) by DM5PR1901MB2197.namprd19.prod.outlook.com ([fe80::4c67:e6ac:d64e:4930%13]) with mapi id 15.20.0548.021; Mon, 12 Mar 2018 18:21:25 +0000 From: Michel Suignard To: Asmus Freytag , "idna-update@ietf.org" Thread-Topic: [Idna-update] emoji and security Thread-Index: AQHTuiH036Wme2wFFkaQ526XY0gPJqPM5Etw Date: Mon, 12 Mar 2018 18:21:25 +0000 Message-ID: References: <533bb471-da9b-64d0-76aa-a8a1251d256b@ix.netcom.com> In-Reply-To: <533bb471-da9b-64d0-76aa-a8a1251d256b@ix.netcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=michel@suignard.com; x-originating-ip: [23.249.129.130] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR1901MB2005; 7:JpvcogB8sx0iP3jNMd4yDBozqUCH0qMnHX2yMjtlxzHlOX65IbCr9nzXgpkFv8Y+vuUZ+wZU9zX2sqLmslMAvNK0Gy4DGpkyyRnKGcGQ/YqiOTjj6Rjm/mPQ5mU6WuSzGYr71YmsEHuwt68KRb1pN45Dj9Axm6E+0q2udphJAPscYjR/4A9d7MPKZmDF4NBFLGyeSqHJu+Xne7uhrTn+bQLRb8tbKSPLhSzI6WMlrrc9WDZtsstxDwEcgsxwE5NP x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 61447c01-d712-4e4b-af6f-08d5884610c2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4604075)(3008032)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:DM5PR1901MB2005; x-ms-traffictypediagnostic: DM5PR1901MB2005: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(192374486261705)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231220)(944501244)(52105095)(6041310)(20161123564045)(20161123562045)(20161123560045)(20161123558120)(2016111802025)(6043046)(6072148)(201708071742011); SRVR:DM5PR1901MB2005; BCL:0; PCL:0; RULEID:; SRVR:DM5PR1901MB2005; x-forefront-prvs: 06098A2863 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(346002)(396003)(39380400002)(39830400003)(199004)(189003)(2906002)(6506007)(2501003)(3280700002)(26005)(606006)(10710500007)(76176011)(99286004)(6246003)(14454004)(33656002)(106356001)(186003)(81166006)(7110500001)(81156014)(8936002)(966005)(59450400001)(3660700001)(25786009)(68736007)(102836004)(15650500001)(5250100002)(53546011)(2420400007)(478600001)(5660300001)(7736002)(55016002)(8676002)(6436002)(2900100001)(97736004)(3846002)(53936002)(790700001)(6116002)(561944003)(9686003)(110136005)(7696005)(74316002)(54896002)(6306002)(105586002)(86362001)(2950100002)(236005)(316002)(8666007)(66066001)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR1901MB2005; H:DM5PR1901MB2197.namprd19.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: suignard.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: PJQ5H08nZF0c7X8JOoWskqnC0Tzch459kCJb/o6nbMZ846ki/0m5ZTJWvkBNn4ZF1ZPt4mWi3yCB92/ACluUHfGRQrkR8w58zfE4FwLydFRBu+/fgKbWBiiSUoUYOxjwgn3VSYbok8Pd+ASIf8VSGeKRz/hQQk+mQPjc0wG1ndePVL8xCGxdExDKasHUt0zfTVZRW4GsBIg9dfbbOx2aXo2SpDiURqmy3oCCMOA+Sl3agIZpt4SzujXjnHNcVKk8G+cuMdzYw0vgy73WYqIX3eVqciO/+YhHAtMjOfNqoFQAr5Uh3vLRioEApLSy0oBK2aDRF0jO8c6nBtiUKjlCNQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR1901MB219712F39A6297F9A147312DA2D30DM5PR1901MB2197_" MIME-Version: 1.0 X-OriginatorOrg: suignard.com X-MS-Exchange-CrossTenant-Network-Message-Id: 61447c01-d712-4e4b-af6f-08d5884610c2 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2018 18:21:25.1669 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c72bffc7-022d-442d-a3fe-f53a3fa020d2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1901MB2005 Archived-At: Subject: Re: [Idna-update] emoji and security X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 18:21:30 -0000 --_000_DM5PR1901MB219712F39A6297F9A147312DA2D30DM5PR1901MB2197_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UFM6IHRoZSByZWFzb24gSSBmb3J3YXJkZWQgdGhpcyBpcyB0aGF0IG1hbnkgcGVvcGxlIGZpbmQg c29tZXRoaW5nDQpmYW1pbGlhciBhbmQgIGFjY2Vzc2libGUgYWJvdXQgZW1vamkgYW5kIHdpbGwg bm90IHVuZGVyc3RhbmQgd2h5IHRoZXJlDQpzaG91bGQgYmUgbW9yZSBzZWN1cml0eSBjb25jZXJu cyBhYm91dCB0aGVtIHRoYW4gYWJvdXQgYSBidW5jaA0Kb2YgYmV3aWxkZXJpbmdseSBzaW1pbGFy IGFuZCBjb21wbGV4IENoaW5lc2UgaWRlb2dyYXBocyBvciBhIGJ1bmNoDQpvZiAiZGF3bi1vZi10 aW1lLWVtb2ppIiBha2EgSGllcm9nbHlwaGljcywgYm90aCBvZiB3aGljaCBhcmUgUFZBTElELg0K SSBjb3VsZCBub3QgcmVzaXN0IGNvbW1lbnRpbmcgb24gdGhpcywgYmVjYXVzZSB1bmxpa2UgZW1v amksIEVneXB0aWFuIEhpZXJvZ2x5cGhzLCB3aGlsZSBsb29raW5nIG9mdGVuIGxpa2UgY29sb3Jm dWwgcGljdHVyZXMsIGFyZSB0aGUgZXhwcmVzc2lvbiBvZiBhIGZ1bGx5IGZvcm1lZCB3cml0aW5n IHN5c3RlbSB3aXRoIGlkZW9ncmFtcyBhbmQgcGhvbm9ncmFtcyBhbmQgYWxsIHRoZSB1c3VhbCBh dHRyaWJ1dGVzIG9mIHN1Y2ggYSBzeXN0ZW0gaW4gdGVybSBvZiBzZW50ZW5jZSBzdHJ1Y3R1cmUu IEpva2luZ2x5IEkgaGF2ZSBzb21ldGltZXMgc2FpZCB0aGF0IGRvb20gd291bGQgYmUgbmVhciBp ZiBwZW9wbGUgcmVhbGl6ZWQgdGhhdCB5b3UgY291bGQgbWl4IEVtb2ppIHdpdGggaGllcm9nbHlw aHMgYW5kIHJlc3VsdCBpbiBhIGZ1bGx5IGZvcm1lZCB3cml0aW5nIHN5c3RlbS4NCg0KSm9rZXMg YXNpZGUsIHRoZSAxMDBzIEVneXB0aWFuIGhpZXJvZ2x5cGhzIGNvbnRhaW5zIGh1bmRyZWRzIG9m IHNlbWFudGljIGFuZCBwaG9uZXRpYyB2YXJpYW50cyBhbmQgYXJlIHRvdGFsbHkgdW5zdWl0ZWQg Zm9yIGFueSBpZGVudGlmaWVyIHVzYWdlIGFuZCBhcmUgc3RpbGwgZnVsbHkgSUROIDIwMDggUFZB TElEICh1bmxlc3Mgb2YgY291cnNlIHlvdSBsaW1pdCB0aGUgc2NvcGUgdXNpbmcgdmFyaWFudCBz ZXRzKS4gQW5kIHRvIG1ha2UgbWF0dGVyIHdvcnNlLCB0aGVyZSBpcyBhIHBsYW4gdG8gYWRkIGZl dyBtb3JlIHRob3VzYW5kcyB0byBjb3ZlciBQdG9sZW1haWMgZXJhICh3aGljaCB3b3VsZCBhbGwg YmVjb21lIFBWQUxJRCBhcyB3ZWxsIGlmIHRoZSBzeW5jaHJvbml6YXRpb24gaXMgcmUtZW5hYmxl ZCkuIEF0IHRoZSBzYW1lIHRpbWUsIHdlIGFyZSBxdWl0ZSBjYXJlZnVsIGF0IG5vdCBlbmNvZGlu ZyBIaWVyb2dseXBocyBob21vZ2x5cGhzIChzdGlsbCBtb3N0IHBlb3BsZSB3b3VsZCBub3Qga25v dyB0aGUgZGlmZmVyZW5jZSkuIChTYXlpbmcg4oCYd2XigJkgYmVjYXVzZSBJIGFtIHRoZSBhdXRo b3Igb2Ygb25lIG9mIHRoZXNlIGV4dGVuc2lvbnMgcHJvcG9zYWwpLg0KDQpGaW5hbGx5LCBJIHNo YXJlIG1hbnkgb2YgQXNtdXPigJlzIGNvbnNpZGVyYXRpb25zIG9uIHRoZSBzdGF0dXMgb2YgSURO QSBhbmQgbGFjayBvZiBzeW5jaHJvbml6YXRpb24gd2l0aCBVbmljb2RlICh3ZSBhcmUgYm90aCBv biB0aGUgSUNBTk4gSW50ZWdyYXRpb24gUGFuZWwsIHNvIHdlIGRvIGEgbG90IG9mIExHUiB3b3Jr IHRvZ2V0aGVyKS4gSSBhbSBjdXJyZW50bHkgYXQgSUNBTk4gNjEgd2l0aCBzb21lIGRlY2VudCBm cmVlIHRpbWUgYW5kIHdpbGxpbmcgdG8gZG8gc29tZXRoaW5nIHRvIG1ha2UgcHJvZ3Jlc3MuDQoN CkJlc3QNCg0KTWljaGVsDQoNCkZyb206IElETkEtVVBEQVRFIDxpZG5hLXVwZGF0ZS1ib3VuY2Vz QGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQXNtdXMgRnJleXRhZw0KU2VudDogTW9uZGF5LCBNYXJj aCAxMiwgMjAxOCA5OjQ4IEFNDQpUbzogaWRuYS11cGRhdGVAaWV0Zi5vcmcNClN1YmplY3Q6IFtJ ZG5hLXVwZGF0ZV0gZW1vamkgYW5kIHNlY3VyaXR5DQoNCg0KQWxsLA0KDQp0aGVyZSdzIGEgZ2Vu ZXJhbCBjb25zZW5zdXMgdGhhdCBlbW9qaSBhbmQgc2VjdXJlIElETnMgZG8gbm90IGdvIHRvZ2V0 aGVyLg0KDQpUaGlzIGlzIGNsZWFybHkgbm90IHNvbWV0aGluZyB0aGF0J3MgdGFrZW4gZm9yIGdy YW50ZWQgYnkgb3RoZXJzLg0KDQpSZWFkIGRvd24gYSBmZXcgbWVzc2FnZXMgaW4gdGhpcyB0aHJl YWQgb24gdGhlIFVuaWNvZGUgbGlzdDoNCg0KaHR0cHM6Ly93d3cudW5pY29kZS5vcmcvbWFpbC1h cmNoL3VuaWNvZGUtbWwveTIwMTgtbTAzLzAwNzUuaHRtbA0KDQp0byBmaW5kIHRoZSBzdWdnZXN0 aW9uIG9mIHRyYW5zbGF0aW5nIHNlY3VyaXR5IGhhc2ggY29kZXMgaW50byBzdHJpbmdzDQpvZiBl bW9qaSBvc3RlbnNpYmxlIGZvciBlYXNpZXIgdmVyaWZpY2F0aW9uOg0KDQoiU28gdGhhdCBtYWtl cw0KbWUgd29uZGVyIHdoaWNoIG9uZSB3b3VsZCBiZSBxdWlja2VyIGZvciBhIGh1bWFuIHRvIHZl cmlmeSBvbiBhdmVyYWdlPw0KQWxzbywgd2hpY2ggb25lIGlzIG1vcmUgYWNjdXJhdGUgZm9yIGEg aHVtYW4gdG8gdmVyaWZ5PyBJIGhhdmUgbm8gaWRlYS4gRm9yDQphY2N1cmFjeSwgaXQgc2VlbXMg bGlrZSBhIGxvdCBvZiB0aG91Z2h0IHdhcyBwdXQgaW50byB0aGUgdmlzdWFsIHVuaXF1ZW5lc3MN Cm9mIFVuaWNvZGUgZW1vamlzLiAiDQoNCkRpc2N1c3MuDQoNCkEuLw0KDQpQUzogdGhlIHJlYXNv biBJIGZvcndhcmRlZCB0aGlzIGlzIHRoYXQgbWFueSBwZW9wbGUgZmluZCBzb21ldGhpbmcNCmZh bWlsaWFyIGFuZCAgYWNjZXNzaWJsZSBhYm91dCBlbW9qaSBhbmQgd2lsbCBub3QgdW5kZXJzdGFu ZCB3aHkgdGhlcmUNCnNob3VsZCBiZSBtb3JlIHNlY3VyaXR5IGNvbmNlcm5zIGFib3V0IHRoZW0g dGhhbiBhYm91dCBhIGJ1bmNoDQpvZiBiZXdpbGRlcmluZ2x5IHNpbWlsYXIgYW5kIGNvbXBsZXgg Q2hpbmVzZSBpZGVvZ3JhcGhzIG9yIGEgYnVuY2gNCm9mICJkYXduLW9mLXRpbWUtZW1vamkiIGFr YSBIaWVyb2dseXBoaWNzLCBib3RoIG9mIHdoaWNoIGFyZSBQVkFMSUQuDQoNCg0K --_000_DM5PR1901MB219712F39A6297F9A147312DA2D30DM5PR1901MB2197_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpDYW5kYXJhOw0KCXBhbm9zZS0xOjIgMTQgNSAyIDMgMyAzIDIgMiA0O30NCi8qIFN0eWxl IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0K YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29u b3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVt YWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlBTOiB0aGUgcmVhc29uIEkgZm9yd2FyZGVkIHRoaXMgaXMg dGhhdCBtYW55IHBlb3BsZSBmaW5kIHNvbWV0aGluZzxicj4NCmZhbWlsaWFyIGFuZCZuYnNwOyBh Y2Nlc3NpYmxlIGFib3V0IGVtb2ppIGFuZCB3aWxsIG5vdCB1bmRlcnN0YW5kIHdoeSB0aGVyZTxi cj4NCnNob3VsZCBiZSBtb3JlIHNlY3VyaXR5IGNvbmNlcm5zIGFib3V0IHRoZW0gdGhhbiBhYm91 dCBhIGJ1bmNoPGJyPg0Kb2YgYmV3aWxkZXJpbmdseSBzaW1pbGFyIGFuZCBjb21wbGV4IENoaW5l c2UgaWRlb2dyYXBocyBvciBhIGJ1bmNoPGJyPg0Kb2YgJnF1b3Q7ZGF3bi1vZi10aW1lLWVtb2pp JnF1b3Q7IGFrYSBIaWVyb2dseXBoaWNzLCBib3RoIG9mIHdoaWNoIGFyZSBQVkFMSUQuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93 dGV4dCI+SSBjb3VsZCBub3QgcmVzaXN0IGNvbW1lbnRpbmcgb24gdGhpcywgYmVjYXVzZSB1bmxp a2UgZW1vamksIEVneXB0aWFuIEhpZXJvZ2x5cGhzLCB3aGlsZSBsb29raW5nIG9mdGVuIGxpa2Ug Y29sb3JmdWwgcGljdHVyZXMsIGFyZSB0aGUgZXhwcmVzc2lvbiBvZiBhIGZ1bGx5IGZvcm1lZCB3 cml0aW5nIHN5c3RlbSB3aXRoIGlkZW9ncmFtcyBhbmQgcGhvbm9ncmFtcw0KIGFuZCBhbGwgdGhl IHVzdWFsIGF0dHJpYnV0ZXMgb2Ygc3VjaCBhIHN5c3RlbSBpbiB0ZXJtIG9mIHNlbnRlbmNlIHN0 cnVjdHVyZS4gSm9raW5nbHkgSSBoYXZlIHNvbWV0aW1lcyBzYWlkIHRoYXQgZG9vbSB3b3VsZCBi ZSBuZWFyIGlmIHBlb3BsZSByZWFsaXplZCB0aGF0IHlvdSBjb3VsZCBtaXggRW1vamkgd2l0aCBo aWVyb2dseXBocyBhbmQgcmVzdWx0IGluIGEgZnVsbHkgZm9ybWVkIHdyaXRpbmcgc3lzdGVtLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+Sm9rZXMgYXNpZGUsIHRo ZSAxMDBzIEVneXB0aWFuIGhpZXJvZ2x5cGhzIGNvbnRhaW5zIGh1bmRyZWRzIG9mIHNlbWFudGlj IGFuZCBwaG9uZXRpYyB2YXJpYW50cyBhbmQgYXJlIHRvdGFsbHkgdW5zdWl0ZWQgZm9yIGFueSBp ZGVudGlmaWVyIHVzYWdlIGFuZCBhcmUgc3RpbGwgZnVsbHkgSUROIDIwMDggUFZBTElEICh1bmxl c3Mgb2YgY291cnNlIHlvdSBsaW1pdA0KIHRoZSBzY29wZSB1c2luZyB2YXJpYW50IHNldHMpLiBB bmQgdG8gbWFrZSBtYXR0ZXIgd29yc2UsIHRoZXJlIGlzIGEgcGxhbiB0byBhZGQgZmV3IG1vcmUg dGhvdXNhbmRzIHRvIGNvdmVyIFB0b2xlbWFpYyBlcmEgKHdoaWNoIHdvdWxkIGFsbCBiZWNvbWUg UFZBTElEIGFzIHdlbGwgaWYgdGhlIHN5bmNocm9uaXphdGlvbiBpcyByZS1lbmFibGVkKS4gQXQg dGhlIHNhbWUgdGltZSwgd2UgYXJlIHF1aXRlIGNhcmVmdWwgYXQgbm90IGVuY29kaW5nIEhpZXJv Z2x5cGhzDQogaG9tb2dseXBocyAoc3RpbGwgbW9zdCBwZW9wbGUgd291bGQgbm90IGtub3cgdGhl IGRpZmZlcmVuY2UpLiAoU2F5aW5nIOKAmHdl4oCZIGJlY2F1c2UgSSBhbSB0aGUgYXV0aG9yIG9m IG9uZSBvZiB0aGVzZSBleHRlbnNpb25zIHByb3Bvc2FsKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOndpbmRvd3RleHQiPkZpbmFsbHksIEkgc2hhcmUgbWFueSBvZiBBc211c+KAmXMg Y29uc2lkZXJhdGlvbnMgb24gdGhlIHN0YXR1cyBvZiBJRE5BIGFuZCBsYWNrIG9mIHN5bmNocm9u aXphdGlvbiB3aXRoIFVuaWNvZGUgKHdlIGFyZSBib3RoIG9uIHRoZSBJQ0FOTiBJbnRlZ3JhdGlv biBQYW5lbCwgc28gd2UgZG8gYSBsb3Qgb2YgTEdSIHdvcmsgdG9nZXRoZXIpLiBJIGFtIGN1cnJl bnRseQ0KIGF0IElDQU5OIDYxIHdpdGggc29tZSBkZWNlbnQgZnJlZSB0aW1lIGFuZCB3aWxsaW5n IHRvIGRvIHNvbWV0aGluZyB0byBtYWtlIHByb2dyZXNzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6d2luZG93dGV4dCI+QmVzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 d2luZG93dGV4dCI+TWljaGVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4gSUROQS1VUERBVEUgJmx0O2lkbmEtdXBk YXRlLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFzbXVzIEZyZXl0 YWc8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBNYXJjaCAxMiwgMjAxOCA5OjQ4IEFNPGJyPg0K PGI+VG86PC9iPiBpZG5hLXVwZGF0ZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbSWRu YS11cGRhdGVdIGVtb2ppIGFuZCBzZWN1cml0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYW5kYXJhJnF1b3Q7LHNhbnMtc2VyaWYi PkFsbCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FuZGFyYSZxdW90OyxzYW5zLXNlcmlmIj50aGVyZSdzIGEgZ2VuZXJhbCBjb25zZW5z dXMgdGhhdCBlbW9qaSBhbmQgc2VjdXJlIElETnMgZG8gbm90IGdvIHRvZ2V0aGVyLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYW5kYXJh JnF1b3Q7LHNhbnMtc2VyaWYiPlRoaXMgaXMgY2xlYXJseSBub3Qgc29tZXRoaW5nIHRoYXQncyB0 YWtlbiBmb3IgZ3JhbnRlZCBieSBvdGhlcnMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbmRhcmEmcXVvdDssc2Fucy1zZXJpZiI+UmVh ZCBkb3duIGEgZmV3IG1lc3NhZ2VzIGluIHRoaXMgdGhyZWFkIG9uIHRoZSBVbmljb2RlIGxpc3Q6 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PGEgaHJlZj0iaHR0cHM6Ly93d3cudW5pY29kZS5v cmcvbWFpbC1hcmNoL3VuaWNvZGUtbWwveTIwMTgtbTAzLzAwNzUuaHRtbCI+aHR0cHM6Ly93d3cu dW5pY29kZS5vcmcvbWFpbC1hcmNoL3VuaWNvZGUtbWwveTIwMTgtbTAzLzAwNzUuaHRtbDwvYT48 bzpwPjwvbzpwPjwvcD4NCjxwPnRvIGZpbmQgdGhlIHN1Z2dlc3Rpb24gb2YgdHJhbnNsYXRpbmcg c2VjdXJpdHkgaGFzaCBjb2RlcyBpbnRvIHN0cmluZ3M8YnI+DQpvZiBlbW9qaSBvc3RlbnNpYmxl IGZvciBlYXNpZXIgdmVyaWZpY2F0aW9uOjxvOnA+PC9vOnA+PC9wPg0KPHA+JnF1b3Q7U28gdGhh dCBtYWtlcyA8YnI+DQptZSB3b25kZXIgd2hpY2ggb25lIHdvdWxkIGJlIHF1aWNrZXIgZm9yIGEg aHVtYW4gdG8gdmVyaWZ5IG9uIGF2ZXJhZ2U/IDxicj4NCkFsc28sIHdoaWNoIG9uZSBpcyBtb3Jl IGFjY3VyYXRlIGZvciBhIGh1bWFuIHRvIHZlcmlmeT8gSSBoYXZlIG5vIGlkZWEuIEZvciA8YnI+ DQphY2N1cmFjeSwgaXQgc2VlbXMgbGlrZSBhIGxvdCBvZiB0aG91Z2h0IHdhcyBwdXQgaW50byB0 aGUgdmlzdWFsIHVuaXF1ZW5lc3MgPGJyPg0Kb2YgVW5pY29kZSBlbW9qaXMuICZxdW90OzxvOnA+ PC9vOnA+PC9wPg0KPHA+RGlzY3Vzcy48bzpwPjwvbzpwPjwvcD4NCjxwPkEuLzxvOnA+PC9vOnA+ PC9wPg0KPHA+UFM6IHRoZSByZWFzb24gSSBmb3J3YXJkZWQgdGhpcyBpcyB0aGF0IG1hbnkgcGVv cGxlIGZpbmQgc29tZXRoaW5nPGJyPg0KZmFtaWxpYXIgYW5kJm5ic3A7IGFjY2Vzc2libGUgYWJv dXQgZW1vamkgYW5kIHdpbGwgbm90IHVuZGVyc3RhbmQgd2h5IHRoZXJlPGJyPg0Kc2hvdWxkIGJl IG1vcmUgc2VjdXJpdHkgY29uY2VybnMgYWJvdXQgdGhlbSB0aGFuIGFib3V0IGEgYnVuY2g8YnI+ DQpvZiBiZXdpbGRlcmluZ2x5IHNpbWlsYXIgYW5kIGNvbXBsZXggQ2hpbmVzZSBpZGVvZ3JhcGhz IG9yIGEgYnVuY2g8YnI+DQpvZiAmcXVvdDtkYXduLW9mLXRpbWUtZW1vamkmcXVvdDsgYWthIEhp ZXJvZ2x5cGhpY3MsIGJvdGggb2Ygd2hpY2ggYXJlIFBWQUxJRC48bzpwPjwvbzpwPjwvcD4NCjxw PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM5PR1901MB219712F39A6297F9A147312DA2D30DM5PR1901MB2197_-- From nobody Mon Mar 12 11:22:17 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7D0126B7E for ; Mon, 12 Mar 2018 11:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ix.netcom.com; domainkeys=pass (2048-bit key) header.from=asmusf@ix.netcom.com header.d=ix.netcom.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFICV2QOMYts for ; Mon, 12 Mar 2018 11:22:14 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF39F1200F1 for ; Mon, 12 Mar 2018 11:22:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ix.netcom.com; s=dk12062016; t=1520878934; bh=2+ViCr3NHJ+W2+YPxnzt+Y5Qj4ftOkpePUue I01BJX0=; h=Received:Subject:To:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Content-Language:X-ELNK-Trace: X-Originating-IP; b=rEp6R+qr7BpwDu5Wh0Hl1uwQ58F/4cxq7IV2A1bifh9epA KozoTo+dzr6EVu/Ubg5ZMpF+YoHBfY9IiB4GUmQhNgOE7kvPm77XbaEc58wMrvrhyqR ZxmxdWC03xbpHIIkX/bSkA1n20SRmWFi4VoXsL6DPxvJDyhnA4E5i2mJWCUWhILS6/f 34YNAhGqtv4npTk/4BjaHEz5gMj2RS2AgBf0ySMmq03bOpc1KkKS9Ex18f8Y6+Ptl/8 fzY9ifA5aw8jts8c5/Mb0wHGcijZbw9sL8EdiadWFjL7199C4w3QhJPuCCWqkf/IUvw nQQ2ott7qPf7MQGARks6sm1z0O4w== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=ix.netcom.com; b=hJ64g//xNSl+eJXbGbL6FuI1S30fBosvlYhq+ZzC2EO0IajR0VsbaSlsJE3nrYgqsnXI9C99th5QQYz95HQBdUncEhG0T18ejihdDIwv8PYqvEVeUzhpQ4PCnk6VKK4mKTcFwpIf+RyKBtmJyO0GDklrerX+/KvHS4nKXFUAIjqLefSCVpbkMWEVCFspMDFVAopSxkAgMyfwwyuRIYXj6TyDf+6+YGxCcXkghBwTY3tNVoZmmsj93wTJIHlykqsodM7IzPYS6ZZ9H+acbyqFRleirw6Zv56+Vqvcwa/GSwu4BshIxGr7MONf1H0SgzTORoZyXPCXGMJtnOWOQYC1ZQ==; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [71.35.186.204] (helo=[192.168.0.5]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1evS5N-0009BP-CH for idna-update@ietf.org; Mon, 12 Mar 2018 14:22:13 -0400 To: idna-update@ietf.org References: <20180310182908.56AE82216259@ary.qy> <6FAA2D68A20DF091B0E0086B@JcK-HP5.jck.com> From: Asmus Freytag Message-ID: <73252c78-361c-c8cb-e392-c5b4c41deded@ix.netcom.com> Date: Mon, 12 Mar 2018 11:22:14 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-ELNK-Trace: 464f085de979d7246f36dc87813833b2c1627926350bb93ff5f19e86419857d5631cb334504139e3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.35.186.204 Archived-At: Subject: Re: [Idna-update] IDNA and combining sequences (was: Re: Expiration impending: ) X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 18:22:16 -0000 On 3/12/2018 8:03 AM, John R Levine wrote: >> Even though it was generally assumed that >> a registry would not allow labels that did not conform to the >> labels it registered, that was never a requirement that anyone >> expected to be enforced at least up to the time those tables got >> entangled with the new gTLD program. > > I've tried some experiments and it appears that gTLDs now enforce the > script rules.  It is certainly true that there is some grandfathered > garbage from before the IDNA rules, and ccTLDs do what they do. John, (L, not K) Restricting repertoire is only the tip of the iceberg. Any TLD that allows SEA and/or South Asian scripts, but does not place limits on the context in which certain code points may occur (those code points mostly being the combining marks) will allow the registration of "garbage" labels - even though each element in the label, if taken by itself may be well-vetted. In those scripts, the "unit" that readers perceive is is not the code point, but the syllable; sequences of code points that do not form valid syllables are expected neither by readers nor by rendering engines, making them ambiguous or unreliable for identifier purposes. (For those used to scripts like Latin or Chinese were "random" strings of code points are merely "not words" but otherwise valid, this constraint inherent to "complex" scripts takes some getting used to, but it is quite real). A cursory glance at the IDN tables published for some of these scripts reveals them as not necessarily vetted well enough and definitely devoid of any contextual restrictions. Before RFC 7940, the only way contextual restrictions could be expressed was in natural language or "pseudo code". The former was done in the registry policy documents or the preamble to a few exceptional idn tables, while you can find the latter in RFC 5892 for the few context rules. With RFC 7940, it is finally possible to capture these rules in a machine readable form, and if you look at the second iteration of the Root Zone LGR (LGR-2) you will find these in place for Thai, Khmer and Lao. (The next iteration will likely bring the ones for all the Indic scripts). Here's a link to the human readable version of the Thai LGR: https://www.icann.org/sites/default/files/lgr/lgr-2-thai-script-01jun17-en.html And here's the overview document for LGR-2: https://www.icann.org/sites/default/files/lgr/lgr-2-overview-01jun17-en.pdf For a full description of the rationale for, say, the constraints on the Thai script, you'd need to follow the link to the original submission: https://www.icann.org/en/system/files/files/proposal-thai-lgr-25may17-en.pdf You mentioned that you were "interested" but felt that you didn't have the background to understand the issues in other scripts without some background and explanation. I would be curious, whether you can make sense out of the description for Thai in the Root Zone. I also invite you to compare that LGR to some of the gTLD IDN tables for Thai. I'd be interested in your conclusion, A./ From nobody Tue Mar 13 02:30:40 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B74D312D80E for ; Tue, 13 Mar 2018 02:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YL58yauiqfuN for ; Tue, 13 Mar 2018 02:30:37 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A18C612D7FC for ; Tue, 13 Mar 2018 02:30:37 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id CD65A28013E; Tue, 13 Mar 2018 10:30:35 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id C75EE280314; Tue, 13 Mar 2018 10:30:35 +0100 (CET) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id C0A6828013E; Tue, 13 Mar 2018 10:30:35 +0100 (CET) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id BDBEF663EBE0; Tue, 13 Mar 2018 10:30:35 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id B947A4020F; Tue, 13 Mar 2018 10:30:35 +0100 (CET) Date: Tue, 13 Mar 2018 10:30:35 +0100 From: Stephane Bortzmeyer To: Asmus Freytag Cc: idna-update@ietf.org Message-ID: <20180313093035.fcax6v3zmz3nv34r@nic.fr> References: <533bb471-da9b-64d0-76aa-a8a1251d256b@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <533bb471-da9b-64d0-76aa-a8a1251d256b@ix.netcom.com> X-Operating-System: Debian GNU/Linux 9.3 X-Kernel: Linux 4.9.0-6-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000017, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.3.13.92416 Archived-At: Subject: Re: [Idna-update] emoji and security X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 09:30:40 -0000 On Mon, Mar 12, 2018 at 09:48:23AM -0700, Asmus Freytag wrote a message of 107 lines which said: > there's a general consensus that emoji and secure IDNs do not go > together. Since the IDNA standard does not allow emojis, I'm not sure of the point. From nobody Tue Mar 13 13:17:25 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC826126C89 for ; Tue, 13 Mar 2018 13:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=iiJWWzjH; dkim=pass (1536-bit key) header.d=taugh.com header.b=TULvKFnt Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uG7IS6_DC129 for ; Tue, 13 Mar 2018 13:17:21 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB71C128896 for ; Tue, 13 Mar 2018 13:17:21 -0700 (PDT) Received: (qmail 67413 invoked from network); 13 Mar 2018 20:17:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=10752.5aa831d0.k1803; bh=UBnMs9rQZJNUxVezUvEgkxkrB4cB/ecWq/KsZYNf2mI=; b=iiJWWzjHOYWLPJmTE16+iIxy7OEnGe1nd2/C8JX8O8O+T65dQlWtGkNcVnms8Dd1PP3vxXC9WD8ABPY1CSftTNxWhrp4Scjzj0LhVZFXk3D2MO/Abq+4FUGi/8BN2GSF/SdNDtKn3+AWKU7DL9ExjcQ4+M6szAmreQW94wi0HgKRuNnjYAlommXcJ5yFXTmhnUyO3g53vNaGj+X3ANlb47e1vhU1CCvbNxL31bQ986U2fPWvCZx8ur22XwY1SRaJ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=10752.5aa831d0.k1803; bh=UBnMs9rQZJNUxVezUvEgkxkrB4cB/ecWq/KsZYNf2mI=; b=TULvKFntmXAuAtKZwW4FvPcBElgzgRALKZ+EsP6eSLuOA4VVnt14cjMrybYHx1SQFM/Qv/6VVKBOQABrDZsEvyu1khBZ7gbJZ4sF5Hp+vqZ+vE6i70DZCccUuswVmI2ddfW30MYHpnWbH2Ba7UcdJfMO+RRCHXENrvtH/uHWSOUGbp/Frd9l/ZFhrAsXCtQyWaHQtw8x8pKJHx3ABGhpBMUm2W6iZVek4d+70NRjP3+m+AEFz7IoUGQACLIyzG00 Received: from ary.local ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 13 Mar 2018 20:17:20 -0000 Received: by ary.local (Postfix, from userid 501) id 2C67F2286F17; Tue, 13 Mar 2018 16:17:19 -0400 (AST) Date: 13 Mar 2018 16:17:19 -0400 Message-Id: <20180313201720.2C67F2286F17@ary.local> From: "John Levine" To: idna-update@ietf.org Cc: bortzmeyer@nic.fr In-Reply-To: <20180313093035.fcax6v3zmz3nv34r@nic.fr> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Idna-update] emoji and security X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 20:17:23 -0000 In article <20180313093035.fcax6v3zmz3nv34r@nic.fr> you write: >> there's a general consensus that emoji and secure IDNs do not go >> together. > >Since the IDNA standard does not allow emojis, I'm not sure of the >point. Hi from ICANN in San Juan. You know and I know that emoji domains are a bad idea for all sorts of reasons. But there are registries and registrars that believe they will make big buck$ by selling them. There have been some presentations on what's permissible and emoji specifically which the ICANN leadership appears to understand. Domains like .WS will sell whatever they can sell and there's not much anyone can do about that. Amusingly, .WS announced with great fanfare that they'd sell emoji and managed to screw it up so the missold the same emoji to multiple people. We TOLD them they were easy to confuse. R's, John From nobody Tue Mar 13 13:25:42 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44032126CD6 for ; Tue, 13 Mar 2018 13:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=Ru0U0Lv4; dkim=pass (1024-bit key) header.d=yitter.info header.b=Veb6KZiR Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5sxIuoaye4o for ; Tue, 13 Mar 2018 13:25:39 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0609126C89 for ; Tue, 13 Mar 2018 13:25:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id E3228BE780 for ; Tue, 13 Mar 2018 20:25:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1520972708; bh=UdLdWNr9Q0wFsEU40vSIDgl77/5/+GEEuEBA5hLAcho=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Ru0U0Lv4+2RewwGcPSFHO5TKXG/7rD2asgd6KorAcQQc2ONib+BK2mynsqPPLWDhh BVenB7fJHasBwiyDkIHZPkUsYe85a+lxd8e5zMSOdthKHVTRbamF8OauY2WYAs6JAg /lNEtEQl/EB2skZKbF//alqDpJlMq/mi56KJHAsw= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zs2pTewj-hEg for ; Tue, 13 Mar 2018 20:25:07 +0000 (UTC) Date: Tue, 13 Mar 2018 16:25:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1520972707; bh=UdLdWNr9Q0wFsEU40vSIDgl77/5/+GEEuEBA5hLAcho=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Veb6KZiR3NJfHV8i9s4ftqe6OsbDlYTlENeAnbrYfE6USDmZLbA6vR3YGQ1vcyiGN Ldy9vXxxRu6OlTU5dpiGQLQku8F/2PMZYuJeq65yxxbD9fEjUSSPDBUyg7WK7O0t38 WyKUolAHK8+eVZtL6emNBNUBGIzg1cVZpLiCo6yE= From: Andrew Sullivan To: idna-update@ietf.org Message-ID: <20180313202505.ztersmy2z5xuxlvp@mx4.yitter.info> References: <533bb471-da9b-64d0-76aa-a8a1251d256b@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [Idna-update] emoji and security X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 20:25:41 -0000 On Mon, Mar 12, 2018 at 06:21:25PM +0000, Michel Suignard wrote: > I could not resist commenting on this, because unlike emoji, Egyptian > Hieroglyphs, while looking often like colorful pictures, are the expression of > a fully formed writing system with ideograms and phonograms and all the usual > attributes of such a system in term of sentence structure. Yes. Which is why they have a general category that … > Jokes aside, the 100s Egyptian hieroglyphs contains hundreds of semantic and > phonetic variants and are totally unsuited for any identifier usage and are > still fully IDN 2008 PVALID (unless of course you limit the scope using variant > sets). … causes them to be PVALID. Which means they're _not_ totally unsuited to any identifier usage, but certainly they are unsuited to any general-purpose identifier usage and almost certainly they will remain in at best extremely limited use effectively forever. Emojis, as you know perfectly well, do not have the same general category and therefore are INVALID. If the general-category approach to IDNA2008 was unsuitable in 2008 because it yielded examples of things that should never in principle be identifiers, I wish someone would have made that argument. I do not recall it having been made, and I believe I participated pretty avidly. I do recall some people arguing that various archaic things were "not needed" or "almost always unusable by anyone", but that would have put us in the situation of going through everything one code point at a time. There were some who wanted to try to re-do IDNA2003 only updated for then-current versions of Unicode, but I think experience shows that wouldn't have worked out too well either. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Mar 13 13:44:51 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C675126CE8 for ; Tue, 13 Mar 2018 13:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=suignard.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1h7w2d2xoJYh for ; Tue, 13 Mar 2018 13:44:46 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0049.outbound.protection.outlook.com [104.47.36.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66293126C89 for ; Tue, 13 Mar 2018 13:44:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suignard.onmicrosoft.com; s=selector1-suignard-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tCojyoMmSbs/eAbYRo+VpWMQzGoKSHjH9h64LxlDew4=; b=JIBWgYkfvF1Ssd9IXSp25gLZV2T8W/5l47r5avLdksdRAxA9N1HuPnbwhOEo8Ch5fBAJhRd2RSUqTGfCtZ49v9Z2sM9IXxTuAEwySKw7QehwIkGAyLHxJ3u/XIvaayIPxKN4RuKa3XmZ0erS+deuSI0E5pyRomLAGyzKNnN32QE= Received: from DM5PR1901MB2197.namprd19.prod.outlook.com (52.132.131.160) by DM5PR1901MB2055.namprd19.prod.outlook.com (52.132.132.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.548.13; Tue, 13 Mar 2018 20:44:43 +0000 Received: from DM5PR1901MB2197.namprd19.prod.outlook.com ([fe80::4c67:e6ac:d64e:4930]) by DM5PR1901MB2197.namprd19.prod.outlook.com ([fe80::4c67:e6ac:d64e:4930%13]) with mapi id 15.20.0548.021; Tue, 13 Mar 2018 20:44:43 +0000 From: Michel Suignard To: Andrew Sullivan , "idna-update@ietf.org" Thread-Topic: [Idna-update] emoji and security Thread-Index: AQHTuiH036Wme2wFFkaQ526XY0gPJqPM5EtwgAG6L4CAAAGDIA== Date: Tue, 13 Mar 2018 20:44:43 +0000 Message-ID: References: <533bb471-da9b-64d0-76aa-a8a1251d256b@ix.netcom.com> <20180313202505.ztersmy2z5xuxlvp@mx4.yitter.info> In-Reply-To: <20180313202505.ztersmy2z5xuxlvp@mx4.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=michel@suignard.com; x-originating-ip: [23.249.129.130] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR1901MB2055; 7:Jxmo18Uua1pZGfmA0w9W12iYZ79H59/oBlbgDNEVYBMruVyuPYSRoAG6NqtV9fbwbynFN4dGgxvWQ2nMcmsHbD9rqAWkWntH3K3bgM40KXLWqnCk2adHq5a+gC9YrPvwkQZX02rDU20XCRSQesi0jpai8UX+qw6WubDvV6cSY8nwdRscRS7tFZ+C1OAAu+6of2U2ipK47H6hA0NJNbhDuTKprWVlER9Dq91Fz28JEYYdVbp68Pz7axncnc0nbaPn x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: c7c07f75-8d0e-4ad3-7f38-08d58923402b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4604075)(3008032)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:DM5PR1901MB2055; x-ms-traffictypediagnostic: DM5PR1901MB2055: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231221)(944501244)(52105095)(6041310)(20161123564045)(20161123560045)(20161123562045)(2016111802025)(20161123558120)(6043046)(6072148)(201708071742011); SRVR:DM5PR1901MB2055; BCL:0; PCL:0; RULEID:; SRVR:DM5PR1901MB2055; x-forefront-prvs: 0610D16BBE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39830400003)(396003)(366004)(376002)(39380400002)(346002)(199004)(189003)(186003)(2906002)(53936002)(26005)(2950100002)(229853002)(6246003)(110136005)(74316002)(2501003)(86362001)(3280700002)(6116002)(5660300001)(106356001)(6506007)(5250100002)(2900100001)(3846002)(33656002)(102836004)(99286004)(8676002)(66066001)(55016002)(105586002)(3660700001)(81166006)(7736002)(8936002)(9686003)(15650500001)(6436002)(81156014)(14454004)(97736004)(7696005)(316002)(76176011)(305945005)(68736007)(25786009)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR1901MB2055; H:DM5PR1901MB2197.namprd19.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: suignard.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: +hW1TpDCncVZN0XDIz1dPC/DR5B46OBBOL2rffWJIFSE3j+q7ulp/cOpeay10k/99o5CC9GEN3e5kkZWSRCes7dPw7VH3aEixpHq8a+liXZbRNBJFeygRVOe8Sfkfm4CjxV/Ji9LxTmfVqmd3ebwqwVsa06ec6Yy45FtGasnBl+nXoiBqhSU1K6VXqmaKmh+QQrJDz3Bp4KuLkmiDf5v9oRw0+YnQPbjwsFZoFvVu2EIJXnY8nf1c2JYVJCiq12Wsz8xqzTJ2D0wabelEvbi50bVemMDVWh34SnuaWnE6aKp1VWKe4qQ51sRVnEmyYZ5/3sghhBa/94JllfxGMXmLg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: suignard.com X-MS-Exchange-CrossTenant-Network-Message-Id: c7c07f75-8d0e-4ad3-7f38-08d58923402b X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2018 20:44:43.4683 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c72bffc7-022d-442d-a3fe-f53a3fa020d2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1901MB2055 Archived-At: Subject: Re: [Idna-update] emoji and security X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 20:44:50 -0000 PDwNCklmIHRoZSBnZW5lcmFsLWNhdGVnb3J5IGFwcHJvYWNoIHRvIElETkEyMDA4IHdhcyB1bnN1 aXRhYmxlIGluIDIwMDggYmVjYXVzZSBpdCB5aWVsZGVkIGV4YW1wbGVzIG9mIHRoaW5ncyB0aGF0 IHNob3VsZCBuZXZlciBpbiBwcmluY2lwbGUgYmUgaWRlbnRpZmllcnMsIEkgd2lzaCBzb21lb25l IHdvdWxkIGhhdmUgbWFkZSB0aGF0IGFyZ3VtZW50LiAgSSBkbyBub3QgcmVjYWxsIGl0IGhhdmlu ZyBiZWVuIG1hZGUsIGFuZCBJIGJlbGlldmUgSSBwYXJ0aWNpcGF0ZWQgcHJldHR5IGF2aWRseS4g IEkgZG8gcmVjYWxsIHNvbWUgcGVvcGxlIGFyZ3VpbmcgdGhhdCB2YXJpb3VzIGFyY2hhaWMgdGhp bmdzIHdlcmUgIm5vdCBuZWVkZWQiIG9yICJhbG1vc3QgYWx3YXlzIHVudXNhYmxlIGJ5IGFueW9u ZSIsIGJ1dCB0aGF0IHdvdWxkIGhhdmUgcHV0IHVzIGluIHRoZSBzaXR1YXRpb24gb2YgZ29pbmcg dGhyb3VnaCBldmVyeXRoaW5nIG9uZSBjb2RlIHBvaW50IGF0IGEgdGltZS4gIFRoZXJlIHdlcmUg c29tZSB3aG8gd2FudGVkIHRvIHRyeSB0byByZS1kbw0KSUROQTIwMDMgb25seSB1cGRhdGVkIGZv ciB0aGVuLWN1cnJlbnQgdmVyc2lvbnMgb2YgVW5pY29kZSwgYnV0IEkgdGhpbmsgZXhwZXJpZW5j ZSBzaG93cyB0aGF0IHdvdWxkbid0IGhhdmUgd29ya2VkIG91dCB0b28gd2VsbCBlaXRoZXIuDQo+ Pg0KTm8sIEkgc3RpbGwgdGhpbmsgaW4gY29udGV4dCwgZ2VuZXJhbC1jYXRlZ29yeSBhcHByb2Fj aCB3YXMgdGhlIGJlc3QgYXBwcm9hY2ggcG9zc2libGUsIHNob3J0IG9mIGRldmVsb3BpbmcgYSBu ZXcgY2F0ZWdvcnkgd2hpY2ggd2FzIHVucGFsYXRhYmxlIHRvIG1vc3QuIEFzIHlvdSBjb3JyZWN0 bHkgcG9pbnRlZCBvdXQgaW4geW91ciBhbnN3ZXIgaW4gbXkgY29tbWVudCBhYm91dCBFZ3lwdGlh biBoaWVyb2dseXBocywgdGhlc2UgbWF5IGJlIHVzZWQgaW4gbGltaXRlZC11c2UgaWRlbnRpZmll ciBjb250ZXh0IChmb3IgZXhhbXBsZSBpZiB5b3Ugd2FudCB0byBpZGVudGlmeSBiYXNlIE9sZCBF Z3lwdGlhbiBwaG9uZW1lcykgYnV0IHdpdGggc29tZSBjYXZlYXQuDQoNClN0aWxsLCB3aGF0IG5l ZWRzIHRvIGhhcHBlbiB0byB1bmxvY2sgdGhlIElBTkEgSUROIHRhYmxlIGZyb20gYmVpbmcgZnJv emVuIGF0IFVuaWNvZGUgNi4zPyBVbmljb2RlIDExLjAgaXMgbW9udGhzIGF3YXkuIEkgZG9uJ3Qg dGhpbmsgYW55b25lIHdhbnRzIHRvIHJldmlzZSB0aGUgcHJvdG9jb2wgKElETkEgMjAwOCksIGNh bid0IHdlIGp1c3QgYWdyZWUgdGhhdCB0aGUgcHJvdG9jb2wgaXMgbm90IDEwMCUgZmFpbHNhZmUg YW5kIG1vdmUgb24/IERvY3VtZW50aW5nIHRoZSBwcm9ibGVtYXRpYyBjYXNlcyBvdXRzaWRlIHRo ZSBwcm90b2NvbCBzZWVtcyB0byBtZSB0aGUgYmVzdCB3YXkgdG8gcHJvY2VlZC4gQW5kIGl0IHNo b3VsZCBub3QgYmUgYSBnYXRpbmcgZmFjdG9yIGluIGxldHRpbmcgSUFOQSByZXZpc2UgdGhlaXIg dGFibGUgKGFsdGhvdWdoIGl0IHdvdWxkIGJlIGdyZWF0IGlmIHRoYXQgZG9jdW1lbnRhdGlvbiB3 YXMgcHJvZ3Jlc3NpbmcpLg0KDQpCZXN0IHJlZ2FyZHMNCg0KTWljaGVsDQo= From nobody Tue Mar 13 14:35:37 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB5B120454 for ; Tue, 13 Mar 2018 14:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CGlD4J5DpwS for ; Tue, 13 Mar 2018 14:35:34 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64AF1120725 for ; Tue, 13 Mar 2018 14:35:34 -0700 (PDT) Received: from [10.196.199.114] (unknown [IPv6:2620:f:8000:210:dd91:8c3:5ae7:2d8c]) by mail.frobbit.se (Postfix) with ESMTPSA id E64BB28494; Tue, 13 Mar 2018 22:35:29 +0100 (CET) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "John Levine" Cc: idna-update@ietf.org, bortzmeyer@nic.fr Date: Tue, 13 Mar 2018 17:35:41 -0400 X-Mailer: MailMate (2.0BETAr6105) Message-ID: In-Reply-To: <20180313201720.2C67F2286F17@ary.local> References: <20180313201720.2C67F2286F17@ary.local> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_952F4B67-A999-4134-BC12-6E385C7E2E59_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [Idna-update] emoji and security X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 21:35:36 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_952F4B67-A999-4134-BC12-6E385C7E2E59_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 13 Mar 2018, at 16:17, John Levine wrote: > There have been some presentations on what's permissible and emoji spec= ifically which the ICANN leadership appears to understand. > Domains like .WS will sell whatever they can sell and there's not much = anyone can do about that. I think it is important to separate these three things from each other --= at least as much as possible: - The IETF work on IDNA2008 - The ICANN work on LGRs and other generic policy issues - Compliance issues It looks to me like if either people intentionally muddy the water or com= ment on issues they are not plugged in on (or both :-D ). paf --=_MailMate_952F4B67-A999-4134-BC12-6E385C7E2E59_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iG0EARECAC0WIQRUH/cJI8i4DDUU3qWsxpsaC4jXzQUCWqhELQ8ccGFmQGZyb2Ji aXQuc2UACgkQrMabGguI181oUQCfWUe6rDwrVKBYmVvx4G6AdDSBdfYAoIiO2Vt1 00Jz9sCcHY9c9Tb1d+wk =3o64 -----END PGP SIGNATURE----- --=_MailMate_952F4B67-A999-4134-BC12-6E385C7E2E59_=-- From nobody Tue Mar 13 14:47:50 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A09A124239 for ; Tue, 13 Mar 2018 14:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=bfT3IM+E; dkim=pass (1536-bit key) header.d=taugh.com header.b=NGl1uuvB Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sC2vyaKPEcii for ; Tue, 13 Mar 2018 14:47:48 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0A91120454 for ; Tue, 13 Mar 2018 14:47:47 -0700 (PDT) Received: (qmail 84856 invoked from network); 13 Mar 2018 21:47:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=14b72.5aa84702.k1803; bh=fbxPK6sYyGi1POzbc935bqcW19xT8PvWZm/hIRN+qIk=; b=bfT3IM+E7dHAZL43J21uq95MBkjtGC2h5A+opOPZrkrqWtEegNdfOzhXnCMI2/cFrh3A8MRyMgu9yFqOzcYo5KHE3rU3shIhJnss/0LUbrCps9+YNCYEBsv1/RNs6WwGJk/UHoMNt+iX1w29+FSb+BGxHdbXZSHpjR4Tx3qaoIEx7g0tiGldeOBPKVoRX6MIxNMkcParhcj41t/mn++9k4SKXurba3lo+TY9AGLc2Xks9/im1EfVpoYVyUigI41P DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=14b72.5aa84702.k1803; bh=fbxPK6sYyGi1POzbc935bqcW19xT8PvWZm/hIRN+qIk=; b=NGl1uuvBUZZCNgQGpQDylrATJf5uhvlX/Z65la7Ov2YpBeGWyK5VXeFz6G2VaVeShFjaWpB6jeu8Glbl8QcV+zTn7K+v6679x1HXz7d6JrD1nLXHGXkExbHffz7C7TTZq65sqqitWcTPvDuW3zk7tM3go1bKu5X8RS1+PXbwvlr8gwPUZFfuJqVN+mjLFT1zLi9Sys8wqfDLaA+GH5p9LPJxCjzI3phonAj8fjikOa+oU0Oe1r/JMwatpkV1fwrq Received: from ary.local ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 13 Mar 2018 21:47:45 -0000 Received: by ary.local (Postfix, from userid 501) id 86AA8228D992; Tue, 13 Mar 2018 17:47:45 -0400 (AST) Date: 13 Mar 2018 17:47:45 -0400 Message-Id: <20180313214745.86AA8228D992@ary.local> From: "John Levine" To: idna-update@ietf.org Cc: asmusf@ix.netcom.com In-Reply-To: <73252c78-361c-c8cb-e392-c5b4c41deded@ix.netcom.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Idna-update] IDNA and combining sequences (was: Re: Expiration impending: ) X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 21:47:49 -0000 In article <73252c78-361c-c8cb-e392-c5b4c41deded@ix.netcom.com> you write: >Here's a link to the human readable version of the Thai LGR: >https://www.icann.org/sites/default/files/lgr/lgr-2-thai-script-01jun17-en.html >I would be curious, whether you can make sense out of the description >for Thai in the Root Zone. I also invite you to compare that LGR to some >of the gTLD IDN tables for Thai. I think I can follow them OK. The characters each are characterized as consonant, various types of vowels, tones, and diacritics. The ordering rules would make more sense to me as regular expressions. R's, John From nobody Tue Mar 13 15:22:46 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7082B127023 for ; Tue, 13 Mar 2018 15:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYw6TkNblxmP for ; Tue, 13 Mar 2018 15:22:42 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C554012D77E for ; Tue, 13 Mar 2018 15:22:24 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1evsJJ-000JFD-UI; Tue, 13 Mar 2018 18:22:21 -0400 Date: Tue, 13 Mar 2018 18:22:15 -0400 From: John C Klensin To: John Levine , idna-update@ietf.org cc: bortzmeyer@nic.fr Message-ID: <08995B571B00C2D35DC502A0@PSB> In-Reply-To: <20180313201720.2C67F2286F17@ary.local> References: <20180313201720.2C67F2286F17@ary.local> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Idna-update] emoji and security X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 22:22:44 -0000 --On Tuesday, March 13, 2018 16:17 -0400 John Levine wrote: >... > There have been some presentations on what's permissible and > emoji specifically which the ICANN leadership appears to > understand. Domains like .WS will sell whatever they can sell > and there's not much anyone can do about that. For better or worse, the last statement is either untrue or misleading. A more accurate statement would be that ICANN, as an institution, has had no will to do anything about it. john From nobody Tue Mar 13 15:38:54 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6DC9126DFB for ; Tue, 13 Mar 2018 15:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJJuq3KNj3Qf for ; Tue, 13 Mar 2018 15:38:52 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6055C127023 for ; Tue, 13 Mar 2018 15:38:52 -0700 (PDT) Received: from [10.196.199.114] (unknown [IPv6:2620:f:8000:210:e5db:4aae:9108:a997]) by mail.frobbit.se (Postfix) with ESMTPSA id 6B09A284C9; Tue, 13 Mar 2018 23:38:48 +0100 (CET) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "John C Klensin" Cc: "John Levine" , idna-update@ietf.org, bortzmeyer@nic.fr Date: Tue, 13 Mar 2018 18:38:46 -0400 X-Mailer: MailMate (2.0BETAr6105) Message-ID: <09D8FEBC-3382-42FD-925E-C7388F6F5BD8@frobbit.se> In-Reply-To: <08995B571B00C2D35DC502A0@PSB> References: <20180313201720.2C67F2286F17@ary.local> <08995B571B00C2D35DC502A0@PSB> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_3024814F-9A1F-47EF-9AEB-957FDE12DBBA_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [Idna-update] emoji and security X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 22:38:54 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_3024814F-9A1F-47EF-9AEB-957FDE12DBBA_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 13 Mar 2018, at 18:22, John C Klensin wrote: > For better or worse, the last statement is either untrue or > misleading. A more accurate statement would be that ICANN, as an insti= tution, has had no will to do anything about it. I hope this will be discussed tomorrow at the ccNSO meeting. paf --=_MailMate_3024814F-9A1F-47EF-9AEB-957FDE12DBBA_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iG0EARECAC0WIQRUH/cJI8i4DDUU3qWsxpsaC4jXzQUCWqhS9g8ccGFmQGZyb2Ji aXQuc2UACgkQrMabGguI183BCwCeNjRIYOHZ7KJlIMAjp2cRa9+DUqYAmgO74iwb xL9txGfyvNpGCYfm0ELo =Rxc+ -----END PGP SIGNATURE----- --=_MailMate_3024814F-9A1F-47EF-9AEB-957FDE12DBBA_=-- From nobody Tue Mar 13 16:01:57 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667E012DA29 for ; Tue, 13 Mar 2018 16:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRWGNms5P4j0 for ; Tue, 13 Mar 2018 16:01:54 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCACC12D95F for ; Tue, 13 Mar 2018 16:01:45 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1evsvQ-000JI6-1r; Tue, 13 Mar 2018 19:01:44 -0400 Date: Tue, 13 Mar 2018 19:01:37 -0400 From: John C Klensin To: Asmus Freytag , idna-update@ietf.org Message-ID: <33C154CFBC70BA3E3300B76A@PSB> In-Reply-To: <533bb471-da9b-64d0-76aa-a8a1251d256b@ix.netcom.com> References: <533bb471-da9b-64d0-76aa-a8a1251d256b@ix.netcom.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Idna-update] emoji and security X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 23:01:56 -0000 --On Monday, March 12, 2018 09:48 -0700 Asmus Freytag wrote: > All, > > there's a general consensus that emoji and secure IDNs do not > go together. > > This is clearly not something that's taken for granted by > others. Possibly true, but your example below has nothing to do with the issue. > Read down a few messages in this thread on the Unicode list: > https://www.unicode.org/mail-arch/unicode-ml/y2018-m03/0075.ht > ml > to find the suggestion of translating security hash codes into > strings of emoji ostensible for easier verification: > "So that makes me wonder which one would be quicker for a > human to verify on average? Also, which one is more accurate > for a human to verify? I have no idea. For accuracy, it seems > like a lot of thought was put into the visual uniqueness of > Unicode emojis. " > Discuss. First, whether emoji are a good idea for encoding hashes or not has nothing to do with whether they are appropriate for domain names. My guess is that they are not as useful for encoding hashes as the messages I look at seem to believe until and unless (1) the presentation forms for the various emoji code points are standardized sufficiently that they differ no more from one platform to the next than conventional, not extremely artistic, type styles do for modern letter or digit display forms and (2) names of emoji and emoji sequences in popular use are standardized sufficiently that text to speech programs pronounce (or describe) them in ways that are consistent across platforms. Whether that hypothesis is correct or not, I would encourage those who are interested in the question of how easily one string of emoji can be compared to each other to find and real Herman Chernoff's original "faces" paper about the representation of multidimensional data. However, those are just my not-very-educated guesses. As far as IDNs and this discussion is concerned, the bottom line is that the are Invalid for use in domain and that, IMO, those who are anxious to see IANA's tables updated to Unicode 10 or 11 in the relatively near future should probably understand that, with the current level of activity and enthusiasm in the IETF for i18n work generally and IDN work in particular, the last thing they wand to do is to get the table update effort blocks behind a substantive IDNA revision. More important, I agree with Patrik that people are, once again, confusing his three-way distinction among IETF work, ICANN policy work, and compliance issues and my earlier, not-quite-orthogonal, earlier distinction among protocol (DNS and IDNA) constraints, general guidance about how policies should be developed about registration in arbitrary zones, and ICANN policies for the root. If people want to make progress, I think it would be helpful to have those distinctions more strongly in mind... and to avoid the emoji and non-IDN uses of code points issue entirely except as compliance issues that are probably discussed in ICANN, legal, and regulatory contexts rather than here. best, john From nobody Tue Mar 13 16:47:26 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F40A1201F8 for ; Tue, 13 Mar 2018 16:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ix.netcom.com; domainkeys=pass (2048-bit key) header.from=asmusf@ix.netcom.com header.d=ix.netcom.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3G-hvlPHmOOf for ; Tue, 13 Mar 2018 16:47:21 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85D35126DFB for ; Tue, 13 Mar 2018 16:47:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ix.netcom.com; s=dk12062016; t=1520984841; bh=GfyVBzLQJuYBHugSvMpiGZcWO+dPSPZP2qU9 A+/w27Y=; h=Received:Subject:To:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Content-Language:X-ELNK-Trace: X-Originating-IP; b=GzMDuCxZmUrfbqGHvAbL2AXrTpSTiP2hYKs3lBgn65FeSC OJanzRNrPKfakZmC/W05RGlyIesYg6iAZMOeyXpoKvgN+PEDttQocosZg/9AilgKfrZ 14b5lgCc9KD3wImUu5XYEcJpEAz4hDizHw/F2nnGp7NgzyKwvUVQrZHRAn/tiAZY5C1 W7SXUY4ZY0HAuNxJZIL5/sv+2fhvtyK3bCEdIxBI2VBQMvZ8nRIgSC6arnq5z/7ushW tvCoVBriYsUOD/JeSQNLITytV1wSS2HRqh9Wno4uv++eQDYTS/AyaFurYGhTBJCLSzo 9+71QIWwRU4zh3WRzLDW82uGw3dg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=ix.netcom.com; b=sad0BEnweBQ3jdN5uzavpepOLUPqzdAuupzxvUmY7x+HeVZK+fX1XZK/1ZDCOAx6PvDfyaPru+6e9TpClErMNBDRFfQsnJJr4Jcil3KTI0Qo+VQwGjP0ulMiysjeriKn423Jk3w/qEdlFdFdLoMDpnHSPK/A/BscQ/Boy6ci5Mq4SpXH+OilYJ83pLyx9UiZUlmrOcbsm49tO0uM/fZEDm1J0QV02PVMIC5G6aH5uvYldKZt8j3hMMBgHe7dny6m+mnoLyW58+j9CCH/o3ghJ1CFgEXEIlgSEWHDWr7p6SjCQWTkpPKPDZZVqYpIErd3VsUVjaAh+5byPPLbuF/yEw==; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [46.21.151.107] (helo=[10.4.47.190]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1evtdX-000EXT-Rb; Tue, 13 Mar 2018 19:47:20 -0400 To: John Levine , idna-update@ietf.org References: <20180313214745.86AA8228D992@ary.local> From: "Asmus Freytag (c)" Message-ID: <1420573e-4d9d-7853-ffdc-7fc7c2290598@ix.netcom.com> Date: Tue, 13 Mar 2018 16:47:17 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180313214745.86AA8228D992@ary.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-ELNK-Trace: 464f085de979d7246f36dc87813833b2c1627926350bb93fd0fd2bb49320ec6434d70163d6cf65b6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 46.21.151.107 Archived-At: Subject: Re: [Idna-update] IDNA and combining sequences (was: Re: Expiration impending: ) X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 23:47:24 -0000 On 3/13/2018 2:47 PM, John Levine wrote: > In article <73252c78-361c-c8cb-e392-c5b4c41deded@ix.netcom.com> you write: >> Here's a link to the human readable version of the Thai LGR: >> https://www.icann.org/sites/default/files/lgr/lgr-2-thai-script-01jun17-en.html >> I would be curious, whether you can make sense out of the description >> for Thai in the Root Zone. I also invite you to compare that LGR to some >> of the gTLD IDN tables for Thai. > I think I can follow them OK. The characters each are characterized > as consonant, various types of vowels, tones, and diacritics. The > ordering rules would make more sense to me as regular expressions. Check out the bottom of the HTML version of each scripts LGR file. Click on https://www.icann.org/sites/default/files/lgr/lgr-2-thai-script-01jun17-en.html and go to WLE Rules. You should see a table of regexes. Let me know if you'd like to see any additional information. A./ > > R's, > John > From nobody Tue Mar 13 17:09:35 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8EE126DFB for ; Tue, 13 Mar 2018 17:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ix.netcom.com; domainkeys=pass (2048-bit key) header.from=asmusf@ix.netcom.com header.d=ix.netcom.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8wCTzGo2sog for ; Tue, 13 Mar 2018 17:09:32 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E954312E897 for ; Tue, 13 Mar 2018 17:09:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ix.netcom.com; s=dk12062016; t=1520986168; bh=9F6xIhs8cz2ComEpKBUISzu0m1vnUiNpi3gQ XGXGTgE=; h=Received:Subject:To:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Content-Language:X-ELNK-Trace: X-Originating-IP; b=C8Ff9jN+m7+tcWVuzAhCmbq8aw55Rubd4pWA73mslXMYq/ bBhETwawM+wNyiWL1KjsE4iGBzupNGwhk1JBO4b+sf3PbW+HdjY/VMYZHKjw43TSbm2 fsnYNoykOGO29V6kcbHK2JvgnSP/bL6IyY9pn1GAiznZ0ofGCMfLPxDvRtVKFNZMWhZ DJlT3JOPAXPfI9OmnNrBGLTxR5UNO/ZPgdg2VvegShr0RqURjoFQ4iAq3ipGIXBTIbU zpeo4dkBL+k+3r6auxNFv0Ao/hYRtKdF4ta87S4U/QFImp+oTK2IIH7uzPgsQNTRgwA L4d88cY6OINazaq69xaSnRLFsdOw== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=ix.netcom.com; b=hZt3y2iRDTOdP0DztFFApvoPExg9kFZkuqmCbW19BpJmvJuhLaX0hg+Id9ok9qdGqlS5r+EpaTW3NLQR35KrarpZLAh7cGIpWsXCTDvXZO7RJyrYS/SwdOn0v1s908W27Y1enBvr805nET9fz9qgeA1aJGahQGfhddKhnqMQ5A+QhxGXdnngCBTmnR7ooQRoTq5be7KFV3o6A5hQJqoylWbaBHWOzn370rAXzOomiaX+KUrYZJB5gWGriV5EQy+0azniTtIV/TBFmyJKMFmbGoMKBp8lOqQNrIE+QL7cacYS4lmPtuAPtF0EeoP36oSCGX+wclRVSg31jJCpSZbKlA==; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [46.21.151.107] (helo=[10.4.47.190]) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1evtyx-000Gp8-BG for idna-update@ietf.org; Tue, 13 Mar 2018 20:09:27 -0400 To: idna-update@ietf.org References: <533bb471-da9b-64d0-76aa-a8a1251d256b@ix.netcom.com> <20180313202505.ztersmy2z5xuxlvp@mx4.yitter.info> From: Asmus Freytag Message-ID: Date: Tue, 13 Mar 2018 17:09:29 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-ELNK-Trace: 464f085de979d7246f36dc87813833b2c1627926350bb93f36669cd4014ef125d9c60059c04c87f9350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 46.21.151.107 Archived-At: Subject: Re: [Idna-update] emoji and security X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 00:09:34 -0000 On 3/13/2018 1:44 PM, Michel Suignard wrote: > << > If the general-category approach to IDNA2008 was unsuitable in 2008 because it yielded examples of things that should never in principle be identifiers, I wish someone would have made that argument. I do not recall it having been made, and I believe I participated pretty avidly. I do recall some people arguing that various archaic things were "not needed" or "almost always unusable by anyone", but that would have put us in the situation of going through everything one code point at a time. There were some who wanted to try to re-do > IDNA2003 only updated for then-current versions of Unicode, but I think experience shows that wouldn't have worked out too well either. > No, I still think in context, general-category approach was the best approach possible, short of developing a new category which was unpalatable to most. As you correctly pointed out in your answer in my comment about Egyptian hieroglyphs, these may be used in limited-use identifier context (for example if you want to identify base Old Egyptian phonemes) but with some caveat. The design of IDNA2008 reflects two or three conflicting thrusts: 1) it was intended to be updatable to newer versions by simply applying the properties, with using an exception list as a fail-safe. 2) it was intended to avoid clear-cut cases of dual encoding (via normalization) 3) it was intended to be usable on all levels of the tree - therefore it could not be maximally restrictive It would have been easy to restrict IDNA 2008 to modern scripts only - the number of scripts that are in actual modern use of significance for network identifiers is not something that changes based on Unicode version (there really aren't any unencoded ones left in that category). They could have been enumerated and their script properties be used to filter the code points. That was seen as too restrictive - and it's not worth arguing about whether that was the wrong or correct thing to do. However, many non-modern scripts are really not suitable for general identifiers: there's not a body of working expertise on where the problems are with them. It's arguable that they should (have been) kept out of second level domains altogether, because nobody who includes them in a registry can be said to have done so understanding the consequences, therefore implicitly violating the prescription in RFC 5891. Yet they are perfectly fine on some 3rd or 4th level, for example any level, where the same entity controls all labels and there therefore can't be a risk from spoofing, etc. Now, given that the protocol as a whole is that permissive, and given that there are some dozens of outright homographs even in the modern scripts, and have been from 2008 (not to mention hundreds if not thousands of rather similar-looking code points), it's bordering on the absurd to stop all work on updating IDNA 2008 over the case of a single Arabic addition that isn't even an exact homoglyph (fonts that I have researched tend to bind the precomposed mark more tightly to the skeleton than an independent code point having the same shape as the mark). So, Michel's question is relevant: > > Still, what needs to happen to unlock the IANA IDN table from being frozen at Unicode 6.3? Unicode 11.0 is months away. I don't think anyone wants to revise the protocol (IDNA 2008), can't we just agree that the protocol is not 100% failsafe and move on? Documenting the problematic cases outside the protocol seems to me the best way to proceed. And it should not be a gating factor in letting IANA revise their table (although it would be great if that documentation was progressing). So, let's get back to that discussion. A./ > > Best regards > > Michel > _______________________________________________ > IDNA-UPDATE mailing list > IDNA-UPDATE@ietf.org > https://www.ietf.org/mailman/listinfo/idna-update > From nobody Tue Mar 13 18:18:22 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425571250B8 for ; Tue, 13 Mar 2018 18:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=NxUMYWAL; dkim=pass (1024-bit key) header.d=yitter.info header.b=P3kWWcDW Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yc3PkODjEvSw for ; Tue, 13 Mar 2018 18:18:19 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8C44124BFA for ; Tue, 13 Mar 2018 18:18:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id A36ACBE780 for ; Wed, 14 Mar 2018 01:18:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1520990297; bh=WcG+DXV8MYqeffECu/hw6pXJae5XXhLuAw4sODvJxe8=; h=Date:From:To:Subject:References:In-Reply-To:From; b=NxUMYWALzT+P+SbbLAyyQAnKNdvymp29RD8Cwy9uwSjMK+yj4ACYtEOp6au6j9x04 P+wtaWtHfe9ItrsOyog57c9PbFIepEI4EuM39cuePoWTM1ISSS/GixYgosd8g8pP0G 2h70U1GbPCXXguMcRg0DEVGIpxxgHetCdtAcudfw= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f07Mk6CPdopn for ; Wed, 14 Mar 2018 01:18:16 +0000 (UTC) Date: Tue, 13 Mar 2018 21:18:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1520990296; bh=WcG+DXV8MYqeffECu/hw6pXJae5XXhLuAw4sODvJxe8=; h=Date:From:To:Subject:References:In-Reply-To:From; b=P3kWWcDWWnwxPLvjf90FYg23jYltsAR8/FNp1uFrEPKrbp7yYsHO6ET/5AdAPHfRJ sbpM256rKb0gflu02Kfwss4/t7xt/kxeQIs9QM/Hc34Yk8dw5IiG3J6vcVDDkNpdhx /oGDJYYQZSwp2x39J8IHpLkX2vfHyMCTvDMnx2mU= From: Andrew Sullivan To: idna-update@ietf.org Message-ID: <20180314011813.2vhpqle3bt726tbb@mx4.yitter.info> References: <533bb471-da9b-64d0-76aa-a8a1251d256b@ix.netcom.com> <20180313202505.ztersmy2z5xuxlvp@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Idna-update] emoji and security X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 01:18:20 -0000 On Tue, Mar 13, 2018 at 05:09:29PM -0700, Asmus Freytag wrote: > It would have been easy to restrict IDNA 2008 to modern scripts only Easy for _whom_? The IETF just does not have that expertise, which was something we had demonstrated pretty nicely using IDNA2003. What the IETF needed was a way of avoiding the problem of evaluating particular code points, and so the Unicode properties were the path. > However, many non-modern scripts are really not suitable for general > identifiers: there's not a body of working expertise on where the problems > are with them. It's arguable that they should (have been) kept out of second > level domains altogether, because nobody who includes them in a registry can > be said to have done so understanding the consequences, therefore implicitly > violating the prescription in RFC 5891. But the IETF does not have, and does not want, authority to "keep them out". That's a policy question, and one rather far from the IETF's area of expertise. Indeed, that division of labour is precisely why the IANA root zone registry policy is set by someone other than the IETF, which sets the policies for IANA protocol parameter registries. > similar-looking code points), it's bordering on the absurd to stop all work > on updating IDNA 2008 over the case of a single Arabic addition that isn't > even an exact homoglyph But that is not, as I think you know perfectly well, why in the past the IAB asked for additional work and a pause. The IAB made that request because it was necessary to do a bunch of work to understand the issues and attempt to get a grasp on what the overall implications are. I think that was a good idea, because proceeding as one ever did without understanding how one was wrong in one's assumptions is pretty foolish. I think there has been considerable work done in the meantime, and it might well be that conditions have changed (I am not the IAB, so I can't speak about that). Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Mar 14 04:04:49 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE49129C51 for ; Wed, 14 Mar 2018 04:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaNajsyNLXX4 for ; Wed, 14 Mar 2018 04:04:40 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3868212711E for ; Wed, 14 Mar 2018 04:04:39 -0700 (PDT) Received: from [172.20.5.159] (unknown [67.203.214.34]) by mail.frobbit.se (Postfix) with ESMTPSA id 57FE826BCB; Wed, 14 Mar 2018 12:04:35 +0100 (CET) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "Asmus Freytag" Cc: idna-update@ietf.org Date: Wed, 14 Mar 2018 07:04:33 -0400 X-Mailer: MailMate (2.0BETAr6106) Message-ID: <34EF799D-892E-48C5-93AE-AE71A8821F56@frobbit.se> In-Reply-To: References: <533bb471-da9b-64d0-76aa-a8a1251d256b@ix.netcom.com> <20180313202505.ztersmy2z5xuxlvp@mx4.yitter.info> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_656B1DE2-4839-45C2-9C9B-78959649305B_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [Idna-update] emoji and security X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 11:04:46 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_656B1DE2-4839-45C2-9C9B-78959649305B_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 13 Mar 2018, at 20:09, Asmus Freytag wrote: > The design of IDNA2008 reflects two or three conflicting thrusts: > > 1) it was intended to be updatable to newer versions by simply applying= the properties, with using an exception list as a fail-safe. Not really. The normative rules in the IDNA2008 standard where to be appl= ied to the Unicode Versions so that derived property values where calcula= ted, and this independent of the Unicode Version. There are no properties= that are applied. > 2) it was intended to avoid clear-cut cases of dual encoding (via norma= lization) > 3) it was intended to be usable on all levels of the tree - therefore i= t could not be maximally restrictive Patrik --=_MailMate_656B1DE2-4839-45C2-9C9B-78959649305B_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iG0EARECAC0WIQRUH/cJI8i4DDUU3qWsxpsaC4jXzQUCWqkBwQ8ccGFmQGZyb2Ji aXQuc2UACgkQrMabGguI181kSACeMjKNEUOGlBjyIdM+AAJXJdJcTmgAn0uOauuq YrriEDKS64Xk7iMSxpBp =wdU7 -----END PGP SIGNATURE----- --=_MailMate_656B1DE2-4839-45C2-9C9B-78959649305B_=-- From nobody Wed Mar 14 04:06:51 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBA3129C51 for ; Wed, 14 Mar 2018 04:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7RfiCe3gE0A for ; Wed, 14 Mar 2018 04:06:47 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1981212711E for ; Wed, 14 Mar 2018 04:06:47 -0700 (PDT) Received: from [172.20.5.159] (unknown [67.203.214.34]) by mail.frobbit.se (Postfix) with ESMTPSA id 3C3E726BD1; Wed, 14 Mar 2018 12:06:44 +0100 (CET) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "Andrew Sullivan" Cc: idna-update@ietf.org Date: Wed, 14 Mar 2018 07:06:41 -0400 X-Mailer: MailMate (2.0BETAr6106) Message-ID: In-Reply-To: <20180314011813.2vhpqle3bt726tbb@mx4.yitter.info> References: <533bb471-da9b-64d0-76aa-a8a1251d256b@ix.netcom.com> <20180313202505.ztersmy2z5xuxlvp@mx4.yitter.info> <20180314011813.2vhpqle3bt726tbb@mx4.yitter.info> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_60880DE2-826A-4310-BA1A-AEDA5FCD7C8D_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [Idna-update] emoji and security X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 11:06:49 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_60880DE2-826A-4310-BA1A-AEDA5FCD7C8D_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 13 Mar 2018, at 21:18, Andrew Sullivan wrote: > But the IETF does not have, and does not want, authority to "keep them = out". That's a policy question, and one rather far from the IETF's area = of expertise. Indeed, that division of labour is precisely why the IANA = root zone registry policy is set by someone other than the IETF, which se= ts the policies for IANA protocol parameter registries. Correct. The IETF Standard explicitly say that a registry must implement a policy = for what code points they want to include, so by definition, and by desig= n, the IDNA2008 is not a minimum set of code points. It is a maximum set = of code points to be used. Patrik --=_MailMate_60880DE2-826A-4310-BA1A-AEDA5FCD7C8D_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iG0EARECAC0WIQRUH/cJI8i4DDUU3qWsxpsaC4jXzQUCWqkCQQ8ccGFmQGZyb2Ji aXQuc2UACgkQrMabGguI181LeACfdDglQKWfLa7rB3ciwd99lmashKEAn3Pxe1MD VDt9q9+X6kaAvDW25cTu =Jo3o -----END PGP SIGNATURE----- --=_MailMate_60880DE2-826A-4310-BA1A-AEDA5FCD7C8D_=-- From nobody Wed Mar 14 07:34:33 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EADA71270FC for ; Wed, 14 Mar 2018 07:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=suignard.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2TKmQ2J25Vv for ; Wed, 14 Mar 2018 07:34:29 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0071.outbound.protection.outlook.com [104.47.34.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD99A126C83 for ; Wed, 14 Mar 2018 07:34:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suignard.onmicrosoft.com; s=selector1-suignard-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PeOL9/k66UyepfvpZC9SDb7BOOWj0GgOcAq5Esj03a0=; b=rpwoJi3PQjlYxUedxvoeMsGwWF9/Q96jgY1v+VglgP1SI6WbRLlUqf49hmf6p19SgKYVJ9cYGh8GUmLBfzUBtcE+9MjZWP8nyt6QnOSd/zOB6H1XvXrqvDXp4TW9Y3i1seCKVujG3jB4AHZ+tv6lAQb0oVHWUmwHj1qBeW4Nk88= Received: from DM5PR1901MB2197.namprd19.prod.outlook.com (52.132.131.160) by DM5PR1901MB2088.namprd19.prod.outlook.com (52.132.130.167) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.548.13; Wed, 14 Mar 2018 14:34:27 +0000 Received: from DM5PR1901MB2197.namprd19.prod.outlook.com ([fe80::4c67:e6ac:d64e:4930]) by DM5PR1901MB2197.namprd19.prod.outlook.com ([fe80::4c67:e6ac:d64e:4930%13]) with mapi id 15.20.0588.013; Wed, 14 Mar 2018 14:34:27 +0000 From: Michel Suignard To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Andrew Sullivan CC: "idna-update@ietf.org" Thread-Topic: [Idna-update] emoji and security Thread-Index: AQHTuiH036Wme2wFFkaQ526XY0gPJqPM5EtwgAG6L4CAAAGDIIAAPS+AgAATNYCAAKRqgIAANTDw Date: Wed, 14 Mar 2018 14:34:26 +0000 Message-ID: References: <533bb471-da9b-64d0-76aa-a8a1251d256b@ix.netcom.com> <20180313202505.ztersmy2z5xuxlvp@mx4.yitter.info> <20180314011813.2vhpqle3bt726tbb@mx4.yitter.info> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=michel@suignard.com; x-originating-ip: [23.249.129.130] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR1901MB2088; 7:AwlECI2PN6CuPOtSIe9Oj3/AoMW524Boi+BkmTc3q3P0nH1xgc5XmQfwOamgabKio9LPzrDYHC+ZD4xS/MGI5wLfygR9VeWtSiF785PIBcQzPwcmyG6JwesikiAibC4OleIIxGarWYcIuwkD9S0MQDpveRSmzzxWB4JlOQbDD/Z+EHU7j1Ta9Pzz4crwi1v+uguJTnOknkdFwJAh96Dym75pk3jWlTtVmE7Zda7wbdWqtl+mAwpzdKjK2/iQkSlg x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 480bf61b-648c-4619-7d04-08d589b8b089 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4604075)(3008032)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:DM5PR1901MB2088; x-ms-traffictypediagnostic: DM5PR1901MB2088: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231221)(944501244)(52105095)(93006095)(93001095)(3002001)(10201501046)(6041310)(20161123558120)(2016111802025)(20161123562045)(20161123564045)(20161123560045)(6043046)(6072148)(201708071742011); SRVR:DM5PR1901MB2088; BCL:0; PCL:0; RULEID:; SRVR:DM5PR1901MB2088; x-forefront-prvs: 0611A21987 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39830400003)(376002)(39380400002)(366004)(346002)(199004)(189003)(13464003)(6246003)(74316002)(7696005)(81166006)(2950100002)(6436002)(93886005)(305945005)(55016002)(15650500001)(7736002)(25786009)(66066001)(4326008)(53936002)(229853002)(9686003)(3660700001)(110136005)(478600001)(14454004)(33656002)(86362001)(81156014)(8936002)(106356001)(8676002)(5250100002)(316002)(2906002)(5660300001)(186003)(99286004)(105586002)(26005)(102836004)(6506007)(68736007)(2900100001)(53546011)(59450400001)(76176011)(97736004)(3846002)(3280700002)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR1901MB2088; H:DM5PR1901MB2197.namprd19.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: suignard.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: QTcChgc37qjY549IWiW+D1MND+PUlKRPS+UddalzOHPJI46BL0BPalIJAExHS4O/saxSt+Vvf/6saUZ9wD3v1spqtZIEKP4qwrkdjFpAuwovZ39R/hDj1zvaY8nO4WD7RUBc2DeIw2f5ZHYoA2PytKeJou3pdYFu7/tnsAh2OASMNbq/BeL4BIqQWxPS+/3E0pNJzCjsQ7sWT8yoKHgpusWL2qd1KYxJJ29RApg1Goj/bmMFYVyqp/HOrRpeymcSN6tA4dg9Eaz/6IRmTgKBwcbnbPiHY54G8SO4dmifovGpC5sS9XRnMNNxklN3AKP+ZJmWvWMFplgRUkT92WQNZQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: suignard.com X-MS-Exchange-CrossTenant-Network-Message-Id: 480bf61b-648c-4619-7d04-08d589b8b089 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2018 14:34:26.8839 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c72bffc7-022d-442d-a3fe-f53a3fa020d2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1901MB2088 Archived-At: Subject: Re: [Idna-update] emoji and security X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 14:34:32 -0000 I want to show how on a concrete level not having a post Unicode 6.3 IDN ta= ble is hurting work done in ICANN. Unicode 7.0 added support for some Myanm= ar minorities. For many reasons that probably do not interest people in thi= s list, the Myanmar script coverage was a late comer in Unicode encoding, e= specially Myanmar minorities coverage. Therefore, Unicode 7.0 added support= for Shan Pali (again a Myanmar minority). If we could use Unicode 7.0 repe= rtoire as available in an updated IANA IDN2008 table, the root zone Integra= tion Panel would have added 6 characters to the Maximum Starting repertoire= (MSR) which is the sand box for Generation Panels (GP) when they define th= eir own repertoire. Obviously, we have no way to know whether a Myanmar GP = would adopt these characters into the RZ-LGR when/if they do that. But at t= his point this is not even an option. At this point, most of the recent Unicode work on scripts (and I made the p= recision on purpose) is concentrated on historic ones, or disadvantaged com= munities. By being stuck on Unicode 6.3 we are putting these communities at= disadvantage. Not a message you want to convey on these days and ages. I think I (and most of us) have decent understanding of the tasks separatio= n mentioned by Patrik, I just want to move on past Unicode 6.3, so we can d= o our work in appropriate context. Michel -----Original Message----- From: IDNA-UPDATE On Behalf Of Patrik F=E4lt= str=F6m Sent: Wednesday, March 14, 2018 4:07 AM To: Andrew Sullivan Cc: idna-update@ietf.org Subject: Re: [Idna-update] emoji and security On 13 Mar 2018, at 21:18, Andrew Sullivan wrote: > But the IETF does not have, and does not want, authority to "keep them ou= t". That's a policy question, and one rather far from the IETF's area of e= xpertise. Indeed, that division of labour is precisely why the IANA root z= one registry policy is set by someone other than the IETF, which sets the p= olicies for IANA protocol parameter registries. Correct. The IETF Standard explicitly say that a registry must implement a policy fo= r what code points they want to include, so by definition, and by design, t= he IDNA2008 is not a minimum set of code points. It is a maximum set of cod= e points to be used. Patrik From nobody Wed Mar 14 07:53:16 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C82FB1270FC for ; Wed, 14 Mar 2018 07:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJk7JJQJuvgn for ; Wed, 14 Mar 2018 07:53:08 -0700 (PDT) Received: from ayla.bortzmeyer.org (ayla.bortzmeyer.org [92.243.4.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9794F12D7EF for ; Wed, 14 Mar 2018 07:53:08 -0700 (PDT) Received: by ayla.bortzmeyer.org (Postfix, from userid 10) id 29309A05CE; Wed, 14 Mar 2018 15:53:06 +0100 (CET) Received: by mail.sources.org (Postfix, from userid 1000) id 62F921908E1; Wed, 14 Mar 2018 15:49:39 +0100 (CET) Date: Wed, 14 Mar 2018 15:49:39 +0100 From: Stephane Bortzmeyer To: John Levine Cc: idna-update@ietf.org, bortzmeyer@nic.fr Message-ID: <20180314144939.ehis5fndfn7x7qqm@sources.org> References: <20180313093035.fcax6v3zmz3nv34r@nic.fr> <20180313201720.2C67F2286F17@ary.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180313201720.2C67F2286F17@ary.local> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 9.3 X-Charlie: Je suis Charlie User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Idna-update] emoji and security X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 14:53:11 -0000 On Tue, Mar 13, 2018 at 04:17:19PM -0400, John Levine wrote a message of 22 lines which said: > You know and I know that emoji domains are a bad idea for all sorts > of reasons. I said it was "illegal", from RFC 5892, which is not exactly the same thing. From nobody Wed Mar 14 08:15:25 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773C6127444 for ; Wed, 14 Mar 2018 08:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMl8xgSgZhEa for ; Wed, 14 Mar 2018 08:15:22 -0700 (PDT) Received: from smtp01.icann.org (smtp01.icann.org [192.0.46.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44F5C1270FC for ; Wed, 14 Mar 2018 08:15:22 -0700 (PDT) Received: from KIDA-6861.local (unknown [10.32.60.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp01.icann.org (Postfix) with ESMTPS id 8FE12E0C1C; Wed, 14 Mar 2018 15:15:20 +0000 (UTC) Date: Wed, 14 Mar 2018 11:15:17 -0400 From: Kim Davies To: Michel Suignard Cc: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= , Andrew Sullivan , "idna-update@ietf.org" Message-ID: <20180314151515.GA70553@KIDA-6861.local> References: <533bb471-da9b-64d0-76aa-a8a1251d256b@ix.netcom.com> <20180313202505.ztersmy2z5xuxlvp@mx4.yitter.info> <20180314011813.2vhpqle3bt726tbb@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.3 (2018-01-21) Archived-At: Subject: Re: [Idna-update] [Ext] Re: emoji and security X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 15:15:23 -0000 Quoting Michel Suignard on Wednesday March 14, 2018: > I want to show how on a concrete level not having a post Unicode 6.3 > IDN table is hurting work done in ICANN. Unicode 7.0 added support > for some Myanmar minorities. ... > If we could use Unicode 7.0 repertoire as available in an > updated IANA IDN2008 table, the root zone Integration Panel would have ... > But at this point this is not even an option. I think a point of clarification would be useful here. The IDNA tables published by IANA is informative, not normative. Nothing in the IDNA 2008 specification says these tables need to be used -- a full implementation would derive their own list of PVALID etc. from Unicode properties and some exception tables in RFC 5892. However, given the IDNA tables are posted, some IDNA 2008 implementations use them as a shortcut to greatly simplify their code. As a consequence, the landscape of implementations is likely variable because you have some implementations using the IANA-published tables limited to the Unicode 6.3 repertoire, and others using more recent versions because they are deriving from Unicode properties directly. kim From nobody Wed Mar 14 08:38:36 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4D71200B9 for ; Wed, 14 Mar 2018 08:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.821 X-Spam-Level: X-Spam-Status: No, score=-0.821 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ix.netcom.com; domainkeys=pass (2048-bit key) header.from=asmusf@ix.netcom.com header.d=ix.netcom.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b_evYzxxQozE for ; Wed, 14 Mar 2018 08:38:33 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A6F2126C19 for ; Wed, 14 Mar 2018 08:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ix.netcom.com; s=dk12062016; t=1521041913; bh=99X1iW6hbG+ehl5H26BVXl/XLekKcle2//om tMrEuvk=; h=Received:Subject:To:Cc:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Content-Language:X-ELNK-Trace: X-Originating-IP; b=bQYyUDMcYjf2WVFBfxwsyBxDTN6ZRxM6ak+Bq10cqdRecO HAuTYtIY81qIR4qdKrGj/4zLvdQRZsM0DwZ0KVo4vGONAlgIVSCu1JaWcSEYI9eTH89 hMD6N8buI7UUT4AZVollS2gfCu0lsII6SjHMaeH/wk/R0btHD5y+BDQjNHby7pFN5bw fPaFOM1S8sdFYkbXTN43QsX/AmeyfKSvy5abMiOsboGKTSTMpuTrrS4Jlch2HgL2BZL QMqYl+47603tuXdytzEX+LEGjt4lryqxFT1ynssuzdwIpWsYNKTq4TO6aT16Yzlryrg eXr7Qv0pKYr5BpYY/fiS8EULGOWA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=ix.netcom.com; b=Ew8AiVeBVHQR99FQFvzx2F7FHK3y0deX8wn6pqllb3TIhWiweDJJO9010TWb3dpdwg0n6onTCmUX+RkmVARYESw8NgdaS97jrfsqrQBP3zttaVlyYXoN9hlkb3DgoJKNLN9zIprXOgHUL09ivtCx2c/EeIfUcgIlquiBxVOZI8qV8vtYr++8Gk/KnoA5/O7SuEjxm7CbWxlQfMZ9dkHef3c2Q92wTo2ok7Fzvfm7eLNOuljKe26avV3zR0XqldGsoPebF2pRTx9WB52rgs2FFgebAVOOKd+2oOUUtOgvXBZA4dU8vKcz3rj3E9YxcYGNvJ/AFRuy+SvlzI6vVK7e4g==; h=Received:Subject:To:Cc:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [71.35.186.204] (helo=[192.168.0.5]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1ew8U3-000Ems-Dy; Wed, 14 Mar 2018 11:38:31 -0400 To: =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= Cc: idna-update@ietf.org References: <533bb471-da9b-64d0-76aa-a8a1251d256b@ix.netcom.com> <20180313202505.ztersmy2z5xuxlvp@mx4.yitter.info> <34EF799D-892E-48C5-93AE-AE71A8821F56@frobbit.se> From: "Asmus Freytag (c)" Message-ID: <41524b3a-a196-7920-ea1a-2387a63e969c@ix.netcom.com> Date: Wed, 14 Mar 2018 08:38:35 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <34EF799D-892E-48C5-93AE-AE71A8821F56@frobbit.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-ELNK-Trace: 464f085de979d7246f36dc87813833b2c1627926350bb93ffc7db339077ee5be45f9ce73fd3619ad350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.35.186.204 Archived-At: Subject: Re: [Idna-update] emoji and security X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 15:38:36 -0000 On 3/14/2018 4:04 AM, Patrik Fältström wrote: > On 13 Mar 2018, at 20:09, Asmus Freytag wrote: > >> The design of IDNA2008 reflects two or three conflicting thrusts: >> >> 1) it was intended to be updatable to newer versions by simply applying the properties, with using an exception list as a fail-safe. > Not really. The normative rules in the IDNA2008 standard where to be applied to the Unicode Versions so that derived property values where calculated, and this independent of the Unicode Version. There are no properties that are applied. Thanks for providing the details; my summary of the process was a bit too abridged. > >> 2) it was intended to avoid clear-cut cases of dual encoding (via normalization) >> 3) it was intended to be usable on all levels of the tree - therefore it could not be maximally restrictive > Patrik From nobody Wed Mar 14 09:13:13 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 766D0126D73 for ; Wed, 14 Mar 2018 09:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xjb4dHTM8F6z for ; Wed, 14 Mar 2018 09:13:09 -0700 (PDT) Received: from ayla.bortzmeyer.org (ayla.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fe27:3d3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 426311252BA for ; Wed, 14 Mar 2018 09:13:09 -0700 (PDT) Received: by ayla.bortzmeyer.org (Postfix, from userid 10) id 2837EA05CE; Wed, 14 Mar 2018 17:13:06 +0100 (CET) Received: by mail.sources.org (Postfix, from userid 1000) id AAA9D1908E1; Wed, 14 Mar 2018 17:11:29 +0100 (CET) Date: Wed, 14 Mar 2018 17:11:29 +0100 From: Stephane Bortzmeyer To: Kim Davies Cc: Michel Suignard , "idna-update@ietf.org" , Andrew Sullivan , Patrik =?utf-8?B?RsOkbHRzdHLDtm0=?= Message-ID: <20180314161129.t6frhcmv6cvqmyrj@sources.org> References: <533bb471-da9b-64d0-76aa-a8a1251d256b@ix.netcom.com> <20180313202505.ztersmy2z5xuxlvp@mx4.yitter.info> <20180314011813.2vhpqle3bt726tbb@mx4.yitter.info> <20180314151515.GA70553@KIDA-6861.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180314151515.GA70553@KIDA-6861.local> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 9.3 X-Charlie: Je suis Charlie User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Idna-update] [Ext] Re: emoji and security X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 16:13:11 -0000 On Wed, Mar 14, 2018 at 11:15:17AM -0400, Kim Davies wrote a message of 30 lines which said: > I think a point of clarification would be useful here. The IDNA tables > published by IANA is informative, not normative. Nothing in the > IDNA 2008 specification says these tables need to be used -- a full > implementation would derive their own list of PVALID etc. from Unicode > properties and some exception tables in RFC 5892. Let me check that I understood RFC 5892: an implementation can calculate its own tables but, if they follow RFC 5892, they should get, FOR THE SAME UNICODE VERSION, the same result than IANA, or anyone else, no? From nobody Wed Mar 14 10:17:10 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9242120227 for ; Wed, 14 Mar 2018 10:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0gw7rxyCmVO for ; Wed, 14 Mar 2018 10:17:07 -0700 (PDT) Received: from smtp01.icann.org (smtp01.icann.org [192.0.46.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB581120047 for ; Wed, 14 Mar 2018 10:17:07 -0700 (PDT) Received: from KIDA-6861.local (unknown [10.32.60.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp01.icann.org (Postfix) with ESMTPS id E2CEDE0B03; Wed, 14 Mar 2018 17:17:05 +0000 (UTC) Date: Wed, 14 Mar 2018 13:17:03 -0400 From: Kim Davies To: Stephane Bortzmeyer Cc: "idna-update@ietf.org" , Michel Suignard , Andrew Sullivan , Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Message-ID: <20180314171701.GA75066@KIDA-6861.local> References: <533bb471-da9b-64d0-76aa-a8a1251d256b@ix.netcom.com> <20180313202505.ztersmy2z5xuxlvp@mx4.yitter.info> <20180314011813.2vhpqle3bt726tbb@mx4.yitter.info> <20180314151515.GA70553@KIDA-6861.local> <20180314161129.t6frhcmv6cvqmyrj@sources.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180314161129.t6frhcmv6cvqmyrj@sources.org> User-Agent: Mutt/1.9.3 (2018-01-21) Archived-At: Subject: Re: [Idna-update] [Ext] Re: emoji and security X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 17:17:09 -0000 Quoting Stephane Bortzmeyer on Wednesday March 14, 2018: > > Let me check that I understood RFC 5892: an implementation can > calculate its own tables but, if they follow RFC 5892, they should > get, FOR THE SAME UNICODE VERSION, the same result than IANA, or > anyone else, no? That is correct. kim From nobody Wed Mar 14 10:53:25 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6C412D86E for ; Wed, 14 Mar 2018 10:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqDxkGeHaBGz for ; Wed, 14 Mar 2018 10:53:21 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBF51124D37 for ; Wed, 14 Mar 2018 10:53:20 -0700 (PDT) Received: from [169.254.169.246] (29-196.icannmeeting.org [199.91.196.29]) by mail.frobbit.se (Postfix) with ESMTPSA id 3205822D95; Wed, 14 Mar 2018 18:53:16 +0100 (CET) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "Stephane Bortzmeyer" Cc: "Kim Davies" , "Michel Suignard" , idna-update@ietf.org, "Andrew Sullivan" Date: Wed, 14 Mar 2018 13:53:14 -0400 X-Mailer: MailMate (2.0BETAr6106) Message-ID: <88B864C0-4C55-42F3-ADF5-02B32A2C2A38@frobbit.se> In-Reply-To: <20180314161129.t6frhcmv6cvqmyrj@sources.org> References: <533bb471-da9b-64d0-76aa-a8a1251d256b@ix.netcom.com> <20180313202505.ztersmy2z5xuxlvp@mx4.yitter.info> <20180314011813.2vhpqle3bt726tbb@mx4.yitter.info> <20180314151515.GA70553@KIDA-6861.local> <20180314161129.t6frhcmv6cvqmyrj@sources.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_2825CA8F-13C1-471E-A700-986A69DABC82_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [Idna-update] [Ext] Re: emoji and security X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 17:53:24 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_2825CA8F-13C1-471E-A700-986A69DABC82_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 14 Mar 2018, at 12:11, Stephane Bortzmeyer wrote: > Let me check that I understood RFC 5892: an implementation can calculat= e its own tables but, if they follow RFC 5892, they should get, FOR THE S= AME UNICODE VERSION, the same result than IANA, or anyone else, no? Yes. The rules are normative, so two implementations of RFC5892 is to pro= duce two equal tables of derived property values. I have myself two implementations I have written in two different languag= es (Ruby and Python3 -- where the Ruby one is not using any IDN library, = for example for normalization) and I compare results of both of them with= the result IANA get applying their software. That is the process we use to validate the tables IANA publish, which are= non-normative. paf --=_MailMate_2825CA8F-13C1-471E-A700-986A69DABC82_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iG0EARECAC0WIQRUH/cJI8i4DDUU3qWsxpsaC4jXzQUCWqlhig8ccGFmQGZyb2Ji aXQuc2UACgkQrMabGguI180xegCdFbNjQ5vsky+nBaAvCnUGadZd8FQAnjhGDJQC bp8RBk9vxx/GPXcUISFm =/JjM -----END PGP SIGNATURE----- --=_MailMate_2825CA8F-13C1-471E-A700-986A69DABC82_=-- From nobody Wed Mar 14 11:00:49 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98CF7126BF0 for ; Wed, 14 Mar 2018 11:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81dmXs5I6Mff for ; Wed, 14 Mar 2018 11:00:47 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E126120047 for ; Wed, 14 Mar 2018 11:00:47 -0700 (PDT) Received: from [169.254.169.246] (29-196.icannmeeting.org [199.91.196.29]) by mail.frobbit.se (Postfix) with ESMTPSA id 898EE2349C; Wed, 14 Mar 2018 19:00:43 +0100 (CET) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "Stephane Bortzmeyer" Cc: "John Levine" , idna-update@ietf.org Date: Wed, 14 Mar 2018 14:00:42 -0400 X-Mailer: MailMate (2.0BETAr6106) Message-ID: In-Reply-To: <20180314144939.ehis5fndfn7x7qqm@sources.org> References: <20180313093035.fcax6v3zmz3nv34r@nic.fr> <20180313201720.2C67F2286F17@ary.local> <20180314144939.ehis5fndfn7x7qqm@sources.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_92DEE20D-CE76-410C-8239-46C91C987CB8_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [Idna-update] emoji and security X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 18:00:49 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_92DEE20D-CE76-410C-8239-46C91C987CB8_= Content-Type: text/plain On 14 Mar 2018, at 10:49, Stephane Bortzmeyer wrote: > On Tue, Mar 13, 2018 at 04:17:19PM -0400, > John Levine wrote > a message of 22 lines which said: > >> You know and I know that emoji domains are a bad idea for all sorts >> of reasons. > > I said it was "illegal", from RFC 5892, which is not exactly the same thing. The precise text is: DISALLOWED: Those that should clearly not be included in IDNs. Code points with this property value are not permitted in IDNs. I.e. "not permitted". paf --=_MailMate_92DEE20D-CE76-410C-8239-46C91C987CB8_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iG0EARECAC0WIQRUH/cJI8i4DDUU3qWsxpsaC4jXzQUCWqljSg8ccGFmQGZyb2Ji aXQuc2UACgkQrMabGguI181vDQCgkrQdN3X9HnxmZs4FOmNjCPJzBdUAoJS8HHiN dwt3On6LXeOKG8AjtDeA =tRtS -----END PGP SIGNATURE----- --=_MailMate_92DEE20D-CE76-410C-8239-46C91C987CB8_=-- From nobody Wed Mar 14 11:24:27 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15913126BF6 for ; Wed, 14 Mar 2018 11:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.821 X-Spam-Level: X-Spam-Status: No, score=-0.821 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ix.netcom.com; domainkeys=pass (2048-bit key) header.from=asmusf@ix.netcom.com header.d=ix.netcom.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnfnI2pbJAJn for ; Wed, 14 Mar 2018 11:24:23 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFAA71267BB for ; Wed, 14 Mar 2018 11:24:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ix.netcom.com; s=dk12062016; t=1521051863; bh=TIiECyYn3z5TnN/l3vQYmX/v8QOoW7N8SfdG g10IE5k=; h=Received:Subject:To:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Content-Language:X-ELNK-Trace: X-Originating-IP; b=ofcohirkvWp3xreBBySDTL9ff24LatkdlbMN2XFsu/UFB5 uCxcmKoXSD1+vo6IZL1ORbaAHu9+U94CHk+0PRDE6digWs4SpU9vSDlem+Idg2OCuZt SnNJbTPoRHARTOPYZ9rL8iGsQCTCTn9nmBr0n0UxDA74/Imq4cHB3v1Fw7mWJYcJCJc 2RLzwIxSMGXkzAsJXS/EesNl97HviGZWzLao7eoyREKhooZhvGIQs8QVnbaQr4PYOLV 1ezaWaiintcx58KZCyFNDpG9Gy79kHMoNR10pNliNhyOAffaCpaU/33EPoRpPBmzzh4 v95zANbyncIFvQS11VvI0kZmE9yw== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=ix.netcom.com; b=ipwKA+qXszXy2qWkwWS/JiBqsEU/Oxv1kKyXwrG1wlwvIUPKKTVVxkbXhDoReAzXKtWBHJv5FAgrUbxUIzrLvIBtcb8efgE/0LYcrXZz7KZbKaYVqANh38JES52TI6wzKuXFiW+p0q1Df5EhPy+Dxb/X1/TFMZ8N6R5PysRqIuPvi2i0F2EwESIZJ3VsKDa7ixsSSPzxZGKY/lJRzBicRfMiimucHfdTQHp5yvMajlOu/UzH2tCxd8EKocwX5Ey9TB4XCe5+Ttpz46tqgkgfSLzTXGmw1G1K2pf+w/gT/5d/ngFAOJJhhjwx0LSahHQKqtloUZDIGZ51tyDS/LFJrQ==; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [71.35.186.204] (helo=[192.168.0.5]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1ewB4X-000BQ6-OV for idna-update@ietf.org; Wed, 14 Mar 2018 14:24:21 -0400 To: idna-update@ietf.org References: <533bb471-da9b-64d0-76aa-a8a1251d256b@ix.netcom.com> <20180313202505.ztersmy2z5xuxlvp@mx4.yitter.info> <20180314011813.2vhpqle3bt726tbb@mx4.yitter.info> From: Asmus Freytag Message-ID: <0e9fe1a0-4658-1a78-d2a0-891828574ea2@ix.netcom.com> Date: Wed, 14 Mar 2018 11:24:26 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-ELNK-Trace: 464f085de979d7246f36dc87813833b2c1627926350bb93f62dd00be9b9a05582596dccea7c3739f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.35.186.204 Archived-At: Subject: Re: [Idna-update] How to get past Unicode 6.3 X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 18:24:25 -0000 We need to bring the discussion back to "what are the concrete steps required to get IDNA update past Unicode 6.3"? A./ On 3/14/2018 7:34 AM, Michel Suignard wrote: > I want to show how on a concrete level not having a post Unicode 6.3 IDN table is hurting work done in ICANN. Unicode 7.0 added support for some Myanmar minorities. For many reasons that probably do not interest people in this list, the Myanmar script coverage was a late comer in Unicode encoding, especially Myanmar minorities coverage. Therefore, Unicode 7.0 added support for Shan Pali (again a Myanmar minority). If we could use Unicode 7.0 repertoire as available in an updated IANA IDN2008 table, the root zone Integration Panel would have added 6 characters to the Maximum Starting repertoire (MSR) which is the sand box for Generation Panels (GP) when they define their own repertoire. Obviously, we have no way to know whether a Myanmar GP would adopt these characters into the RZ-LGR when/if they do that. But at this point this is not even an option. > > At this point, most of the recent Unicode work on scripts (and I made the precision on purpose) is concentrated on historic ones, or disadvantaged communities. By being stuck on Unicode 6.3 we are putting these communities at disadvantage. Not a message you want to convey on these days and ages. > > I think I (and most of us) have decent understanding of the tasks separation mentioned by Patrik, I just want to move on past Unicode 6.3, so we can do our work in appropriate context. > > Michel > > -----Original Message----- > From: IDNA-UPDATE On Behalf Of Patrik Fältström > Sent: Wednesday, March 14, 2018 4:07 AM > To: Andrew Sullivan > Cc: idna-update@ietf.org > Subject: Re: [Idna-update] emoji and security > > On 13 Mar 2018, at 21:18, Andrew Sullivan wrote: > >> But the IETF does not have, and does not want, authority to "keep them out". That's a policy question, and one rather far from the IETF's area of expertise. Indeed, that division of labour is precisely why the IANA root zone registry policy is set by someone other than the IETF, which sets the policies for IANA protocol parameter registries. > Correct. > > The IETF Standard explicitly say that a registry must implement a policy for what code points they want to include, so by definition, and by design, the IDNA2008 is not a minimum set of code points. It is a maximum set of code points to be used. > > Patrik > > _______________________________________________ > IDNA-UPDATE mailing list > IDNA-UPDATE@ietf.org > https://www.ietf.org/mailman/listinfo/idna-update > From nobody Wed Mar 14 17:56:35 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF2512D7F5 for ; Wed, 14 Mar 2018 17:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oPD45_SdvIW for ; Wed, 14 Mar 2018 17:56:31 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ED1D12D7E5 for ; Wed, 14 Mar 2018 17:56:30 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ewHC1-000Leo-5p; Wed, 14 Mar 2018 20:56:29 -0400 Date: Wed, 14 Mar 2018 20:56:21 -0400 From: John C Klensin To: Asmus Freytag cc: idna-update@ietf.org Message-ID: <3F9BFC15AA26613D6E364523@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Idna-update] Expiration impending: X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2018 00:56:34 -0000 --On Saturday, 10 March, 2018 23:28 -0800 Asmus Freytag wrote: >... >> (2) Advice, guidelines, or policy requirements applicable to = a >> broad variety of domains. =20 > May not need to define precisely what the limits of that > variety is, but should note that zones where all labels are > owned by the same entity may already be restrictive in other > ways, whereas zones that not only are "public" but also > support users of more than one script (and by extension > multiple languages are perhaps most in need of these). Yes, absolutely. But this is one of the places where my rant about DNAME (see recent note in response to John Levine) comes in. Suppose we have a nice, orderly, TLD named = "=D0=BE=D0=B1=D0=BB=D0=B0=D1=81=D1=82=D1=8C" with rules that allow basic Latin and Russian Cyrillic code points. Suppose those tables are not only enforced by the registry but that they are published using the mechanisms of RFC 7940 and that lookup applications, knowing that those are the published rules, enforce them at lookup time. The latter would not be necessary if all registries followed the rules but would constitute powerful protection for users if some did not (and would not have been possible until RFC 7940 standardized the table format and make it machine-processable). =20 Now, let's assume a second TLD, =CE=BA=CF=84=CE=AE=CF=83=CE=B7, = and assume it has rules that only allow the subset of Greek script used in modern Greek. Assume that its registry operator is well-behaved enough to avoid anything at the second level that includes a DNAME pointing out of the zone, but it does register an SLD that, to make the problem clear, we will call =CE=BA=CE=B1=CE=BA=CF=8C. = We now have =CE=BA=CE=B1=CE=BA=CF=8C.=CE=BA=CF=84=CE=AE=CF=83=CE=B7, a = perfectly valid SLD (modulo some issues about the tonos, but let's not get distracted). But now the owner/ zone administrator of = =CE=BA=CE=B1=CE=BA=CF=8C.=CE=BA=CF=84=CE=AE=CF=83=CE=B7, being = as unconcerned about good and safe user experience as its chosen name implies, creates a subdomain whose DNS entry, in the usual presentation form, looks like = =CE=BA=CF=84=CE=AE=CF=83=CE=B7.=CE=BA=CE=B1=CE=BA=CF=8C.=CE=BA=CF= =84=CE=AE=CF=83=CE=B7. IN DNAME = =D0=BE=D0=B1=D0=BB=D0=B0=D1=81=D1=82=D1=8C. Now, all of the rules of both TLDs have been conformed to -- there are no labels in subdomains of = =D0=BE=D0=B1=D0=BB=D0=B0=D1=81=D1=82=D1=8C that are anything but Latin or Cyrillic and no labels in subdomains of =CE=BA=CF=84=CE=AE=CF=83=CE=B7 that are anything but Greek. But = apparent subdomains of = =CE=BA=CF=84=CE=AE=CF=83=CE=B7.=CE=BA=CE=B1=CE=BA=CF=8C.=CE=BA=CF= =84=CE=AE=CF=83=CE=B7 are not in Greek, rules that apply to individual labels in individual zones (rather than FQDNs) are of no help, and, given the number of graphemes that appear in both Greek and Cyrillic, all bets are off. One could try to make rules against FQDNs that use different scripts in different labels, but that would not only be contradictory to the "distributed administration" principle but there are a large collection of reasonable examples for which it would make no sense (consider, e.g., subdomains of the EU TLD). Some far nastier examples are possible and are left as an exercise. Many of those examples require an unscrupulous or inattentive TLD registry, but we haven't had a big shortage of those. >... >> For zones that are well >> and carefully run, with name use and the best interests of >> Internet users in mind, it is reasonable to expect that >> well-designed guidelines will be followed, as least unless=20 >> the zone administrators understand things well enough to=20 >> carefully allow exceptions. =20 > These zones will take active steps to mitigate issues caused > by the fact that IDNs are necessarily reflective of f the > writing systems involved - including their comparative > complexity vis a vis the basic Latin alphabet. Right. I just believe that, absent much more serious enforcement mechanisms than have proven possible in the past (for those who believe such mechanisms are feasible, I suggest a careful study of ICANN's history when a TLD has started with one set of rules, signed appropriate contracts, and then come back and said something equivalent to "well, that didn't work as a business model so we want to make changes") or a sudden outbreak of a disease that causes all TLD registries to suddenly start putting the best interests of Internet users ahead of the interests of their registrants and profits, we need to be quite clear about our expectations. =20 >> The meta-rule that zones are required to >> understand what they are doing is one such guideline and, at >> least to a first approximation, I think most registries >> (including zones below the second level that are using IDNs) >> try. =20 > Not my impression at all. For anything other than very simple > scripts, the IDNtables that can be easily inspected because > they are available online as tables are not reflective of a > deeper understanding of the writing system, beyond the most > basic limitation of the repertoire to a given script. Ok. Probably I was being too optimistic. But, if you are correct (as you probably are), that is another answer to John Levine's question. It also raises what is probably the fundamental strategic question in all of this. There are two possible extreme positions. There are probably some middle grounds, but I have had no success in finding them (perhaps you and others can do better). At one extreme, we try to persuade registries to allow only those labels whose implications they fully understand, not just in terms of code point lists but in, to use your words, reflecting a deeper understanding of the writing system. Although it isn't spelled out clearly in the IDNA2008 specs, and may not be clear enough even in the 5891bis draft, it means that a TLD registry that does not have a deep understanding of a script and _all_ of the writing systems with which it is used has no business allowing SLD registrations in that script at all and that, the DNAME issue notwithstanding, each (TLD) registry should be contractually imposing similar requirements on each SLD it creates and all of their subdomains (something 1591 clearly anticipated but ICANN has required only for a few "sponsored" domains and then effectively abandoned the requirements). The alternative, stated as positively as I can manage, is that we accept as a fact that we are never going to get that level of responsible behavior from registries, even some (or many) TLD registries, and take measures to enable those who don't have a clue about particular scripts but are determined to register labels that use them anyway to do a somewhat less bad job. =20 The thing that concerns me about going down the second path is that it may encourage registries who have no idea about, e.g., how the writing system for Lower Slobbovian works to say, "well, maybe we can make some money selling Lower Slobbovian names and all we have to do is follow ICANN's code point lists and rules and, even if the result is dangerous in some way, no one will be able to blame us". >... >> What has not panned out is the assumption that ICANN would >> make at least some serious effort to either persuade or = induce >> registries, even second-level entities under contracted TLD >> registries, to follow those guidelines, especially with >> regard to taking active responsibility for what they are >> doing. =20 > This is an empty letter as long as no guidelines exist that > establish meaningful metrics allowing to tell apart successful > mitigation from simply copying some basically insufficient IDN > table from some other zone. I'm not sure I agree with your assertion at all and doubt the fundamental assumption behind it, but, assuming that I did, I don't see how you establish credible metrics. The problem, as we have discussed at length and agreed about in other contexts, is that no set of tables and rules, no matter how detailed, are going to be able to enumerate all of the possible cases that should be blocked, not looked up, or otherwise avoided. So, you can count the number of labels that have been blocked but cannot, as far as I can tell, count those that should have been blocked and weren't ... unless you can persuade the browser vendors to instrument their code (and give you the results) and I'm not sure even that would be effective. >> But that doesn't make establishing the guidelines a bad idea. >> I'm not aware of it having happened yet with IDNs, but there >> is precedent for people who are harmed by someone else's bad >> behavior to cite violation of widely-accepted guidelines as >> evidence that the behavior was bad or negligent. > This would be a beneficial use of guidelines that actually > cover meaningful best-practice. It would also be, at least from my point of view, a beneficial use of guidelines that clearly identified stupid behavior. If the "meaningful best practice" comes down to "don't do anything stupid or that you don't understand" then the two formulations are probably equivalent. =20 >> (3) The rules that are used by the operator/ administrator of >> a particular registry to determine what can or will be >> allowed in that zone. > Note that for many zones what is allowed is not static, but > depends on what is already delegated. The rules effectively > describe what is allowed next, given a status quo. > This approach is something that is useful (or should be > understood as useful) for the majority of zones: in all zones > registrants compete for available labels, but in some zones, a > delegated label does not only prevent the same label, but also > certain related labels from being registered. !! I think I finally figured out why we agree on the facts but keep struggling over the conclusions. Sorry for taking so long. Let me see if I can explain. The above is perfectly reasonable and rational. It is, indeed, the way the DNS was run for many years before ICANN came along. Names were delegated (or reserved, which did happen, although not often, and some names were rejected when applied for independent of formal reservations) on a first-come, first-served (FCFS) basis. If someone came along later and wanted a reserved name, they needed to be able to explain convincingly why the reason it was reserved didn't apply any more. If they wanted one that was already delegated, too bad for them. Disputes about "rights" to names were largely avoided by repeating that the things were no more than convenient mnemonics and not brands or marks (that might not have been realistic, but it was generally believed and accepted with a few very notable exceptions). The system, and the reasons for it, were generally enough understood that the frequency with which someone needed to be told "no, you lose, either propose a different name or go away" was exceedingly low. That model worked well for all levels of the tree below the root and under the distributed administration model. The root was different because it had its own, fairly clear, rules (see RFC 1591 for an instantiation of those rules). What you are suggesting about would have fit very will into that model. Now, let me see if I can describe an alternate reality. In that reality, people decide that there should be a competitive market in names. Suddenly, the childhood fantasy of one of my peers to own "3" becomes plausible, especially after someone else actually does get to buy "zero". Because a lot of people would like to own "3", (or whatever example one might pick), rather complex policies are put in place to manage dispute resolution, policies that, in general, do not recognize either FCFS or technical considerations. A result of that and other factors caused FCFS moved from being an administrative convenience to being "early adopter advantage" and unfair to those who came along later and did so in an environment in which unfairness was a powerful argument for reversing a policy decision. If a registrant collected a series of names, perhaps to minimize confusion or make typing more convenient when it was important (for example, consider "isoc.org" and "internetsociety.org"), it was possible that the dispute resolution procedures (or legal action independent of them) could apply a Solomon-like solution to a dispute and split the bundle up. =20 Of course, the second is a different reality sufficiently different that none of us could imagine it in, say, 1996. I suggest that it bears a much closer resemblance to what has occurred in practice in recent years than the earlier model. > Such related labels are called variants -- but the use of the > term variants does not necessary imply that more than one > label gets to be allocated. On the contrary, our experience in > Root Zone has shown that blocked variants are by far more > common and useful tool. Useful to whom? If the goal question is "how best to prevent confusion" or "how to avoid getting tangled up in the DNS's poor alias facilities", certainly blocking anything that can be confusing with a known and delegated (or about to be delegated) label is the right answer. If the goal is to increase the odds that users will find the names they are looking for no matter how they type them, then one wants to delegate as many of the strings as possible and cope with the aliasing problem (possibly by pushing it off to the registrant with some sort of "same owner" rule and hoping that sticks. I know it isn't how parts of ICANN want to think about the problem, but I believe that, if a consistent user experience is the target, then whatever rules are applied to blocking or delegation of character variants ought to also apply to other types of orthographic variants and, if the labels are words, same-language synonyms. =20 >> Noting that the rules for the root (including the >> LGR rules but not limited to them, at least yet) are just a >> special case of this category, all that is necessary to >> application and enforcement of the rules is that the registry >> decide to do so... and that the rules that are chosen be >> sufficiently acceptable to whatever community(ies) are in a >> position to hold the registry accountable that they don't >> either turn into a source of never-ending strife or change >> often enough to cause perceived instability. =20 > Again, the Root Zone project is informative. > So far, a single proposed script LGR has proven contentious -- > with the wider community objecting to it being too permissive, > rather than the other way around. As this has not reached the > stage where an LGR has been submitted, the community may yet > come to some agreement. =20 > Generally, the drafting panels appear to have been well > anchored in their respective communities and their submitted > proposals perform well when tested against lists of putative > labels while mitigating known issues. I don't want to go much further down this path -- it is very much separate from anything having to do with IDNA as a protocol -- but I wonder if it is worth remembering that there have been questions about whether some of the "communities" of which those panels are representative are actually defined correctly and that the number of new gTLDs actually allocated and delegated under LGR rules so far is zero. It may be a little early to start drawing firm conclusions. >> I think some of our discussions have confused the first two >> and last two categories and then gone on to confuse the third >> (general guidelines for the second level and below) and = fourth >> (registry-specific rules), assuming, for example, that what = is >> suitable for one registry should be applicable, either as a >> guideline or as a protocol changes, to the others. >=20 > Very cogent observation. >=20 > I'm certainly keenly aware of the difference between the > RZ-LGR project which effectively results in registry-specific > rules (for the root) and general guidelines that can be used > to define registry-specific rules on other levels. =20 > The RZ-LGR is purposefully limited to the modern-use subset of > modern- use scripts. (It also includes hyphen and digits). It > further makes the assump- tion that the zone is shared by > users of multiple scripts - and users of "all" languages - at > least those that are widely written for everyday purposes. Good assumptions except that I thought digits and the hyphen were banned from labels in the root by other decisions... decisions that go back to RFCs 1123 and 1591. Or maybe I misunderstood you. > The individual script LGRs are also accompanied by very > detailed description > and references to source materials. =20 > That allows them to serve as examples/starting point for > defining registry- specific rules for other zones. The closer > these zones match the other assumptions for the RZ project, > the closer to the RZ-LGR their eventual rules would be > expected to end up - unless the RZ-LGR erred in how to account > for the risks inherent in multi-script/multi-zone domains. > This simplifies the task of the guideline writer, without > reducing the task to simply imposing the RZ-LGR unexamined > everywhere. Yes, certainly. > If I were to be asked by a registry to develop policy for the > second level, I might proceed as follows: >=20 > (0) Start with the RZ-LGR s for all the scripts to be > supported in the new zone. >=20 > (1) Add all digits and the hyphen > (1a) Mitigate the issue of homoglyph digits (Arabic) by making > them blocked in-script variants > (1b) Mitigate the issue of some digits being homglyphs of > letters by making these blocked in-script variants >=20 > (2) Retain cross-script variants from RZ-LGR for all scripts > in the new zone >=20 > (3) Optional, if a feature (restriction) in the RZ-LGR is > documented as being > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 motivated by the need to be = particularly > restrictive for the root, > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 investigate the cost/benefit = of removing the > restriction. (If in doubt keep the restriction). >=20 > (4) If the zone is limited to certain languages, remove > features (restrictions) > documented as being necessary in a multilingual zone > (4a) investigate the cost/benefit of adding language-specific > support for any language that isn't well-supported due to RZ > restrictions. >=20 > (5) Make sure LGR follows guidelines on combining marks; (like > the ones we discussed under separate cover. >=20 > (6) Make sure LGR follows guidelines on repertoire (TBD). >=20 > (7) Make sure WLE rules and context rules continue to work if > repertoire expanded > =C2=A0=C2=A0=C2=A0 (7a) It may be appropriate to relax / = tighten some of > these rules if > =C2=A0=C2=A0=C2=A0=C2=A0 the mix of languages to be supported = requires that > or benefits from it. >=20 > and so on. This seems to me like good guidance, especially for those cases that use scripts and languages that are part of the root zone process, I note that it might be perfectly sensible for a script community to decide that the processes required by ICANN (formation of a Generation Panel, making the request for one or more TLDs that involves a more or less complex and expensive application process, coming up with an operations model or operator that would meet ICANN requirements, paying an application fee, etc.) was not worth the effort and consequently to not try to put names in that script in the root while nonetheless using them at the second level or below in trees that the considered appropriate. Presumably, any guidelines would not try to block names that were part of that pattern, but that implies that either they would not be applicable at all to such scripts but would need to make special provisions for them. Either way, it is not an IETF problem > The guidelines would effectively focus on well-understood > modern-use script, because that's what is addressed by the > RZ-LGR. Because (most) historical scripts are supremely > ill-understood and have not had the benefit of any deeper > analysis for IDN purposes, a general guideline would strongly > recommend against including them. > Some lesser-used and/or emerging scripts (with modern user > communities) would benefit from their communities following > the RZ-LGR procedure with appropriate adaptations. See above. > Some very limited zones, e.g. Cyrillic only, or Polynesian > only, might come under pressure to support code points for > characters that look like punctuation marks; these code points > were not ruled out in IDNA, but are considered deeply > troublesome (not least by RFC 6912) -- actual guidelines would > have to be written so as to settle the question whether > "secure" LGRs should always eschew them, or whether limited > exceptions are to be seen as justified. I think that trying to make general statements or guidelines about these situations put you into territory where neither you nor ICANN would be wise to go but, again, not an IETF problem. > The issues facing the various scripts are diverse enough that > trying to write fully general guidelines gets either > meaningless (too vague) or bewilderingly complex in no time. > That's the reason I keep coming back to the use of the RZ-LGR > as a non-binding starting point. Understood. john From nobody Thu Mar 15 12:43:02 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C9B124C27 for ; Thu, 15 Mar 2018 12:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.761 X-Spam-Level: X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=TqPMz31G; dkim=pass (1536-bit key) header.d=taugh.com header.b=OVvTOg/W Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cNW9fx8f9F2 for ; Thu, 15 Mar 2018 12:42:58 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79D0912D77C for ; Thu, 15 Mar 2018 12:42:58 -0700 (PDT) Received: (qmail 42253 invoked from network); 15 Mar 2018 19:42:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=a509.5aaaccc1.k1803; bh=nwsK7jYEW4qKy/+S70uD3S5JhjhfLR75a94epSlj9JM=; b=TqPMz31Ggb/aqKHGftEErvVc48k6wBZ0Ajac/6z6LI5qNkPNBbWMpUWbMcdYOa7hFNmyPVVtzkN6mAbn20ZdzvTJ4tsgvg+ciz6oROz255zoaG0+ByLn9Z9b8WRNkantGawQR5LQRDDCIMXMNjC7J0FCCsqNiIe94rtDnppihKVNZrX4nGc/prgcMV1mLgWVly35U2u9PQ/vpR3AZm1S/YJl+0XgGY+fuYudg6FepkllciIB2IbIDHaw7iJNeGZl DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=a509.5aaaccc1.k1803; bh=nwsK7jYEW4qKy/+S70uD3S5JhjhfLR75a94epSlj9JM=; b=OVvTOg/WEs8PC6WRogczy18qsC4mS7gmXkGP7e2AoNBr1XmmJSleE5jnp5BxztaX1xZF4bNyU5HtfqPmWo6/8bAWws4Fa2RDUvF2nPnH93YYzy3kwDwG5HyxldgSjuCP+M5ObSr7DxuFiY9b4Mj/jW1opT4wm4A1wnixUKKgZTS50vg+KE659erP8LtNpj43B7R3omaiad1IPAzNFw+g3bcWZiR+kwUFNgDo+Ymuc4zUxd/JkxEE60ZG/uyvFzRP Received: from ary.local ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 15 Mar 2018 19:42:57 -0000 Received: by ary.local (Postfix, from userid 501) id CF68F22C3BA1; Thu, 15 Mar 2018 15:42:56 -0400 (AST) Date: 15 Mar 2018 15:42:56 -0400 Message-Id: <20180315194256.CF68F22C3BA1@ary.local> From: "John Levine" To: idna-update@ietf.org Cc: asmusf@ix.netcom.com In-Reply-To: <1420573e-4d9d-7853-ffdc-7fc7c2290598@ix.netcom.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Idna-update] IDNA and combining sequences (was: Re: Expiration impending: ) X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2018 19:43:00 -0000 In article <1420573e-4d9d-7853-ffdc-7fc7c2290598@ix.netcom.com> you write: >> I think I can follow them OK. The characters each are characterized >> as consonant, various types of vowels, tones, and diacritics. The >> ordering rules would make more sense to me as regular expressions. >Check out the bottom of the HTML version of each scripts LGR file. > >Click on > >https://www.icann.org/sites/default/files/lgr/lgr-2-thai-script-01jun17-en.html > >and go to WLE Rules. You should see a table of regexes. I was more thinking of regexes for an entire valid string, not for each rule, but close enough. R's, John From nobody Thu Mar 15 14:01:30 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C92B0126DED for ; Thu, 15 Mar 2018 14:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ix.netcom.com; domainkeys=pass (2048-bit key) header.from=asmusf@ix.netcom.com header.d=ix.netcom.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBfzTczPpzXw for ; Thu, 15 Mar 2018 14:01:26 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF8301200F1 for ; Thu, 15 Mar 2018 14:01:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ix.netcom.com; s=dk12062016; t=1521147686; bh=6Az7P/gk/fKfCV/hEssmTP0KShmbxz2QoY9x yFZQv2c=; h=Received:Subject:To:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Content-Language:X-ELNK-Trace: X-Originating-IP; b=Ft4nGlYDqT0vN16Xs4yHO+nAeU2WzAdnEP/IfWbE2d7L+M 9FfPIR/ws/PyUP2EMZX0Qa7fiYZJxpttO+rLxsJz4xbRlg4xo7C1vkyRk2d5qEpT6q6 h02P6+ieamgbg9BLTnxEUCPP3LOzaTZ4boRJO/Q5PNCE8aAJoIhloZ9JOxPygtbMMRw ZIae9vHHp6woFRlAM3v0ZpLWYiE9vEAko/kHAxDaFsqD8TSD/h7pnCTUaOcHxZ1DTn7 HsrS+REkVTCC3zwnnrC9ybEbszuHh+nCXwvm/fLxIfL9R65dNdlOY8GH4/NsgPR6Eu2 m0KOyj/xmdpx5nD9Hx0GrFpMc78g== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=ix.netcom.com; b=iYVdv9e2xL4RhwOnQAHEEmfddXsFD1y3GWocbxfOBFcuHLI7LrjlnwAEsdowX1DeYMPiALro/lUDnsNKw+q4PKB/O/Gf4cn3xmDhlM5TotPhuaq71EGCpr/CYdyJYaqY3kbu7zvv8IAGLx3bnk+jSi2Tutbj4590nfgS4dfVqzWC16EsVKG5yYF4l3BNsEDMgtuyVJecixSNju8scIHwW+66Pb6qPvJnakWroP5vcv6kMfgxW0YeTI9CF2RzS5HFfveqskTR1eRDWJHNODwulYwJwkgTs/+B+2f1O4Xa7FUvXBg+h7QSWaYZdeqmC10k8gJv5zDtLPGlif3HdAf8lw==; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [173.244.217.91] (helo=[10.104.138.162]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1ewa03-000DGc-Mp; Thu, 15 Mar 2018 17:01:23 -0400 To: John Levine , idna-update@ietf.org References: <20180315194256.CF68F22C3BA1@ary.local> From: "Asmus Freytag (c)" Message-ID: <647d97cf-4b2a-c5f6-194b-c6887c5e4947@ix.netcom.com> Date: Thu, 15 Mar 2018 14:01:28 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180315194256.CF68F22C3BA1@ary.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-ELNK-Trace: 464f085de979d7246f36dc87813833b2c1627926350bb93f7ee6915665675388b3e2c5e54062abd1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.244.217.91 Archived-At: Subject: Re: [Idna-update] IDNA and combining sequences (was: Re: Expiration impending: ) X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2018 21:01:29 -0000 On 3/15/2018 12:42 PM, John Levine wrote: > In article <1420573e-4d9d-7853-ffdc-7fc7c2290598@ix.netcom.com> you write: >>> I think I can follow them OK. The characters each are characterized >>> as consonant, various types of vowels, tones, and diacritics. The >>> ordering rules would make more sense to me as regular expressions. >> Check out the bottom of the HTML version of each scripts LGR file. >> >> Click on >> >> https://www.icann.org/sites/default/files/lgr/lgr-2-thai-script-01jun17-en.html >> >> and go to WLE Rules. You should see a table of regexes. > I was more thinking of regexes for an entire valid string, not for > each rule, but close enough. John, the rules are designed this way for a purpose. The reason is that the most common scenario is the need to prevent some Y from following some X, where the Y is typically a combining mark. Sometimes, script rendering will "ligate" certain combinations, but fail if incompatible ones are encountered; in that case you may see right had contexts or both left and right contexts. We originally thought we could start for the Indic scripts with an Akshar (syllable) for which there exist BNF definitions. A label would then be a concatenation of valid Akshars. The attempt resulted in horrifically complex looking rules that were impossible to review and  tended to be overly restrictive: there are many strings that are a bit unusual/uncommon, but not "broken". Sometimes the available Akshar rules were language-specific. For all of these reasons, but mainly to be able to break down things into easily understood bits, we ended up with the system we have now. Now, given that an XML per RFC 7940 is fully machine parsable, it could be an exercise to the reader to compile a regex for full labels. I think that should be possible, however, I've not attempted to prove this - there may be some syntax construction that is difficult/impossible to translate into a regex for the whole lable. All I know is that I can translate each of the context rules to regexes (that's how the tool I wrote evaluates labels based on an LGR), but I apply them iteratively at each character position in the string rather than using the regex mechanism. A./ From nobody Thu Mar 15 14:30:19 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF25F127241 for ; Thu, 15 Mar 2018 14:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=NhZdi7HF; dkim=pass (1536-bit key) header.d=taugh.com header.b=AISNxCii Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Pyq42iuILjw for ; Thu, 15 Mar 2018 14:30:16 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C09081270B4 for ; Thu, 15 Mar 2018 14:30:15 -0700 (PDT) Received: (qmail 64473 invoked from network); 15 Mar 2018 21:30:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=fbd7.5aaae5e6.k1803; bh=LpXtX33Dim+zSnSd3RUxsmXLL3QSwvC93Osd+i3eIK4=; b=NhZdi7HFisiNDUXOgg4zAre4uoLRAym/2xZuqEmxVtdNl0qTEvaTN2QpJOJE0YgWtKR4f/s6uiU9cGrNx+pMIi51qjOIrDjeIq1jh/YD9bW3t5sXpj3pNHpiStMIdcA9oroKaVhTlIwP1iWRK4awdSCC+Qp1JjLZNHYmFGvvJaIUcFVbBJ4W/3tYN9mhWiQUi46Tb2KWeefUnhRZ2cebCHOBE5ybRHBWvVliJJjm7J0aVh+OMeLXIJDCTb0N7iEI DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=fbd7.5aaae5e6.k1803; bh=LpXtX33Dim+zSnSd3RUxsmXLL3QSwvC93Osd+i3eIK4=; b=AISNxCii6IQ15dSV+iznDINUYsnEkCNw1HI2W4zpJx7wHyiTpHIadH2I2fQh26rzo7Pl2dM5feKhmbIPPcjhq6rN7B5gqsZ0spvXcZ8S7AqEhB4HnqbUHcRNx4C6U8Ily53OMTRFqcQnfWCKMzD8Vl9qObUr1FEOu9JOzz925n6ZKYPCqwG87qesjA9EHv7R8RXQUadnQsBtdpq+wikIrWnJoQFdnH1BDnPWZbYI73mDwGkrk14JQVkE8XOGj0ch Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 15 Mar 2018 21:30:14 -0000 Date: 15 Mar 2018 17:30:12 -0400 Message-ID: From: "John R Levine" To: "Asmus Freytag (c)" Cc: "John Levine" , idna-update@ietf.org In-Reply-To: <647d97cf-4b2a-c5f6-194b-c6887c5e4947@ix.netcom.com> References: <20180315194256.CF68F22C3BA1@ary.local> <647d97cf-4b2a-c5f6-194b-c6887c5e4947@ix.netcom.com> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Idna-update] IDNA and combining sequences (was: Re: Expiration impending: ) X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2018 21:30:18 -0000 > Now, given that an XML per RFC 7940 is fully machine parsable, it could be an > exercise to the reader to compile a regex for full labels. I think that > should be possible, however, I've not attempted to prove this - there may be > some syntax construction that is difficult/impossible to translate into a > regex for the whole label. Interesting point, I'll take a look. I'm not surprised that other people are less thrilled by regexes than I am, since the probably weren't teaching compiler courses and drawing state machines on the chalkboard 40 years ago. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri Mar 16 22:49:56 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8BAD126DFB for ; Fri, 16 Mar 2018 22:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPuRDTPQY0Xu for ; Fri, 16 Mar 2018 22:49:52 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28AF3120726 for ; Fri, 16 Mar 2018 22:49:52 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 0BB3528018B; Sat, 17 Mar 2018 06:49:50 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 05C2628066B; Sat, 17 Mar 2018 06:49:50 +0100 (CET) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id F324628018B; Sat, 17 Mar 2018 06:49:49 +0100 (CET) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id EF1F3642A7A1; Sat, 17 Mar 2018 06:49:49 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id E4C4840FCA; Sat, 17 Mar 2018 06:49:49 +0100 (CET) Date: Sat, 17 Mar 2018 06:49:49 +0100 From: Stephane Bortzmeyer To: Asmus Freytag Cc: idna-update@ietf.org Message-ID: <20180317054949.joqlorudn6pfjyfo@nic.fr> References: <533bb471-da9b-64d0-76aa-a8a1251d256b@ix.netcom.com> <20180313202505.ztersmy2z5xuxlvp@mx4.yitter.info> <20180314011813.2vhpqle3bt726tbb@mx4.yitter.info> <0e9fe1a0-4658-1a78-d2a0-891828574ea2@ix.netcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0e9fe1a0-4658-1a78-d2a0-891828574ea2@ix.netcom.com> X-Operating-System: Debian GNU/Linux 9.3 X-Kernel: Linux 4.9.0-6-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.016951, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.3.17.53616 Archived-At: Subject: Re: [Idna-update] How to get past Unicode 6.3 X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2018 05:49:55 -0000 On Wed, Mar 14, 2018 at 11:24:26AM -0700, Asmus Freytag wrote a message of 49 lines which said: > We need to bring the discussion back to "what are the concrete steps > required to get IDNA update past Unicode 6.3"? "We have therefore asked the expert reviewer to bring the IDNA Parameters registry up to date by June of 2018, working with other experts as necessary." https://www.iab.org/documents/correspondence-reports-documents/2018-2/iab-statement-on-identifiers-and-unicode/ From nobody Sat Mar 17 19:57:43 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B284126BF0 for ; Sat, 17 Mar 2018 19:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mZg3-T7Tqya for ; Sat, 17 Mar 2018 19:57:40 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8CD71243F3 for ; Sat, 17 Mar 2018 19:57:40 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1exOVr-0006if-7W; Sat, 17 Mar 2018 22:57:35 -0400 Date: Sat, 17 Mar 2018 22:57:27 -0400 From: John C Klensin To: Kim Davies , Michel Suignard cc: idna-update@ietf.org, Andrew Sullivan , =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= Message-ID: <7DEBC7AEB8C79C7B9A7ECAAF@PSB> In-Reply-To: <20180314151515.GA70553@KIDA-6861.local> References: <533bb471-da9b-64d0-76aa-a8a1251d256b@ix.netcom.com> <20180313202505.ztersmy2z5xuxlvp@mx4.yitter.info> <20180314011813.2vhpqle3bt726tbb@mx4.yitter.info> <20180314151515.GA70553@KIDA-6861.local> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Idna-update] [Ext] Re: emoji and security X-BeenThere: idna-update@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2018 02:57:42 -0000 Kim, Just to clarify one other part of your comments... --On Wednesday, March 14, 2018 11:15 -0400 Kim Davies wrote: > However, given the IDNA tables are posted, some IDNA 2008 > implementations use them as a shortcut to greatly simplify > their code. As a consequence, the landscape of implementations > is likely variable because you have some implementations using > the IANA-published tables limited to the Unicode 6.3 > repertoire, and others using more recent versions because they > are deriving from Unicode properties directly. yes. But that is inevitable, whether there are tables stored at IANA or not. Unless every registry in the DNS (not just TLD or SLD registries) is either calculating code point and label validity using the IDNA rules in real time or making that calculation every time a new version of Unicode is announced (and exactly the same number of minutes after the announcement) _and_ every instance of every lookup application does one of those things as well, there will always be some practical risk of unsynchronized implementations. I don't know whether having the tables posted by/at IANA makes that problem any worse, but it seems obvious to me that it doesn't make it much worse. Noting that the DNS itself uses a slow synchronization model, those properties of IDNA2008 probably don't even change the problem in a qualitative way. best, john