From nobody Mon Oct 8 12:58: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 A2804130F5E; Mon, 8 Oct 2018 12:58:25 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 exOnqySDKkQQ; Mon, 8 Oct 2018 12:58:24 -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 27697130F67; Mon, 8 Oct 2018 12:58:24 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1g9bfY-000KLe-3s; Mon, 08 Oct 2018 15:58:20 -0400 Date: Mon, 08 Oct 2018 15:58:14 -0400 From: John C Klensin To: Ted Hardie , =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= cc: nordmark@acm.org, Applications and Real-Time Area Discussion , idna-update@ietf.org Message-ID: In-Reply-To: References: 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] [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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 19:58:26 -0000 --On Monday, October 8, 2018 09:06 -0700 Ted Hardie wrote: > Modulo Erik's comments, I think this is ready for publication. > The instructions to IANA are clear and the rationale behind > those instructions is laid out. > > I think we could ask for AD-sponsorship for this, but I also > believe that the instructions could go to IANA now; at the > very least, we could ask them to review. Ted, I'm sorry, but I disagree. Patrik has, as far as I can tell, done the job that the IAB asked him to do in his liaison capacity to Unicode, but that job involves a number of assumptions about how to proceed that interact with i18n documents that the IETF has been unable to process. If we follow the precedent of RFC 6452, this document should be processed as standards track even if it changes nothing. It would be wildly inappropriate for it to constrain the conclusions the IETF could reach about those other documents. My understanding coming out of the BOF at IETF 102 was that the ART ADs were going to establish a directorate to determine how i18n documents were to be handled and to start processing those documents. This document would make an entirely reasonable addition to that directorate's queue. However, if an progress has been made on creating that directorate, much less having it convene and discuss processing of documents, I seem to have missed the announcement(s). best, john From nobody Mon Oct 8 13:27: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 9008313101B; Mon, 8 Oct 2018 13:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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] 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 CnNPgoeofU13; Mon, 8 Oct 2018 13:27:25 -0700 (PDT) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 B61A1131007; Mon, 8 Oct 2018 13:27:25 -0700 (PDT) Received: by mail-ot1-x32a.google.com with SMTP id u22so21202028ota.12; Mon, 08 Oct 2018 13:27:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RDoSaEtt0JsbKNcw4FFeA2kyK6tM06sgH1uhHcwdiiM=; b=gJ+BC9D/AYK4IFQZcZa28B8MAjamx6aIaVAu0cQ86sW9n9F+mua/txct0BtJDi1iPh 0xFVMGWuZyTwzzduz6Vb6TP9j4IksKfVNClFjdWMzHoQgSKFY/vIq/huJT6bAJZLwSd0 PR8Rd2205jatyBNRnuP+vKFaaDZ2YBuaWYQzehapMcjKokOvPF5lA5o85AyrFy+Afww7 rveWVE80QzIgbx9UC8vKpkd59BgLGAI9hbkfEWkih3+kUaHPgw5ZgNyr1s4/ltHwBLkr YVN8HoG+H+YW/bMDLBrxdw6Z5Nna6ePa92NhTWtb+kUCnamP8nem5dZOIpmoXfHyoENu uzMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RDoSaEtt0JsbKNcw4FFeA2kyK6tM06sgH1uhHcwdiiM=; b=eSK/n9DJuR7XwVZAAhd1oUMdEH+y3u4yZKT/9CLTe+SCw62oC6JjOXXOfIb8Ro7ZHc s+Zoj8A8kpf0+XNAt3lyKTmgFsyHI1kGeVLtVuY+Hp7EEwRf/eZ0sxhsICzLs4QhaCcn MUDYcf0MUKNcHg8kYZMZhjLXhT+pLfhRq/aVIXiAM7Q3VrQN9p10RvtL9Qqz5eswwvrG ZvRUd8QWkGZN5r/iVLlFA2yOpTuokXllU6p9GscNWiqoENWq1ktnkWE+TPD/cp5xhcpC YkiqduPQAEZ/KJiOI3Cn1DQGCgL7KQbDidvbRw+wPan94yAZevN0/GY+qPPd/gWXZfMu uChw== X-Gm-Message-State: ABuFfohGz9G2aXYkqWtkxW1qoZr30mSSk1POaLrQvkmD3zJnHbdFxSim Gamm7pczukErLSIrtun57Ykn5sRFWekAqpjDgxQ= X-Google-Smtp-Source: ACcGV60eOdc64H+y81TnOrtx14z0dkRbSNZldZKzGrOKcKIzRwCJI1soEHygT82GIrcbmFtmr8fRTk8lxkAHVcox1Dw= X-Received: by 2002:a9d:992:: with SMTP id q18mr7624777otd.351.1539030444793; Mon, 08 Oct 2018 13:27:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ted Hardie Date: Mon, 8 Oct 2018 13:26:58 -0700 Message-ID: To: John C Klensin Cc: =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= , nordmark@acm.org, Applications and Real-Time Area Discussion , idna-update@ietf.org Content-Type: multipart/alternative; boundary="000000000000f5e5300577bd7237" Archived-At: Subject: Re: [Idna-update] [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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 20:27:28 -0000 --000000000000f5e5300577bd7237 Content-Type: text/plain; charset="UTF-8" Howdy, On Mon, Oct 8, 2018 at 12:58 PM John C Klensin wrote: > --On Monday, October 8, 2018 09:06 -0700 Ted Hardie > wrote: > > > Modulo Erik's comments, I think this is ready for publication. > > The instructions to IANA are clear and the rationale behind > > those instructions is laid out. > > > > I think we could ask for AD-sponsorship for this, but I also > > believe that the instructions could go to IANA now; at the > > very least, we could ask them to review. > > Ted, > > I'm sorry, but I disagree. Patrik has, as far as I can tell, > done the job that the IAB asked him to do in his liaison > capacity to Unicode, but that job involves a number of > assumptions about how to proceed that interact with i18n > documents that the IETF has been unable to process. If we > follow the precedent of RFC 6452, this document should be > processed as standards track even if it changes nothing. It > would be wildly inappropriate for it to constrain the > conclusions the IETF could reach about those other documents. > > I infer that you are disagreeing with my suggestion that this get AD-sponsorship, not with my suggestion that it get at minimum IANA review. If you disagree with that as well, perhaps you'd care to say why. My personal take is that it is useful to get confirmation from IANA that the instructions are clear as soon as possible. My understanding coming out of the BOF at IETF 102 was that the > ART ADs were going to establish a directorate to determine how > i18n documents were to be handled and to start processing those > documents. This document would make an entirely reasonable > addition to that directorate's queue. However, if an progress > has been made on creating that directorate, much less having it > convene and discuss processing of documents, I seem to have > missed the announcement(s). > > As you know doubt recall from RFC 2418, the purpose of a directorate is to advise an Area Director or a set of Area Directors: In many areas, the Area Directors have formed an advisory group or > directorate. These comprise experienced members of the IETF and the > technical community represented by the area. The specific name and the > details of the role for each group differ from area to area, but the > primary intent is that these groups assist the Area Director(s), e.g., with > the review of specifications produced in the area. > I certainly agree that the presence of a fully functional i18n directorate would be a boon, but I believe that any AD considering sponsorship of this would do so by consulting, informally, many of the same folks who might serve on that directorate were it in place. So I do not, personally, see any reason to gate on the formality when the ADs can get the same advice for this one without it. regards, Ted Hardie > best, > john > > --000000000000f5e5300577bd7237 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

On Mon, Oct 8, 2018 at 12:58 PM John C Klensin <john-ietf@jck.com> wrote:
--On Monday, October 8, 2018 09:06 -0700 Ted Hardie
<ted.ietf@gmail.= com> wrote:

> Modulo Erik's comments, I think this is ready for publication.
> The instructions to IANA are clear and the rationale behind
> those instructions is laid out.
>
> I think we could ask for AD-sponsorship for this, but I also
> believe that the instructions could go to IANA now; at the
> very least, we could ask them to review.

Ted,

I'm sorry, but I disagree.=C2=A0 Patrik has, as far as I can tell,
done the job that the IAB asked him to do in his liaison
capacity to Unicode, but that job involves a number of
assumptions about how to proceed that interact with i18n
documents that the IETF has been unable to process.=C2=A0 If we
follow the precedent of RFC 6452, this document should be
processed as standards track even if it changes nothing.=C2=A0 It
would be wildly inappropriate for it to constrain the
conclusions the IETF could reach about those other documents.

I infer that you are disagreeing with my suggestion t= hat this get AD-sponsorship, not with my suggestion that it get at minimum = IANA review.=C2=A0 If you disagree with that as well, perhaps you'd car= e to say why.=C2=A0 My personal take is that it is useful to get confirmati= on from IANA that the instructions are clear as soon as possible.
=

My understanding coming out of the BOF at IETF 102 was that the
ART ADs were going to establish a directorate to determine how
i18n documents were to be handled and to start processing those
documents.=C2=A0 This document would make an entirely reasonable
addition to that directorate's queue.=C2=A0 =C2=A0However, if an progre= ss
has been made on creating that directorate, much less having it
convene and discuss processing of documents, I seem to have
missed the announcement(s).

As you know doubt recall from RFC 2418, the purpose o= f a directorate is to advise an Area Director or a set of Area Directors:

I= n many areas, the Area Directors have formed an advisory group or=20 directorate. These comprise experienced members of the IETF and the=20 technical community represented by the area. The specific name and the=20 details of the role for each group differ from area to area, but the=20 primary intent is that these groups assist the Area Director(s), e.g.,=20 with the review of specifications produced in the area.
<= div>
I certainly agree that the presence of a fully functiona= l i18n directorate would be a boon, but I believe that any AD considering s= ponsorship of this would do so by consulting, informally, many of the same = folks who might serve on that directorate were it in place.=C2=A0 So I do n= ot, personally, see any reason to gate on the formality when the ADs can ge= t the same advice for this one without it.

reg= ards,

Ted Hardie
=C2=A0
best,
=C2=A0 =C2=A0john

--000000000000f5e5300577bd7237-- From nobody Mon Oct 8 13:34: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 CCB5C130F67; Mon, 8 Oct 2018 13:34:16 -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 kGUo4Ihgt7hP; Mon, 8 Oct 2018 13:34:14 -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 047CE130FED; Mon, 8 Oct 2018 13:34:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ix.netcom.com; s=dk12062016; t=1539030850; bh=N4cUlQGHxmJPfIh0xttvHPrK3sTTNx5F/fWw tWcGjSs=; 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=ZAHmppd0nlO1rTEKFrGD3bFp3oCc3DTJE 0c/dsqG1zYF/jU84N07SMp8y+v/vD2wUfKzotIledzl4GOJ7LLwDq1Q1KElGaiiMO92 xOl3unAq7mhNEE7SMoMA0NuA166UqngwSF7EtRPgddSmO/PhYUIeKwrwDAMXfzrpgAS 1g+IUz4MNG65CJZoOQQ1TQ/owqE3jRF/NWMB/Wz0Xwg9Uf3w+s9Ijf1Z3zUxaB5Pikp wtNA4jLUpRlDBBYgrrpfDSf/yzAxqOpRvfZc+XDBBGKgRpPlxgCTUomvshgkAQx7Ktv 3tFUHNm7s+cECDOBayIz72RcR1cZOllNX0QA7kEPg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=ix.netcom.com; b=N142wsRx0uJFHAM0fg6URalXjz8EJUPZeeT8RUPvz868HRdPbCU1lmRmhQC09DLImqh0lSpRG2q/coMwN4GRgWq3I7pKHErjBBWUW12jQz7yqCpclyAmqp97iPplUpfLB4nbO2WBVU2JUKiidxhzSDNfADyrTa5us6BNHKId9FCIa9NcLOF3lrYmPKLEAq3aDj33Ui20jNKKLpq4qWyYJ2X927xmVeChbZrGInps1WFyO5YOJhvY8ewIUOLla4sW6nUCixGQdXbrsoKqk2slI0lyk4vpDRpyGqnqGIOJ9SmNAbBYbff2L41T89sN5tWgDr9fGRiorvhvyCkXFYIZYA==; 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 [174.21.170.119] (helo=[192.168.1.108]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1g9cE7-0005GH-N6; Mon, 08 Oct 2018 16:34:03 -0400 To: John C Klensin , Ted Hardie , =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= Cc: nordmark@acm.org, idna-update@ietf.org, Applications and Real-Time Area Discussion , i18nrp@ietf.org References: From: Asmus Freytag Message-ID: Date: Mon, 8 Oct 2018 13:34:04 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------FDABF4CDD5D941C29B2723A1" Content-Language: en-US X-ELNK-Trace: 464f085de979d7246f36dc87813833b2b7eec10b52094b3e26484a1db409fbf83e1308fa4a16f794350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 174.21.170.119 Archived-At: Subject: Re: [Idna-update] [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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 20:34:17 -0000 This is a multi-part message in MIME format. --------------FDABF4CDD5D941C29B2723A1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 10/8/2018 12:58 PM, John C Klensin wrote: > --On Monday, October 8, 2018 09:06 -0700 Ted Hardie > wrote: > >> Modulo Erik's comments, I think this is ready for publication. >> The instructions to IANA are clear and the rationale behind >> those instructions is laid out. >> >> I think we could ask for AD-sponsorship for this, but I also >> believe that the instructions could go to IANA now; at the >> very least, we could ask them to review. > Ted, > > I'm sorry, but I disagree. Patrik has, as far as I can tell, > done the job that the IAB asked him to do in his liaison > capacity to Unicode, I thought this draft was in Patrik's role as the designated expert for the IANA registry. > but that job involves a number of > assumptions about how to proceed that interact with i18n > documents that the IETF has been unable to process. If we > follow the precedent of RFC 6452, this document should be > processed as standards track even if it changes nothing. The relevant difference is that RFC 6452 contained this section: ------------------- IETF Consensus    No change to RFC 5892 is needed based on the changes made in    Unicode 6.0.    This consensus does not imply that no changes will be made to    RFC 5892 for all future updates of The Unicode Standard.    This RFC has been produced because 6.0 is the first version of    Unicode to be released since IDNA2008 was published. -------------------- I see no particular reason why such a section couldn't be added to Patrik's draft, allowing it to be processed like 6452 if that is felt to be more appropriate. > It > would be wildly inappropriate for it to constrain the > conclusions the IETF could reach about those other documents. I don't see how this would constrain IETF conclusions about other documents, or even RFC 5892 itself (other than that the consensus is to not add exceptions). There are changes that may be motivated by the general aspects of the interaction between Unicode and IDNA, but the kind of language as quoted above would not rule those out. You would need to make a more concrete claim how processing this RFC interferes with the work of IETF. > My understanding coming out of the BOF at IETF 102 was that the > ART ADs were going to establish a directorate to determine how > i18n documents were to be handled and to start processing those > documents. This document would make an entirely reasonable > addition to that directorate's queue. However, if an progress > has been made on creating that directorate, much less having it > convene and discuss processing of documents, I seem to have > missed the announcement(s). I don't necessarily see the plan for a new directorate as suspending IETFs ability to process certain RFCs indefinitely. The goal was to make it possible to process more of them and more consistently, not to provide an additional hurdle. (Taken to its logical conclusion, such restriction would have to apply to all RFCs that such a directorate might be giving i18n related input on. I don't see that happening, so I don't see why this draft needs to be singled out). That said, I would also like to learn what progress is being made. At some point, people were looking for volunteers, but at that point the parameters were sufficiently vague for anyone to know what they would be committing to. A./ --------------FDABF4CDD5D941C29B2723A1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 10/8/2018 12:58 PM, John C Klensin wrote:
--On Monday, October 8, 2018 09:06 -0700 Ted Hardie
<ted.ietf@gmail.com> wrote:


Modulo Erik's comments, I think this is ready for publication.
The instructions to IANA are clear and the rationale behind
those instructions is laid out.

I think we could ask for AD-sponsorship for this, but I also
believe that the instructions could go to IANA now; at the
very least, we could ask them to review.

Ted,

I'm sorry, but I disagree.  Patrik has, as far as I can tell,
done the job that the IAB asked him to do in his liaison
capacity to Unicode,

I thought this draft was in Patrik's role as the designated expert for the IANA registry. 

but that job involves a number of
assumptions about how to proceed that interact with i18n
documents that the IETF has been unable to process.  If we
follow the precedent of RFC 6452, this document should be
processed as standards track even if it changes nothing.

The relevant difference is that RFC 6452 contained this section:

-------------------

IETF Consensus

   No change to RFC 5892 is needed based on the changes made in
   Unicode 6.0.

   This consensus does not imply that no changes will be made to
   RFC 5892 for all future updates of The Unicode Standard.

   This RFC has been produced because 6.0 is the first version of
   Unicode to be released since IDNA2008 was published.
--------------------

I see no particular reason why such a section couldn't be added
to Patrik's draft, allowing it to be processed like 6452 if that is
felt to be more appropriate.

 It
would be wildly inappropriate for it to constrain the
conclusions the IETF could reach about those other documents.

I don't see how this would constrain IETF conclusions about other documents,
or even RFC 5892 itself (other than that the consensus is to not add exceptions).

There are changes that may be motivated by the general aspects of the interaction
between Unicode and IDNA, but the kind of language as quoted above would not
rule those out.

You would need to make a more concrete claim how processing this RFC
interferes with the work of IETF. 

My understanding coming out of the BOF at IETF 102 was that the
ART ADs were going to establish a directorate to determine how
i18n documents were to be handled and to start processing those
documents.  This document would make an entirely reasonable
addition to that directorate's queue.   However, if an progress
has been made on creating that directorate, much less having it
convene and discuss processing of documents, I seem to have
missed the announcement(s).

I don't necessarily see the plan for a new directorate as suspending IETFs
ability to process certain RFCs indefinitely. The goal was to make it possible
to process more of them and more consistently, not to provide an additional
hurdle.

(Taken to its logical conclusion, such restriction would have to apply to all
RFCs that such a directorate might be giving i18n related input on. I don't
see that happening, so I don't see why this draft needs to be singled out).

That said, I would also like to learn what progress is being made.

At some point, people were looking for volunteers, but at that point the
parameters were sufficiently vague for anyone to know what they would
be committing to.

A./



--------------FDABF4CDD5D941C29B2723A1-- From nobody Mon Oct 8 20: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 5DF64131119; Mon, 8 Oct 2018 20:29:11 -0700 (PDT) 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 Q0rpHkig0HcT; Mon, 8 Oct 2018 20:29:08 -0700 (PDT) Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (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 6D0A913110B; Mon, 8 Oct 2018 20:29:08 -0700 (PDT) Received: by mail-yb1-xb32.google.com with SMTP id e16-v6so62969ybk.8; Mon, 08 Oct 2018 20:29:08 -0700 (PDT) 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=mNKwO7kYmZ3U9LF9ackFaeGUV5APVx9psAMd9X5QI5M=; b=GMKi2Drh2uWUoB9XKdLuISZnOxPJ3N+2glKwjBmKPWRyCipsGhMf4MMBp0JsnTtvm/ 1Hr4ptFRHDcDPNeG/vU6Gn1p6e2NwWJrzZge7hDhfX+RiU6IbTgn6K5vuueAZCglCb2r jW9mfofTP1COLqLpAV5mzqnVuoB++gxV7f91ZCqsLNw7vxWvRDRKrel4Z6r5Z2uGUETM xCKHXvzWS0SGZJ9OYb0M9nTbrg8yI7kAUwzkIIiBgTWZqC+UcMrJ/o8wYmEikjHPjvAt 8gMLN0qS932PbWFK567xg7YCnnvBRDsOoH9iMG+qGJlMPnyC2Wd7Y5faZkwBooYTWdKk Xtxg== 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=mNKwO7kYmZ3U9LF9ackFaeGUV5APVx9psAMd9X5QI5M=; b=AUK6eHPDn767C59ajB5kGmejtwRoRr3m4/Urwzc24a19UalXQJvaiDkfylytOHAvZh zdBc7cGDQvmvOxxuz2X8D7McXs/HmhPeDls3t3wb2UD69G/BuItC5rSHw/jITNwtRbkH Jj8QjULJA/l8t5s53Hnh/WTpNbIRdTow50+eN5QzzXsN3UKK9+rHvnZT1YEky0d0it+g oTScLbWyPYKbd+rtLZWaKtoo6ZmB2JD9x0PKwLUkQgV8TfWu0liG3twQfIZnP5wVpq45 TwI75PgndDu3kZ/nOQk12kBDua4w7T+FC8GLZxTGYuBGmy+oAfho7+elGvJ6awJpRCQD x2rw== X-Gm-Message-State: ABuFfoi3fMOiwoWEXeH8UkfpuY0CVoRvKx+Ly36Uhj33PnZBRlMiumNX la+fMKIeE/fbtKgPVLTbjjE= X-Google-Smtp-Source: ACcGV61rP/AT6Tju8VlMjg2a+sN80tIAXoZ1r39eU5sQge2y+US4mFtlrS0JYklFbCnQyf6979o/ZQ== X-Received: by 2002:a25:2613:: with SMTP id m19-v6mr15215646ybm.513.1539055747647; Mon, 08 Oct 2018 20:29:07 -0700 (PDT) Received: from ?IPv6:2601:181:c381:29fe:49aa:4bbc:55d9:c0c1? ([2601:181:c381:29fe:49aa:4bbc:55d9:c0c1]) by smtp.gmail.com with ESMTPSA id e187-v6sm6634208ywb.106.2018.10.08.20.29.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Oct 2018 20:29:07 -0700 (PDT) From: Suzanne Woolf Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_5D157C11-501B-4360-8C4D-C00EB6498B98" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 8 Oct 2018 23:29:04 -0400 In-Reply-To: Cc: John C Klensin , Ted Hardie , =?utf-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= , i18nrp@ietf.org, nordmark@acm.org, idna-update@ietf.org, Applications and Real-Time Area Discussion To: Asmus Freytag References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 03:29:11 -0000 --Apple-Mail=_5D157C11-501B-4360-8C4D-C00EB6498B98 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, (A little confused over which mailing list is preferred for this = particular discussion=E2=80=A6.) > On Oct 8, 2018, at 4:34 PM, Asmus Freytag = wrote: >=20 > On 10/8/2018 12:58 PM, John C Klensin wrote: >> --On Monday, October 8, 2018 09:06 -0700 Ted Hardie >> wrote: >>=20 >>> Modulo Erik's comments, I think this is ready for publication. >>> The instructions to IANA are clear and the rationale behind >>> those instructions is laid out. >>>=20 >>> I think we could ask for AD-sponsorship for this, but I also >>> believe that the instructions could go to IANA now; at the >>> very least, we could ask them to review. >> Ted, >>=20 >> I'm sorry, but I disagree. Patrik has, as far as I can tell, >> done the job that the IAB asked him to do in his liaison >> capacity to Unicode,=20 > I thought this draft was in Patrik's role as the designated expert for = the IANA registry.=20 >=20 That was also my impression. In March, the IAB said that =E2=80=9CThe = IAB believes that the best current course of action for now is to bring = the two [Unicode and the IDNA parameters registry] back into alignment = while the IETF continues to work toward consensus on the underlying = issues. We have therefore asked the expert reviewer to bring the IDNA = Parameters registry up to date=E2=80=A6=E2=80=9D The draft (I thought) = is documenting the expert's examination of code points that had been = added or had properties change in the course of that update, and the = rationale for his recommendation about how to handle them in the = registry. >> but that job involves a number of >> assumptions about how to proceed that interact with i18n >> documents that the IETF has been unable to process. If we >> follow the precedent of RFC 6452, this document should be >> processed as standards track even if it changes nothing.=20 > The relevant difference is that RFC 6452 contained this section: >=20 > ------------------- >=20 > IETF Consensus >=20 > No change to RFC 5892 is needed based on the changes made in > Unicode 6.0. >=20 > This consensus does not imply that no changes will be made to > RFC 5892 for all future updates of The Unicode Standard. >=20 > This RFC has been produced because 6.0 is the first version of > Unicode to be released since IDNA2008 was published. > -------------------- > I see no particular reason why such a section couldn't be added > to Patrik's draft, allowing it to be processed like 6452 if that is > felt to be more appropriate. >=20 >=20 I think that having an RFC for this set of updates, documenting the = rationale for the decision to update the registry to Unicode 11 without = exceptions for the code points that changed properties, will be valuable = for the future=E2=80=94 but AFAICT it=E2=80=99s not strictly necessary = as part of the action Patrik was asked to take. I=E2=80=99m fine with = adding language as Asmus is suggesting, which clarifies the current = reasoning without restricting future decisions inappropriately. >> It >> would be wildly inappropriate for it to constrain the >> conclusions the IETF could reach about those other documents. > I don't see how this would constrain IETF conclusions about other = documents, > or even RFC 5892 itself (other than that the consensus is to not add = exceptions). >=20 > There are changes that may be motivated by the general aspects of the = interaction > between Unicode and IDNA, but the kind of language as quoted above = would not > rule those out. > You would need to make a more concrete claim how processing this RFC > interferes with the work of IETF. >=20 I admit I don=E2=80=99t see this either.=20 >> My understanding coming out of the BOF at IETF 102 was that the >> ART ADs were going to establish a directorate to determine how >> i18n documents were to be handled and to start processing those >> documents. This document would make an entirely reasonable >> addition to that directorate's queue. However, if an progress >> has been made on creating that directorate, much less having it >> convene and discuss processing of documents, I seem to have >> missed the announcement(s). > I don't necessarily see the plan for a new directorate as suspending = IETFs > ability to process certain RFCs indefinitely. The goal was to make it = possible > to process more of them and more consistently, not to provide an = additional > hurdle. >=20 >=20 At this point, I see three separate issues, any two of which have some = interaction, but I don=E2=80=99t see hard dependencies: 1. Updating the IDN parameters registry as the IAB requested. With = apologies if I=E2=80=99m missing something, I don=E2=80=99t see the = expert saying he can=E2=80=99t update the registry for some reason, or = that there=E2=80=99s any ambiguity in what the update should be; it=E2=80=99= s his judgment that =E2=80=9Cthe right thing to do=E2=80=9D 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. 2. Having an RFC about the specifics of updating the registry to Unicode = 11. I agree with Patrik that having this document is useful, as an = example of how to apply IDNA2008 to changes in Unicode; at the very = least, the reasoning can inform future experts. But I see it as = Informational=E2=80=94 a service to the community=E2=80=94 not as a = change to the registry policy or an extension to the protocol standard. = I don=E2=80=99t see a problem with making it AD-sponsored. 3. Establishing the proposed I18N directorate. I strongly agree that the = IETF needs the directorate, or some other mechanism for reviewing i18n = aspects of work across the IETF and providing backup for expert review = as needed. But that=E2=80=99s also an optimization, to improve future = handling of i18n documents. I think all three of these things are important and useful. But it = doesn=E2=80=99t look to me like any of the necessary decisions for these = three items are gating on the others, or constraining the options for = the others. They can be done more or less in parallel. Suzanne --Apple-Mail=_5D157C11-501B-4360-8C4D-C00EB6498B98 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

(A= little confused over which mailing list is preferred for this = particular discussion=E2=80=A6.)

On Oct 8, 2018, at 4:34 PM, = Asmus Freytag <asmusf@ix.netcom.com> wrote:

=20 =20
On 10/8/2018 12:58 PM, John C Klensin wrote:
--On Monday, October 8, =
2018 09:06 -0700 Ted Hardie
<ted.ietf@gmail.com> wrote:


Modulo Erik's comments, I =
think this is ready for publication.
The instructions to IANA are clear and the rationale behind
those instructions is laid out.

I think we could ask for AD-sponsorship for this, but I also
believe that the instructions could go to IANA now; at the
very least, we could ask them to review.

Ted,

I'm sorry, but I disagree.  Patrik has, as far as I can tell,
done the job that the IAB asked him to do in his liaison
capacity to Unicode,

I thought this draft was in Patrik's role = as the designated expert for the IANA registry.


That was also my impression. In March, the IAB said that = =E2=80=9CThe IAB believes that the best current course of action for now = is to bring the two [Unicode and the IDNA parameters registry] back into = alignment while the IETF continues to work toward consensus on the = underlying issues.  We have therefore asked the expert reviewer to = bring the IDNA Parameters registry up to date=E2=80=A6=E2=80=9D The = draft (I thought) is documenting the expert's examination of code points = that had been added or had properties change in the course of that = update, and the rationale for his recommendation about how to handle = them in the registry.

but that job involves a =
number of
assumptions about how to proceed that interact with i18n
documents that the IETF has been unable to process.  If we
follow the precedent of RFC 6452, this document should be
processed as standards track even if it changes nothing.

The relevant difference is that RFC 6452 = contained this section:

-------------------

IETF Consensus

   No change to RFC 5892 is needed based on the changes = made in
   Unicode 6.0.

   This consensus does not imply that no changes will be = made to
   RFC 5892 for all future updates of The Unicode = Standard.

   This RFC has been produced because 6.0 is the first = version of
   Unicode to be released since IDNA2008 was = published.
--------------------

I see no particular reason why such a section = couldn't be added
to Patrik's draft, allowing it to be processed like 6452 if that is
felt to be more appropriate.


I think that having an RFC for = this set of updates, documenting the rationale for the decision to = update the registry to Unicode 11 without exceptions for the code points = that changed properties, will be valuable for the future=E2=80=94 but = AFAICT it=E2=80=99s not strictly necessary as part of the action Patrik = was asked to take. I=E2=80=99m fine with adding language as Asmus is = suggesting, which clarifies the current reasoning without restricting = future decisions inappropriately.
 It
would be wildly inappropriate for it to constrain the
conclusions the IETF could reach about those other documents.

I don't see how this would constrain IETF = conclusions about other documents,
or even RFC 5892 itself (other than that the consensus is to not add exceptions).

There are changes that may be = motivated by the general aspects of the interaction
between Unicode and IDNA, but the kind of language as quoted above would not
rule those out.

You would need to make a more concrete claim how = processing this RFC
interferes with the work of IETF.

I admit I don=E2=80=99t see this = either. 
My understanding coming out =
of the BOF at IETF 102 was that the
ART ADs were going to establish a directorate to determine how
i18n documents were to be handled and to start processing those
documents.  This document would make an entirely reasonable
addition to that directorate's queue.   However, if an progress
has been made on creating that directorate, much less having it
convene and discuss processing of documents, I seem to have
missed the announcement(s).

I don't necessarily see the plan for a = new directorate as suspending IETFs
ability to process certain RFCs indefinitely. The goal was to make it possible
to process more of them and more consistently, not to provide an additional
hurdle.


At this point, I see three = separate issues, any two of which have some interaction, but I don=E2=80=99= t see hard dependencies:

1. = Updating the IDN parameters registry as the IAB requested. With = apologies if I=E2=80=99m missing something, I don=E2=80=99t see the = expert saying he can=E2=80=99t update the registry for some reason, or = that there=E2=80=99s any ambiguity in what the update should be; it=E2=80=99= s his judgment that =E2=80=9Cthe right thing to do=E2=80=9D 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.

2. Having an RFC about the = specifics of updating the registry to Unicode 11. I agree with Patrik = that having this document is useful, as an example of how to apply = IDNA2008 to changes in Unicode; at the very least, the reasoning can = inform future experts. But I see it as Informational=E2=80=94 a service = to the community=E2=80=94 not as a change to the registry policy or an = extension to the protocol standard. I don=E2=80=99t see a problem with = making it AD-sponsored.

3. = Establishing the proposed I18N directorate. I strongly agree that the = IETF needs the directorate, or some other mechanism for reviewing i18n = aspects of work across the IETF and providing backup for expert review = as needed. But that=E2=80=99s also an optimization, to improve future = handling of i18n documents.

I think = all three of these things are important and useful. But it doesn=E2=80=99t= look to me like any of the necessary decisions for these three items = are gating on the others, or constraining the options for the others. = They can be done more or less in parallel.



Suzanne

= --Apple-Mail=_5D157C11-501B-4360-8C4D-C00EB6498B98-- From nobody Mon Oct 8 21:37: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 3914C131193 for ; 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 ; 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 ; Mon, 8 Oct 2018 21:37:27 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id g89-v6so175642lfl.5 for ; 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: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= X-Mailer: iPad Mail (16B5059d) In-Reply-To: Date: Tue, 9 Oct 2018 06:37:23 +0200 Cc: Asmus Freytag , John C Klensin , Ted Hardie , i18nrp@ietf.org, nordmark@acm.org, idna-update@ietf.org, Applications and Real-Time Area Discussion Content-Transfer-Encoding: quoted-printable Message-Id: <3F126D7C-7D3D-4561-A238-A6EFACF79EBB@netnod.se> References: To: Suzanne Woolf Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 04:37:35 -0000 > On 9 Oct 2018, at 05:29, Suzanne Woolf wrote: >=20 > 1. Updating the IDN parameters registry as the IAB requested. With apologi= es if I=E2=80=99m missing something, I don=E2=80=99t see the expert saying h= e can=E2=80=99t update the registry for some reason, or that there=E2=80=99s= any ambiguity in what the update should be; it=E2=80=99s his judgment that =E2= =80=9Cthe right thing to do=E2=80=9D about the code points that changed prop= erties between Unicode 6.3 and Unicode 11 is consistent with what the standa= rd tells him to do. So for the current situation, the standard, including th= e instructions to the expert, is adequate. The key thing here is that I do not see myself have the competence in actual= ly ensuring what I propose in the I-D is the correct thing to do. There are o= ther alternatives as well, such as adding an exception to the IDNA2008 rule s= et. 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 =E2=80=9CIAB have= decided that the changes made in Unicode do not require backward compatible= rules in IDNA2008=E2=80=9D C.2. I move things forward based on B.1. FWIW, I did not interpret what IAB told me was =E2=80=9CC=E2=80=9D which I r= ead in your note Suz. Maybe I misunderstand you. Now, IF IAB really told me C, then can you please clarify? Patrik From nobody Mon Oct 8 22:37:24 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 531B6131166; Mon, 8 Oct 2018 22:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, 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 c2UBn-2TKmYN; Mon, 8 Oct 2018 22:37:05 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) (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 B089413115A; Mon, 8 Oct 2018 22:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ix.netcom.com; s=dk12062016; t=1539063425; bh=8K7LOVMZY93sl1Ifyfqp1fO8WfS5m/GouxKO 5ZRCMaE=; 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=bkNYQfQH3tVhw9nvx/GWWah/BmtV3B+kk RJltmZF/RPA5EjUflhnHvijpc+oIa/Xg6d/p6BuI1WQHT/p7E78B75ojTn/KoVAG1qK l40uMBTXPaaB5HGHrRR7iJri9m8Xn7n2ptnZvyoBBlJgrYkDyEE83KXI4nGF4h0oYs4 a/q3kRRAdM7Fs8h8w9UlYN85zSxPeUcSwcopuSTCMB6/HUPHuVUaz86i/wB1wCPwe7/ ZdLSuu4toyJqKfeuDICd/CO+6rPU3Pumio9WM7VUgCZtc6mR5ZGj4ojPLoOaZhijmhw TWNq6iETcnzngGIXlC3iwyp1anuboZ8N2+3cpaLuA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=ix.netcom.com; b=e1TGXEmWtqwTFwAdatUbuINH/2CTgXeNr8FWVInO7W371+pUddmhg2LVXWhLwfA6OyvEiea8pjRUv50aBTO85tlU7yvP5KawCBynn3jTwVP2xT1V1G+PmweJxlHUE9SJ2FQHPe/zFU6uScs11T0HLWNZf2FLXoI6GzkaNgK7tzpWsquauPyjHIYsPzVQPahEyysIxb0Js0QOuH3+p+aAAst3da7hrJYi11er4H1Sy0o4rvE8t4gmbKGNmiD1XXlJAvq1nOKhlRJayNORJvqGRjm+3Mo9DFs6CFjwaiT2T0w4IuGxpZTrglNz2DkQpZDCvk8NreeTftCAp0rUutYVsg==; 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 [174.21.170.119] (helo=[192.168.1.108]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1g9khY-0005kh-OO; Tue, 09 Oct 2018 01:37:01 -0400 To: =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= , Suzanne Woolf Cc: Ted Hardie , i18nrp@ietf.org, nordmark@acm.org, Applications and Real-Time Area Discussion , John C Klensin , idna-update@ietf.org References: <3F126D7C-7D3D-4561-A238-A6EFACF79EBB@netnod.se> From: "Asmus Freytag (c)" Message-ID: Date: Mon, 8 Oct 2018 22:37:01 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <3F126D7C-7D3D-4561-A238-A6EFACF79EBB@netnod.se> Content-Type: multipart/alternative; boundary="------------62972A07847AA92503EFA7F8" Content-Language: en-US X-ELNK-Trace: 464f085de979d7246f36dc87813833b2b7eec10b52094b3e949cfd12a8bd0aa53155b74982b4360f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 174.21.170.119 Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 05:37:09 -0000 This is a multi-part message in MIME format. --------------62972A07847AA92503EFA7F8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 10/8/2018 9:37 PM, Patrik Fältström wrote: > >> On 9 Oct 2018, at 05:29, Suzanne Woolf 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. Sounds like a good approach in any case. From where I sit, what you did looks fine, so my answer to A.2. would be affirmative. A./ PS: if IAB agrees with your assessment re: rules, the more the better. > > 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 > > _______________________________________________ > IDNA-UPDATE mailing list > IDNA-UPDATE@ietf.org > https://www.ietf.org/mailman/listinfo/idna-update --------------62972A07847AA92503EFA7F8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 10/8/2018 9:37 PM, Patrik Fältström 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.

Sounds like a good approach in any case.

From where I sit, what you did looks fine, so my answer to A.2. would be affirmative.

A./

PS: if IAB agrees with your assessment re: rules, the more the better.


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

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


--------------62972A07847AA92503EFA7F8-- From nobody Mon Oct 8 22:41: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 58D3C131153; Mon, 8 Oct 2018 22:41:03 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 CWDKDYYrCc61; Mon, 8 Oct 2018 22:41:01 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4D27613114E; Mon, 8 Oct 2018 22:40:58 -0700 (PDT) Received: from healthyao-PC (unknown [218.241.103.187]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0AZIPxYP7xbNcUdAA--.22364S2; Tue, 09 Oct 2018 13:40:40 +0800 (CST) Date: Tue, 9 Oct 2018 13:40:34 +0800 From: "Jiankang Yao" To: suzworldwide , "Asmus Freytag" Cc: "Ted Hardie" , i18nrp , nordmark , =?utf-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= , "Applications and Real-Time Area Discussion" , "John C Klensin" , idna-update Reply-To: yaojk References: , X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <2018100913393087166197@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart710151255258_=----" X-CM-TRANSID: AQAAf0AZIPxYP7xbNcUdAA--.22364S2 X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UUUYh7k0a2IF6FyUM7kC6x804xWl14x267AK xVW8JVW5JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUJVWUGw A2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK021l84ACjcxK6xIIjxv20xvE14v26ryj 6F1UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4j6F4UM28EF7xvwVC2z280aVAFwI0_Cr 1j6rxdM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv 0487Mc02F40E42I26xC2a48xMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxV WUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAxZF0E w4CEw7xC0wCY02Avz4vE14v_GrWl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr 0_Gr1lx2IqxVAqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY 17CE14v26r1q6r43MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcV C0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF 0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_Gr1l6VACY4xI67 k04243AbIYCTnIWIevJa73UjIFyTuYvjxU2eOJDUUUU X-CM-SenderInfo: x1dryyw6fq0xffof0/ Archived-At: Subject: Re: [Idna-update] [art] [I18nrp] 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 05:41:03 -0000 This is a multi-part message in MIME format. ------=_001_NextPart710151255258_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IFN1emFubmUgV29vbGYNCkRhdGU6IDIwMTgtMTAtMDkgMTE6MjkNClRvOiBBc211 cyBGcmV5dGFnDQpDQzogVGVkIEhhcmRpZTsgaTE4bnJwOyBub3JkbWFyazsgUGF0cmlrIEbDpGx0 c3Ryw7ZtOyBBcHBsaWNhdGlvbnMgYW5kIFJlYWwtVGltZSBBcmVhIERpc2N1c3Npb247IEpvaG4g QyBLbGVuc2luOyBpZG5hLXVwZGF0ZQ0KU3ViamVjdDogUmU6IFthcnRdIFtJMThucnBdIFtJZG5h LXVwZGF0ZV0gQ29tbWVudHMgb24gZHJhZnQtZmFsdHN0cm9tLXVuaWNvZGUxMS0wMg0KPiBUaGF0 IHdhcyBhbHNvIG15IGltcHJlc3Npb24uIEluIE1hcmNoLCB0aGUgSUFCIHNhaWQgdGhhdCDigJxU aGUgSUFCIGJlbGlldmVzIHRoYXQgdGhlIGJlc3QgY3VycmVudCBjb3Vyc2Ugb2YgYWN0aW9uIGZv ciBub3cgaXMgdG8gYnJpbmcgdGhlIHR3byBbVW5pY29kZSBhbmQgdGhlIElETkEgcGFyYW1ldGVy cyByZWdpc3RyeV0gYmFjayBpbnRvIGFsaWdubWVudCANCltKaWFua2FuZyBZYW9dID4NCj4g ------=_001_NextPart710151255258_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
 
 
Date: 2018-10-09 11:29
CC: Ted Hardie;= i18nrp; nordmark; Patrik F=C3=A4ltstr=C3=B6m; Applications and Real-Time Area Discussion; John C Klensin; idna-update
Subject: Re: [art] [I18nrp] [Idna-update] Comments on=20 draft-faltstrom-unicode11-02

= > That=20 was also my impression. In March, the IAB said that =E2=80=9CThe IAB belie= ves that the=20 best current course of action for now is to bring the two [Unicode and the= IDNA=20 parameters registry] back into alignment
= [Jiankang=20 Yao] >
> 

=
------=_001_NextPart710151255258_=------ From nobody Mon Oct 8 22:52: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 CB64F13115A; Mon, 8 Oct 2018 22:52:13 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 onAG7kbBflMS; Mon, 8 Oct 2018 22:52:11 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0098913114E; Mon, 8 Oct 2018 22:52:08 -0700 (PDT) Received: from healthyao-PC (unknown [218.241.103.187]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0Dp8Px_QbxbgMUdAA--.21958S2; Tue, 09 Oct 2018 13:49:51 +0800 (CST) Date: Tue, 9 Oct 2018 13:49:45 +0800 From: "Jiankang Yao" To: suzworldwide , "Asmus Freytag" Cc: "Ted Hardie" , i18nrp , nordmark , =?utf-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= , "Applications and Real-Time Area Discussion" , "John C Klensin" , idna-update Reply-To: yaojk References: , , <2018100913393087166197@cnnic.cn> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <20181009134942726001101@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart463408531813_=----" X-CM-TRANSID: AQAAf0Dp8Px_QbxbgMUdAA--.21958S2 X-Coremail-Antispam: 1UD129KBjvdXoWrJw4DZFy5Zw4kJw18GFWxJFb_yoWxXrbEgr 4kKrW0ya1DJF43WwsFyan8XFn29r45ua10qwsFkr4Ygr1vqFs8Xw4ktry7Zw1jgFyft34Y gr98GrsxKryUXjkaLaAFLSUrUUUUjb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbfkYjsxI4VWDJwAYFVCjjxCrM7AC8VAFwI0_Gr0_Xr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVW8JVW5JwA2z4x0Y4vE2Ix0 cI8IcVCY1x0267AKxVW8JVWxJwA2z4x0Y4vEx4A2jsIE14v26F4UJVW0owA2z4x0Y4vEx4 A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG6xAIxVCF xsxG0wAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFV Cjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4xvF2IEb7IF0Fy264kE64k0F24lc7CjxVAa w2AFwI0_Jw0_GFylc2xSY4AK67AK6r4rMxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4 AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE 17CEb7AF67AKxVWUtVW8ZwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMI IF0xvE2Ix0cI8IcVCY1x0267AKxVW8JVWxJwCI42IY6xAIw20EY4v20xvaj40_Wr1j6rW3 Jr1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8JVW8Jr1l6V ACY4xI67k04243AbIYCTnIWIevJa73UjIFyTuYvjxUwlksUUUUU X-CM-SenderInfo: x1dryyw6fq0xffof0/ Archived-At: Subject: Re: [Idna-update] [art] [I18nrp] 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 05:52:14 -0000 This is a multi-part message in MIME format. ------=_001_NextPart463408531813_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpGcm9tOiBTdXphbm5lIFdvb2xmDQpEYXRlOiAyMDE4LTEwLTA5IDExOjI5DQpUbzogQXNtdXMg RnJleXRhZw0KQ0M6IFRlZCBIYXJkaWU7IGkxOG5ycDsgbm9yZG1hcms7IFBhdHJpayBGw6RsdHN0 csO2bTsgQXBwbGljYXRpb25zIGFuZCBSZWFsLVRpbWUgQXJlYSBEaXNjdXNzaW9uOyBKb2huIEMg S2xlbnNpbjsgaWRuYS11cGRhdGUNClN1YmplY3Q6IFJlOiBbYXJ0XSBbSTE4bnJwXSBbSWRuYS11 cGRhdGVdIENvbW1lbnRzIG9uIGRyYWZ0LWZhbHRzdHJvbS11bmljb2RlMTEtMDINCj4gVGhhdCB3 YXMgYWxzbyBteSBpbXByZXNzaW9uLiBJbiBNYXJjaCwgdGhlIElBQiBzYWlkIHRoYXQg4oCcVGhl IElBQiBiZWxpZXZlcyB0aGF0IHRoZSBiZXN0IGN1cnJlbnQgY291cnNlIG9mIGFjdGlvbiBmb3Ig bm93IGlzIHRvIGJyaW5nIHRoZSB0d28gW1VuaWNvZGUgYW5kIHRoZSBJRE5BIHBhcmFtZXRlcnMg cmVnaXN0cnldIGJhY2sgaW50byBhbGlnbm1lbnQgDQogPg0KDQpJIHRoaW5rIHRoYXQgIGhhdmlu ZyBhIGdvb2QgZGVzaWduIHJlZ2lzdHJ5IG9mIFtVbmljb2RlIGFuZCB0aGUgSUROQSBwYXJhbWV0 ZXJzIHJlZ2lzdHJ5XSBpcyBhIGdvb2QgaWRlYS4NCg0KQmVzdCBSZWdhcmRzDQpKaWFua2FuZyBZ YW8= ------=_001_NextPart463408531813_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
 
Date: 2018-10-09 11:29
CC: Ted Hardie;= i18nrp; nordmark; Patrik F=C3=A4ltstr=C3=B6m; Applications and Real-Time Area Discussion; John C Klensin; idna-update
Subject: Re: [art] [I18nrp] [Idna-update] Comments on=20 draft-faltstrom-unicode11-02

= > That=20 was also my impression. In March, the IAB said that =E2=80=9CThe IAB belie= ves that the=20 best current course of action for now is to bring the two [Unicode and the= IDNA=20 parameters registry] back into alignment 
=  >
=
I=20 think that  having a good design registry of [U= nicode=20 and the IDNA parameters registry] is a good idea.

Best=20 Regards
Jiankang=20 Yao

------=_001_NextPart463408531813_=------ From nobody Tue Oct 9 00:11:11 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 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 ) 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 To: =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= , Suzanne Woolf cc: Asmus Freytag , Ted Hardie , i18nrp@ietf.org, nordmark@acm.org, idna-update@ietf.org, Applications and Real-Time Area Discussion Message-ID: <86A3FF7AA13985AFD134554D@PSB> In-Reply-To: <3F126D7C-7D3D-4561-A238-A6EFACF79EBB@netnod.se> References: <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: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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=C3=A4ltstr=C3=B6m wrote: >=20 >=20 >> On 9 Oct 2018, at 05:29, Suzanne Woolf >> wrote: >>=20 >> 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. >=20 > 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. >=20 > 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. >=20 > This is btw what was done last time we had an incompatible > change like this. >=20 > Alternatives could have been: >=20 > 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 >=20 > 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. >=20 > FWIW, I did not interpret what IAB told me was "C" which I > read in your note Suz. Maybe I misunderstand you. >=20 > Now, IF IAB really told me C, then can you please clarify? >=20 > Patrik >=20 From nobody Tue Oct 9 10:59:34 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 0CFAD127AC2; Tue, 9 Oct 2018 10:59:16 -0700 (PDT) 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 AD7aQUmQZN7v; Tue, 9 Oct 2018 10:59:12 -0700 (PDT) Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (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 A58BE1274D0; Tue, 9 Oct 2018 10:59:12 -0700 (PDT) Received: by mail-yb1-xb2d.google.com with SMTP id g15-v6so1034872ybf.6; Tue, 09 Oct 2018 10:59:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FMsCJOx/VoPHjmSQyV9tIy1RkzwhX+Qxw0SoLAT68Ds=; b=n32Xg0KyQBBUkHqI5kcqi2Ca55WdcWUJPxKjwMytx3LXtYcOA7lIIruicMMOn+Fsym 0+ZzU8E5Lx12yyOnnHOgshyF/hzTr8i1KxugTxTVl+d7pUYy8YuY4C3olx9XaBm2IWWD 9HelA23dRY6O2QkyL5AraF4WQNdeylsKNC/NUfx3ogLqDCwxVM7AKcl/XP16fYhatcat A5Aiv1H1t8k0L9A2xLZB3jZsO6oewUEzzqIF/Xh3gLNJR9xNJbRPrUfuXXvrocvtyNJg WS+Rjcn2sM+33gRu7h4r+vPPOHINNgFgicc+jxTR4fwERm2SASGhUEN1Myig3lqhWYau da7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FMsCJOx/VoPHjmSQyV9tIy1RkzwhX+Qxw0SoLAT68Ds=; b=sCGL1TN+gyJ0czzwxeQqe1zfYpS4Nh30XS/aTBDwOnXru/CEDryIw925mD3JY8Ax+E bqgzy3obbB4rD1soQ3y1eoW69FZx0PvH/sR6QJtcWnoMnInuxaoQMAgEeU6syfPkba32 agv0ObltKQc+tqS7C0UxOgJJwRAUDnjofo2nE5ltqmi3TkJnL8th1yGQ5dpik/EBZBcp 6RWjU9ZdP8LBvJ1S7rw/GYG9IHUCx6//rSgBge1dCrTYS84egNA+z+ixFL+IrAIIaXJ6 jmFw48bMRI9Wie3LqAxISINK1doxOVOR9DrBjC3QNAHEuA5fKmZtWTDBeP3/xBI+u20Z BEHg== X-Gm-Message-State: ABuFfoj96ddvTidDus96CwWtlKGVQEa0Qo7JaVJxNhtNF2TaYvd28SaE EHV9HP2FAMRWuQo4ZKMNDfwba7/I6BlTCVSo3Vc= X-Google-Smtp-Source: ACcGV63yKAgMIvmcqb2CSe8+K64gkXrPgi0CyZUjqjE2sBbnWo0m+Se8bkqUpr7CjGwI9s5wNUZXeNMo0+tECGYZL2g= X-Received: by 2002:a25:cc4:: with SMTP id 187-v6mr16039312ybm.490.1539107951640; Tue, 09 Oct 2018 10:59:11 -0700 (PDT) MIME-Version: 1.0 References: <3F126D7C-7D3D-4561-A238-A6EFACF79EBB@netnod.se> <86A3FF7AA13985AFD134554D@PSB> In-Reply-To: <86A3FF7AA13985AFD134554D@PSB> From: Spencer Dawkins at IETF Date: Tue, 9 Oct 2018 12:59:00 -0500 Message-ID: To: John C Klensin Cc: paf@netnod.se, Suzanne Woolf , Ted Hardie , asmusf@ix.netcom.com, i18nrp@ietf.org, nordmark@acm.org, art@ietf.org, idna-update@ietf.org Content-Type: multipart/alternative; boundary="000000000000ba84cd0577cf7eeb" Archived-At: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 17:59:16 -0000 --000000000000ba84cd0577cf7eeb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Posting from far outside the level of expertise I'd hope to find in the archives for this mailing list, but on one particular point. On Tue, Oct 9, 2018 at 2:11 AM John C Klensin wrote: > 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. > As an AD, I've had more problems when I asked for feedback on schedule and could reasonably have asked for early feedback, than I've had when asking for early feedback. I don't have a lot of experience with complex IANA instructions, but even then, we've asked IANA their opinions a few times, early in the process. I'll leave it to others to determine what the right answer is in this specific case, but I hope John is right. Spencer > 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=C3=A4ltstr=C3=B6m > wrote: > > > > > > >> On 9 Oct 2018, at 05:29, Suzanne Woolf > >> 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 > > > > > > > _______________________________________________ > i18nRP mailing list > i18nRP@ietf.org > https://www.ietf.org/mailman/listinfo/i18nrp > --000000000000ba84cd0577cf7eeb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Posting from far outside the level of expertise I'd ho= pe to find in the archives for this mailing list, but on one particular poi= nt.

On Tue, Oct 9, 2018= at 2:11 AM John C Klensin <john-ie= tf@jck.com> wrote:
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).=C2=A0 =C2=A0I 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.=C2=A0 I think that would be a bad idea for the
reasons below.=C2=A0 =C2=A0But 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.=C2=A0 =C2=A0I 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.

<= /div>
As an AD, I've had more problems when I asked for feedback on= schedule and could reasonably have asked for early feedback, than I've= had when asking for early feedback. I don't have a lot of experience w= ith complex IANA instructions, but even then, we've asked IANA their op= inions a few times, early in the process.

I'll= leave it to others to determine what the right answer is in this specific = case, but I hope John is right.

Spencer
= =C2=A0
My concern was precisely about h= eading down the path to Patrik's
"C".=C2=A0 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.=C2=A0 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.=C2=A0 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,
=C2=A0 =C2=A0 john




--On Tuesday, October 9, 2018 06:37 +0200 Patrik F=C3=A4ltstr=C3=B6m
<paf@netnod.se>= ; wrote:

>
>
>> On 9 Oct 2018, at 05:29, Suzanne Woolf
>> <su= zworldwide@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?
>
>=C2=A0 =C2=A0 Patrik
>




_______________________________________________
i18nRP mailing list
i18nRP@ietf.org https://www.ietf.org/mailman/listinfo/i18nrp
--000000000000ba84cd0577cf7eeb-- From nobody Wed Oct 17 05:11:05 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 CB9D4130DD3 for ; Wed, 17 Oct 2018 05:11:04 -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 geU4g_vdZkHf for ; Wed, 17 Oct 2018 05:11:03 -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 2DBCE130DC1 for ; Wed, 17 Oct 2018 05:11:03 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1gCkfF-0006g4-R7 for idna-update@ietf.org; Wed, 17 Oct 2018 08:11:01 -0400 Date: Wed, 17 Oct 2018 08:10:56 -0400 From: John C Klensin To: idna-update@ietf.org Message-ID: <37776513B82B58631CF24F3E@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] Discussion moved and became substantive 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 12:11:05 -0000 Hi. In case anyone who is following this list is not on i18nrp@ietf.org, the recent discussion, part of which was copied to this list, have shifted to that one. It has also evolved from questions about how to process documents, draft-faltstrom-unicode11 included, into substantive issues. Whether mixing the substantive with the procedural is a good idea or not, it has happened and I suggest that people keep an eye on that list as well. Subscription information and links to archives at https://www.ietf.org/mailman/listinfo/i18nrp john