From nobody Thu Oct 5 10:36:12 2017 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 59863134301 for ; Thu, 5 Oct 2017 10:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=unavailable 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 pHUzPNtbzzxN for ; Thu, 5 Oct 2017 10:35:19 -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 A6068134305 for ; Thu, 5 Oct 2017 10:35:08 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1e0A39-000Ck4-Mt for idna-update@ietf.org; Thu, 05 Oct 2017 13:35:07 -0400 Date: Thu, 05 Oct 2017 13:35:00 -0400 From: John C Klensin To: idna-update@ietf.org Message-ID: <8EB791E33C4FFB1EEE2614FB@PSB> 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: [Idna-update] Heads up -- Arabic Normalization or rendering issue -- draft UTR 53 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, 05 Oct 2017 17:35:29 -0000 Hi. I call the attention of this group to draft UTR#53, "UNICODE ARABIC MARK ORDERING ALGORITHM". I'm not going to try to summarize it because people should read it for themselves, but it _may_ have some or all of the following implications: * Special normalization rules, based on combining classes and inconsistent with current Unicode canonical normalization, may be needed to Arabic script when combining marks are used. That would presumably have significant impact on IDNA. On the other hand, if we continue to require that all strings that are input to IDNA be in NFC form, this might be irrelevant to even if it is important for Arabic * If certain marks are used, Arabic script requires more attention to rendering that current Unicode specifications assume. That probably would not affect IDNA because we do no deal with rendering at all. * Independent of the proposed solution, the document suggests that a situation exists that is the opposite of "confusability", i.e., a single valid U-label might look very different, and possibly even be interpreted as different strings, depending on whether the label is in NFC form or has has something like this algorithm applied after normalization. I will leave other IDNA implications to the imagination (and further research), but it is possible that we need to build contextual rules around combining classes. On the other hand, if combining sequences were banned entirely with Arabic script, as has been proposed a few times, this (real or potential) problem would disappear for IDNs. Precis would probably be another story. If this really is intended as a normalization add-on or post processing step, it seems to me it is really a new normalization form or set of forms (additional to NFC, NFD, NFKC, and NFKD) in disguise and that treating it as such might be a lot less problematic than trying to be sure UAOA is applied (if needed) after each time one of the traditional normalizations is applied. Note that this document is out for public review. Anyone having comments on it should send them directly to Unicode as specified in http://www.unicode.org/review/pri359/. The document is probably worth discussing on this list only with regard to IDNA-specific effects. john From nobody Thu Oct 5 10:53:33 2017 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 EC2BF134304 for ; Thu, 5 Oct 2017 10:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.408 X-Spam-Level: X-Spam-Status: No, score=-1.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=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 ohaanAM9CoCe for ; Thu, 5 Oct 2017 10:53:28 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 6A8F21342F4 for ; Thu, 5 Oct 2017 10:53:28 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id j126so2285248oib.8 for ; Thu, 05 Oct 2017 10:53:28 -0700 (PDT) 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=Wbgc1Kb3T6BTqrq52hcwaorUMOxJxf5l8eVusTqVBqY=; b=Ve3U7TK1MteOdBAYLewrvk/gzzXUMyC6KAyjbpW5/qFeBBFYUmplXANTmVKSQf4uZA 8Q+o1YdjDi+7oF4OKc+PZZn2krcg5LbBwa5uMsmzEkGo3q9gRE9TEBmojtzckWeGwLZK jLLDUldd1Yw0yetu8/wtg2qPl4TY1B5vMn8TWEXx056IDph+9pZwmi7oKe6vHedb0zIq Jcij+T6co9YSBEElpt1GJb4EzeLpq9r0lUQwX5n/bFnNsNbNiAZlFMuM9H5Nwh86XiJM 4jSYv41ocC6TRnP2RGXrK1C9rbTFO8FJhTVezrQbLJrOGGsB0hXq2+NwyTwZ9Bo2JJMP /pPQ== 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=Wbgc1Kb3T6BTqrq52hcwaorUMOxJxf5l8eVusTqVBqY=; b=B2DhU9BaWXTdpF4JIbkJb5z2DhTwJhshIE+iCOesBdLSE4QQIRQSPJaK2wmGj38AHk DmZdykjNX+GYT8J9fDDIbY7w2QcU76vtfSCE71G8vlxjNVhTbpqR4P7PVjx3i5rxXKWL iT6/vSlh6COsu6Qm3C/oj355he6YVmCe0oRAcB2C9dk6r4m/3a/hkLupT1h40cJP9cjb 70hQN6EPQiDbIf+oMzvTgMitpM3U2haj/s6J9e7tqej6ZZkFyUrpGsLU4u+CbYa77YYR g1cXknOlXv2yMZPi9Ov/xABo7Wx5QciSGGZIZk77l3AvnwamXoR+nAmwbfs1XIf0ibu1 5nVQ== X-Gm-Message-State: AMCzsaUmZUGDuwEudPeJOB4ujHKXkX/t7riSeisYF6OWywe1UF6ucerN BnHZnGOexMBc3arJDgcwo3I4CSUgdwSvREXz3+g= X-Google-Smtp-Source: AOwi7QAqzbrdbUzdf3mm0GpIXEx5hoLO4LsP7PE9uRY1pEICJlwqB4J/qDVO3QXuni4KQu3LOI80U5h01bbysld4cy0= X-Received: by 10.157.34.132 with SMTP id y4mr12497353ota.255.1507226007522; Thu, 05 Oct 2017 10:53:27 -0700 (PDT) MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.157.37.229 with HTTP; Thu, 5 Oct 2017 10:53:06 -0700 (PDT) In-Reply-To: <8EB791E33C4FFB1EEE2614FB@PSB> References: <8EB791E33C4FFB1EEE2614FB@PSB> From: =?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?= Date: Thu, 5 Oct 2017 19:53:06 +0200 X-Google-Sender-Auth: Co27ENVO7mHjlUJI9s08uHdwpyA Message-ID: To: John C Klensin Cc: idna-update@ietf.org Content-Type: multipart/alternative; boundary="94eb2c04d9c2c6529b055ad06600" Archived-At: Subject: Re: [Idna-update] Heads up -- Arabic Normalization or rendering issue -- draft UTR 53 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, 05 Oct 2017 17:53:31 -0000 --94eb2c04d9c2c6529b055ad06600 Content-Type: text/plain; charset="UTF-8" I believe there is a misunderstanding of this. It is the preordering of marks as input to the purpose of rendering, and has nothing to do with the interchanged form of text or any of the normalization forms. Others have already pointed out that the document as it stands does not make that sufficiently clear. Mark Mark (https://twitter.com/mark_e_davis) On Thu, Oct 5, 2017 at 7:35 PM, John C Klensin wrote: > Hi. > > I call the attention of this group to draft UTR#53, "UNICODE > ARABIC MARK ORDERING ALGORITHM". I'm not going to try to > summarize it because people should read it for themselves, but > it _may_ have some or all of the following implications: > > * Special normalization rules, based on combining classes and > inconsistent with current Unicode canonical normalization, may > be needed to Arabic script when combining marks are used. > That would presumably have significant impact on IDNA. On the > other hand, if we continue to require that all strings that are > input to IDNA be in NFC form, this might be irrelevant to even > if it is important for Arabic > > * If certain marks are used, Arabic script requires more > attention to rendering that current Unicode specifications > assume. That probably would not affect IDNA because we do no > deal with rendering at all. > > * Independent of the proposed solution, the document suggests > that a situation exists that is the opposite of "confusability", > i.e., a single valid U-label might look very different, and > possibly even be interpreted as different strings, depending on > whether the label is in NFC form or has has something like this > algorithm applied after normalization. > > I will leave other IDNA implications to the imagination (and > further research), but it is possible that we need to build > contextual rules around combining classes. On the other hand, > if combining sequences were banned entirely with Arabic script, > as has been proposed a few times, this (real or potential) > problem would disappear for IDNs. Precis would probably be > another story. > > If this really is intended as a normalization add-on or post > processing step, it seems to me it is really a new normalization > form or set of forms (additional to NFC, NFD, NFKC, and NFKD) in > disguise and that treating it as such might be a lot less > problematic than trying to be sure UAOA is applied (if needed) > after each time one of the traditional normalizations is applied. > > Note that this document is out for public review. Anyone having > comments on it should send them directly to Unicode as specified > in http://www.unicode.org/review/pri359/. The document is > probably worth discussing on this list only with regard to > IDNA-specific effects. > > john > > > > > _______________________________________________ > IDNA-UPDATE mailing list > IDNA-UPDATE@ietf.org > https://www.ietf.org/mailman/listinfo/idna-update > --94eb2c04d9c2c6529b055ad06600 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe there is a misunderstanding of this. It is the pre= ordering of marks as input to the purpose of rendering, and has nothing to = do with the interchanged form of text or any of the normalization forms. Ot= hers have already pointed out that the document as it stands does not make = that sufficiently clear.

