Re: [Idna-update] [I18nrp] [art] Comments on draft-faltstrom-unicode11-02

Patrik Fältström <paf@netnod.se> Tue, 09 October 2018 04:37 UTC

Return-Path: <paf@netnod.se>
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 3914C131193 for <idna-update@ietfa.amsl.com>; Mon, 8 Oct 2018 21:37:34 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=netnod-se.20150623.gappssmtp.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 zWq9O9L7_ImF for <idna-update@ietfa.amsl.com>; Mon, 8 Oct 2018 21:37:31 -0700 (PDT)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 4AB8E13110B for <idna-update@ietf.org>; Mon, 8 Oct 2018 21:37:27 -0700 (PDT)
Received: by mail-lf1-x12e.google.com with SMTP id g89-v6so175642lfl.5 for <idna-update@ietf.org>; Mon, 08 Oct 2018 21:37:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netnod-se.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hJXJ4oXKdH227sXYqU+dXtp0fU9MN9ZDqdEbIpVG2dU=; b=1mLqHXQPVQ5O3F8tByaCs6/nd7ckHbXGTc+CXmjZo+WPgfXcp7cy3oMQ6j04LY49qa PKUMILAXDpXoOp2GM859UDGipIXZr28jgn1XrBpSATV0Vhnvp/KQZfbB8/mEw+pozsL2 rYqmtCi+3NAuQYqE9TY5vP+F6ACQCEkEanMumM3sLuLVZEuSARIQugt24oNmF0/YVCjH dErtUTjX/mDV+ByHeV4eHe2Ytq0U7A+IZcbO3hCOepA1MSv2fGuH2/XBWXVSN8y5Mjht GhuNm64oyxxvhiHakHGX9PLDEgQmIgiE4qvZ01VmQGoGopbfkJnsZd9pBnp+YYTMH/pk fXsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hJXJ4oXKdH227sXYqU+dXtp0fU9MN9ZDqdEbIpVG2dU=; b=MLWOY7Pp0qMt8fPqBkfHkJE9m65v60w1sPu/YjbLlq0Yu9Rcwlfod1s1DMzdgNkORM XyP9fkdjITFil5HQZGsiPDUULmP5ZLHaHFjlT0huUgHUl5WVIzpcN4iC9zC84kcZfrdE Wd7zKzUDnX7DB5xks+uHdg9JNhKBYBxAGR12R0xT5+7v7JWofV2lRNgazwkdydZH7yJx wUBDkVXWeBfPmI4j/W6GabOnl++M75/IeBwkDI+XwX9vHbpcbzWGGwVavwS0bEyTJMQ8 HkGs5wsgnF+rKZprdV1j1fbWtxN+lWYb8rXnfVw9Z5KKMgYxNN+48JKcZcDlaQhEoV2W rM3w==
X-Gm-Message-State: ABuFfohaFN3FnnfKrWQgbH5C+26G2DrLvKCXJYsai8kcAr9zCR1kxs51 BERji0ArtuTkhgIBcoePNapKnAmqoNM=
X-Google-Smtp-Source: ACcGV61rnxPmXYz5/7yngwvVKq6gZa95XX89LcQ4lPFIW75RSD439t0lI37bQssnt28XFZ85ZgvjAA==
X-Received: by 2002:a19:6719:: with SMTP id b25-v6mr14120037lfc.54.1539059845161; Mon, 08 Oct 2018 21:37:25 -0700 (PDT)
Received: from [192.168.10.104] (c-40b2d954.028-114-73746f27.bbcust.telenor.se. [84.217.178.64]) by smtp.gmail.com with ESMTPSA id l9-v6sm3766786ljb.70.2018.10.08.21.37.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Oct 2018 21:37:24 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Patrik Fältström <paf@netnod.se>
X-Mailer: iPad Mail (16B5059d)
In-Reply-To: <D1115463-2780-49CB-851C-9FBAB7C1590A@gmail.com>
Date: Tue, 09 Oct 2018 06:37:23 +0200
Cc: Asmus Freytag <asmusf@ix.netcom.com>, John C Klensin <john-ietf@jck.com>, Ted Hardie <ted.ietf@gmail.com>, i18nrp@ietf.org, nordmark@acm.org, idna-update@ietf.org, Applications and Real-Time Area Discussion <art@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3F126D7C-7D3D-4561-A238-A6EFACF79EBB@netnod.se>
References: <ac2f439d-bed2-11e1-dcc7-34ee2d11fc1b@acm.org> <EEBE6FD4-A75C-4BB7-92BF-BD5F5AD7E171@netnod.se> <CA+9kkMB1AcJD9v6EggN3Hx2Wqv0VHwwhbR3P18a7O+OGkf7Odw@mail.gmail.com> <B0BA40527CB85EC369DD812D@PSB> <c4862804-9182-e446-02b2-dcdf5e552d11@ix.netcom.com> <D1115463-2780-49CB-851C-9FBAB7C1590A@gmail.com>
To: Suzanne Woolf <suzworldwide@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idna-update/5plLvZPlP8rI7-3YezeuBeudM9g>
Subject: Re: [Idna-update] [I18nrp] [art] Comments on draft-faltstrom-unicode11-02
X-BeenThere: idna-update@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" <idna-update.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idna-update>, <mailto:idna-update-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idna-update/>
List-Post: <mailto:idna-update@ietf.org>
List-Help: <mailto:idna-update-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idna-update>, <mailto:idna-update-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Oct 2018 04:37:35 -0000


> On 9 Oct 2018, at 05:29, Suzanne Woolf <suzworldwide@gmail.com> wrote:
> 
> 1. Updating the IDN parameters registry as the IAB requested. With apologies if I’m missing something, I don’t see the expert saying he can’t update the registry for some reason, or that there’s any ambiguity in what the update should be; it’s his judgment that “the right thing to do” about the code points that changed properties between Unicode 6.3 and Unicode 11 is consistent with what the standard tells him to do. So for the current situation, the standard, including the instructions to the expert, is adequate.

The key thing here is that I do not see myself have the competence in actually ensuring what I propose in the I-D is the correct thing to do. There are other alternatives as well, such as adding an exception to the IDNA2008 rule set.

IAB asked me to bring things forward, and my call is what I call path A:
A.1. Suggest a path forward
A.2. Ask IETF to ensure what I propose is the right thing.

This is btw what was done last time we had an incompatible change like this.

Alternatives could have been:

B. Be passive:
B.1. I ask IETF what to do with the incompatible changes (but do not suggest anything)
B.2. IETF tell me what to do

C. Have IAB make the call
C.1. IAB tell me not only to move things forward, but also “IAB have decided that the changes made in Unicode do not require backward compatible rules in IDNA2008”
C.2. I move things forward based on B.1.

FWIW, I did not interpret what IAB told me was “C” which I read in your note Suz. Maybe I misunderstand you.

Now, IF IAB really told me C, then can you please clarify?

   Patrik