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

John C Klensin <john-ietf@jck.com> Tue, 09 October 2018 07:11 UTC

Return-Path: <john-ietf@jck.com>
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 51EB71311C0; Tue, 9 Oct 2018 00:11:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 77LHvZheeMqI; Tue, 9 Oct 2018 00:10:58 -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 1DB481311AF; Tue, 9 Oct 2018 00:10:58 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1g9mAP-000MN6-1w; Tue, 09 Oct 2018 03:10:53 -0400
Date: Tue, 09 Oct 2018 03:10:46 -0400
From: John C Klensin <john-ietf@jck.com>
To: Patrik Fältström <paf@netnod.se>, Suzanne Woolf <suzworldwide@gmail.com>
cc: Asmus Freytag <asmusf@ix.netcom.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>
Message-ID: <86A3FF7AA13985AFD134554D@PSB>
In-Reply-To: <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> <3F126D7C-7D3D-4561-A238-A6EFACF79EBB@netnod.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: <https://mailarchive.ietf.org/arch/msg/idna-update/3KUFduG_YSaMZ0jpcVoRoFtMF0s>
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 07:11:00 -0000

Suzanne, Ted,

Let me build on Patrik's clarification to explain what I'm
concerned about (some other issues have been raised that I'll
come back to later).   I had read Ted's comment about
AD-sponsorship and IANA as implying something close to Patrik's
"C", i.e., the IAB decides it has the authority to just move
forward with this.  I think that would be a bad idea for the
reasons below.   But Ted said he was suggesting only asking
IANA's opinion as to whether the instructions to them were
sufficient and doing so in parallel with starting to advance the
document.   I don't see any problem with that; it would
certainly be consistent with other comments I've made lately
about working together informally to get things done rather than
getting tied up in procedures, throwing things over virtual
walls, and figuring out how and when to do that.

My concern was precisely about heading down the path to Patrik's
"C".  I think what we have learned in the last few years is that
things are more complicated -- and complicated in ways that
affect IDNA (and, btw, PRECIS) -- than the community assumed
when IDNA2008 was adopted.  Those complications include, but are
not just about, the issues that started out with the "Hamza"
discussion that prompted the original IAB statement on that
subject and evolved into what some of us have called the
non-decomposing precomposed character issue.  They also include
some of the issues Asmus has identified about complex scripts
and the requirements they impose as well as, e.g., issues of
registry responsibility and accountability (not only from
IDNA2008 but going back to RFC 1591 and earlier) and other
topics that may be in need of clarification and/or more serious
attention.

If we are either going to change or clarify IDNA2008 to address
those issues or decide to push ahead without addressing them at
all (which, itself, would change or clarify IDNA2008), I think
that must be an IETF consensus position, not done on the basis
of the IAB declaring what it believes (something the IAB is
certainly entitled to do).

best,
    john




--On Tuesday, October 9, 2018 06:37 +0200 Patrik Fältström
<paf@netnod.se> wrote:

> 
> 
>> 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
>