Mark


On Thu, Oct 5, 2017 at 7:35 PM, John C Klens= in <john-ietf@jck.com> wrote:
Hi.

I call the attention of this group to draft UTR#53, "UNICODE
ARABIC MARK ORDERING ALGORITHM".=C2=A0 =C2=A0I'm not going to try = to
summarize it because people should read it for themselves, but
it _may_ have some or all of the following implications:

* Special normalization rules, based on combining classes and
inconsistent with current Unicode canonical normalization, may
be needed to Arabic script when combining marks are used.
That would presumably have significant impact on IDNA.=C2=A0 On the
other hand, if we continue to require that all strings that are
input to IDNA be in NFC form, this might be irrelevant to even
if it is important for Arabic

* If certain marks are used, Arabic script requires more
attention to rendering that current Unicode specifications
assume.=C2=A0 That probably would not affect IDNA because we do no
deal with rendering at all.

* Independent of the proposed solution, the document suggests
that a situation exists that is the opposite of "confusability",<= br> i.e., a single valid U-label might look very different, and
possibly even be interpreted as different strings, depending on
whether the label is in NFC form or has has something like this
algorithm applied after normalization.

I will leave other IDNA implications to the imagination (and
further research), but it is possible that we need to build
contextual rules around combining classes.=C2=A0 =C2=A0On the other hand, if combining sequences were banned entirely with Arabic script,
as has been proposed a few times, this (real or potential)
problem would disappear for IDNs.=C2=A0 Precis would probably be
another story.

If this really is intended as a normalization add-on or post
processing step, it seems to me it is really a new normalization
form or set of forms (additional to NFC, NFD, NFKC, and NFKD) in
disguise and that treating it as such might be a lot less
problematic than trying to be sure UAOA is applied (if needed)
after each time one of the traditional normalizations is applied.

Note that this document is out for public review.=C2=A0 Anyone having
comments on it should send them directly to Unicode as specified
in http://www.unicode.org/review/pri359/.=C2=A0 =C2=A0= The document is
probably worth discussing on this list only with regard to
IDNA-specific effects.

=C2=A0 =C2=A0 john




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

--94eb2c04d9c2c6529b055ad06600-- From nobody Thu Oct 5 10:55:11 2017 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 9884A1342F4 for ; Thu, 5 Oct 2017 10:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 swCrcE0Tqt3B for ; Thu, 5 Oct 2017 10:55:06 -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 1A3B9134304 for ; Thu, 5 Oct 2017 10:55:05 -0700 (PDT) Received: from [192.71.80.208] (vpn-client-208.netnod.se [192.71.80.208]) by mail.frobbit.se (Postfix) with ESMTPSA id 508E82317F; Thu, 5 Oct 2017 19:55:02 +0200 (CEST) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "John C Klensin" Cc: idna-update@ietf.org Date: Thu, 05 Oct 2017 10:54:58 -0700 Message-ID: <5F69970E-5271-4880-8FC2-51039E4F55E7@frobbit.se> In-Reply-To: <8EB791E33C4FFB1EEE2614FB@PSB> References: <8EB791E33C4FFB1EEE2614FB@PSB> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_BA661BEA-3D26-4FAD-BE48-E07B182DC965_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (2.0BETAr6092) Archived-At: Subject: Re: [Idna-update] Heads up -- Arabic Normalization or rendering issue -- draft UTR 53 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, 05 Oct 2017 17:55:10 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_BA661BEA-3D26-4FAD-BE48-E07B182DC965_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 5 Oct 2017, at 10:35, John C Klensin wrote: > If this really is intended as a normalization add-on or post processing= step, it seems to me it is really a new normalization form or set of for= ms (additional to NFC, NFD, NFKC, and NFKD) in disguise and that treating= it as such might be a lot less > problematic than trying to be sure UAOA is applied (if needed) > after each time one of the traditional normalizations is applied. After having spent 15 seconds thinking about what you describe, I have tw= o thoughts: 1. You are correct in your view related to normalization 2. Can someone *really* knowing arabic script _and_ IDNA speak up? Patrik --=_MailMate_BA661BEA-3D26-4FAD-BE48-E07B182DC965_= 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/cJI8i4DDUU3qWsxpsaC4jXzQUCWdZx8g8ccGFmQGZyb2Ji aXQuc2UACgkQrMabGguI18012gCfc0r9FO0FV7HeyTYumlsCuuUje58AmQE/p+hv 3V1eTvjUZuM8kUbDAyxE =xthX -----END PGP SIGNATURE----- --=_MailMate_BA661BEA-3D26-4FAD-BE48-E07B182DC965_=-- From nobody Thu Oct 5 10:57:14 2017 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 4DF9513430D for ; Thu, 5 Oct 2017 10:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 oWqnRdA3fTKW for ; Thu, 5 Oct 2017 10:57:11 -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 DD2F713430B for ; Thu, 5 Oct 2017 10:57:10 -0700 (PDT) Received: from [192.71.80.208] (vpn-client-208.netnod.se [192.71.80.208]) by mail.frobbit.se (Postfix) with ESMTPSA id 0B49323181; Thu, 5 Oct 2017 19:57:07 +0200 (CEST) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "Mark Davis =?utf-8?b?4piV77iP?=" Cc: "John C Klensin" , idna-update@ietf.org Date: Thu, 05 Oct 2017 10:57:04 -0700 Message-ID: <3A374BF0-31F3-4262-BCDB-1B190E4C4AEA@frobbit.se> In-Reply-To: References: <8EB791E33C4FFB1EEE2614FB@PSB> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_CF294B6B-1B34-4E52-A05E-603585B829CC_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (2.0BETAr6092) Archived-At: Subject: Re: [Idna-update] Heads up -- Arabic Normalization or rendering issue -- draft UTR 53 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, 05 Oct 2017 17:57:13 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_CF294B6B-1B34-4E52-A05E-603585B829CC_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =2E..but if this implies something being rendered as ABC can be stored ei= ther as ABC or ACB, then it do have implications. That said, if you say the document should in next version make the implic= ations and application be more clear, that is of course appreciated, and = I am looking forward to a new version. Patrik On 5 Oct 2017, at 10:53, Mark Davis =E2=98=95=EF=B8=8F wrote: > I believe there is a misunderstanding of this. It is the preordering of= marks as input to the purpose of rendering, and has nothing to do with t= he interchanged form of text or any of the normalization forms. Others ha= ve already pointed out that the document as it stands does not make that = sufficiently clear. > > Mark > > Mark > > (https://twitter.com/mark_e_davis) > > On Thu, Oct 5, 2017 at 7:35 PM, John C Klensin wrot= e: > >> Hi. >> >> I call the attention of this group to draft UTR#53, "UNICODE >> ARABIC MARK ORDERING ALGORITHM". I'm not going to try to >> summarize it because people should read it for themselves, but >> it _may_ have some or all of the following implications: >> >> * Special normalization rules, based on combining classes and >> inconsistent with current Unicode canonical normalization, may >> be needed to Arabic script when combining marks are used. >> That would presumably have significant impact on IDNA. On the >> other hand, if we continue to require that all strings that are >> input to IDNA be in NFC form, this might be irrelevant to even >> if it is important for Arabic >> >> * If certain marks are used, Arabic script requires more >> attention to rendering that current Unicode specifications >> assume. That probably would not affect IDNA because we do no >> deal with rendering at all. >> >> * Independent of the proposed solution, the document suggests >> that a situation exists that is the opposite of "confusability", >> i.e., a single valid U-label might look very different, and >> possibly even be interpreted as different strings, depending on >> whether the label is in NFC form or has has something like this >> algorithm applied after normalization. >> >> I will leave other IDNA implications to the imagination (and >> further research), but it is possible that we need to build >> contextual rules around combining classes. On the other hand, >> if combining sequences were banned entirely with Arabic script, >> as has been proposed a few times, this (real or potential) >> problem would disappear for IDNs. Precis would probably be >> another story. >> >> If this really is intended as a normalization add-on or post >> processing step, it seems to me it is really a new normalization >> form or set of forms (additional to NFC, NFD, NFKC, and NFKD) in >> disguise and that treating it as such might be a lot less >> problematic than trying to be sure UAOA is applied (if needed) >> after each time one of the traditional normalizations is applied. >> >> Note that this document is out for public review. Anyone having >> comments on it should send them directly to Unicode as specified >> in http://www.unicode.org/review/pri359/. The document is >> probably worth discussing on this list only with regard to >> IDNA-specific effects. >> >> john >> >> >> >> >> _______________________________________________ >> 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_CF294B6B-1B34-4E52-A05E-603585B829CC_= 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/cJI8i4DDUU3qWsxpsaC4jXzQUCWdZycA8ccGFmQGZyb2Ji aXQuc2UACgkQrMabGguI183tFgCeJwR2swfP59Q3O/hJWCQyWmgSrukAnRExQoGq 5rc3iRIo0+rUmIU7npQR =+mFH -----END PGP SIGNATURE----- --=_MailMate_CF294B6B-1B34-4E52-A05E-603585B829CC_=-- From nobody Thu Oct 5 11:22:49 2017 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 794E013445D for ; Thu, 5 Oct 2017 11:22:47 -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] 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 krBqtEap_lGp for ; Thu, 5 Oct 2017 11:22:46 -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 36C311343C3 for ; Thu, 5 Oct 2017 11:22:46 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1e0AnD-000D2r-L3; Thu, 05 Oct 2017 14:22:43 -0400 Date: Thu, 05 Oct 2017 14:22:36 -0400 From: John C Klensin To: =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= , =?UTF-8?Q?Mark_Davis_=E2=98=95=EF=B8=8F?= cc: idna-update@ietf.org Message-ID: <295B1F186F0545A769EDA97D@PSB> In-Reply-To: <3A374BF0-31F3-4262-BCDB-1B190E4C4AEA@frobbit.se> References: <8EB791E33C4FFB1EEE2614FB@PSB> <3A374BF0-31F3-4262-BCDB-1B190E4C4AEA@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] Heads up -- Arabic Normalization or rendering issue -- draft UTR 53 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, 05 Oct 2017 18:22:47 -0000 --On Thursday, October 5, 2017 10:57 -0700 Patrik = F=C3=A4ltstr=C3=B6m wrote: > ...but if this implies something being rendered as ABC can be > stored either as ABC or ACB, then it do have implications. When B and C are combining marks, that has always been possible. It is one important reason we require that strings be normalized before IDNA processing and why that is important. Interestingly, as W3C moves more and more toward "normalize only when actually needed", it is an additional reason why (hypothetical) implementations that push whatever they get through Punycode (without any checking or preprocessing) and then look that up can get themselves in false-negative trouble. I haven't identified any such implementations, but have heard claims that they are, or should be, out there. =20 > That said, if you say the document should in next version make > the implications and application be more clear, that is of > course appreciated, and I am looking forward to a new version. I'll let Mark comment on how likely this is to go anywhere. I don't have even a guess. But, if the answer is that it won't until and unless the document is clear that it is only about rendering and has no effect otherwise, I (and others) will mostly stop worrying. As Mark's note implies, the present draft uses terms like "normalization" and "canonicalization" in ways that are confusing about its objectives. john From nobody Thu Oct 5 11:23:04 2017 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 5EDE21332D7 for ; Thu, 5 Oct 2017 11:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.408 X-Spam-Level: X-Spam-Status: No, score=-1.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=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 8L4Dcko3csVR for ; Thu, 5 Oct 2017 11:22:48 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::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 475C3134317 for ; Thu, 5 Oct 2017 11:22:48 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id m198so13622200oig.5 for ; Thu, 05 Oct 2017 11:22:48 -0700 (PDT) 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=HyUMOJV1Zasl/sAtpQdaR7ty+DA9ME4vJhUXLZf7Em4=; b=uv5wE4k523Ffc9/q9Rr20aAz4Ox5jqi//xNTwRTiXYCcGyyl2XWWZQENYKaO6tsqGj sjSXi0QrWpTB4e9r/3deHnDxPqFZiAhlJJTc5IP8+Dvn1/Cb4bHAjWKrTcx6DaOlW0dD zloR61nGwN4ioUmLwCraa8Z8lgofvNtQcJqnqFxA+KFkEV0OLBYA8OpO1LN29QljeO0+ 7W9uygdgYcz7S6EI1DwUzDN5aLpU+TDp9Q2wJTuUtQN64FWMbeTbySyVeCJgnzK2hOfI bkxMxWhD0XAB5fA0zjdMin/NGhWBndAHSuVL0/VfdqYXvQ7IA44eabz8CsLtth1xbH+r 4rKg== 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=HyUMOJV1Zasl/sAtpQdaR7ty+DA9ME4vJhUXLZf7Em4=; b=gFa2qWNRitrm0bamsVRWqHEzGcZiVXslpI9nKI0roYrynbChBl58R5L2+meTltYmjP 12/I2wVqhwC8RSxB81xejUuvReAq20rmbZkNGerSt3PpWWC49ZYosD7csdFAT/fWTygH HKTHA0Z/VLQ3R5lob45mFkIrvapaKAP95qtmRyflrdDkq0miRyF74yQJXbWc6B397Axi pr5uNqFjfdDbpFYU1oGM7SO1ECDEi1fA/VfZFiSSNILxL7NGTWOxf5wMl2sZfCYiwkdZ z93bikh7neWzPaGuleKLSg9Wtt0nhUuQ0ENZPhs4m5LFVnLsUr2x4gZdGui3b/5/EBXc SoKA== X-Gm-Message-State: AMCzsaX9Qls2DeW1LGN7u7L7B5CSFtf3rJqzpkXVqrYh7/z8PYeF/FJT 7uFiJo8cDSS2HFeBe08rYMgzZ5htslfkHPOPIQc= X-Google-Smtp-Source: AOwi7QCs0iMxkdCavnwTQXungjE7Lu5zfHNBGYoNBBNyy0cgQD8nluamJQJlDzbVSui5OhkTKey8ybkDWBquYqmuP0o= X-Received: by 10.157.34.132 with SMTP id y4mr12549868ota.255.1507227767562; Thu, 05 Oct 2017 11:22:47 -0700 (PDT) MIME-Version: 1.0 Sender: mark.edward.davis@gmail.com Received: by 10.157.37.229 with HTTP; Thu, 5 Oct 2017 11:22:27 -0700 (PDT) In-Reply-To: <3A374BF0-31F3-4262-BCDB-1B190E4C4AEA@frobbit.se> References: <8EB791E33C4FFB1EEE2614FB@PSB> <3A374BF0-31F3-4262-BCDB-1B190E4C4AEA@frobbit.se> From: =?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?= Date: Thu, 5 Oct 2017 20:22:27 +0200 X-Google-Sender-Auth: Pxf2tEEx6WFWV9a0X_nrPaLEQ5I Message-ID: To: =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= Cc: John C Klensin , idna-update@ietf.org Content-Type: multipart/alternative; boundary="94eb2c04d9c2ae6967055ad0cfa4" Archived-At: Subject: Re: [Idna-update] Heads up -- Arabic Normalization or rendering issue -- draft UTR 53 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, 05 Oct 2017 18:22:51 -0000 --94eb2c04d9c2ae6967055ad0cfa4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The rendering steps already has to process the input for any complex script. See https://www.microsoft.com/typography/OpenTypeDev/USE/intro.htm, which discusses the fairly complex reordering already done for Indic scripts. That doesn't mean that the original text is modified in order to do that; it is just transient processing. Mark Mark (https://twitter.com/mark_e_davis) On Thu, Oct 5, 2017 at 7:57 PM, Patrik F=C3=A4ltstr=C3=B6m = wrote: > ...but if this implies something being rendered as ABC can be stored > either as ABC or ACB, then it do have implications. > > That said, if you say the document should in next version make the > implications and application be more clear, that is of course appreciated= , > and I am looking forward to a new version. > > Patrik > > On 5 Oct 2017, at 10:53, Mark Davis =E2=98=95=EF=B8=8F wrote: > > > I believe there is a misunderstanding of this. It is the preordering of > marks as input to the purpose of rendering, and has nothing to do with th= e > interchanged form of text or any of the normalization forms. Others have > already pointed out that the document as it stands does not make that > sufficiently clear. > > > > Mark > > > > Mark > > > > (https://twitter.com/mark_e_davis) > > > > On Thu, Oct 5, 2017 at 7:35 PM, John C Klensin > wrote: > > > >> Hi. > >> > >> I call the attention of this group to draft UTR#53, "UNICODE > >> ARABIC MARK ORDERING ALGORITHM". I'm not going to try to > >> summarize it because people should read it for themselves, but > >> it _may_ have some or all of the following implications: > >> > >> * Special normalization rules, based on combining classes and > >> inconsistent with current Unicode canonical normalization, may > >> be needed to Arabic script when combining marks are used. > >> That would presumably have significant impact on IDNA. On the > >> other hand, if we continue to require that all strings that are > >> input to IDNA be in NFC form, this might be irrelevant to even > >> if it is important for Arabic > >> > >> * If certain marks are used, Arabic script requires more > >> attention to rendering that current Unicode specifications > >> assume. That probably would not affect IDNA because we do no > >> deal with rendering at all. > >> > >> * Independent of the proposed solution, the document suggests > >> that a situation exists that is the opposite of "confusability", > >> i.e., a single valid U-label might look very different, and > >> possibly even be interpreted as different strings, depending on > >> whether the label is in NFC form or has has something like this > >> algorithm applied after normalization. > >> > >> I will leave other IDNA implications to the imagination (and > >> further research), but it is possible that we need to build > >> contextual rules around combining classes. On the other hand, > >> if combining sequences were banned entirely with Arabic script, > >> as has been proposed a few times, this (real or potential) > >> problem would disappear for IDNs. Precis would probably be > >> another story. > >> > >> If this really is intended as a normalization add-on or post > >> processing step, it seems to me it is really a new normalization > >> form or set of forms (additional to NFC, NFD, NFKC, and NFKD) in > >> disguise and that treating it as such might be a lot less > >> problematic than trying to be sure UAOA is applied (if needed) > >> after each time one of the traditional normalizations is applied. > >> > >> Note that this document is out for public review. Anyone having > >> comments on it should send them directly to Unicode as specified > >> in http://www.unicode.org/review/pri359/. The document is > >> probably worth discussing on this list only with regard to > >> IDNA-specific effects. > >> > >> john > >> > >> > >> > >> > >> _______________________________________________ > >> 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 > --94eb2c04d9c2ae6967055ad0cfa4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The rendering steps already has to process the i= nput for any complex script. See=C2=A0https://www.microsoft.com/typography/= OpenTypeDev/USE/intro.htm, which discusses the fairly complex reorderin= g already done for Indic scripts. That doesn't mean that the original t= ext is modified in order to do that; it is just transient processing.
=

Mark

On Thu, Oct 5, 2017 at 7:57 PM, Patrik F=C3= =A4ltstr=C3=B6m <paf@frobbit.se> wrote:
...but if this implies something being rendered as ABC can be st= ored either as ABC or ACB, then it do have implications.

That said, if you say the document should in next version make the implicat= ions and application be more clear, that is of course appreciated, and I am= looking forward to a new version.

=C2=A0 =C2=A0Patrik

On 5 Oct 2017, at 10:53, Mark Davis =E2=98=95=EF=B8=8F wrote:

> I believe there is a misunderstanding of this. It is the preordering o= f marks as input to the purpose of rendering, and has nothing to do with th= e interchanged form of text or any of the normalization forms. Others have = already pointed out that the document as it stands does not make that suffi= ciently clear.
>
> Mark
>
> Mark
>
> (https://twitter.com/mark_e_davis)
>
> On Thu, Oct 5, 2017 at 7:35 PM, John C Klensin <john-ietf@jck.com> wrote:
>
>> Hi.
>>
>> I call the attention of this group to draft UTR#53, "UNICODE<= br> >> ARABIC MARK ORDERING ALGORITHM".=C2=A0 =C2=A0I'm not goin= g to try to
>> summarize it because people should read it for themselves, but
>> it _may_ have some or all of the following implications:
>>
>> * Special normalization rules, based on combining classes and
>> inconsistent with current Unicode canonical normalization, may
>> be needed to Arabic script when combining marks are used.
>> That would presumably have significant impact on IDNA.=C2=A0 On th= e
>> other hand, if we continue to require that all strings that are >> input to IDNA be in NFC form, this might be irrelevant to even
>> if it is important for Arabic
>>
>> * If certain marks are used, Arabic script requires more
>> attention to rendering that current Unicode specifications
>> assume.=C2=A0 That probably would not affect IDNA because we do no=
>> deal with rendering at all.
>>
>> * Independent of the proposed solution, the document suggests
>> that a situation exists that is the opposite of "confusabilit= y",
>> i.e., a single valid U-label might look very different, and
>> possibly even be interpreted as different strings, depending on >> whether the label is in NFC form or has has something like this >> algorithm applied after normalization.
>>
>> I will leave other IDNA implications to the imagination (and
>> further research), but it is possible that we need to build
>> contextual rules around combining classes.=C2=A0 =C2=A0On the othe= r hand,
>> if combining sequences were banned entirely with Arabic script, >> as has been proposed a few times, this (real or potential)
>> problem would disappear for IDNs.=C2=A0 Precis would probably be >> another story.
>>
>> If this really is intended as a normalization add-on or post
>> processing step, it seems to me it is really a new normalization >> form or set of forms (additional to NFC, NFD, NFKC, and NFKD) in >> disguise and that treating it as such might be a lot less
>> problematic than trying to be sure UAOA is applied (if needed)
>> after each time one of the traditional normalizations is applied.<= br> >>
>> Note that this document is out for public review.=C2=A0 Anyone hav= ing
>> comments on it should send them directly to Unicode as specified >> in http://www.unicode.org/review/pri359/.=C2= =A0 =C2=A0The document is
>> probably worth discussing on this list only with regard to
>> IDNA-specific effects.
>>
>>=C2=A0 =C2=A0 =C2=A0john
>>
>>
>>
>>
>> _______________________________________________
>> IDNA-UPDATE mailing list
>> IDNA-UPDATE@ietf.org >> https://www.ietf.org/mailman/listinf= o/idna-update
>>
>
> _______________________________________________
> IDNA-UPDATE mailing list
> IDNA-UPDATE@ietf.org
> https://www.ietf.org/mailman/listinfo/idn= a-update

--94eb2c04d9c2ae6967055ad0cfa4-- From nobody Thu Oct 5 13:39:32 2017 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 1732F13431F for ; Thu, 5 Oct 2017 13:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.509 X-Spam-Level: X-Spam-Status: No, score=-4.509 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_H2=-2.8, 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 pBdmB3jpJ17C for ; Thu, 5 Oct 2017 13:39:26 -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 B0B82124207 for ; Thu, 5 Oct 2017 13:39:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ix.netcom.com; s=dk12062016; t=1507235966; bh=/VXoenXYJpHaoJsehOqJTaFaZHnm51GlGZwZ AZOeQvE=; 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=ljCY43rPI8qcFK/GsCTZYrh+CJehnKW3p sTKPWgoSLy7Jn9hZQ9SYMnbw4Mi+wXSBY5Vg0v8fBK6mAfsVQ9BM8k+X0ZyOu2DVmY7 RYFQ952p4+w9TSAk6GnOrjOq9rdKVEp9Rlr95QVahJ4O1Wx01s4QkPBskUzwIQ9WZwC ofQJ5XpeyjwHXaZF7zmlpJOwaTSne1xEJ5yS9YI3yj0urYkD4fCL+6CLu5JeyQLPAKt Zlg5SyJT6UW7B+UEu2fIIGeIIfA/HLV/Jhgu/vszlfQL3bijr+LWqb+tbry133/yBst Ny+UgPsyOeDtlZuERKP20Q0AgaNuDN40qP1Hltm2w== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=ix.netcom.com; b=Sb/QP2kqAfaePOsd8Cr7etFLQokP4Wj6VzixXH0x3owDGnqJuBTU7eYdl09oCzoIqR8AhfaikQyLsqy5Ih6L2P2XLIUIY/HAltzsiugX+/5dzJS6AETV+WfALzmKImlvp04s1UlCxvCXfCCNGVzsiyAVuoyuQct3HP88iGoxfVD7Hpct2JSCGlzx0jKJgttir82PCSmo4i2k6bhGvQJNkTHPDNxSmMTNjwhD2P8DwaQ8OhZGM+le+20BQMFt0uY2ZMijANM96FDeA/HsyK4rphTPJ6HxbRt1JsfbLb+2L8ENSOoQd0umCjzqkrjgk9HEi4/F6HQO6JMJqyQBIoMRGA==; 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.212.18.178] (helo=[192.168.0.5]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1e0CvU-000BOB-PG for idna-update@ietf.org; Thu, 05 Oct 2017 16:39:25 -0400 To: idna-update@ietf.org References: <8EB791E33C4FFB1EEE2614FB@PSB> <3A374BF0-31F3-4262-BCDB-1B190E4C4AEA@frobbit.se> From: Asmus Freytag Message-ID: Date: Thu, 5 Oct 2017 13:39:30 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4091D0AED5CED82A89C924D4" Content-Language: en-US X-ELNK-Trace: 464f085de979d7246f36dc87813833b245123d0f0160089eb2697f1c5c975e6d4e81ca8474dc6445350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.212.18.178 Archived-At: Subject: Re: [Idna-update] Heads up -- Arabic Normalization or rendering issue -- draft UTR 53 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, 05 Oct 2017 20:39:31 -0000 This is a multi-part message in MIME format. --------------4091D0AED5CED82A89C924D4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit My strong feedback to the UTC was to make the following point crystal clear: On 10/5/2017 11:22 AM, Mark Davis ☕️ wrote: > The rendering steps already has to process the input for any complex > script. See > https://www.microsoft.com/typography/OpenTypeDev/USE/intro.htm, which > discusses the fairly complex reordering already done for Indic > scripts. That doesn't mean that the original text is modified in order > to do that; it is just transient processing. > > Mark > I'm glad therefore, to see this clarification, but the discussion on this list shows that not being careful in scoping the draft was a serious omission. Let's hope that this can be fixed before the wrong idea of the intended scope becomes accepted.. A./ More comments: > Mark > > > // > > On Thu, Oct 5, 2017 at 7:57 PM, Patrik Fältström > wrote: > > ...but if this implies something being rendered as ABC can be > stored either as ABC or ACB, then it do have implications. > > That said, if you say the document should in next version make the > implications and application be more clear, that is of course > appreciated, and I am looking forward to a new version. > You can do more than that - there's a simple online form that allows you to register your input (except that the next meeting of the UTC is just about imminent, so time is of the essence). John gave the details: > > > > On Thu, Oct 5, 2017 at 7:35 PM, John C Klensin > > wrote: > > > >>> Note that this document is out for public review.  Anyone having > >> comments on it should send them directly to Unicode as specified > >> in http://www.unicode.org/review/pri359/ > .  The document is > >> probably worth discussing on this list only with regard to > >> IDNA-specific effects > > > > > >> I call the attention of this group to draft UTR#53, "UNICODE > >> ARABIC MARK ORDERING ALGORITHM".   I'm not going to try to > >> summarize it because people should read it for themselves, but > >> it _may_ have some or all of the following implications: > >> > >> > >> * If certain marks are used, Arabic script requires more > >> attention to rendering that current Unicode specifications > >> assume.  That probably would not affect IDNA because we do no > >> deal with rendering at all. > And neither does Unicode - the variability between low-end and high-end typography is too great to allow the standard to give anything close to comprehensive guidance to implementers in rendering and fonts. What you will find in Unicode is generally aimed at helping establish the *identity* of the coded character. Part of that identity is when to use it (over some possibly competing code point). in complex scripts, some of the edge cases are not trivial and therefore Unicode tends to call them out. > > >> > >> * Independent of the proposed solution, the document suggests > >> that a situation exists that is the opposite of "confusability", > >> i.e., a single valid U-label might look very different, and > >> possibly even be interpreted as different strings, depending on > >> whether the label is in NFC form or has has something like this > >> algorithm applied after normalization. > That is relatively unsurprising. Being in NFC does not mean the absence of combining marks; and therefore mixtures of precomposed characters and combining marks exist. For Latin/Greek/Cyrillic it is generally enough to decompose this input to NFD to get explicit combining marks presented in an ordering that matches the stacking behavior. In complex scripts the methods used to force ordering of combining marks is too simplistic (and at times froze historic mistakes, because not all scripts were understood well enough when Normalization had to be made stable). The draft specification simply tells implementers how to arrive at an ordering that naturally relates to how rendering engines will need their input presented to them. > > >> > >> I will leave other IDNA implications to the imagination (and > >> further research), but it is possible that we need to build > >> contextual rules around combining classes. > In the general case contextual rules are needed for combining marks. You only have to look at the WLE rules and context rules in LGR-2 to see that carried out for SEA scripts. (see https://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-en ). For many other scripts, a generic context rule disallowing two *non-spacing* combining marks being repeated might make sense. The aim is to disallow cases where low-end rendering systems would overprint rather than stack, or where stacked diacritics are clipped. For the latter, a limit of the total number of diacritics on the same side of the base character would also be needed. For Thai, we had a situation where we could demonstrate that required stacking did not take place in some combinations not used in standard Thai (but in minority languages with large user populations). We had to disallow these for the root. For languages where bast+accent form members of an alphabet, the recommended method should be to allow these only as part of an explicit sequence. (The total set of these needed for modern living languages even in a script as widely used as Latin is not expected to exceed a few dozen at most -- everything else is overkill). See the discussion in MSR-2 (sections 4 and 5) https://www.icann.org/en/system/files/files/msr-2-overview-14apr15-en.pdf >  On the other hand, > >> if combining sequences were banned entirely with Arabic script, > >> as has been proposed a few times, this (real or potential) > >> problem would disappear for IDNs.  Precis would probably be > >> another story. > If it wasn't for backwards compatibility, for Arabic, IDNA should simply disallow ALL combining marks: there is no way to build a secure LGR using combining marks in Arabic (in the general case). This is not just my opinion after having done the exercise of trying to define the needed variant relations, but you find in RFC 5564 and the most recently released LGRs for Arabic for the Root Zone and the Second Level. Perhaps updating RFC 5564 or providing a more general recommendation would be a better approach than updating IDNA itself. --------------4091D0AED5CED82A89C924D4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit  
My strong feedback to the UTC was to make the following point crystal clear:

On 10/5/2017 11:22 AM, Mark Davis ☕️ wrote:
The rendering steps already has to process the input for any complex script. See https://www.microsoft.com/typography/OpenTypeDev/USE/intro.htm, which discusses the fairly complex reordering already done for Indic scripts. That doesn't mean that the original text is modified in order to do that; it is just transient processing.

Mark


I'm glad therefore, to see this clarification, but the discussion on this list shows that not being careful in scoping the draft was a serious omission.

Let's hope that this can be fixed before the wrong idea of the intended scope becomes accepted..

A./

More comments:
Mark

On Thu, Oct 5, 2017 at 7:57 PM, Patrik Fältström <paf@frobbit.se> wrote:
...but if this implies something being rendered as ABC can be stored either as ABC or ACB, then it do have implications.

That said, if you say the document should in next version make the implications and application be more clear, that is of course appreciated, and I am looking forward to a new version.
You can do more than that - there's a simple online form that allows you to register your input (except that the next meeting of the UTC is just about imminent, so time is of the essence). John gave the details:

> On Thu, Oct 5, 2017 at 7:35 PM, John C Klensin <john-ietf@jck.com> wrote:
>
>>> Note that this document is out for public review.  Anyone having
>> comments on it should send them directly to Unicode as specified
>> in http://www.unicode.org/review/pri359/.   The document is
>> probably worth discussing on this list only with regard to
>> IDNA-specific effects
>
>
>> I call the attention of this group to draft UTR#53, "UNICODE
>> ARABIC MARK ORDERING ALGORITHM".   I'm not going to try to
>> summarize it because people should read it for themselves, but
>> it _may_ have some or all of the following implications:
>>
>>
>> * If certain marks are used, Arabic script requires more
>> attention to rendering that current Unicode specifications
>> assume.  That probably would not affect IDNA because we do no
>> deal with rendering at all.

And neither does Unicode - the variability between low-end and high-end typography is too great to allow the standard to give anything close to comprehensive guidance to implementers in rendering and fonts.

What you will find in Unicode is generally aimed at helping establish the *identity* of the coded character. Part of that identity is when to use it (over some possibly competing code point). in complex scripts, some of the edge cases are not trivial and therefore Unicode tends to call them out.
>>
>> * Independent of the proposed solution, the document suggests
>> that a situation exists that is the opposite of "confusability",
>> i.e., a single valid U-label might look very different, and
>> possibly even be interpreted as different strings, depending on
>> whether the label is in NFC form or has has something like this
>> algorithm applied after normalization.

That is relatively unsurprising. Being in NFC does not mean the absence of combining marks; and therefore mixtures of precomposed characters and combining marks exist.

For Latin/Greek/Cyrillic it is generally enough to decompose this input to NFD to get explicit combining marks presented in an ordering that matches the stacking behavior.

In complex scripts the methods used to force ordering of combining marks is too simplistic (and at times froze historic mistakes, because not all scripts were understood well enough when Normalization had to be made stable).

The draft specification simply tells implementers how to arrive at an ordering that naturally relates to how rendering engines will need their input presented to them.
>>
>> I will leave other IDNA implications to the imagination (and
>> further research), but it is possible that we need to build
>> contextual rules around combining classes. 

In the general case contextual rules are needed for combining marks.

You only have to look at the WLE rules and context rules in LGR-2 to see that carried out for SEA scripts. (see https://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-en ).

For many other scripts, a generic context rule disallowing two *non-spacing* combining marks being repeated might make sense. The aim is to disallow cases where low-end rendering systems would overprint rather than stack, or where stacked diacritics are clipped. For the latter, a limit of the total number of diacritics on the same side of the base character would also be needed.

For Thai, we had a situation where we could demonstrate that required stacking did not take place in some combinations not used in standard Thai (but in minority languages with large user populations). We had to disallow these for the root.

For languages where bast+accent form members of an alphabet, the recommended method should be to allow these only as part of an explicit sequence. (The total set of these needed for modern living languages even in a script as widely used as Latin is not expected to exceed a few dozen at most -- everything else is overkill).

See the discussion in MSR-2 (sections 4 and 5)
https://www.icann.org/en/system/files/files/msr-2-overview-14apr15-en.pdf



 On the other hand,
>> if combining sequences were banned entirely with Arabic script,
>> as has been proposed a few times, this (real or potential)
>> problem would disappear for IDNs.  Precis would probably be
>> another story.

If it wasn't for backwards compatibility, for Arabic, IDNA should simply disallow ALL combining marks: there is no way to build a secure LGR using combining marks in Arabic (in the general case). This is not just my opinion after having done the exercise of trying to define the needed variant relations, but you find in RFC 5564 and the most recently released LGRs for Arabic for the Root Zone and the Second Level.

Perhaps updating RFC 5564 or providing a more general recommendation would be a better approach than updating IDNA itself.

--------------4091D0AED5CED82A89C924D4-- From nobody Thu Oct 5 14:11:29 2017 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 19906133090 for ; Thu, 5 Oct 2017 14:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 kvYcDjstwbiU for ; Thu, 5 Oct 2017 14:11:26 -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 0FA20133073 for ; Thu, 5 Oct 2017 14:11:25 -0700 (PDT) Received: from [2.69.178.176] (2.69.178.176.mobile.tre.se [2.69.178.176]) by mail.frobbit.se (Postfix) with ESMTPSA id 93B91202C1; Thu, 5 Oct 2017 23:11:22 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= X-Mailer: iPhone Mail (15A402) In-Reply-To: <295B1F186F0545A769EDA97D@PSB> Date: Thu, 5 Oct 2017 14:11:20 -0700 Cc: =?utf-8?Q?Mark_Davis_=E2=98=95=EF=B8=8F?= , idna-update@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <8EB791E33C4FFB1EEE2614FB@PSB> <3A374BF0-31F3-4262-BCDB-1B190E4C4AEA@frobbit.se> <295B1F186F0545A769EDA97D@PSB> To: John C Klensin Archived-At: Subject: Re: [Idna-update] Heads up -- Arabic Normalization or rendering issue -- draft UTR 53 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, 05 Oct 2017 21:11:28 -0000 > On 5 Oct 2017, at 11:22, John C Klensin wrote: >=20 > --On Thursday, October 5, 2017 10:57 -0700 Patrik F=C3=A4ltstr=C3=B6m > wrote: >=20 >> ...but if this implies something being rendered as ABC can be >> stored either as ABC or ACB, then it do have implications. >=20 > When B and C are combining marks, that has always been possible. Oh yes, of course. I meant =E2=80=9Cafter the normalization people are suppo= sed to do before IDNA and the strings touch dns=E2=80=9D. I.e. it all depends on in what order all of these transformations take place= , and if that is the slightest unclear, or if it impacts =E2=80=9Cthe normal= ized string used in dns=E2=80=9D then we have a so called serious situation.= Patrik > It is one important reason we require that strings be normalized > before IDNA processing and why that is important. > Interestingly, as W3C moves more and more toward "normalize only > when actually needed", it is an additional reason why > (hypothetical) implementations that push whatever they get > through Punycode (without any checking or preprocessing) and > then look that up can get themselves in false-negative trouble. > I haven't identified any such implementations, but have heard > claims that they are, or should be, out there. >=20 >> That said, if you say the document should in next version make >> the implications and application be more clear, that is of >> course appreciated, and I am looking forward to a new version. >=20 > I'll let Mark comment on how likely this is to go anywhere. I > don't have even a guess. But, if the answer is that it won't > until and unless the document is clear that it is only about > rendering and has no effect otherwise, I (and others) will > mostly stop worrying. >=20 > As Mark's note implies, the present draft uses terms like > "normalization" and "canonicalization" in ways that are > confusing about its objectives. >=20 > john >=20 From nobody Thu Oct 5 16:38:19 2017 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 B2686133039 for ; Thu, 5 Oct 2017 16:38:17 -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] 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 Hj8ddhmL4beI for ; Thu, 5 Oct 2017 16:38:16 -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 329A8132331 for ; Thu, 5 Oct 2017 16:38:15 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1e0FiV-000ERr-O8; Thu, 05 Oct 2017 19:38:11 -0400 Date: Thu, 05 Oct 2017 19:38:04 -0400 From: John C Klensin To: =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= cc: =?UTF-8?Q?Mark_Davis_=E2=98=95=EF=B8=8F?= , idna-update@ietf.org Message-ID: In-Reply-To: References: <8EB791E33C4FFB1EEE2614FB@PSB> <3A374BF0-31F3-4262-BCDB-1B190E4C4AEA@frobbit.se> <295B1F186F0545A769EDA97D@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] Heads up -- Arabic Normalization or rendering issue -- draft UTR 53 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, 05 Oct 2017 23:38:18 -0000 --On Thursday, October 5, 2017 14:11 -0700 Patrik = F=C3=A4ltstr=C3=B6m wrote: >> When B and C are combining marks, that has always been >> possible. >=20 > Oh yes, of course. I meant "after the normalization people > are supposed to do before IDNA and the strings touch dns". >=20 > I.e. it all depends on in what order all of these > transformations take place, and if that is the slightest > unclear, or if it impacts "the normalized string used in > dns" then we have a so called serious situation. I think IDNA2008 (RFC 5891 Sections 4.1 and 5.2) are actually crystal clear that, whatever else one does, the string MUST be in NFC form before entering IDNA processing. Now, if that is ignored or people are confused because of all of the IDNA-ish things we have floating around, that is a separate issue, but the problem isn't the order of transformations or any ambiguity in IDNA2008. john From nobody Thu Oct 5 20:07:27 2017 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 9DEFF1331F6 for ; Thu, 5 Oct 2017 20:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 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_SORBS_SPAM=0.5, T_SPF_PERMERROR=0.01] autolearn=no 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 ODY-45VUlumG for ; Thu, 5 Oct 2017 20:07:25 -0700 (PDT) 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 E92BE134216 for ; Thu, 5 Oct 2017 20:07:24 -0700 (PDT) Received: by mork.alvestrand.no (Postfix) id 6A7E27C3D9B; Fri, 6 Oct 2017 05:07:23 +0200 (CEST) Delivered-To: idna-update@alvestrand.no Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 5BE7D7C3693 for ; Fri, 6 Oct 2017 05:07:23 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Authentication-Results: mork.alvestrand.no (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 mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQ6ZpEffCDNl for ; Fri, 6 Oct 2017 05:07:21 +0200 (CEST) X-Greylist: delayed 02:03:46 by SQLgrey-1.8.0 X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.86.89.68; helo=elasmtp-masked.atl.sa.earthlink.net; envelope-from=asmusf@ix.netcom.com; receiver=idna-update@alvestrand.no Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by mork.alvestrand.no (Postfix) with ESMTPS id B996F7C0DBA for ; Fri, 6 Oct 2017 05:07:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ix.netcom.com; s=dk12062016; t=1507259241; bh=puwU2OFRD+4EaazWBY7RQy1nn7dB833qjoIJ ujv/IkY=; 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=KdKKGERVjJSm9G1nqXK1mN6MXw/Hu8Ef18G8cboSEwXdtq aPBfu2zHn3XZqgvojibUniY3MazmOwQDHcNaDbvw9nx3vTehOAsTqECc9sj5fD7ts2C OWVHpKRs2g05tQxNCd4iKsebu/HFHEX+9Oz57EAs7plBeAqM9+e6Ma3JkP1j2mprB0u Ewxm61WlZsUwwcmB3/xGp0QdwM5XhI8ZiF6KwhMYave6uvRG9rFd+yr+irnVieIeLfI nPz1uenz7FeJu15BwDCXMoUdjXA4kN6iYlHIgYD2AOInEAs3TjctF4Nq/Sf2TvMOYUg 1AISgKFsf3ZSF1tOJUEA8f8EeLiA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=ix.netcom.com; b=lMkmiDjlp0NeJt+F77rcaQ3rvb7Tk50tvHiU6ojwI8ICdgqjafE5DjcixcIwOhaDSlR+R7FA7d8yp53pxqlINMGIQiqzPwf3YliHj/ziNoqEfMYA7lg83KOKKiJ3aJv+tg/52W/Q3X/yvqXAzwGxuWGfj0vqx/NQpwtf9tn+fDsSAJl8z6P6J5f9XIZ4WSRSuzwy5rbF8rkQBadgs8m4C37VulwSpOJcy3oNxl5EWjWwAmV2lF43Z1GeY5vp7tYxrlpJ5V+MG9skIYkH5+KUiFJxx1yNUiKOojOqh8kHufUHSGMuqEgmTuE9fZGU+5sWCv9Nd6sNx2hB0z/fPQqFDQ==; 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.212.18.178] (helo=[192.168.0.5]) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1e0H35-00081w-7w; Thu, 05 Oct 2017 21:03:31 -0400 To: i18n-discuss@iab.org, IDNA update work References: <07CBE38E286EBC149DD9EEF9@PSB> <6597e548-f7c6-0845-a0d3-f5c0fa92a100@ix.netcom.com> From: Asmus Freytag Message-ID: <44483934-bb7d-9b59-5083-82235acc72aa@ix.netcom.com> Date: Thu, 5 Oct 2017 18:03:35 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.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: 464f085de979d7246f36dc87813833b245123d0f0160089ea3c9973fc89ac2bc4b7afd86caadbff1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.212.18.178 Archived-At: Subject: Re: [Idna-update] [I18n-discuss] Draft UTR 53 and associated issues 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, 06 Oct 2017 03:07:26 -0000 On 10/5/2017 5:20 PM, John C Klensin wrote: > > --On Thursday, October 5, 2017 13:55 -0700 Asmus Freytag > wrote: > >> There's an important clarification of scope that's missing >> from the document, but can be found in the mail-thread on >> idna-update. >> >> Implication for IETF may be less than it appears without that >> clarified scope. >> >> A./ >> >> PS: John, can you forward this as necessary - I'm not on all >> the lists you sent this to. > That is the reason I tried to force the discussion onto the > idna-update list and just tell people on the other two about it. > Will pull the other two lists in as needed. So far, silence on > PRECIS, which is actually more likely to have problems than IDNA. > > I may just not understand UTC procedures well enough but if the > need for rewriting and clarification is as clear as Mark's note > seemed to indicate, I don't understand why the draft has not > been withdrawn and rewritten. An announcement to all three > lists about a new version would seem to me to be appropriate; > otherwise, this is my last posting to this one. Because this is about on the level of an internet-draft (="proposed draft") and will see much editing before it becomes accepted in principle for publication (="draft"). Retracting it would make it impossible for us to comment on its deficiencies. A./ > > john > > > best, > john > > > > > _______________________________________________ > I18n-discuss mailing list > I18n-discuss@iab.org > https://www.iab.org/mailman/listinfo/i18n-discuss >