From nobody Tue Dec 4 12:20:08 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 18B1C130DFD; Tue, 4 Dec 2018 12:19:49 -0800 (PST) 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 ID0hNCroNoj4; Tue, 4 Dec 2018 12:19:47 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97D6B12F1AB; Tue, 4 Dec 2018 12:19:47 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1gUHAY-0001AD-Ea; Tue, 04 Dec 2018 15:19:46 -0500 Date: Tue, 04 Dec 2018 15:19:40 -0500 From: John C Klensin To: idna-update@ietf.org cc: precis@ietf.org, i18n-discuss@iab.org, ima@ietf.org Message-ID: <3079F05172A384D8987A2338@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] draft-faltstrom-unicode11, i18n "directorate", and related issues 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, 04 Dec 2018 20:19:49 -0000 Hi. Just a heads-up to lower the odds of anyone's being surprised or unintentionally left out of the conversation. Please do not start a discussion of it on any of the mailing lists copied. An IETF Last Call was initiated yesterday on draft-faltstrom-unicode11-05, whose main intention was to follow the model of RFC 6452 and bring the IANA registry of IDNA code points into line with Unicode 11.0. In addition to a few comments on the IETF list, a discussion started on the I18Nrp list, the list set up for the BOF held during IETF 102 in Montreal to try to figure out how to progress the several i18n documents that have been stalled for some time. Because that draft is very much specific to IDNA2008, I would have expected the discussion to be on the idna-update@ietf.org list, but I suppose we should all be grateful that we don't have either parallel discussions on multiple lists or extensive cross-posting. (Patrik, it would probably be wise for -06 to explicitly identify the mailing list on which discussion would be helpful). Those who attended or watched the IETF 102 BOF in July will probably recall that it concluded that a group should be formed to provide a focus and expert advice on I18n issues to the community. It was described as a "directorate" because that term and organizational arrangement is familiar in the IETF, but it was quite clear (at least to many of us) that its mission was to advise, inform, and perhaps even educate the community on i18n issues, rather than merely advising the ART ADs and/or designating people to perform reviews late in the Last Call cycle. Alexey (as the ART AD who is apparently taking lead responsibility for this work) has indicated that the "directorate" should be organized and announced very soon now. Because (if nothing else) the document follows up on RFC 6452, which was Standards Track, and because the directorate should have a chance to come together and review this document and its relationship to other pending work, the Last Call has now been cancelled (or, I hope more accurately, deferred). However, people should be aware of that document, that there has been a discussion on the I18Nrp list that is certainly relevant to the IDNA list and effort, that includes details not covered by the summary above, and may be relevant to the other lists copied; that the directorate is expected to be announced soon; and that draft-faltstrom-unicode11 and other relevant I-Ds, including some expired ones, may soon [re-]appear and require review and evaluation. At least until Patrik or the ADs suggest otherwise, the discussion of draft-faltstrom-unicode11 is on I18Nrp (subscription and archive information at https://www.ietf.org/mailman/listinfo/i18nrp ) Happy reading and reviewing. And apologies for not getting this note out when the discussion first started up. john (no particular hats other than interested party although my hats as ex-EAI Co-Chair and author or contributor to a number of relevant RFCs and pending documents are around here somewhere) From nobody Tue Dec 4 13:05:06 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 81272130E9B; Tue, 4 Dec 2018 13:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYD5Se-OgnTQ; Tue, 4 Dec 2018 13:04:48 -0800 (PST) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 CE83D130FA5; Tue, 4 Dec 2018 13:04:47 -0800 (PST) Received: by mail-ot1-x336.google.com with SMTP id n8so12709783otl.6; Tue, 04 Dec 2018 13:04:47 -0800 (PST) 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=67eZchZ3BTuOQTWviHEvwYhRZEaY+zrYG2UcRtoM60U=; b=NJiElB5OW3vVrOZVhACG12ng6l7x55QooAMm/1OiPl3w3fU3OrNZ+beOAykS540+PS bK0HVj/RNyWBhLwne7pIVnLXminDaUrbUpG3piGqeowZLOR8kQ0wmQ+TjEJ+tcpBdHYD DrXaYCpoOaq4KqbkJduvV6EgdA1ctNGeJNxxko503y4GHwCqRuprv76jxs36M/PHLsBs uxkJ5UxCFLtX7RqMbY6Imvqsq6dsOldhHv71g/28nfrXq60WI9RGO/xHzBDxkFhHB9wx 6HyDiJKq/Mkwpz1PzqSqI4EQi/ba0FgJOOYPBDu5aKDLkdxkbmeGSwxh6pVElV/ImflK dRFg== 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=67eZchZ3BTuOQTWviHEvwYhRZEaY+zrYG2UcRtoM60U=; b=EFvylkiH+joTYjpgDVxzcR/vmtIqiOqRdVy6XWY0664zi38A8OO9vT1PAdH0kePhoo oWTsoguscoVmZpFDheopE/uGXsDEVCOO2/T/F/CIjeqiphpTHbJcWFo3dG5Al28lJzXR +zah9gGpMxILjp9FmPKnC46KpU6437LmW8g43xMWRCROLnKTqUA99hMio3Hd7pruo7Qx lA0PrdEkbCLKZA2B+1fgpsp0w5k58Vzq2D+U460AoT7HUku8mSM2OiRo2h0zFGK3HMzB r8oMyJqa+liW6lRoKfvCnFLIlNNE2k35a+WgpT5qnF6hURWqZLkN0GtcCqQrsrkxpt5m aCpw== X-Gm-Message-State: AA+aEWb0ScYZCxY/gC64cdnnZ0TDfWISlFASy2rQ1p+X7XQQe02KrDHi GPlZTEC5w4/r6fdBVvsbF+vPO1/8EDH3B3jFDGy83w== X-Google-Smtp-Source: AFSGD/XaFAotIcTxgi5Y+y/9HbRkmPVar60Yd8Tde/XnctrSzi5SR6+YsoXC7MC0Q8hYOAU4aV4EOBkx/B4tIPl1FQc= X-Received: by 2002:a9d:59c9:: with SMTP id u9mr14453122otg.75.1543957486891; Tue, 04 Dec 2018 13:04:46 -0800 (PST) MIME-Version: 1.0 References: <3079F05172A384D8987A2338@PSB> In-Reply-To: <3079F05172A384D8987A2338@PSB> From: Ted Hardie Date: Tue, 4 Dec 2018 13:04:20 -0800 Message-ID: To: John C Klensin Cc: idna-update@ietf.org, ima@ietf.org, precis@ietf.org, i18n-discuss@iab.org Content-Type: multipart/alternative; boundary="0000000000008df606057c389d7c" Archived-At: Subject: Re: [Idna-update] [I18n-discuss] draft-faltstrom-unicode11, i18n "directorate", and related issues 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, 04 Dec 2018 21:04:52 -0000 --0000000000008df606057c389d7c Content-Type: text/plain; charset="UTF-8" John, This is to advise you that I have notified the IESG that I strongly disagree with this conclusion on the scope of an i18n directorate; I heard calls for a directorate, not for a body with different characteristics sharing the name. I have also notified them that I object to the formation of a body with a different remit to the usual "advise the ADs" unless a community discussion, charter, and discussion of how membership is selected takes place. We charter directorates now as advisory bodies to the ADs, and the ADs bear the responsibility for the related decisions (taking or not taking the advice as they see fit). Since the ADs are selected by the NomCom, how they derive that authority and its limits are well known. What you describe below departs from that, and unless it is made clear what authority is being granted and how the community is being consulted, I think it is outside of our process. Since this amounts to the early stage of an appeal, I have recused myself from further discussion within the IESG on this topic. On the more technical topic of the appropriate status (Standards Track or Informational) for this document, I will follow up as you suggest. Ted On Tue, Dec 4, 2018 at 12:19 PM John C Klensin wrote: > > Those who attended or watched the IETF 102 BOF in July will > probably recall that it concluded that a group should be formed > to provide a focus and expert advice on I18n issues to the > community. It was described as a "directorate" because that > term and organizational arrangement is familiar in the IETF, but > it was quite clear (at least to many of us) that its mission was > to advise, inform, and perhaps even educate the community on > i18n issues, rather than merely advising the ART ADs and/or > designating people to perform reviews late in the Last Call > cycle. Alexey (as the ART AD who is apparently taking lead > responsibility for this work) has indicated that the > "directorate" should be organized and announced very soon now. > > > Because (if nothing else) the document follows up on RFC 6452, > which was Standards Track, and because the directorate should > have a chance to come together and review this document and its > relationship to other pending work, the Last Call has now been > cancelled (or, I hope more accurately, deferred). > > However, people should be aware of that document, that there has > been a discussion on the I18Nrp list that is certainly relevant > to the IDNA list and effort, that includes details not covered > by the summary above, and may be relevant to the other lists > copied; that the directorate is expected to be announced soon; > and that draft-faltstrom-unicode11 and other relevant I-Ds, > including some expired ones, may soon [re-]appear and require > review and evaluation. > > At least until Patrik or the ADs suggest otherwise, the > discussion of draft-faltstrom-unicode11 is on I18Nrp > (subscription and archive information at > https://www.ietf.org/mailman/listinfo/i18nrp ) > > Happy reading and reviewing. > And apologies for not getting this note out when the discussion > first started up. > > john > (no particular hats other than interested party although my > hats as ex-EAI Co-Chair and author or contributor to a number of > relevant RFCs and pending documents are around here somewhere) > > _______________________________________________ > I18n-discuss mailing list > I18n-discuss@iab.org > https://www.iab.org/mailman/listinfo/i18n-discuss > --0000000000008df606057c389d7c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
John,

This is to advise you = that I have notified the IESG that I strongly disagree with this conclusion= on the scope of an i18n directorate; I heard calls for a directorate, not = for a body with different characteristics sharing the name.=C2=A0 I have al= so notified them that I object to the formation of a body with a different = remit to the usual "advise the ADs" unless a community discussion= , charter, and discussion of how membership is selected takes place.=C2=A0 =

We charter directorates now as advisory bodie= s to the ADs, and the ADs bear the responsibility for the related decisions= (taking or not taking the advice as they see fit).=C2=A0 Since the ADs are= selected by the NomCom, how they derive that authority and its limits are = well known.=C2=A0 What you describe below departs from that, and unless it = is made clear what authority is being granted and how the community is bein= g consulted, I think it is outside of our process.

Since this amounts to the early stage of an appeal, I have recused myself = from further discussion within the IESG on this topic.

=
On the more technical topic of the appropriate status (Standards Track= or Informational) for this document, I will follow up as you suggest.

Ted

On Tue, Dec 4, 2018 at 12:19 PM John C Klensin <john-ietf@jck.com> wrote:

Those who attended or watched the IETF 102 BOF in July will
probably recall that it concluded that a group should be formed
to provide a focus and expert advice on I18n issues to the
community.=C2=A0 =C2=A0It was described as a "directorate" becaus= e that
term and organizational arrangement is familiar in the IETF, but
it was quite clear (at least to many of us) that its mission was
to advise, inform, and perhaps even educate the community on
i18n issues, rather than merely advising the ART ADs and/or
designating people to perform reviews late in the Last Call
cycle.=C2=A0 Alexey (as the ART AD who is apparently taking lead
responsibility for this work) has indicated that the
"directorate" should be organized and announced very soon now.


=C2=A0
Because (if nothing else) the document follows up on RFC 6452,
which was Standards Track, and because the directorate should
have a chance to come together and review this document and its
relationship to other pending work, the Last Call has now been
cancelled (or, I hope more accurately, deferred).

However, people should be aware of that document, that there has
been a discussion on the I18Nrp list that is certainly relevant
to the IDNA list and effort, that includes details not covered
by the summary above, and may be relevant to the other lists
copied; that the directorate is expected to be announced soon;
and that draft-faltstrom-unicode11 and other relevant I-Ds,
including some expired ones, may soon [re-]appear and require
review and evaluation.

At least until Patrik or the ADs suggest otherwise, the
discussion of draft-faltstrom-unicode11 is on I18Nrp
(subscription and archive information at
https://www.ietf.org/mailman/listinfo/i18nrp )

Happy reading and reviewing.
And apologies for not getting this note out when the discussion
first started up.

=C2=A0 =C2=A0 john
=C2=A0 =C2=A0 (no particular hats other than interested party although my hats as ex-EAI Co-Chair and author or contributor to a number of
relevant RFCs and pending documents are around here somewhere)

_______________________________________________
I18n-discuss mailing list
I18n-discuss@iab.= org
https://www.iab.org/mailman/listinfo/i18n-discuss
--0000000000008df606057c389d7c-- From nobody Tue Dec 4 13:30:10 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EEA7130EE4; Tue, 4 Dec 2018 13:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qL8TjcIPOeIv; Tue, 4 Dec 2018 13:30:00 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 9A3F9130E51; Tue, 4 Dec 2018 13:29:59 -0800 (PST) Received: from [10.0.1.24] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wB4LTuom039406 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 4 Dec 2018 15:29:57 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.24] From: Ben Campbell Message-Id: <8458F480-52CB-4DD4-9C52-6ED9F2860DFD@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_3093192E-4AA2-4A43-99A0-ACB31F2F44BE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Tue, 4 Dec 2018 15:29:56 -0600 In-Reply-To: Cc: John C Klensin , i18n-discuss@iab.org, idna-update@ietf.org, ima@ietf.org, precis@ietf.org To: Ted Hardie References: <3079F05172A384D8987A2338@PSB> X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [Idna-update] [precis] [I18n-discuss] draft-faltstrom-unicode11, i18n "directorate", and related issues 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, 04 Dec 2018 21:30:03 -0000 --Apple-Mail=_3093192E-4AA2-4A43-99A0-ACB31F2F44BE Content-Type: multipart/alternative; boundary="Apple-Mail=_EFDBB8EC-3D12-4774-B7A4-B68E5BAC1ABC" --Apple-Mail=_EFDBB8EC-3D12-4774-B7A4-B68E5BAC1ABC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ted, I=E2=80=99d like to understand your objection better. (Please don=E2=80=99= t take this as disagreement. Or agreement, for that matter :-) ) How do you see things like =E2=80=9Cadvise=E2=80=9D, =E2=80=9Ceducate=E2=80= =9D and =E2=80=9Cinform=E2=80=9D as being a grant of authority beyond = that of a directorate? Individual participants can and do those things = regularly; so I=E2=80=99m confused as why doing it as part of a = directorate would be different. Do you read those things as putting the = directorate in the approval path? Or are you concerned such advice would = be given greater weight because of the directorate? Thanks! Ben. > On Dec 4, 2018, at 3:04 PM, Ted Hardie wrote: >=20 > John, >=20 > This is to advise you that I have notified the IESG that I strongly = disagree with this conclusion on the scope of an i18n directorate; I = heard calls for a directorate, not for a body with different = characteristics sharing the name. I have also notified them that I = object to the formation of a body with a different remit to the usual = "advise the ADs" unless a community discussion, charter, and discussion = of how membership is selected takes place. >=20 > We charter directorates now as advisory bodies to the ADs, and the ADs = bear the responsibility for the related decisions (taking or not taking = the advice as they see fit). Since the ADs are selected by the NomCom, = how they derive that authority and its limits are well known. What you = describe below departs from that, and unless it is made clear what = authority is being granted and how the community is being consulted, I = think it is outside of our process. >=20 > Since this amounts to the early stage of an appeal, I have recused = myself from further discussion within the IESG on this topic. >=20 > On the more technical topic of the appropriate status (Standards Track = or Informational) for this document, I will follow up as you suggest. >=20 > Ted >=20 > On Tue, Dec 4, 2018 at 12:19 PM John C Klensin > wrote: >=20 > Those who attended or watched the IETF 102 BOF in July will > probably recall that it concluded that a group should be formed > to provide a focus and expert advice on I18n issues to the > community. It was described as a "directorate" because that > term and organizational arrangement is familiar in the IETF, but > it was quite clear (at least to many of us) that its mission was > to advise, inform, and perhaps even educate the community on > i18n issues, rather than merely advising the ART ADs and/or > designating people to perform reviews late in the Last Call > cycle. Alexey (as the ART AD who is apparently taking lead > responsibility for this work) has indicated that the > "directorate" should be organized and announced very soon now. >=20 >=20 >=20 >=20 > Because (if nothing else) the document follows up on RFC 6452, > which was Standards Track, and because the directorate should > have a chance to come together and review this document and its > relationship to other pending work, the Last Call has now been > cancelled (or, I hope more accurately, deferred). >=20 > However, people should be aware of that document, that there has > been a discussion on the I18Nrp list that is certainly relevant > to the IDNA list and effort, that includes details not covered > by the summary above, and may be relevant to the other lists > copied; that the directorate is expected to be announced soon; > and that draft-faltstrom-unicode11 and other relevant I-Ds, > including some expired ones, may soon [re-]appear and require > review and evaluation. >=20 > At least until Patrik or the ADs suggest otherwise, the > discussion of draft-faltstrom-unicode11 is on I18Nrp > (subscription and archive information at > https://www.ietf.org/mailman/listinfo/i18nrp = ) >=20 > Happy reading and reviewing. > And apologies for not getting this note out when the discussion > first started up. >=20 > john > (no particular hats other than interested party although my > hats as ex-EAI Co-Chair and author or contributor to a number of > relevant RFCs and pending documents are around here somewhere) >=20 > _______________________________________________ > I18n-discuss mailing list > I18n-discuss@iab.org > https://www.iab.org/mailman/listinfo/i18n-discuss = > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis --Apple-Mail=_EFDBB8EC-3D12-4774-B7A4-B68E5BAC1ABC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Ted,

I=E2=80=99d = like to understand your objection better. (Please don=E2=80=99t take = this as disagreement. Or agreement, for that matter :-) )

How do you see things = like =E2=80=9Cadvise=E2=80=9D, =E2=80=9Ceducate=E2=80=9D and = =E2=80=9Cinform=E2=80=9D as being a grant of authority beyond that of a = directorate? Individual participants can and do those things regularly; = so I=E2=80=99m confused as why doing it as part of a directorate would = be different. Do you read those things as putting the directorate in the = approval path? Or are you concerned such advice would be given greater = weight because of the directorate?


Thanks!

Ben.

On Dec 4, 2018, at 3:04 PM, Ted = Hardie <ted.ietf@gmail.com> wrote:

John,

This is to advise you that I have = notified the IESG that I strongly disagree with this conclusion on the = scope of an i18n directorate; I heard calls for a directorate, not for a = body with different characteristics sharing the name.  I have also = notified them that I object to the formation of a body with a different = remit to the usual "advise the ADs" unless a community discussion, = charter, and discussion of how membership is selected takes place.  =

We charter directorates now as advisory bodies to the ADs, = and the ADs bear the responsibility for the related decisions (taking or = not taking the advice as they see fit).  Since the ADs are selected = by the NomCom, how they derive that authority and its limits are well = known.  What you describe below departs from that, and unless it is = made clear what authority is being granted and how the community is = being consulted, I think it is outside of our process.

Since this amounts to = the early stage of an appeal, I have recused myself from further = discussion within the IESG on this topic.

On the more technical topic of the = appropriate status (Standards Track or Informational) for this document, = I will follow up as you suggest.

Ted

On Tue, Dec 4, 2018 at 12:19 PM John C Klensin <john-ietf@jck.com> = wrote:

Those who attended or watched the IETF 102 BOF in July will
= probably recall that it concluded that a group should be formed
to provide a focus and expert advice on I18n issues to the
community.   It was described as a "directorate" because = that
term and organizational arrangement is familiar in the IETF, but
it was quite clear (at least to many of us) that its mission was
to advise, inform, and perhaps even educate the community on
i18n issues, rather than merely advising the ART ADs and/or
= designating people to perform reviews late in the Last Call
= cycle.  Alexey (as the ART AD who is apparently taking lead
responsibility for this work) has indicated that the
"directorate" should be organized and announced very soon now.



 
Because (if nothing else) the document follows up on RFC 6452,
which was Standards Track, and because the directorate should
have a chance to come together and review this document and its
relationship to other pending work, the Last Call has now been
cancelled (or, I hope more accurately, deferred).

However, people should be aware of that document, that there has
been a discussion on the I18Nrp list that is certainly relevant
to the IDNA list and effort, that includes details not covered
by the summary above, and may be relevant to the other lists
copied; that the directorate is expected to be announced soon;
and that draft-faltstrom-unicode11 and other relevant I-Ds,
= including some expired ones, may soon [re-]appear and require
review and evaluation.

At least until Patrik or the ADs suggest otherwise, the
discussion of draft-faltstrom-unicode11 is on I18Nrp
(subscription and archive information at
https://www.ietf.org/mailman/listinfo/i18nrp )

Happy reading and reviewing.
And apologies for not getting this note out when the discussion
first started up.

    john
    (no particular hats other than interested party although = my
hats as ex-EAI Co-Chair and author or contributor to a number of
relevant RFCs and pending documents are around here somewhere)

_______________________________________________
I18n-discuss mailing list
I18n-discuss@iab.org
https://www.iab.org/mailman/listinfo/i18n-discuss
_______________________________________________
precis = mailing list
precis@ietf.org
https://www.ietf.org/mailman/listinfo/precis

= --Apple-Mail=_EFDBB8EC-3D12-4774-B7A4-B68E5BAC1ABC-- --Apple-Mail=_3093192E-4AA2-4A43-99A0-ACB31F2F44BE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlwG8dQACgkQgFZKbJXz 1A3Xqg//Vl0r51/FbSIreNAjH0Qpnuli1DDR0ushLgneQMlSO5AZwXi4a4hfyAOp yoaZw9+hO+2egVjM3/O7nHwy2ulD3014YpamfPM+ItU3pOlvKiDSaSId5SrtHZMo 0k6X9GI+vV7gxOkpERA8QouihxEIdPwNbipOavsT3YKckrMpz3xnIqD4c4WcDB7U WDQ+pTUMlegaxLQq+ZdPRkFdAGjLgmDT6uhVY1jTlIgMSS1wcnUzcBxds9W4GMqm 4gwhNbf+/ulPl6rgBm2Uzq4wS2hwdJ3mSkNT9uR4CfRwv7Al7rPhPZAhlNYXnxTH M7FhZccsSDPI2FBNrThBTJuJ2o9LooN+yLoq+DfU9rtMs3Q3t6MetB1Ug+G6gygh D6efBUWQ9wNRcloMCNOc6DKlCaRlSgI0fVgrkOjhsBleRflaXG6v76Z7Fx9sUgfx eajWl85KqEfzXeTF7hRcPygTlnkvxa0FWNE+IwkWGPiVX4/BvVbKZemRy9gw9qDm 7aYxPbp4Pm11HOz+57Fu26X3V7XqUqXngo4at9qQpANq+zAXGT10sVnju/WDVfxB y6Uz20ACfNO2yzvY2KywT1c1+G7xFbqgq25Y3BgSIA+tdXFuhlr8FyJJqTJ15V/x siwK+kv3A+qKknmEusEMbSPzvwkRl2o1C5Xgvc6ONMtuoZqxCCk= =tJvX -----END PGP SIGNATURE----- --Apple-Mail=_3093192E-4AA2-4A43-99A0-ACB31F2F44BE-- From nobody Tue Dec 4 14:03:08 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 B4F97130E97; Tue, 4 Dec 2018 14:02:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6PWSDY1O8LV; Tue, 4 Dec 2018 14:02:56 -0800 (PST) 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 6A9951200B3; Tue, 4 Dec 2018 14:02:56 -0800 (PST) Received: by mail-ot1-x32a.google.com with SMTP id u16so16734851otk.8; Tue, 04 Dec 2018 14:02:56 -0800 (PST) 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=o56rKKMJZI41EcfZCKUuBWYBwkBIdX+iAGondqAeHxc=; b=NKZKMKBcqAL8QUJpD2x2W3JqZ/ZXuPw5GaiJ6maVTM6StJBB5oYirWSJsa++9qQQhn 8nyrD/HSUY4uPjjZpZzkLOVrvbGcWrB5pgwlnO0S7BXdeqHyvaHvZ/p0DTyC2i8kg1/B v8IMkZJGSmshiXgO1CQMF6Tq0slAwnJPQznELe7yl4+EOxCiFiUGRWekAgeQrfZNp4s4 4lSuiszbGWXmPNusmnszCiSQXE0lJAEq/FKSdOe0mb+vXwkq+FA79L7K0hSSmKzEFwJT 78rmLShJ79AQnJMDxZnObwoc1DHCaho+FdgvzLUU6h9JcXT4kMCEYQVm3cz5qwQImBYP RfIw== 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=o56rKKMJZI41EcfZCKUuBWYBwkBIdX+iAGondqAeHxc=; b=YZl7UkFB9VzqNJV45QawPTyhnqr9/NC6QD7OX92Pa/aFqyuof0NeBSm8tr/oq/m50N p3Ws6UO9azGxej3ebvxfkzmXCbQmUncTdeAQcz/x6wnmh8XelygzrripXomnqxdtyPKx QA1awsNTjnZbccnoBcN/sKuCLMi2hE8Nc/BIOOV0qUXNndAdq1eUE3TtIVDDpjhA1d5l uSmS8+FowZi2aO2rqqFJ4Z8Oy7cLFXGKtOS9KhAhNgBjqepz4EbQZK6/n4Ofvgtpd0ph LOGzDKafwVKeKNd2ZEgA6nXk3CIpWSVhN1wopGJcGOkZrBiRCJrdnZB4LICGfnVwHn4I shTg== X-Gm-Message-State: AA+aEWY8UCAn/u3N1AfnUI7H5KsCQkjazQC8pypr5yFDv0+29oksj50b WDbAPuPD70QMjIocyBikSQI5mpy4Y90LPtvJUQw= X-Google-Smtp-Source: AFSGD/XGMB9GMZ/pB7tWG/8DPEdklC9Ne6Lz0EeMrYEsNJf+A1dBO3aWC1IkvspE5TioyfTFega6l3JF6Q2s5YIlxM8= X-Received: by 2002:a9d:72a:: with SMTP id 39mr15031719ote.134.1543960975251; Tue, 04 Dec 2018 14:02:55 -0800 (PST) MIME-Version: 1.0 References: <3079F05172A384D8987A2338@PSB> <8458F480-52CB-4DD4-9C52-6ED9F2860DFD@nostrum.com> In-Reply-To: <8458F480-52CB-4DD4-9C52-6ED9F2860DFD@nostrum.com> From: Ted Hardie Date: Tue, 4 Dec 2018 14:02:27 -0800 Message-ID: To: Ben Campbell Cc: John C Klensin , i18n-discuss@iab.org, idna-update@ietf.org, ima@ietf.org, precis@ietf.org Content-Type: multipart/alternative; boundary="0000000000007a1e70057c396d8f" Archived-At: Subject: Re: [Idna-update] [precis] [I18n-discuss] draft-faltstrom-unicode11, i18n "directorate", and related issues 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, 04 Dec 2018 22:03:00 -0000 --0000000000007a1e70057c396d8f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ben, On Tue, Dec 4, 2018 at 1:29 PM Ben Campbell wrote: > Hi Ted, > > I=E2=80=99d like to understand your objection better. (Please don=E2=80= =99t take this as > disagreement. Or agreement, for that matter :-) ) > > How do you see things like =E2=80=9Cadvise=E2=80=9D, =E2=80=9Ceducate=E2= =80=9D and =E2=80=9Cinform=E2=80=9D as being a > grant of authority beyond that of a directorate? Individual participants > can and do those things regularly; so I=E2=80=99m confused as why doing i= t as part > of a directorate would be different. Do you read those things as putting > the directorate in the approval path? Or are you concerned such advice > would be given greater weight because of the directorate? > Given that the first suggestion here was that a document could not go through last call until it had been reviewed by the group and John's message seemed to indicate that its authority was not simply to advise an AD, I inferred that the intent was to set up a group with an independent authority to foster work or block documents. That seems to me to require discussion. Even the EDU team, which has a remit to educate the community is defined as a directorate serving the GEN area, and why this cannot be not an area director led activity is not clear to me. If we need something beyond that, okay, but I believe that requires community discussion about how such groups are chartered, how their membership is selected, and what the limits of their authority should be. regards, Ted Hardie > > > Thanks! > > Ben. > > On Dec 4, 2018, at 3:04 PM, Ted Hardie wrote: > > John, > > This is to advise you that I have notified the IESG that I strongly > disagree with this conclusion on the scope of an i18n directorate; I hear= d > calls for a directorate, not for a body with different characteristics > sharing the name. I have also notified them that I object to the formati= on > of a body with a different remit to the usual "advise the ADs" unless a > community discussion, charter, and discussion of how membership is select= ed > takes place. > > We charter directorates now as advisory bodies to the ADs, and the ADs > bear the responsibility for the related decisions (taking or not taking t= he > advice as they see fit). Since the ADs are selected by the NomCom, how > they derive that authority and its limits are well known. What you > describe below departs from that, and unless it is made clear what > authority is being granted and how the community is being consulted, I > think it is outside of our process. > > Since this amounts to the early stage of an appeal, I have recused myself > from further discussion within the IESG on this topic. > > On the more technical topic of the appropriate status (Standards Track or > Informational) for this document, I will follow up as you suggest. > > Ted > > On Tue, Dec 4, 2018 at 12:19 PM John C Klensin wrote: > >> >> Those who attended or watched the IETF 102 BOF in July will >> probably recall that it concluded that a group should be formed >> to provide a focus and expert advice on I18n issues to the >> community. It was described as a "directorate" because that >> term and organizational arrangement is familiar in the IETF, but >> it was quite clear (at least to many of us) that its mission was >> to advise, inform, and perhaps even educate the community on >> i18n issues, rather than merely advising the ART ADs and/or >> designating people to perform reviews late in the Last Call >> cycle. Alexey (as the ART AD who is apparently taking lead >> responsibility for this work) has indicated that the >> "directorate" should be organized and announced very soon now. >> >> > > > >> Because (if nothing else) the document follows up on RFC 6452, >> which was Standards Track, and because the directorate should >> have a chance to come together and review this document and its >> relationship to other pending work, the Last Call has now been >> cancelled (or, I hope more accurately, deferred). >> >> However, people should be aware of that document, that there has >> been a discussion on the I18Nrp list that is certainly relevant >> to the IDNA list and effort, that includes details not covered >> by the summary above, and may be relevant to the other lists >> copied; that the directorate is expected to be announced soon; >> and that draft-faltstrom-unicode11 and other relevant I-Ds, >> including some expired ones, may soon [re-]appear and require >> review and evaluation. >> >> At least until Patrik or the ADs suggest otherwise, the >> discussion of draft-faltstrom-unicode11 is on I18Nrp >> (subscription and archive information at >> https://www.ietf.org/mailman/listinfo/i18nrp ) >> >> Happy reading and reviewing. >> And apologies for not getting this note out when the discussion >> first started up. >> >> john >> (no particular hats other than interested party although my >> hats as ex-EAI Co-Chair and author or contributor to a number of >> relevant RFCs and pending documents are around here somewhere) >> >> _______________________________________________ >> I18n-discuss mailing list >> I18n-discuss@iab.org >> https://www.iab.org/mailman/listinfo/i18n-discuss >> > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis > > > --0000000000007a1e70057c396d8f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ben,

On Tue, Dec 4, 2018 at 1:29 PM Ben Campbell <ben@nostrum.com> wrote:
Hi Ted,

I=E2=80=99d like to understand your objectio= n better. (Please don=E2=80=99t take this as disagreement. Or agreement, fo= r that matter :-) )

How do you see things like =E2= =80=9Cadvise=E2=80=9D, =E2=80=9Ceducate=E2=80=9D and =E2=80=9Cinform=E2=80= =9D as being a grant of authority beyond that of a directorate?=C2=A0 Indiv= idual participants can and do those things regularly; so I=E2=80=99m confus= ed as why doing it as part of a directorate would be different. Do you read= those things as putting the directorate in the approval path? Or are you c= oncerned such advice would be given greater weight because of the directora= te?

Given that the first sugges= tion here was that a document could not go through last call until it had b= een reviewed by the group and John's message seemed to indicate that it= s authority was not simply to advise an AD, I inferred that the intent was = to set up a group with an independent authority to foster work or block doc= uments.=C2=A0 That seems to me to require discussion.=C2=A0 Even the EDU te= am, which has a remit to educate the community is defined as a directorate = serving the GEN area, and why this cannot be not an area director led activ= ity is not clear to me.

If we need something beyon= d that, okay, but I believe that requires community discussion about how su= ch groups are chartered, how their membership is selected, and what the lim= its of their authority should be.

regards,

Ted Hardie
=C2=A0


Thanks!

Ben.

On Dec 4, 2018, at 3:04 PM, Ted H= ardie <ted.ietf@= gmail.com> wrote:

John,

= This is to advise you that I have notified the IESG that I strongly disagre= e with this conclusion on the scope of an i18n directorate; I heard calls f= or a directorate, not for a body with different characteristics sharing the= name.=C2=A0 I have also notified them that I object to the formation of a = body with a different remit to the usual "advise the ADs" unless = a community discussion, charter, and discussion of how membership is select= ed takes place.=C2=A0

We charter directorates= now as advisory bodies to the ADs, and the ADs bear the responsibility for= the related decisions (taking or not taking the advice as they see fit).= =C2=A0 Since the ADs are selected by the NomCom, how they derive that autho= rity and its limits are well known.=C2=A0 What you describe below departs f= rom that, and unless it is made clear what authority is being granted and h= ow the community is being consulted, I think it is outside of our process.<= /div>

Since this amounts to the early stage of an appeal= , I have recused myself from further discussion within the IESG on this top= ic.

On the more technical topic of the appropriate= status (Standards Track or Informational) for this document, I will follow= up as you suggest.

Ted

On Tue, Dec 4, 2018 at 12:19 PM John C = Klensin <john-iet= f@jck.com> wrote:

Those who attended or watched the IETF 102 BOF in July will
probably recall that it concluded that a group should be formed
to provide a focus and expert advice on I18n issues to the
community.=C2=A0 =C2=A0It was described as a "directorate" becaus= e that
term and organizational arrangement is familiar in the IETF, but
it was quite clear (at least to many of us) that its mission was
to advise, inform, and perhaps even educate the community on
i18n issues, rather than merely advising the ART ADs and/or
designating people to perform reviews late in the Last Call
cycle.=C2=A0 Alexey (as the ART AD who is apparently taking lead
responsibility for this work) has indicated that the
"directorate" should be organized and announced very soon now.


=C2=A0
Because (if nothing else) the document follows up on RFC 6452,
which was Standards Track, and because the directorate should
have a chance to come together and review this document and its
relationship to other pending work, the Last Call has now been
cancelled (or, I hope more accurately, deferred).

However, people should be aware of that document, that there has
been a discussion on the I18Nrp list that is certainly relevant
to the IDNA list and effort, that includes details not covered
by the summary above, and may be relevant to the other lists
copied; that the directorate is expected to be announced soon;
and that draft-faltstrom-unicode11 and other relevant I-Ds,
including some expired ones, may soon [re-]appear and require
review and evaluation.

At least until Patrik or the ADs suggest otherwise, the
discussion of draft-faltstrom-unicode11 is on I18Nrp
(subscription and archive information at
https://www.ietf.org/mailman/listinfo/i18nrp )

Happy reading and reviewing.
And apologies for not getting this note out when the discussion
first started up.

=C2=A0 =C2=A0 john
=C2=A0 =C2=A0 (no particular hats other than interested party although my hats as ex-EAI Co-Chair and author or contributor to a number of
relevant RFCs and pending documents are around here somewhere)

_______________________________________________
I18n-discuss mailing list
I18n-discuss@iab.= org
https://www.iab.org/mailman/listinfo/i18n-discuss
_______________________________________________
precis mailing list
<= a href=3D"mailto:precis@ietf.org" target=3D"_blank">precis@ietf.org
= = https://www.ietf.org/mailman/listinfo/precis

--0000000000007a1e70057c396d8f-- From nobody Tue Dec 4 14:55:09 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C0E130E73; Tue, 4 Dec 2018 14:54:55 -0800 (PST) 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-3L4DoHMKJG; Tue, 4 Dec 2018 14:54:53 -0800 (PST) Received: from episteme.net (episteme.net [216.169.5.102]) by ietfa.amsl.com (Postfix) with ESMTP id DE18B128D0C; Tue, 4 Dec 2018 14:54:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id CA5206F62280; Tue, 4 Dec 2018 16:54:48 -0600 (CST) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQjkmIagOOZ1; Tue, 4 Dec 2018 16:54:44 -0600 (CST) Received: from [172.16.1.76] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id DD1D46F62277; Tue, 4 Dec 2018 16:54:44 -0600 (CST) From: "Pete Resnick" To: "Ted Hardie" Cc: "Ben Campbell" , "John C Klensin" , i18n-discuss@iab.org, idna-update@ietf.org, ima@ietf.org, precis@ietf.org Date: Tue, 04 Dec 2018 16:54:44 -0600 X-Mailer: MailMate (1.12.2r5568) Message-ID: <680E50F3-3881-416F-A11A-22563F44A732@episteme.net> In-Reply-To: References: <3079F05172A384D8987A2338@PSB> <8458F480-52CB-4DD4-9C52-6ED9F2860DFD@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown Archived-At: Subject: Re: [Idna-update] [precis] [I18n-discuss] draft-faltstrom-unicode11, i18n "directorate", and related issues 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, 04 Dec 2018 22:54:55 -0000 On 4 Dec 2018, at 16:02, Ted Hardie wrote: > Given that the first suggestion here was that a document could not go > through last call until it had been reviewed by the group and John's > message seemed to indicate that its authority was not simply to advise > an AD, I inferred that the intent was to set up a group with an > independent authority to foster work or block documents. Have a look at https://datatracker.ietf.org/help/state/draft/iesg. You will see a state between "AD Evaluation" and "Last Call Requested" called "Expert Review". At an AD's discretion, before a document is sent for Last Call: An AD sometimes asks for an external review by an outside party as part of evaluating whether a document is ready for advancement. MIBs, for example, are reviewed by the "MIB doctors". Other types of reviews may also be requested (e.g., security, operations impact, etc.). Documents stay in this state until the review is complete and possibly until the issues raised in the review are addressed. See the "note" field for specific details on the nature of the review. Moving a document out of Last Call back to AD Evaluation to send it for Expert Review, and blocking on that state until such review is complete, is and has been standard operating procedure for a long time. I see no independent authority being added here that overrides the discretion of the responsible AD. > That seems to me to require discussion. I disagree. pr -- Pete Resnick http://www.episteme.net/ All connections to the world are tenuous at best From nobody Tue Dec 4 15:38:15 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 D36C9130DC8; Tue, 4 Dec 2018 15:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 SaPW7A7LXlPZ; Tue, 4 Dec 2018 15:38:06 -0800 (PST) Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E32F212E7C1; Tue, 4 Dec 2018 15:38:05 -0800 (PST) Received: by mail-oi1-x22d.google.com with SMTP id c206so15964904oib.0; Tue, 04 Dec 2018 15:38:05 -0800 (PST) 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=yz4X05uHxfmIxvCJtPvDL/U4A4zg0WHufwuDr0BoNKk=; b=jCL1LJG/RfdXOMUp2TNeL2uRACj/dK9L3r9rF3u64VQ3viLlTcOZTmc8188ZswkXfS XzNhPbZuCUeufewSIN3CFAEvN6NbtYBRMytedo/thBA5msZKIr9MbEci1yWX2aP8oSlJ /Wz0k1eeXauD0ylEYAFzsh+a0PUhu2lhSdubhohHmLxmwxAXKWKOAwIzU3raT5kKGUsv lGGjBY8oG5J01F0+fnOFKh4knCZlztzcrG+4tcju8KA7MyaBkDSASMGxZe9Xl5sjeIm/ 24BGKsJyUm112SzzgerCb7FBT82hdImFAPwwOa9FRJvwru+i/ZMjiLyZ7ccaPZ1SZm06 yJDg== 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=yz4X05uHxfmIxvCJtPvDL/U4A4zg0WHufwuDr0BoNKk=; b=fuSJJvRBlzV8rwDcms7SZm+wpkWYsO5bw+YxAb1NiflV7wmx4CL/1hywAUP/qbH1TE TPvkGNsfNGpgrDeVVWC5WSI3HRnTZCYgTGpbFdf8M/dT4WHNeatAUdqiuUvc9Q8Z6Mkt BXcsib+pqX5rGmchUW9Yy2fKTiizSGqkRd21vhuvl1sgQxgAurgml4D1mjrWnuyaUXPz x8SkDbwyAfLGsCykBQkU/T4cX4KSe/jKaN22tLdh9wEe8uacB5cENvY6njiAFdJDIO1b 5eJ5Nb24zO9zkcPqxnHryd7bq6HLReNeWsSBQYSuTYyIQ0SE5UVdmFIk9iJyFPVxSlWq rGQA== X-Gm-Message-State: AA+aEWaiROZokxe5AGPYOiDecAWsC2rdCkRhSo2TzjhvQNzctwwzBnSi FWJQTRDDy1CvNiURFmNTM8n6Kx1cRR2JY7LL2BxDSRD1 X-Google-Smtp-Source: AFSGD/XfiRlCPEeM7W60LgnyNUi9XBfMry/F0QsuMpcXlYAeZN3n/hEYNAxyFm5YzbNwxSdE4LBtuXCE5sFphb+eCJk= X-Received: by 2002:aca:c4d8:: with SMTP id u207mr13225849oif.30.1543966684823; Tue, 04 Dec 2018 15:38:04 -0800 (PST) MIME-Version: 1.0 References: <3079F05172A384D8987A2338@PSB> <8458F480-52CB-4DD4-9C52-6ED9F2860DFD@nostrum.com> <680E50F3-3881-416F-A11A-22563F44A732@episteme.net> In-Reply-To: <680E50F3-3881-416F-A11A-22563F44A732@episteme.net> From: Ted Hardie Date: Tue, 4 Dec 2018 15:37:37 -0800 Message-ID: To: resnick@episteme.net Cc: Ben Campbell , John C Klensin , i18n-discuss@iab.org, idna-update@ietf.org, ima@ietf.org, precis@ietf.org Content-Type: multipart/alternative; boundary="000000000000cb459e057c3ac16e" Archived-At: Subject: Re: [Idna-update] [precis] [I18n-discuss] draft-faltstrom-unicode11, i18n "directorate", and related issues 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, 04 Dec 2018 23:38:09 -0000 --000000000000cb459e057c3ac16e Content-Type: text/plain; charset="UTF-8" Howdy Pete, Please re-read John's message, which includes this: " It was described as a "directorate" because that term and organizational arrangement is familiar in the IETF, but it was quite clear (at least to many of us) that its mission was to advise, inform, and perhaps even educate the community on i18n issues, rather than merely advising the ART ADs and/or designating people to perform reviews late in the Last Call cycle. " As I have said multiple times, I have no problem with an AD requesting a review of a specific individual or set of individuals. But John's message is highlighting that this group is meant to be something different than the usual directorate. That concerns me, especially if it is meant to have a review power beyond "advising the ART ADs", which is what (ART) directorates do. Soliciting and receiving that advice is the state you're pointing to, and but John has asserted this is not that. Given that assertion, I think the community ought to know and have a voice in what it is instead. I also am disappointed that the ART ADs did not simply ask the relevant questions of the people that they would or will put on the Directorate, if they are seeking the usual sort of advice. There is no power in the advice coming from a directorate rather than Individual 1 or 2. But that is a timing question, not a process point. regards, Ted On Tue, Dec 4, 2018 at 2:54 PM Pete Resnick wrote: > On 4 Dec 2018, at 16:02, Ted Hardie wrote: > > > Given that the first suggestion here was that a document could not go > > through last call until it had been reviewed by the group and John's > > message seemed to indicate that its authority was not simply to advise > > an AD, I inferred that the intent was to set up a group with an > > independent authority to foster work or block documents. > > Have a look at https://datatracker.ietf.org/help/state/draft/iesg. You > will see a state between "AD Evaluation" and "Last Call Requested" > called "Expert Review". At an AD's discretion, before a document is sent > for Last Call: > > An AD sometimes asks for an external review by an outside party as > part of evaluating whether a document is ready for advancement. > MIBs, for example, are reviewed by the "MIB doctors". Other types of > reviews may also be requested (e.g., security, operations impact, > etc.). Documents stay in this state until the review is complete and > possibly until the issues raised in the review are addressed. See > the "note" field for specific details on the nature of the review. > > Moving a document out of Last Call back to AD Evaluation to send it for > Expert Review, and blocking on that state until such review is complete, > is and has been standard operating procedure for a long time. I see no > independent authority being added here that overrides the discretion of > the responsible AD. > > > That seems to me to require discussion. > > I disagree. > > pr > > -- > Pete Resnick http://www.episteme.net/ > All connections to the world are tenuous at best > --000000000000cb459e057c3ac16e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy Pete,


P= lease re-read John's message, which includes this:

=
" It was described as a "directorate" because that
term and organizational arrangement is familiar in the IETF, but
it was quite clear (at least to many of us) that its mission was
to advise, inform, and perhaps even educate the community on
i18n issues, rather than merely advising the ART ADs and/or
designating people to perform reviews late in the Last Call
cycle. "

As I have said multiple times, I hav= e no problem with an AD requesting a review of a specific individual or set= of individuals.=C2=A0 But John's message is highlighting that this gro= up is meant to be something different than the usual directorate. That conc= erns me, especially if it is meant to have a review power beyond "advi= sing the ART ADs", which is what (ART) directorates do.=C2=A0 Soliciti= ng and receiving that advice is the state you're pointing to, and but J= ohn has asserted this is not that.=C2=A0 Given that assertion, I think the = community ought to know and have a voice in what it is instead.

I also am disappointed that the ART ADs did not simply as= k the relevant questions of the people that they would or will put on the D= irectorate, if they are seeking the usual sort of advice.=C2=A0 There is no= power in the advice coming from a directorate rather than Individual 1 or = 2. But that is a timing question, not a process point.

regards,

Ted

On Tue, Dec 4, 2018 at 2:54 PM Pete Resn= ick <resnick@episteme.net>= ; wrote:
On 4 Dec 2018, at 16:02, T= ed Hardie wrote:

> Given that the first suggestion here was that a document could not go =
> through last call until it had been reviewed by the group and John'= ;s
> message seemed to indicate that its authority was not simply to advise=
> an AD, I inferred that the intent was to set up a group with an
> independent authority to foster work or block documents.

Have a look at https://datatracker.ietf.org/help/s= tate/draft/iesg. You
will see a state between "AD Evaluation" and "Last Call Requ= ested"
called "Expert Review". At an AD's discretion, before a docum= ent is sent
for Last Call:

=C2=A0 =C2=A0 An AD sometimes asks for an external review by an outside par= ty as
=C2=A0 =C2=A0 part of evaluating whether a document is ready for advancemen= t.
=C2=A0 =C2=A0 MIBs, for example, are reviewed by the "MIB doctors"= ;. Other types of
=C2=A0 =C2=A0 reviews may also be requested (e.g., security, operations imp= act,
=C2=A0 =C2=A0 etc.). Documents stay in this state until the review is compl= ete and
=C2=A0 =C2=A0 possibly until the issues raised in the review are addressed.= See
=C2=A0 =C2=A0 the "note" field for specific details on the nature= of the review.

Moving a document out of Last Call back to AD Evaluation to send it for Expert Review, and blocking on that state until such review is complete, is and has been standard operating procedure for a long time. I see no
independent authority being added here that overrides the discretion of the responsible AD.

> That seems to me to require discussion.

I disagree.

pr

--
Pete Resnick http://www.episteme.net/
All connections to the world are tenuous at best
--000000000000cb459e057c3ac16e-- From nobody Tue Dec 4 15:54:39 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 04D80130EB5; Tue, 4 Dec 2018 15:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Et9TGWQDUVBu; Tue, 4 Dec 2018 15:54:35 -0800 (PST) Received: from episteme.net (episteme.net [216.169.5.102]) by ietfa.amsl.com (Postfix) with ESMTP id 42CD4130DCA; Tue, 4 Dec 2018 15:54:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id B2F476F63815; Tue, 4 Dec 2018 17:54:31 -0600 (CST) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgUEOetAFoFo; Tue, 4 Dec 2018 17:54:30 -0600 (CST) Received: from [172.16.1.76] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 1D4266F6380A; Tue, 4 Dec 2018 17:54:30 -0600 (CST) From: "Pete Resnick" To: "Ted Hardie" Cc: "Ben Campbell" , "John C Klensin" , i18n-discuss@iab.org, idna-update@ietf.org, ima@ietf.org, precis@ietf.org Date: Tue, 04 Dec 2018 17:54:29 -0600 X-Mailer: MailMate (1.12.2r5568) Message-ID: In-Reply-To: References: <3079F05172A384D8987A2338@PSB> <8458F480-52CB-4DD4-9C52-6ED9F2860DFD@nostrum.com> <680E50F3-3881-416F-A11A-22563F44A732@episteme.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_1E74A519-BCED-4CDD-A757-E489F427815B_=" Archived-At: Subject: Re: [Idna-update] [precis] [I18n-discuss] draft-faltstrom-unicode11, i18n "directorate", and related issues 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, 04 Dec 2018 23:54:37 -0000 --=_MailMate_1E74A519-BCED-4CDD-A757-E489F427815B_= Content-Type: text/plain; format=flowed Trimming a bit: On 4 Dec 2018, at 17:37, Ted Hardie wrote: > Howdy Pete, > > > Please re-read John's message, which includes this: > > "its mission was > to advise, inform, and perhaps even educate the community on > i18n issues, rather than merely advising the ART ADs and/or > designating people to perform reviews late in the Last Call > cycle. " > > As I have said multiple times, I have no problem with an AD requesting > a > review of a specific individual or set of individuals. But John's > message > is highlighting that this group is meant to be something different > than the > usual directorate. Certainly to some small extent all of the directorates "advise, inform, and perhaps even educate the community", as each is willing to do early reviews, and some of the advisory groups (like the assorted "Doctors") will help a WG when directly solicited by the WG. The fact that those duties get a more formal mention in the mission of the i18n directorate doesn't give me pause. But what I was responding to was this part of your earlier message: >> On 4 Dec 2018, at 16:02, Ted Hardie wrote: >> >>> ...I inferred that the intent was to set up a group with an >>> independent authority to foster work or block documents. Like Ben, I see nothing in John's words (or any of the discussions of the directorate) that indicate any power to "block documents", let alone some other sort of special "independent authority" (beyond what we already have experience with). And that seems the real basis for your objection. I think perhaps you're tilting at a windmill. > That concerns me, especially if it is meant to have a > review power beyond "advising the ART ADs", which is what (ART) > directorates do. Soliciting and receiving that advice is the state > you're > pointing to, and but John has asserted this is not that. John has asserted that it is not *only* that. But the only thing that it appears to be beyond that is a group that can, as John said, "advise, inform, and perhaps even educate the community". > Given that > assertion, I think the community ought to know and have a voice in > what it > is instead. If it had any additional authority, I would agree. It does not appear to, and therefore I do not. > I also am disappointed that the ART ADs did not simply ask the > relevant > questions of the people that they would or will put on the > Directorate, if > they are seeking the usual sort of advice. There is no power in the > advice > coming from a directorate rather than Individual 1 or 2. But that is a > timing question, not a process point. There is no power, but often there is more organization. That seems like a legitimate reason for the pause. pr -- Pete Resnick http://www.episteme.net/ All connections to the world are tenuous at best --=_MailMate_1E74A519-BCED-4CDD-A757-E489F427815B_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Trimming a bit:

On 4 Dec 2018, at 17:37, Ted Hardie wrote:

H= owdy Pete,


Please re-read John's message, which includes this:

"its mission was
to advise, inform, and perhaps even educate the community on
i18n issues, rather than merely advising the ART ADs and/or
designating people to perform reviews late in the Last Call
cycle. "

As I have said multiple times, I have no problem with an AD requesting a<= br> review of a specific individual or set of individuals. But John's messag= e
is highlighting that this group is meant to be something different than t= he
usual directorate.

Certainly to some small extent all of the directorates "a= dvise, inform, and perhaps even educate the community", as each is willin= g to do early reviews, and some of the advisory groups (like the assorted= "Doctors") will help a WG when directly solicited by the WG. The fact th= at those duties get a more formal mention in the mission of the i18n dire= ctorate doesn't give me pause. But what I was responding to was this part= of your earlier message:

On 4 Dec 2018, at 16:02, Ted= Hardie wrote:

...I inferr= ed that the intent was to set up a group with an
independent authority to foster work or block documents.

Like Ben, I see nothing in John's words (or any of the di= scussions of the directorate) that indicate any power to "block documents= ", let alone some other sort of special "independent authority" (beyond w= hat we already have experience with). And that seems the real basis for y= our objection. I think perhaps you're tilting at a windmill.

T= hat concerns me, especially if it is meant to have a
review power beyond "advising the ART ADs", which is what (ART)
directorates do. Soliciting and receiving that advice is the state you'r= e
pointing to, and but John has asserted this is not that.

John has asserted that it is not only that. But = the only thing that it appears to be beyond that is a group that can, as = John said, "advise, inform, and perhaps even educate the community".

G= iven that
assertion, I think the community ought to know and have a voice in what i= t
is instead.

If it had any additional authority, I would agree. It doe= s not appear to, and therefore I do not.

I= also am disappointed that the ART ADs did not simply ask the relevant questions of the people that they would or will put on the Directorate, i= f
they are seeking the usual sort of advice. There is no power in the advi= ce
coming from a directorate rather than Individual 1 or 2. But that is a timing question, not a process point.

There is no power, but often there is more organization. = That seems like a legitimate reason for the pause.

pr

--
Pete Resnick http://www.episteme.net/
All connections to the world are tenuous at best

--=_MailMate_1E74A519-BCED-4CDD-A757-E489F427815B_=-- From nobody Tue Dec 4 16:09:04 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 0742A130DCA for ; Tue, 4 Dec 2018 16:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjNm3nNeRWIV for ; Tue, 4 Dec 2018 16:08:58 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 6E1FC1200B3 for ; Tue, 4 Dec 2018 16:08:58 -0800 (PST) Received: from [10.0.1.24] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wB508uiE064761 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 4 Dec 2018 18:08:57 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.24] From: Ben Campbell Message-Id: <921E77FB-64DA-4A09-95BB-7307099F0B43@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_33D2BA77-35E5-468C-A032-377297E070FE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Tue, 4 Dec 2018 18:08:56 -0600 In-Reply-To: Cc: Ted Hardie , John C Klensin , i18n-discuss@iab.org, idna-update@ietf.org, ima@ietf.org, precis@ietf.org To: Pete Resnick References: <3079F05172A384D8987A2338@PSB> <8458F480-52CB-4DD4-9C52-6ED9F2860DFD@nostrum.com> <680E50F3-3881-416F-A11A-22563F44A732@episteme.net> X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [Idna-update] [precis] [I18n-discuss] draft-faltstrom-unicode11, i18n "directorate", and related issues 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, 05 Dec 2018 00:09:01 -0000 --Apple-Mail=_33D2BA77-35E5-468C-A032-377297E070FE Content-Type: multipart/alternative; boundary="Apple-Mail=_EEABB0CA-7322-408A-91DA-6057B406AC69" --Apple-Mail=_EEABB0CA-7322-408A-91DA-6057B406AC69 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Responding to a couple of points, inline: > On Dec 4, 2018, at 5:54 PM, Pete Resnick wrote: >=20 > Trimming a bit: >=20 > On 4 Dec 2018, at 17:37, Ted Hardie wrote: >=20 > Howdy Pete, >=20 >=20 > Please re-read John's message, which includes this: >=20 > "its mission was > to advise, inform, and perhaps even educate the community on > i18n issues, rather than merely advising the ART ADs and/or > designating people to perform reviews late in the Last Call > cycle. " >=20 > As I have said multiple times, I have no problem with an AD requesting = a > review of a specific individual or set of individuals. But John's = message > is highlighting that this group is meant to be something different = than the > usual directorate. >=20 > Certainly to some small extent all of the directorates "advise, = inform, and perhaps even educate the community", as each is willing to = do early reviews, and some of the advisory groups (like the assorted = "Doctors") will help a WG when directly solicited by the WG. The fact = that those duties get a more formal mention in the mission of the i18n = directorate doesn't give me pause. But what I was responding to was this = part of your earlier message: >=20 > On 4 Dec 2018, at 16:02, Ted Hardie wrote: >=20 > ...I inferred that the intent was to set up a group with an > independent authority to foster work or block documents. >=20 > Like Ben, I see nothing in John's words (or any of the discussions of = the directorate) that indicate any power to "block documents", let alone = some other sort of special "independent authority" (beyond what we = already have experience with). And that seems the real basis for your = objection. I think perhaps you're tilting at a windmill >=20 >=20 As an ART AD, my expectation is that the directorates only power to = block documents would be to convince a (typically ART) AD to do so. > That concerns me, especially if it is meant to have a > review power beyond "advising the ART ADs", which is what (ART) > directorates do. Soliciting and receiving that advice is the state = you're > pointing to, and but John has asserted this is not that. >=20 > John has asserted that it is not only that. But the only thing that it = appears to be beyond that is a group that can, as John said, "advise, = inform, and perhaps even educate the community". >=20 > Given that > assertion, I think the community ought to know and have a voice in = what it > is instead. >=20 > If it had any additional authority, I would agree. It does not appear = to, and therefore I do not. >=20 > I also am disappointed that the ART ADs did not simply ask the = relevant > questions of the people that they would or will put on the = Directorate, if > they are seeking the usual sort of advice. There is no power in the = advice > coming from a directorate rather than Individual 1 or 2. But that is a > timing question, not a process point. >=20 > There is no power, but often there is more organization. That seems = like a legitimate reason for the pause. >=20 At the risk of putting words into Alexey=E2=80=99s mouth, I think this = was an exceptional case due to the fact that the directorate creation = was imminent, but perhaps not so imminent that it could finish it=E2=80=99= s first review before the LC ended. It was Alexey=E2=80=99s choice to = stop the LC, but he might have chosen the same even if he just asked an = individual to do an expert review. Thanks! Ben. --Apple-Mail=_EEABB0CA-7322-408A-91DA-6057B406AC69 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Responding to a couple of points, inline:

On Dec 4, 2018, at 5:54 PM, Pete Resnick <resnick@episteme.net> wrote:

Trimming a bit:

On 4 Dec 2018, = at 17:37, Ted Hardie wrote:

Howdy Pete,


Please re-read John's message, which includes this:

"its mission was
to advise, inform, and perhaps even educate the community on
i18n issues, rather than merely advising the ART ADs and/or
= designating people to perform reviews late in the Last Call
= cycle. "

As I have said multiple times, I have no problem with an AD requesting = a
review of a specific individual or set of individuals. But John's = message
is highlighting that this group is meant to be something different than = the
usual directorate.

Certainly to some small extent all of the directorates = "advise, inform, and perhaps even educate the community", as each is = willing to do early reviews, and some of the advisory groups (like the = assorted "Doctors") will help a WG when directly solicited by the WG. = The fact that those duties get a more formal mention in the mission of = the i18n directorate doesn't give me pause. But what I was responding to = was this part of your earlier message:

On 4 Dec = 2018, at 16:02, Ted Hardie wrote:

...I inferred that the intent was to set up a group with = an
independent authority to foster work or block documents.

Like Ben, I see nothing in John's words (or any of the = discussions of the directorate) that indicate any power to "block = documents", let alone some other sort of special "independent authority" = (beyond what we already have experience with). And that seems the real = basis for your objection. I think perhaps you're tilting at a = windmill



As an ART AD, my expectation is that the = directorates only power to block documents  would be to convince a = (typically ART) AD to do so.

That concerns = me, especially if it is meant to have a
review power beyond "advising the ART ADs", which is what (ART)
directorates do. Soliciting and receiving that advice is the state = you're
pointing to, and but John has asserted this is not that.

John has asserted that it is not only = that. But the only thing that it appears to be beyond that is a group = that can, as John said, "advise, inform, and perhaps even educate the = community".

Given that
assertion, I think the community ought to know and have a voice in what = it
is instead.

If= it had any additional authority, I would agree. It does not appear to, = and therefore I do not.

I also am = disappointed that the ART ADs did not simply ask the relevant
questions of the people that they would or will put on the Directorate, = if
they are seeking the usual sort of advice. There is no power in the = advice
coming from a directorate rather than Individual 1 or 2. But that is = a
timing question, not a process point.

There is no power, but often there is more organization. That = seems like a legitimate reason for the = pause.

At the risk of putting = words into Alexey=E2=80=99s mouth, I think this was an exceptional case = due to the fact that the directorate creation was imminent, but perhaps = not so imminent that it could finish it=E2=80=99s first review before = the LC ended. It was Alexey=E2=80=99s choice to stop the LC, but he = might have chosen the same even if he just asked an individual to do an = expert review.

Thanks!

Ben.
= --Apple-Mail=_EEABB0CA-7322-408A-91DA-6057B406AC69-- --Apple-Mail=_33D2BA77-35E5-468C-A032-377297E070FE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlwHFxgACgkQgFZKbJXz 1A0xoA/+I78Me88vhuz1r6NsPNDDEf73VWVsv4Ou0rBKvWTrHw1n9xBJyWSRfzYl /N04p0B09hdOCCSagkRuJjvv/iX9iriVLe64aHiVpGd3JyYoEZUUMc6SKuyj2my0 PKaIBkDh7COB/Bhzdn/XOghKO4oujOcBmDfu/fTayauvioxz3SgjF6Qka3GTZAE2 BvaUcZP1umMjHdroIJJEb2UgowV+y2pFdSrgkYJdhOdqvNDqQvkl+BiN46fWhC/f GkyRHIpLBkmG8HHuTrVxBGE2f0m2Ubv9ijYx1IEnpk8srIDQMTIqUQY2zZpTspwZ dgZ7kM9kq+2Dje9rNencjNRlBzg4iZ6/lWb/udtjDbiMj/QairSZPUbsPROWisTU dNV0a9djLoBLBBFKYypn5k5jNI0QwqrCucEymOjCzYUIz1T8nxqWJPmuggeRiJe+ 4wVpPfbkdrZixA8K6tNglIHzJGpK/B4bjRm5sNSAFZH/IOgynlUVqd/O19Au9bfr yGQNzvQcRGAecXsSo3PU/s4iGcL/qUjzP/hMwI6RWgYDerG+ergGjXJ6CI/qMKwS qbOkKSUL4r9C/zm/J8YbC07ZotqNWs+acqvb9GkmKvUW14Csblyy8j63eoUrNLtz R8C3bBUyowbPiiDFe9EgyzKt1hpol+R+Yj6PxCu1VRIeS1muKAw= =Ewlz -----END PGP SIGNATURE----- --Apple-Mail=_33D2BA77-35E5-468C-A032-377297E070FE-- From nobody Tue Dec 4 16:21: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 806BA1200B3 for ; Tue, 4 Dec 2018 16:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.958 X-Spam-Level: X-Spam-Status: No, score=-18.958 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 sKXroSCpaEmU for ; Tue, 4 Dec 2018 16:21:15 -0800 (PST) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (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 4425E130DCA for ; Tue, 4 Dec 2018 16:21:13 -0800 (PST) Received: by mail-oi1-x233.google.com with SMTP id b141so15990981oii.12 for ; Tue, 04 Dec 2018 16:21:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iNVTkff7PLY1nSLCsnaxYPwZXpoln1dmdzlYwDWdBEQ=; b=hjuUnKPpKlZY5ZIAojf8hR6S/1cqmTKHUGWloYufVMgp1x0oslLX3Jc4vi6fiwO9oJ Wx4cH73TDXrgP+Gu3KrL6kKqf+x6bJ+2OLHhhSwXZI49knXVd2Vs5CxDmNUhurYoqoNx /gtWQJBe3FDqpSS9AYV/qJXQizeDhCaqMx/nWXbhArwscruYi4rjgYbzvMw0xK3QUFC9 0glYRBc3+verqQRxjvJIz7qHW7SL4T7qIuUnvyOQR8BLoxE7RRf1VlZTYAtj8LYX+pjZ 1wxVyC+Mz6owYj0/tFC00ycmM5Gt9ngVZBrfS0sE9nLeefcJh8ILiIl8ZId+tAYciiPJ v8uQ== 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=iNVTkff7PLY1nSLCsnaxYPwZXpoln1dmdzlYwDWdBEQ=; b=flm65IxG5aQ7GXgUsM5xgW8QMZikR1Bz+FrD7IZSq2t/9RuiB3rIoguPp5+MB+6fH/ sssxomMpRl3nYKffHgwiS7tU+YTIky9H+xGysPPmnlFohDu2cSadsvlJH3AnvtaK9NWP 9iFeOlee15w1QJ3SqlaBRUkrMQ4Mt/BgHb4ydIilfHwsDHiltT04YSvzEIfS66t9X+y/ S+C5/S7W3uyr4tg5tst4TuLiQC5zz6lubMv2GLNc4N1a2AC3AUfCYkqkZXFMhVrCcTZ3 av5IUZUvy+EA8rJeJMpU4KiRZvxz1Tu+7NuMwmU0B2yTkTSfwikxk1VOFFhH4VvIW3jb ggPA== X-Gm-Message-State: AA+aEWYgI2SBnurVIfiejET4YwwdF/kv7Zkhl6QPv+kVTCfTe7gEZPez zoJPg/g1pi3Q7ImbrwBgTyWbuAeeCydtMSbSYjisIg== X-Google-Smtp-Source: AFSGD/X+WP66+ooFIZnE05Og5hnHFHuaQYFTRfkrZGDn5A3JPneH0SIZuSDjyBehUbaHLc/CsE0cT3Ysv01sWvVaxF4= X-Received: by 2002:aca:adcd:: with SMTP id w196mr14256701oie.353.1543969272229; Tue, 04 Dec 2018 16:21:12 -0800 (PST) MIME-Version: 1.0 References: <3079F05172A384D8987A2338@PSB> <8458F480-52CB-4DD4-9C52-6ED9F2860DFD@nostrum.com> <680E50F3-3881-416F-A11A-22563F44A732@episteme.net> <921E77FB-64DA-4A09-95BB-7307099F0B43@nostrum.com> In-Reply-To: <921E77FB-64DA-4A09-95BB-7307099F0B43@nostrum.com> From: Vint Cerf Date: Tue, 4 Dec 2018 19:21:01 -0500 Message-ID: To: ben@nostrum.com Cc: resnick@episteme.net, Ted Hardie , i18n-discuss@iab.org, precis@ietf.org, ima@ietf.org, John C Klensin , idna-update@ietf.org Content-Type: multipart/alternative; boundary="0000000000000497ab057c3b5cb0" Archived-At: Subject: Re: [Idna-update] [precis] [I18n-discuss] draft-faltstrom-unicode11, i18n "directorate", and related issues 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, 05 Dec 2018 00:21:17 -0000 --0000000000000497ab057c3b5cb0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable suggestion: set up the advisory group and allow it to offer advice to the appropriate AD. This same advisory group can reasonably share its findings more generally, thereby "educating...." the rest of the community. No power to block should either explicitly or implicitly be inferred by the creation of the advisory body. vint On Tue, Dec 4, 2018 at 7:09 PM Ben Campbell wrote: > Responding to a couple of points, inline: > > On Dec 4, 2018, at 5:54 PM, Pete Resnick wrote: > > Trimming a bit: > > On 4 Dec 2018, at 17:37, Ted Hardie wrote: > > Howdy Pete, > > > Please re-read John's message, which includes this: > > "its mission was > to advise, inform, and perhaps even educate the community on > i18n issues, rather than merely advising the ART ADs and/or > designating people to perform reviews late in the Last Call > cycle. " > > As I have said multiple times, I have no problem with an AD requesting a > review of a specific individual or set of individuals. But John's message > is highlighting that this group is meant to be something different than t= he > usual directorate. > > Certainly to some small extent all of the directorates "advise, inform, > and perhaps even educate the community", as each is willing to do early > reviews, and some of the advisory groups (like the assorted "Doctors") wi= ll > help a WG when directly solicited by the WG. The fact that those duties g= et > a more formal mention in the mission of the i18n directorate doesn't give > me pause. But what I was responding to was this part of your earlier > message: > > On 4 Dec 2018, at 16:02, Ted Hardie wrote: > > ...I inferred that the intent was to set up a group with an > independent authority to foster work or block documents. > > Like Ben, I see nothing in John's words (or any of the discussions of the > directorate) that indicate any power to "block documents", let alone some > other sort of special "independent authority" (beyond what we already hav= e > experience with). And that seems the real basis for your objection. I thi= nk > perhaps you're tilting at a windmill > > > As an ART AD, my expectation is that the directorates only power to block > documents would be to convince a (typically ART) AD to do so. > > That concerns me, especially if it is meant to have a > review power beyond "advising the ART ADs", which is what (ART) > directorates do. Soliciting and receiving that advice is the state you're > pointing to, and but John has asserted this is not that. > > John has asserted that it is not *only* that. But the only thing that it > appears to be beyond that is a group that can, as John said, "advise, > inform, and perhaps even educate the community". > > Given that > assertion, I think the community ought to know and have a voice in what i= t > is instead. > > If it had any additional authority, I would agree. It does not appear to, > and therefore I do not. > > I also am disappointed that the ART ADs did not simply ask the relevant > questions of the people that they would or will put on the Directorate, i= f > they are seeking the usual sort of advice. There is no power in the advic= e > coming from a directorate rather than Individual 1 or 2. But that is a > timing question, not a process point. > > There is no power, but often there is more organization. That seems like = a > legitimate reason for the pause. > > At the risk of putting words into Alexey=E2=80=99s mouth, I think this wa= s an > exceptional case due to the fact that the directorate creation was > imminent, but perhaps not so imminent that it could finish it=E2=80=99s f= irst > review before the LC ended. It was Alexey=E2=80=99s choice to stop the LC= , but he > might have chosen the same even if he just asked an individual to do an > expert review. > > Thanks! > > Ben. > _______________________________________________ > IDNA-UPDATE mailing list > IDNA-UPDATE@ietf.org > https://www.ietf.org/mailman/listinfo/idna-update > --=20 New postal address: Google 1875 Explorer Street, 10th Floor Reston, VA 20190 --0000000000000497ab057c3b5cb0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
suggestion:

set up the advisory group a= nd allow it to offer advice to the appropriate AD.
This same advi= sory group can reasonably share its findings more generally,
ther= eby "educating...." the rest of the community. No power to block = should
either explicitly or implicitly be inferred by the creatio= n of the advisory body.

vint

<= /div>
On Tue, Dec 4, 2018 at= 7:09 PM Ben Campbell <ben@nostrum.co= m> wrote:
Responding to a couple of po= ints, inline:

On Dec 4, 2018, at= 5:54 PM, Pete Resnick <resnick@episteme.net> wrote:

Trimming a bit:

On 4 Dec 2018, at 17:37, Te= d Hardie wrote:

Howdy Pe= te,


Please re-read John's message, which includes this:

"its mission was
to advise, inform, and perhaps even educate the community on
i18n issues, rather than merely advising the ART ADs and/or
designating people to perform reviews late in the Last Call
cycle. "

As I have said multiple times, I have no problem with an AD requesting a review of a specific individual or set of individuals. But John's mess= age
is highlighting that this group is meant to be something different than the=
usual directorate.

Certainly to some small e= xtent all of the directorates "advise, inform, and perhaps even educat= e the community", as each is willing to do early reviews, and some of = the advisory groups (like the assorted "Doctors") will help a WG = when directly solicited by the WG. The fact that those duties get a more fo= rmal mention in the mission of the i18n directorate doesn't give me pau= se. But what I was responding to was this part of your earlier message:

On 4 Dec 2018, at 16:02, Ted Hardie wrote:<= br>

...I inferred that = the intent was to set up a group with an
independent authority to foster work or block documents.

Like Ben, I see nothing i= n John's words (or any of the discussions of the directorate) that indi= cate any power to "block documents", let alone some other sort of= special "independent authority" (beyond what we already have exp= erience with). And that seems the real basis for your objection. I think pe= rhaps you're tilting at a windmill


=

As an ART AD, my expectation is that= the directorates only power to block documents =C2=A0would be to convince = a (typically ART) AD to do so.

That con= cerns me, especially if it is meant to have a
review power beyond "advising the ART ADs", which is what (ART) directorates do. Soliciting and receiving that advice is the state you'= ;re
pointing to, and but John has asserted this is not that.

John has asserted that it= is not only that. But the only thing that it appears to be beyond= that is a group that can, as John said, "advise, inform, and perhaps = even educate the community".

Given th= at
assertion, I think the community ought to know and have a voice in what it<= br> is instead.

If it had any additional = authority, I would agree. It does not appear to, and therefore I do not.

I also a= m disappointed that the ART ADs did not simply ask the relevant
questions of the people that they would or will put on the Directorate, if<= br> they are seeking the usual sort of advice. There is no power in the advice=
coming from a directorate rather than Individual 1 or 2. But that is a
timing question, not a process point.

There is no power, but of= ten there is more organization. That seems like a legitimate reason for the= pause.

At the risk of putting word= s into Alexey=E2=80=99s mouth, I think this was an exceptional case due to = the fact that the directorate creation was imminent, but perhaps not so imm= inent that it could finish it=E2=80=99s first review before the LC ended. I= t was Alexey=E2=80=99s choice to stop the LC, but he might have chosen the = same even if he just asked an individual to do an expert review.
=
Thanks!

Ben.
___________= ____________________________________
IDNA-UPDATE mailing list
IDNA-UPDATE@ietf.= org
https://www.ietf.org/mailman/listinfo/idna-update


--
New postal address:
Google
1875 Explorer Street, 10th Floor=
Reston, VA 20190
--0000000000000497ab057c3b5cb0-- From nobody Tue Dec 4 17:49:13 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2F8130E18 for ; Tue, 4 Dec 2018 17:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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 (1024-bit key) header.d=xgenplus.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 9mKpCHO6BIpk for ; Tue, 4 Dec 2018 17:49:04 -0800 (PST) Received: from a.tbms.in (a.tbms.in [202.157.95.34]) by ietfa.amsl.com (Postfix) with ESMTP id 62D07130DD2 for ; Tue, 4 Dec 2018 17:49:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; q=dns/txt; c=simple/relaxed; t=1543974541; s=xgen; d=xgenplus.com; h=In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:From:Date:Message-ID; z=In-Reply-To:|References:<3079F05172A384D8987A2338@PSB>=20=20<8458F480-52CB-4DD4-9C52-6ED9F2860DFD@nostrum.= com>=20=20<= 680E50F3-3881-416F-A11A-22563F44A732@episteme.net>=20=20=20<921E77FB-64DA-4A09-95BB-7307099F0B43@nostrum.com>=20|MIME-Version:1.0|Content-Transfer-Encoding:7bit|From:Ajay=20Data=20|Date:Wed,=2005=20Dec=202018=2006:51:42=20+0530|Message-ID:<1962619927.9846101543974541939.JavaMail.root@mx2.datainfosys.com>; l=13176; bh=4TMgy2f5+shTJkPBpmI1qYcN5CI=; b=VqfaCOIRghh8bjjQEunIHKitzFhosH/9y99q60dn5XYakoWo/8yyM43fbYnO1UzT VyrQ+o9GynJVinRU5n16VTPN/DmSVm6ET6pr5g3Kk/t6txoV3wB6LTi9SdA0TGr1F3J yWLUa24HIHobIy7myoHCX5sdkD6xlUJY3YXco5n4= Received: From 202.157.83.44[202.157.83.44] by [202.157.83.51] [mx2.datainfosys.com] [mta] with SMTP id ../InBoxS/20181205/06/98427.83364751653(1543973007801); Wed, 5 Dec 2018 01:23:27 +0000 Received: From 202.157.87.20[202.157.87.20] by [202.157.87.20] [DataMailApp-2] [mta] with SMTP id 51620.455814962115(1543973007710); Wed, 5 Dec 2018 01:23:27 +0000 Received: From[9c365f6ade93d2ec480c9a39a918d5eb] [223.189.167.235] with SMTP id 93692.67697678864(1543972967559); Wed, 5 Dec 2018 01:22:47 +0000 User-Agent: XGenPlus for Android X-Mailer: XGenPlus App Ver 1.70 X_Xgen_Delivery_Report: yes X_Xgen_Device_Id: 352016090237397 In-Reply-To: References: <3079F05172A384D8987A2338@PSB> <8458F480-52CB-4DD4-9C52-6ED9F2860DFD@nostrum.com> <680E50F3-3881-416F-A11A-22563F44A732@episteme.net> <921E77FB-64DA-4A09-95BB-7307099F0B43@nostrum.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----491R58XUK1P3JJ108BMQYD10CJUCPA" Content-Transfer-Encoding: 7bit From: Ajay Data Date: Wed, 05 Dec 2018 06:51:42 +0530 To: vint=40google.com@dmarc.ietf.org,ben@nostrum.com CC: ted.ietf@gmail.com, i18n-discuss@iab.org, precis@ietf.org, ima@ietf.org, idna-update@ietf.org, resnick@episteme.net Message-ID: <1962619927.9846101543974541939.JavaMail.root@mx2.datainfosys.com> Archived-At: Subject: Re: [Idna-update] [EAI] [precis] [I18n-discuss] draft-faltstrom-unicode11, i18n "directorate", and related issues 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, 05 Dec 2018 01:49:07 -0000 ------491R58XUK1P3JJ108BMQYD10CJUCPA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 On 5 December 2018 05:51:01 GMT+05:30, Vint Cerf wrote: >suggestion: > >set up the advisory group and allow it to offer advice to the >appropriate >AD=2E >This same advisory group can reasonably share its findings more >generally, >thereby "educating=2E=2E=2E=2E" the rest of the community=2E No power to = block >should >either explicitly or implicitly be inferred by the creation of the >advisory >body=2E > >vint > > >On Tue, Dec 4, 2018 at 7:09 PM Ben Campbell wrote: > >> Responding to a couple of points, inline: >> >> On Dec 4, 2018, at 5:54 PM, Pete Resnick >wrote: >> >> Trimming a bit: >> >> On 4 Dec 2018, at 17:37, Ted Hardie wrote: >> >> Howdy Pete, >> >> >> Please re-read John's message, which includes this: >> >> "its mission was >> to advise, inform, and perhaps even educate the community on >> i18n issues, rather than merely advising the ART ADs and/or >> designating people to perform reviews late in the Last Call >> cycle=2E " >> >> As I have said multiple times, I have no problem with an AD >requesting a >> review of a specific individual or set of individuals=2E But John's >message >> is highlighting that this group is meant to be something different >than the >> usual directorate=2E >> >> Certainly to some small extent all of the directorates "advise, >inform, >> and perhaps even educate the community", as each is willing to do >early >> reviews, and some of the advisory groups (like the assorted >"Doctors") will >> help a WG when directly solicited by the WG=2E The fact that those >duties get >> a more formal mention in the mission of the i18n directorate doesn't >give >> me pause=2E But what I was responding to was this part of your earlier >> message: >> >> On 4 Dec 2018, at 16:02, Ted Hardie wrote: >> >> =2E=2E=2EI inferred that the intent was to set up a group with an >> independent authority to foster work or block documents=2E >> >> Like Ben, I see nothing in John's words (or any of the discussions of >the >> directorate) that indicate any power to "block documents", let alone >some >> other sort of special "independent authority" (beyond what we already >have >> experience with)=2E And that seems the real basis for your objection=2E= I >think >> perhaps you're tilting at a windmill >> >> >> As an ART AD, my expectation is that the directorates only power to >block >> documents would be to convince a (typically ART) AD to do so=2E >> >> That concerns me, especially if it is meant to have a >> review power beyond "advising the ART ADs", which is what (ART) >> directorates do=2E Soliciting and receiving that advice is the state >you're >> pointing to, and but John has asserted this is not that=2E >> >> John has asserted that it is not *only* that=2E But the only thing that >it >> appears to be beyond that is a group that can, as John said, "advise, >> inform, and perhaps even educate the community"=2E >> >> Given that >> assertion, I think the community ought to know and have a voice in >what it >> is instead=2E >> >> If it had any additional authority, I would agree=2E It does not appear >to, >> and therefore I do not=2E >> >> I also am disappointed that the ART ADs did not simply ask the >relevant >> questions of the people that they would or will put on the >Directorate, if >> they are seeking the usual sort of advice=2E There is no power in the >advice >> coming from a directorate rather than Individual 1 or 2=2E But that is >a >> timing question, not a process point=2E >> >> There is no power, but often there is more organization=2E That seems >like a >> legitimate reason for the pause=2E >> >> At the risk of putting words into Alexey=E2=80=99s mouth, I think this = was an >> exceptional case due to the fact that the directorate creation was >> imminent, but perhaps not so imminent that it could finish it=E2=80=99s= first >> review before the LC ended=2E It was Alexey=E2=80=99s choice to stop th= e LC, >but he >> might have chosen the same even if he just asked an individual to do >an >> expert review=2E >> >> Thanks! >> >> Ben=2E >> _______________________________________________ >> IDNA-UPDATE mailing list >> IDNA-UPDATE@ietf=2Eorg >> https://www=2Eietf=2Eorg/mailman/listinfo/idna-update >> > > >--=20 >New postal address: >Google >1875 Explorer Street, 10th Floor >Reston, VA 20190 > > >------------------------------------------------------------------------ > >_______________________________________________ >IMA mailing list >IMA@ietf=2Eorg >https://www=2Eietf=2Eorg/mailman/listinfo/ima --=20 Sent from my Android device with XGenPlus=2E ------491R58XUK1P3JJ108BMQYD10CJUCPA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1

On 5 December= 2018 05:51:01 GMT+05:30, Vint Cerf <vint=3D40google=2Ecom@dmarc=2Eietf=2Eorg> wrote:
suggestion:

set up the advisory grou= p and allow it to offer advice to the appropriate AD=2E
This same= advisory group can reasonably share its findings more generally,
thereby "educating=2E=2E=2E=2E" the rest of the community=2E No = power to block should
either explicitly or implicitly be inferred= by the creation of the advisory body=2E

vint


On Tue, Dec 4, 2018 at 7:09 PM Ben Campbell <ben@nostrum=2Ecom> wrote:
Responding to a couple of points, inline:

On Dec 4, 2018, at 5:54 PM, Pete Resnick <resnick@episteme=2Enet&g= t; wrote:

Trimming a bit:

On 4 Dec 2018, at 17:37, T= ed Hardie wrote:

Howdy P= ete,


Please re-read John's message, which includes this:

"its mission was
to advise, inform, and perhaps even educate the community on
i18n issues, rather than merely advising the ART ADs and/or
designating people to perform reviews late in the Last Call
cycle=2E "

As I have said multiple times, I have no problem with an AD requesting a review of a specific individual or set of individuals=2E But John's m= essage
is highlighting that this group is meant to be something different than th= e
usual directorate=2E

Certainly to some small = extent all of the directorates "advise, inform, and perhaps even educa= te the community", as each is willing to do early reviews, and some of= the advisory groups (like the assorted "Doctors") will help a WG= when directly solicited by the WG=2E The fact that those duties get a more= formal mention in the mission of the i18n directorate doesn't give me = pause=2E But what I was responding to was this part of your earlier message= :

On 4 Dec 2018, at 16:02, Ted Hardie wrote:=

=2E=2E=2EI inferre= d that the intent was to set up a group with an
independent authority to foster work or block documents=2E

Like Ben, I see nothing = in John's words (or any of the discussions of the directorate) that ind= icate any power to "block documents", let alone some other sort o= f special "independent authority" (beyond what we already have ex= perience with)=2E And that seems the real basis for your objection=2E I thi= nk perhaps you're tilting at a windmill



As an ART AD, my expectatio= n is that the directorates only power to block documents =C2=A0would be to = convince a (typically ART) AD to do so=2E

That co= ncerns me, especially if it is meant to have a
review power beyond "advising the ART ADs", which is what (ART)<= br /> directorates do=2E Soliciting and receiving that advice is the state you&= #39;re
pointing to, and but John has asserted this is not that=2E

John has asserted that i= t is not only that=2E But the only thing that it appears to be bey= ond that is a group that can, as John said, "advise, inform, and perha= ps even educate the community"=2E

Given t= hat
assertion, I think the community ought to know and have a voice in what it=
is instead=2E

If it had any additional= authority, I would agree=2E It does not appear to, and therefore I do not= =2E

I also = am disappointed that the ART ADs did not simply ask the relevant
questions of the people that they would or will put on the Directorate, if=
they are seeking the usual sort of advice=2E There is no power in the adv= ice
coming from a directorate rather than Individual 1 or 2=2E But that is a timing question, not a process point=2E

There is no power, but o= ften there is more organization=2E That seems like a legitimate reason for = the pause=2E

At the risk of putting= words into Alexey=E2=80=99s mouth, I think this was an exceptional case du= e to the fact that the directorate creation was imminent, but perhaps not s= o imminent that it could finish it=E2=80=99s first review before the LC end= ed=2E It was Alexey=E2=80=99s choice to stop the LC, but he might have chos= en the same even if he just asked an individual to do an expert review=2E

Thanks!

Ben=2E
_______________________________________________
IDNA-UPDATE mailing list
IDNA-UPDATE@ie= tf=2Eorg
https://www=2Eietf=2Eorg/mailman/listinfo/idna= -update


--
New postal address:
Google
1875 Explorer Street, = 10th Floor
Reston, VA 20190


IMA mailing list
IMA@i=
etf=2Eorg
ht=
tps://www=2Eietf=2Eorg/mailman/listinfo/ima

--
Sent from my Android device with XGenPlus=2E ------491R58XUK1P3JJ108BMQYD10CJUCPA-- From nobody Wed Dec 5 13:03:35 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53044130EEA; Wed, 5 Dec 2018 13:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2DPJ67y6smIY; Wed, 5 Dec 2018 13:03:19 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A1AF130E55; Wed, 5 Dec 2018 13:03:19 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1gUeKA-0004DH-Fp; Wed, 05 Dec 2018 16:03:14 -0500 Date: Wed, 05 Dec 2018 16:03:07 -0500 From: John C Klensin To: Ben Campbell , Ted Hardie , i18nrp@ietf.org cc: i18n-discuss@iab.org, idna-update@ietf.org, ima@ietf.org, precis@ietf.org Message-ID: <39FC1797F4E0305921306004@PSB> In-Reply-To: <8458F480-52CB-4DD4-9C52-6ED9F2860DFD@nostrum.com> References: <3079F05172A384D8987A2338@PSB> <8458F480-52CB-4DD4-9C52-6ED9F2860DFD@nostrum.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Idna-update] [precis] [I18n-discuss] draft-faltstrom-unicode11, i18n "directorate", and related issues 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, 05 Dec 2018 21:03:21 -0000 Ben and others, Sorry... had to be away from the list for a while. I very much appreciate your note and Pete's clarifications. I want to add some observations in the hope that they will be helpful. Apologies for length -- I think it is important to understand the context of the "directorate" idea, in large measure because I believe that the IETF should be trying to solve problems rather than looking for procedural reasons not to (or to avoid important aspects of them). Even while I'm concerned about delays too, I think you and your ART AD colleagues are on the right path there. To go back to basics, when Patrik and I requested the BOF that became I18NRP it was precisely because we saw an unusual and problematic situation. I suppose it could be described in several different ways, but one version is that there seemed to be agreement in principle in the IETF that lowering the barriers to Internet use by people whose preferred languages and writing systems are not English, or even Western European, was important but that the IETF was (or had become) unable to advance work to address that requirement. This affected work directly concerned with what has usually been called internationalization (or i18n) including follow-in efforts for work developed by the IDNABIS, PRECIS, and EAI WGs; extending other protocols to use non-ASCII text or identifiers such as the work on certificates in LAMPS; and maintenance of assorted registries with high confidence that all relevant issues were being addressed. While we could usually get interest in creating new WGs for the first type of work, they tended to run out of energy among people with the right mix of expertise to get the work done before they concluded. The two most recent WGs devoted to the area, PRECIS and EAI, had less than a handful of people actually doing the work of developing and reviewing documents by the time they wound down. Getting good input and reviews for other work often involved people calling in personal favors with friends and colleagues. The net result has been that work has been stalled for several years. In a way, this is not surprising. While almost anyone with familiarity with more than one language (even rather closely-related ones) can understand that there are issues, true experts in the field (actually the multiple fields that bear on the issues) are very rare. The subset of them who are also familiar enough with the protocols that lie in the IETF's mainstream is even smaller, to the point that anyone claiming comprehensive expertise in both may well be suffering from a bad case of not knowing what they don't know. Picking on the people who first made substantive comments on this thread, I don't believe that any of Patrik, Asmus, or myself would claim that our knowledge was so comprehensive that is wasn't necessary to involve others (if I ever appear to do so, a forceful reminder would we welcome). Anyone who generates a proposal or analysis and says that one particular other person has looked at it and therefore it is ok is doing that person, as well as the community, a serious disservice. One thing that is clear is that we can't seek answers and expertise from individuals. We have to find it in diverse teams who talk with each other and explore ideas and proposals with each other. Another problem is that the knowledge and skill sets needed to address the issues are not exactly part of the mainstream of IETF work. We can't expect people who don't have the background for the work to read in quickly. That background is not part of the education of the typical network engineer. I suggest that we might have similar problems if we embarked on work that had significant interactions with power engineering or, for that matter, with the proverbial rocket science. We'd need to find the few people within the normal IETF community who happened to have the relevant background in addition to whatever interests, skills, and background brought them to the IETF. Then we'd need to convince them (and, in most cases, employers, etc.) to participate actively in the work, presumably borrowing time from, or sharing it with, time for rather than whatever brought them to the IETF. They would also have to learn things they didn't know in spite of at least having the background to learn. And, unless they were also expert in the relevant IETF protocol work, we'd need to make them part of team efforts. The BOF was created against that background to see if we could find a way to get un-stuck. It was aware of things that had been tried or suggested in the past and that had not proven helpful, including the IAB's decision to shut down its own I18n Program because it couldn't make it useful. I deliberately stayed out of the discussion of what the "directorate" should be called but, because of the team and educational requirements, it was clear that it would be necessary to either invent an entirely new beast or to have a slightly-odd directorate, slightly-odd review team, slightly-odd working group, or even a slightly-odd area. The ART ADs decided on a directorate, which was fine, although I hope and assume everyone understood (and understands) the team and internal consultation models -- not to form a hard position, but to be as sure as possible that the issues were fully (or at least adequately) understood. There was never any implication of blocking work or somehow functioning outside the system. The IESG (and individual Areas) remain in a position to listen carefully to any advice they get and then go do something else (although there are at least implicit requirements to explain a decision like that to the community). The strong suggestion for "reviews first, then Last Call" are just a pragmatic notion for getting the advice and perspective in front of the community (not just the IESG) that the community needs to perform an evaluation. Not only, as Pete has pointed out, has it never been prohibited by the procedures (and RFC 2028 doesn't even mention directorates), but the basis between the distinction between two-week Last Calls for WG products and four-week Last Calls for everything else is precisely the notion that, in the former case, there has been careful review, analysis, and reporting prior to the Last Call by a systematically-organized and focused expert group within the community. We've never discussed whether outputs of more diffuse "Area WGs" should get the same consideration, but I've noticed that many ADs treat them somewhat differently than WGs specifically organized and chartered around a topic. So I don't see anything unusual going on here other than the ART ADs trying to address issues with making progress and getting effective reviews, insight, and opportunities for community understanding of what is going on when prior attempts have failed. If Ted or others feel a need to make a case that there should instead be a formally-chartered WG to examine and process all proposed documents involving i18n issues, nothing prevents them from making that argument... but I hope they would remember not only that more narrowly-focused i18n-related WGs have come very close to running out of steam and that the process of chartering such a WG would add even more of the delay about which they are presumably objecting. best, john --On Tuesday, December 4, 2018 15:29 -0600 Ben Campbell wrote: > Hi Ted, > > I'd like to understand your objection better. (Please > don't take this as disagreement. Or agreement, for that > matter :-) ) > > How do you see things like "advise", "educate" and > "inform" as being a grant of authority beyond that of a > directorate? Individual participants can and do those things > regularly; so I'm confused as why doing it as part of a > directorate would be different. Do you read those things as > putting the directorate in the approval path? Or are you > concerned such advice would be given greater weight because of > the directorate? From nobody Wed Dec 5 13: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 63C71130E95; Wed, 5 Dec 2018 13:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 lzi70Ib2VLKT; Wed, 5 Dec 2018 13:37:44 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46C9012D4E7; Wed, 5 Dec 2018 13:37:44 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1gUerR-0004Fd-Q3; Wed, 05 Dec 2018 16:37:37 -0500 Date: Wed, 05 Dec 2018 16:37:30 -0500 From: John C Klensin To: Vint Cerf , ben@nostrum.com cc: resnick@episteme.net, Ted Hardie , i18n-discuss@iab.org, precis@ietf.org, ima@ietf.org, idna-update@ietf.org Message-ID: In-Reply-To: References: <3079F05172A384D8987A2338@PSB> <8458F480-52CB-4DD4-9C52-6ED9F2860DFD@nostrum.com> <680E50F3-3881-416F-A11A-22563F44A732@episteme.net> <921E77FB-64DA-4A09-95BB-7307099F0B43@nostrum.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Idna-update] [precis] [I18n-discuss] draft-faltstrom-unicode11, i18n "directorate", and related issues 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, 05 Dec 2018 21:37:47 -0000 But, with two qualifications, that is all that has ever been proposed. Those are: (1) Because the root of the problems in this topic area is (or appears to be) that the IETF community doesn't know nearly as much about the topic as it would in a more ideal world and because i18n work spans traditional and current Areas, I hope the advice would be public rather than delivered in secret to the AD and I would hope that the group would make an extra effort to explain its reasoning in ways that the community (not just the ADs) could understand and learn from. I would hope that the group members would want to do those things and that the relevant AD(s) would insist on them. (I don't think you intended advice delivered in secret and kept that way, but your suggestion could be read that way). I think that is consistent with your interpretation of "educating..." but can be see how that could be interpreted differently, just as my initial suggestion was. (2) Not unlike our "Doctors" model (and consistent with the very informal consultations about some LAMPS documents which I believe were successful), I'd expect WGs and document-developers, including those in other Areas, to want to consult this group for advice and even help with text in documents. I'd hope that could be handled informally, directly, and efficiently, with a focus on getting quality work done. I think it would be very unfortunate if the same sort of procedure-lawyering that has gotten involved in this thread would turn those efforts into requirements for a process that would go something like: (OtherWG (or AD in other Area)): Dear ART ADs, would you please ask the Directorate to review XYZ and help with text. (ART AD to OtherWG): Sure (ART AD to Directorate): Please see this request from OtherWG, deal with it, and tell me. (Directorate to ART AD (because they are expected to advise that AD and no one else): ART AD, we think ABCDE (ART AT to Other WG): Directorate says "we think ABCDE" Possibly followed by additional iterations of this waste of the time of ADs and Directorate members, especially if specific text were asked for and/or suggested. I think that would be seriously dumb and hope my example shows that and why. But it would be consistent with efforts to draw narrow lines around supposed principles such as "the only thing a directorate is allowed to do is to advise ADs in that area). best, john --On Tuesday, December 4, 2018 19:21 -0500 Vint Cerf wrote: > suggestion: > > set up the advisory group and allow it to offer advice to the > appropriate AD. > This same advisory group can reasonably share its findings > more generally, thereby "educating...." the rest of the > community. No power to block should either explicitly or > implicitly be inferred by the creation of the advisory body. From nobody Wed Dec 5 13:47: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 5EC89130DFF; Wed, 5 Dec 2018 13:46:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOPPetMGYXh9; Wed, 5 Dec 2018 13:46:56 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FFB6130E95; Wed, 5 Dec 2018 13:46:56 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1gUf0O-0004GM-Nd; Wed, 05 Dec 2018 16:46:52 -0500 Date: Wed, 05 Dec 2018 16:46:45 -0500 From: John C Klensin To: =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= , Paul Hoffman cc: i18nrp@ietf.org, Asmus Freytag , idna-update@ietf.org Message-ID: In-Reply-To: References: <154385119878.18333.5085298134102919486.idtracker@ietfa.amsl.com> <8E20D432-01B0-4B52-80BB-3348C5FE73AF@vpnc.org> <217ede0e-ea1f-bb31-a276-f8c618c71278@ix.netcom.com> <8885EE4C-412E-4337-A099-66354A36CEA1@vpnc.org> 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] Last Call: (IDNA2008 and Unicode 11.0.0) to Informational RFC 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, 05 Dec 2018 21:46:57 -0000 --On Wednesday, December 5, 2018 08:56 +0100 Patrik = F=C3=A4ltstr=C3=B6m wrote: > 3. Registries should not "just" allow all PVALID (etc) code > points, but also include a conservative registration policy >=20 > I do though not see (3) is in violation with other documents. > It just emphasizes the same thing already said elsewhere. For > example in the "troublesome characters" draft there is a > suggestion on a method to use when developing one such policy. It is also an existing requirement. See discussion and references in draft-klensin-idna-rfc5891bis but that I-D doesn't actually change anything other than clarifying the existing rules. So, whether (3) should be said here may be controversial unless it is clearly stated as restating rules established elsewhere (a reference to draft-klensin-idna-rfc5891bis would help with that, but certainly is not essential). On the other hand, if you were to say anything about registry policies that changed that rule or encouraged a belief that anything authorized by the 5892 rules was ok, that would not only clearly update several other documents but be very controversial. john p.s. addressing another issue, I don't believe we've ever made a document Historic that is part of the record of evolution of a Standards Track specification that is not itself considered Historic. Even if we had, I think it would be really unfortunate in this case. From nobody Wed Dec 5 14:02:43 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F22130E89; Wed, 5 Dec 2018 14:02:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 XiMHlPg9NQNE; Wed, 5 Dec 2018 14:02:32 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F03F130E5D; Wed, 5 Dec 2018 14:02:32 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1gUfFW-0004IC-QW; Wed, 05 Dec 2018 17:02:30 -0500 Date: Wed, 05 Dec 2018 17:02:23 -0500 From: John C Klensin To: S Moonesamy cc: i18nrp@ietf.org, Ted Hardie , idna-update@ietf.org Message-ID: In-Reply-To: <6.2.5.6.2.20181204185928.1085a3d0@elandnews.com> References: <6.2.5.6.2.20181204185928.1085a3d0@elandnews.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Idna-update] [I18nrp] FWD: Re: [I18n-discuss] draft-faltstrom-unicode11, i18n "directorate", and related issues 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, 05 Dec 2018 22:02:34 -0000 --On Tuesday, December 4, 2018 19:30 -0800 S Moonesamy wrote: > Hi John, > At 01:56 PM 04-12-2018, John C Klensin wrote: >> As the last part of the note below will make obvious (I was >> planning on noting it to this list separately) I decided to >> summarize what I believe the discussion was about to the >> IDNA-update, EAI, PRECIS, and IAB i18n-discuss lists to lower >> the odds that someone who should be participating in the >> discussion is accidentally left out of the loop. > > The proposal sounds like a cross between a working group and a > directorate. To a considerable extent, it is a cross between a working group, a directorate, and a review team. See my recent long note. > I gather that directorate is not an exact fit if > it operates as a review team. But this is where we go into either a rathole or a procedural swamp that wastes time and frustrates some of the relevant experts into deciding to spend their time in other ways. Certainly, if they wanted to, the ART ADs could propose setting up three (in the extreme case) separate groups, a directorate to advise them on i18n strategy, a review team to evaluate both in-area and out-of-area (but primarily out-of-area) documents with i18n topics or impacts, and a WG to generate new i18n work and process documents. They could then consider the fairly small number of experts available (both by knowledge and ability and willingness to commit) to populate such groups and do i18n work and respond by (at least mostly) appointing the same people to the first two groups and encourage them to join/participate in the third. If only because of a shortage of volunteers, they might even appoint the same chairs/coordinators for all three. Then they could figure out a way to make it clear which hat people were wearing when they said something and be prepared for complaints (or even appeals) when it wasn't sufficiently clear. Seems to me like a huge opportunity to waste time, spend energy on procedures that would be better spent on substantive work, and drive experts away from participation and the IETF and that it would have absolutely no advantages other than impressive ritual correctness. YMMD. > A directorate review cannot block a draft. Of course not. Nor can a review team review or, by itself, a WG decision to not proceed with a draft. An AD could take input from any of them and use it to block a draft or could proceed anyway (in the WG case by changing WG leadership, spinning up a separate WG, or handle the draft as an individual submission). Do you see enough difference there to justify quibbling over what this is called or creating new and elaborate procedures? I don't but, again, YMMD. > As Ted pointed out, it would be up to the Area > Director to take the decision on whether to "block" a draft. Exactly. And that decision would be subject to pushback from other ADs in the Area, the full IESG, and to potential appeals. We have lots of protection against abuse against unreasonable blocking behavior... by anyone or any group. john From nobody Wed Dec 5 14:09:10 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41148130E89 for ; Wed, 5 Dec 2018 14:08:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.36 X-Spam-Level: X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=viagenie-ca.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 kwiuNJg-8k5M for ; Wed, 5 Dec 2018 14:08:50 -0800 (PST) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 5448D130F11 for ; Wed, 5 Dec 2018 14:08:47 -0800 (PST) Received: by mail-qt1-x834.google.com with SMTP id n21so24159431qtl.6 for ; Wed, 05 Dec 2018 14:08:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=viagenie-ca.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=Ixohzz4uQmIoHImCOsgFiOuGUUCE05hkQLOtWIaRkeQ=; b=OOXK6Eryntfe9UO4/zxmiCjJAlAa1ygcnvKMNaTYzYWWAm1eTYjffI4JreAa6HvJSM /mvKlko5zMAgLUGcUc4gD8VVRLiO0338h1+w+FORB8k/NWOwcsuGzvkE/TKndOuZWBji zX71mDYcS0OR8ERkeH2G70xg1NaQdidn25qMDPWmy4aZCEYvHdv6Xc0RujGXRBeoJ2qA yIU2tanhNqPo0yPozsuNi9hTBawghq9HgQxKZWJTLvTtyt9ISTuQ5jteh+wt+1Q2DC4D nfqcCdcRfT66I9hToKLrk5i7GdveT34IEMn/pPYDQID8iCjYlz+CWCkIq4bsG4QOxRKM 4WaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Ixohzz4uQmIoHImCOsgFiOuGUUCE05hkQLOtWIaRkeQ=; b=MJUUqk/d7gZVI77ph35ou0Bkz23NFBOGdxV4lj9xhvrmaKEQEtEa5x+zp1b+UItXOr scrPEKoSjFXDnFWT2HeFdzLR0z796Tltp1Pc8qZCubWqKEKXirfTcUBobHrGXRTj89zk tcVOAmSJXUblDzhLKEklNs5uLsaHBqq83zt3X3lXbX0MprgrNa3TEDdbN1PFTAcFHVco GoIaliwdx0YiS47aVnsskbfVrw0fT0XgAXD7miTvLHtnY2crr9ImCIVkauFE89B1a+T3 BOamUllv4LStrwC21EM6Sl5M8t/p8Is+CspPlqlUoSJcLaqRI9VCfzjkJzQwZWfZ0bGN 1nTQ== X-Gm-Message-State: AA+aEWYU2gpjnjnJg6sWgcl3SyyRwvXC5ku8Ud+YEUyGnCoX86hVoR9Q fzXHUKTCJifMdhg0gbivzcb2PA== X-Google-Smtp-Source: AFSGD/WOnRmYP5boMhtaNJoHsrMKFYjg+OMBHrpSLDKqOa4kgQDMzvYcwS2RQzE3UeruKfwyXL68SA== X-Received: by 2002:ac8:6b18:: with SMTP id w24mr25485920qts.144.1544047726260; Wed, 05 Dec 2018 14:08:46 -0800 (PST) Received: from [192.168.1.60] (modemcable138.218-70-69.static.videotron.ca. [69.70.218.138]) by smtp.gmail.com with ESMTPSA id v42sm13725513qth.32.2018.12.05.14.08.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Dec 2018 14:08:45 -0800 (PST) From: "Marc Blanchet" To: "John C Klensin" Cc: "Vint Cerf" , ben@nostrum.com, "Ted Hardie" , i18n-discuss@iab.org, precis@ietf.org, ima@ietf.org, idna-update@ietf.org, resnick@episteme.net Date: Wed, 05 Dec 2018 17:08:43 -0500 X-Mailer: MailMate (1.12.2r5568) Message-ID: In-Reply-To: References: <3079F05172A384D8987A2338@PSB> <8458F480-52CB-4DD4-9C52-6ED9F2860DFD@nostrum.com> <680E50F3-3881-416F-A11A-22563F44A732@episteme.net> <921E77FB-64DA-4A09-95BB-7307099F0B43@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Idna-update] [precis] [I18n-discuss] draft-faltstrom-unicode11, i18n "directorate", and related issues 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, 05 Dec 2018 22:08:54 -0000 On 5 Dec 2018, at 16:37, John C Klensin wrote: > But, with two qualifications, that is all that has ever been > proposed. Those are: > > (1) Because the root of the problems in this topic area is (or > appears to be) that the IETF community doesn't know nearly as > much about the topic as it would in a more ideal world and > because i18n work spans traditional and current Areas, I hope > the advice would be public rather than delivered in secret to > the AD and I would hope that the group would make an extra > effort to explain its reasoning in ways that the community (not > just the ADs) could understand and learn from. I would hope > that the group members would want to do those things and that > the relevant AD(s) would insist on them. (I don't think you > intended advice delivered in secret and kept that way, but your > suggestion could be read that way). I think that is consistent > with your interpretation of "educating..." but can be see how > that could be interpreted differently, just as my initial > suggestion was. it has been « by design » that Stringprep [RFC3454] and its replacement Precis[RFC8264] that there will be « requests » on how to do « the precis profile for my protocol » from the community. This happened for Stringprep quite a lot after the release of Stringprep. With Precis, we updated many of those to use Precis instead, but when the precis working group was closed, there was still many profiles-to-update left and obviously others will come. Therefore, for Precis at least, there will be some community—i18ndirectorate exchanges similar to yang doctors. Marc. > > (2) Not unlike our "Doctors" model (and consistent with the very > informal consultations about some LAMPS documents which I > believe were successful), I'd expect WGs and > document-developers, including those in other Areas, to want to > consult this group for advice and even help with text in > documents. I'd hope that could be handled informally, > directly, and efficiently, with a focus on getting quality work > done. I think it would be very unfortunate if the same sort of > procedure-lawyering that has gotten involved in this thread > would turn those efforts into requirements for a process that > would go something like: > > (OtherWG (or AD in other Area)): Dear ART ADs, would you > please ask the Directorate to review XYZ and help with text. > (ART AD to OtherWG): Sure > (ART AD to Directorate): Please see this request from > OtherWG, deal with it, and tell me. > (Directorate to ART AD (because they are expected to advise > that AD and no one else): ART AD, we think ABCDE > (ART AT to Other WG): Directorate says "we think ABCDE" > > Possibly followed by additional iterations of this waste of the > time of ADs and Directorate members, especially if specific text > were asked for and/or suggested. > > I think that would be seriously dumb and hope my example shows > that and why. But it would be consistent with efforts to draw > narrow lines around supposed principles such as "the only thing > a directorate is allowed to do is to advise ADs in that area). > > best, > john > > > --On Tuesday, December 4, 2018 19:21 -0500 Vint Cerf > wrote: > >> suggestion: >> >> set up the advisory group and allow it to offer advice to the >> appropriate AD. >> This same advisory group can reasonably share its findings >> more generally, thereby "educating...." the rest of the >> community. No power to block should either explicitly or >> implicitly be inferred by the creation of the advisory body. > > > > > _______________________________________________ > IDNA-UPDATE mailing list > IDNA-UPDATE@ietf.org > https://www.ietf.org/mailman/listinfo/idna-update From nobody Wed Dec 5 14:54:49 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2B1130F2C; Wed, 5 Dec 2018 14:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isuD09JRxq_N; Wed, 5 Dec 2018 14:54:39 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC073130F55; Wed, 5 Dec 2018 14:54:38 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1gUg3v-0004NX-LD; Wed, 05 Dec 2018 17:54:35 -0500 Date: Wed, 05 Dec 2018 17:54:28 -0500 From: John C Klensin To: Nico Williams , =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= cc: i18nrp@ietf.org, iab@iab.org, idna-update@ietf.org Message-ID: <62C0C9D453720E19EF649173@PSB> In-Reply-To: <20181011211736.GA2486@localhost> References: <20181011211736.GA2486@localhost> 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] draft-faltstrom-unicode11-04.txt 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, 05 Dec 2018 22:54:48 -0000 --On Thursday, October 11, 2018 16:17 -0500 Nico Williams wrote: > On Sun, Oct 07, 2018 at 07:53:51AM +0200, Patrik = F=C3=A4ltstr=C3=B6m > wrote: >... >> In short the draft proposes (just like RFC 6452) IETF >> continue to follow Unicode Standard without adding exceptions >> to the IDNA2008 algorithm, EVEN IF changes are made that are >> incompatible to earlier versions of Unicode. >=20 > +1 >=20 > We're talking specifically about future incompatible changes = in > either case mappings or normalization. Correct? First of all, if you go back and check the IDNA2008 documents (not just 5892), you will find there is no such limitation. Let me invent an example while hoping we can avoid a lengthy argument about how likely it is. The Unicode Stability rules require that, one a code point is assigned and properties assigned to it, some of those properties (not limited to, e.g., normalization) are just not ever going to be changed. Should they discover they have made a really serious mistake (unless one believes that UTC is infallible, that is always possible, however unlikely), the only option would be to assign a new code point and properties to the abstract character and deprecate the old code point. Now, largely because we understood that such a situation is unlikely, IDNA2008 contains no provision for dealing with that sort of situation, so we would need to detect it in the review process and, presumably, do so even though the algorithm, which knows nothing about Unicode code point deprecation, would not detect the situation. And, assuming we didn't want to allow both code points (the ultimate in confusable characters), we would need to decide which one to treat as an exception and update the exception list in 5892 accordingly. So, no, not just those two sets of cases. > And to confirm the IDNA2008 / UTS#46 context: > - IDNA2008 is hear-no-evil-see-no-evil, says to do no case > mappings, relies on users entering domainnames in the > correct case whatever that is I think that characterization is incorrect or at least misleading. For example, IDNA2008 doesn't only say "do no case mappings", it explicitly DISALLOWS upper case characters, etc. =20 > - UTS#46 says to lower-case first, then apply the rest of > IDNA2008 >=20 > Correct? No, UTS#46 also does a number of other things. As two examples that have stirred up controversy, it disallows a few characters that IDNA2008 treats as PVALID (I might advise a registry to permit those characters only with great care, if at all, but that is different from disallowing them -- see comments about registry restricts and behavior elsewhere in these threads). And it allows a number of code points that IDNA2008 DISALLOWS, primarily some of those in the "So" General Category, including specifically emjoi. >... > The choices for IETF when things like this happens are: >>=20 >> 1. Keep IDNA2008 with no exceptions >>=20 >> 2. Keep IDNA2008 with exceptions >>=20 >> 3. Stop referring (directly) to Unicode as it is not stable >> enough >=20 > (3) has got to be out as it amounts to hard-forking Unicode. > A fork of Unicode would be momentous and extraordinary, and > not to be undertaken lightly! It might be useful to think > about how we'd go about forking Unicode process-wise, but I > think any analysis will convince us that we should not > actually do it. I am not quite sure what Patrik had in mind with (3) but I think there are options that would make "hard-forking Unicode" hyperbolic at best. In particular, while I don't believe IETF has the resources to competently do so (an issue tied up with the "directorate" and "inability to process documents" topics), one could conceive of an IETF-specific normalization technique and associated tables that could be references in lieu of the Unicode ones. That has been discussed several times. It may well be a bad idea even independent of the resource issue, but it would stop a lot sort of a hard fork in Unicode, if only because we would not be assigning new code points. > We should, however, use our liason to communicate to the UC = our > displeasure as to backwards-incompatible changes, and that > we'd like the UC to at least consider adding a stability > attribute to every codepoint. If there were a stability > attribute, then we could exclude codepoints whose stability > the UC will not guarantee. Yes. Sure. I hope I can ask whether you would like your supplemental pony delivered by a flock of flying pigs without getting myself in trouble. > Future codepoint assignments could all begin life as unstable > and gain stability with experience. Curiously (and one reason for the above snarky comment), this would take us back to a very early proposal for what became IDNA2008. In that proposal, rather than dividing code points into "PVALID" and "DISALLOWED" (and a few special-case categories), the main division would include "PROBABLY-YES" and "PROBABLY-NO" categories that would be assigned to anything that might be expected to change or that was uncertain for other reasons (such as being from a script for which there were no living active users) and impose additional restriction on their use. That idea was pulled out of the spec largely at the urging (and claims it would be confusing and was completely unnecessary) but people from the Unicode Consortium. =20 > We could, perhaps, implement codepoint stability attributes at > the IETF alone if the UC balks. I would be OK with that > provided it was simple and simple to automate -- I don't think > we want to be in the business of inspecting every new > codepoint assignment and guessing a stability level for it, so > nothing much more complicated than time-since-assignment > should be used. See above. Been there. Of course we could revisit it, but that would, at this point, be a very significant change in IDNA2008.... and it would add another layer of difficulty to the issue of getting documents reviewed. I don't know whether it would be more or less problematic than an IETF-specific normalization technique or normalization profile. >> Probably more choices than these... >>=20 >> My proposal is [1], together with a more forceful push to >> strict IDNA2008 adoption. No IDNA2003, no UTS#46, no homebrew >> mixes. >=20 > I would much prefer that we adopt UTS#46. I await your I-D with great interest, including how you expect to handle emoji string-matching and making sure that the rules about which combining and modifier sequences are allowed are clear to registrants and zone administrators. Or perhaps you are proposing a profile of UTS#46, but I'd assume that would also raise either forking problems or a review procedure as least as complicated as that now called for in IDNA2008. >... >> This very fast turn into a process issue where IAB have asked >> for progress, and IETF is to deliver. >>=20 >> And this is where I take a step back, and want IESG and IAB >> to make up their mind. This group was created for I18N >> issues, we have a charter, but then what? Is this where >> drafts like these should be discussed? >=20 > I believe we need IETF consensus on these matters, but the IAB > must be involved. Any notion of forking Unicode should > require buy-in from the IAB. Out of curiosity, why? There is nothing in the selection process for IAB members that guarantees a supply of expertise in these matters, even sufficient expertise to evaluate the external consequences of such a decision. Even if the current IAB had that expertise, there is nothing in the Nomcom process that guarantees for the future. The IAB's shutting down of the I18N Program came with an assertion (almost certainly true) that the Program wasn't getting anything done and an implicit assertion that the IAB didn't know how to fix that except by creating new structures that would cover i18n issues (if any progress has been made on that, it has not been discernable outside the IAB). So why do you think the IAB "must be involved" or is even, anymore, relevant? john From nobody Wed Dec 5 14:56: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 D33571294D7; Wed, 5 Dec 2018 14:56:20 -0800 (PST) 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 kSHQFayb0Ztd; Wed, 5 Dec 2018 14:56:18 -0800 (PST) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 3AFF3126CC7; Wed, 5 Dec 2018 14:56:18 -0800 (PST) Received: by mail-ot1-x32f.google.com with SMTP id 32so20243068ota.12; Wed, 05 Dec 2018 14:56:18 -0800 (PST) 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=fHo2z5JB7K0IloWcE8hB+U//Iu13k+Op+MIqCblfckQ=; b=cUt7tGttTkThBV/XCdpj2/wclgQ1mtfUEfvPMrsrXQ1nxHNkCfCIUP6IxTFGNpAfux xw/1Q1+5R4NYbfMt0UcSJRTxUsc36ahA+8embK+z2hTIykfVsIu5UsKW3BSazeQB7ltu jWZnL9yyOidqUvH2oZkLhtjk7cPhAOxpJRMKcZoUlGkx2VhsAoUfq8VBN3/IsSNbHvYR 0+FTNi1o9z2HGho03gl+ly0mLznOlKoYBsDaKwkgZvdKBABLzf5gMs1w/gkEfO3tx0pF SdW0LEXaWtI1hMwPK1NZcAw90Gv38FbnxjgBnW5L2mm9TVIOgFNstem/adswenvFEvqe 2mJQ== 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=fHo2z5JB7K0IloWcE8hB+U//Iu13k+Op+MIqCblfckQ=; b=h3VUvnhu2lk4iw4XHdv6c9L9UFsvIKAbDC4TV3RbAr6xcHNsV9W8fhs0w3wpcGDwSe PmE/4X6NcqfMFz82GV7xmbQsfzWi9Mg+oJMdAPmsYvBQpAXCaivQ526HDH2o0UxgYDao hAVe16ieNCJmsPLwIUxt+DyK/54xyQlxSYpVqXkoxh9xcUa3Ai/IhNoXfax6J+rd9U15 JialkQquD5i65EhUpRcDQaCoqwEOWt/bjBo95TgmX7CnOlGE5H+snmyv6e3uV/6uadR8 jIMe+75FNosPppn16jjCwErW2EOhIlbjsOBGjaPqttB4b46N2aq4aa5cbk2GMd5yyNsg IrGw== X-Gm-Message-State: AA+aEWZbR1Sg2hnjqUEc+1lLl8IuxD6dD6g0xoU8g8CZ/qMgJwpLOuso l0SAtymaFHS4sIeyv8EKwJh8ZwxMrvwBPTOxizSB6g== X-Google-Smtp-Source: AFSGD/UJS7pYMbsVoPV7zb+1+cwijGbbXQvcAMbREo4+fMOCW9NjjRdgAZPhMH3KCVy1NUm/JOh/44K1V9BQ5dS//N0= X-Received: by 2002:a9d:72a:: with SMTP id 39mr18020458ote.134.1544050577249; Wed, 05 Dec 2018 14:56:17 -0800 (PST) MIME-Version: 1.0 References: <6.2.5.6.2.20181204185928.1085a3d0@elandnews.com> In-Reply-To: From: Ted Hardie Date: Wed, 5 Dec 2018 14:55:49 -0800 Message-ID: To: John C Klensin Cc: SM , i18nrp@ietf.org, idna-update@ietf.org Content-Type: multipart/alternative; boundary="0000000000002c1980057c4e4af9" Archived-At: Subject: Re: [Idna-update] [I18nrp] FWD: Re: [I18n-discuss] draft-faltstrom-unicode11, i18n "directorate", and related issues 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, 05 Dec 2018 22:56:21 -0000 --0000000000002c1980057c4e4af9 Content-Type: text/plain; charset="UTF-8" John, On Wed, Dec 5, 2018 at 2:02 PM John C Klensin wrote: > > > --On Tuesday, December 4, 2018 19:30 -0800 S Moonesamy > wrote: > > > Hi John, > > At 01:56 PM 04-12-2018, John C Klensin wrote: > >> As the last part of the note below will make obvious (I was > >> planning on noting it to this list separately) I decided to > >> summarize what I believe the discussion was about to the > >> IDNA-update, EAI, PRECIS, and IAB i18n-discuss lists to lower > >> the odds that someone who should be participating in the > >> discussion is accidentally left out of the loop. > > > > The proposal sounds like a cross between a working group and a > > directorate. > > To a considerable extent, it is a cross between a working group, > a directorate, and a review team. See my recent long note. > > There are critical differences in membership among these three. In the case of a working group, all IETF working groups are open to all comers. Generally, review teams are closed but have their work evaluated by an open group, and they may be self-organized as well as assigned by chairs or ADs. Directorates serve at the pleasure of specific ADs. The accountability models in each of these is quite different as a result of the different membership models. If I understand correctly from conversations with them since yesterday, the ADs are constituting a directorate and associating that membership model and that accountability model with the effort. That's clear, and I'm fine with it. Continuing to say it is a cross between or among other models makes me concerned again, though, that there is some mis-communication going on. > > I gather that directorate is not an exact fit if > > it operates as a review team. > > But this is where we go into either a rathole or a procedural > swamp that wastes time and frustrates some of the relevant > experts into deciding to spend their time in other ways. > Certainly, if they wanted to, the ART ADs could propose setting > up three (in the extreme case) separate groups, a directorate to > advise them on i18n strategy, a review team to evaluate both > in-area and out-of-area (but primarily out-of-area) documents > with i18n topics or impacts, and a WG to generate new i18n work > and process documents. They could then consider the fairly > small number of experts available (both by knowledge and ability > and willingness to commit) to populate such groups and do i18n > work and respond by (at least mostly) appointing the same people > to the first two groups and encourage them to join/participate > in the third. If only because of a shortage of volunteers, > they might even appoint the same chairs/coordinators for all > three. Then they could figure out a way to make it clear which > hat people were wearing when they said something and be prepared > for complaints (or even appeals) when it wasn't sufficiently > clear. > > Seems to me like a huge opportunity to waste time, spend energy > on procedures that would be better spent on substantive work, > and drive experts away from participation and the IETF and that > it would have absolutely no advantages other than impressive > ritual correctness. YMMD. > > While I generally like a good ritual (it's that background as an anthropologist), I cannot agree that something that touches on the accountability model is uselessly procedural. As I am sure you are aware, some of the issues in this area have both large sums of money and large-scale political implications at stake; being able to describe exactly the scope of the power allotted to a group and from whom is one way of avoiding expensive confusion later on. > A directorate review cannot block a draft. > > Of course not. Nor can a review team review or, by itself, a WG > decision to not proceed with a draft. An AD could take input > from any of them and use it to block a draft or could proceed > anyway (in the WG case by changing WG leadership, spinning up a > separate WG, or handle the draft as an individual submission). > Do you see enough difference there to justify quibbling over > what this is called or creating new and elaborate procedures? I > don't but, again, YMMD. > > > As Ted pointed out, it would be up to the Area > > Director to take the decision on whether to "block" a draft. > > Exactly. And that decision would be subject to pushback from > other ADs in the Area, the full IESG, and to potential appeals. > We have lots of protection against abuse against unreasonable > blocking behavior... by anyone or any group. > > If we are clear that the model is that of a directorate and that the ADs are the ones responsible, I agree. In an open working group, the mode by which one pushes back on a decision is very different, though, which is part of why I continue to be concerned at descriptions that make this a cross between or among models. regards, Ted > john > > --0000000000002c1980057c4e4af9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
John,

= On Wed, Dec 5, 2018 at 2:02 PM John C Klensin <john-ietf@jck.com> wrote:


--On Tuesday, December 4, 2018 19:30 -0800 S Moonesamy
<sm+ietf@ela= ndsys.com> wrote:

> Hi John,
> At 01:56 PM 04-12-2018, John C Klensin wrote:
>> As the last part of the note below will make obvious (I was
>> planning on noting it to this list separately) I decided to
>> summarize what I believe the discussion was about to the
>> IDNA-update, EAI, PRECIS, and IAB i18n-discuss lists to lower
>> the odds that someone who should be participating in the
>> discussion is accidentally left out of the loop.
>
> The proposal sounds like a cross between a working group and a
> directorate.

To a considerable extent, it is a cross between a working group,
a directorate, and a review team.=C2=A0 =C2=A0See my recent long note.


There are critical differences in memb= ership among these three.=C2=A0 In the case of a working group, all IETF wo= rking groups are open to all comers.=C2=A0 Generally, review teams are clos= ed but have their work evaluated by an open group,=C2=A0 and they may be se= lf-organized as well as assigned by chairs or ADs. =C2=A0=C2=A0 Directorate= s serve at the pleasure of specific ADs.=C2=A0 The accountability models in= each of these is quite different as a result of the different membership m= odels.=C2=A0

If I understand correctly from c= onversations with them since yesterday, the ADs are constituting a director= ate and associating that membership model and that accountability model wit= h the effort.=C2=A0 That's clear, and I'm fine with it.=C2=A0 Conti= nuing to say it is a cross between or among other models makes me concerned= again, though, that there is some mis-communication going on.

=C2=A0
>=C2=A0 I gather that directorate is not an exact fit if
> it operates as a review team.=C2=A0

But this is where we go into either a rathole or a procedural
swamp that wastes time and frustrates some of the relevant
experts into deciding to spend their time in other ways.
Certainly, if they wanted to, the ART ADs could propose setting
up three (in the extreme case) separate groups, a directorate to
advise them on i18n strategy, a review team to evaluate both
in-area and out-of-area (but primarily out-of-area) documents
with i18n topics or impacts, and a WG to generate new i18n work
and process documents.=C2=A0 They could then consider the fairly
small number of experts available (both by knowledge and ability
and willingness to commit) to populate such groups and do i18n
work and respond by (at least mostly) appointing the same people
to the first two groups and encourage them to join/participate
in the third.=C2=A0 =C2=A0If only because of a shortage of volunteers,
they might even appoint the same chairs/coordinators for all
three.=C2=A0 Then they could figure out a way to make it clear which
hat people were wearing when they said something and be prepared
for complaints (or even appeals) when it wasn't sufficiently
clear.

Seems to me like a huge opportunity to waste time, spend energy
on procedures that would be better spent on substantive work,
and drive experts away from participation and the IETF and that
it would have absolutely no advantages other than impressive
ritual correctness.=C2=A0 =C2=A0YMMD.


While I generally like a good ritual (= it's that background as an anthropologist), I cannot agree that somethi= ng that touches on the accountability model is uselessly procedural. As I a= m sure you are aware, some of the issues in this area have both large sums = of money and large-scale political implications at stake; being able to des= cribe exactly the scope of the power allotted to a group and from whom is o= ne way of avoiding expensive confusion later on.

> A directorate review cannot block a draft.

Of course not.=C2=A0 Nor can a review team review or, by itself, a WG
decision to not proceed with a draft.=C2=A0 =C2=A0An AD could take input from any of them and use it to block a draft or could proceed
anyway (in the WG case by changing WG leadership, spinning up a
separate WG, or handle the draft as an individual submission).
Do you see enough difference there to justify quibbling over
what this is called or creating new and elaborate procedures?=C2=A0 I
don't but, again, YMMD.

>=C2=A0 As Ted pointed out, it would be up to the Area
> Director to take the decision on whether to "block" a draft.=

Exactly.=C2=A0 =C2=A0And that decision would be subject to pushback from other ADs in the Area, the full IESG, and to potential appeals.
We have lots of protection against abuse against unreasonable
blocking behavior... by anyone or any group.

If we are clear that the model is that of a directora= te and that the ADs are the ones responsible, I agree.=C2=A0 In an open wor= king group, the mode by which one pushes back on a decision is very differe= nt, though, which is part of why I continue to be concerned at descriptions= that make this a cross between or among models.

r= egards,

Ted


=C2=A0
=C2=A0 =C2=A0 john

--0000000000002c1980057c4e4af9-- From nobody Wed Dec 5 15:59: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 C942E130E51; Wed, 5 Dec 2018 15:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=cSgUMYjR; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=UdE6912w 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 9mTka1BeLSnn; Wed, 5 Dec 2018 15:59:08 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 874E312E043; Wed, 5 Dec 2018 15:59:08 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([197.224.108.107]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id wB5NwmoS004416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2018 15:58:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1544054341; x=1544140741; bh=k9ob0OzG1ETX3AoVgern6Nc+yHV833rQXCJn+cPPKu8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=cSgUMYjRv71vu5CeA22OOztagS7d58whpW1F373H0JXrym1w5buKMYC/0qpohR6IO RO9DSrCQmqw1hFO+DeiOp/KFtpZulRvLB/R/+Ffa/fCRdu7Irm9Wie83M2+81ALmXe c0mCq8lFdjox+aLnmadOcPO5GQSZKx4oKQoh9r98= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1544054341; x=1544140741; i=@elandsys.com; bh=k9ob0OzG1ETX3AoVgern6Nc+yHV833rQXCJn+cPPKu8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=UdE6912wPrUrZrwXthGXMXRkdISCcqqrRF1P1cw6ixFBIoQ2OrTspg1ZSbmrhzFT/ 4WdRiSOM90/LxLBRzRS1mqKmE0oCRt+O/b0qGgbgyKynsVoSCaxKWA1edKQ3gSz0mZ P0YVM6RX7TVVtGTKsBmJCJ/Lpigh4J3UHcXdOquw= Message-Id: <6.2.5.6.2.20181205150339.114bfd60@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 05 Dec 2018 15:58:23 -0800 To: John C Klensin , i18nrp@ietf.org From: S Moonesamy Cc: Ted Hardie , idna-update@ietf.org In-Reply-To: References: <6.2.5.6.2.20181204185928.1085a3d0@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [Idna-update] [I18nrp] FWD: Re: [I18n-discuss] draft-faltstrom-unicode11, i18n "directorate", and related issues 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, 05 Dec 2018 23:59:10 -0000 Hi John, At 02:02 PM 05-12-2018, John C Klensin wrote: >To a considerable extent, it is a cross between a working group, >a directorate, and a review team. See my recent long note. Ok. >But this is where we go into either a rathole or a procedural >swamp that wastes time and frustrates some of the relevant >experts into deciding to spend their time in other ways. >Certainly, if they wanted to, the ART ADs could propose setting >up three (in the extreme case) separate groups, a directorate to >advise them on i18n strategy, a review team to evaluate both >in-area and out-of-area (but primarily out-of-area) documents >with i18n topics or impacts, and a WG to generate new i18n work >and process documents. They could then consider the fairly >small number of experts available (both by knowledge and ability >and willingness to commit) to populate such groups and do i18n >work and respond by (at least mostly) appointing the same people >to the first two groups and encourage them to join/participate >in the third. If only because of a shortage of volunteers, >they might even appoint the same chairs/coordinators for all >three. Then they could figure out a way to make it clear which >hat people were wearing when they said something and be prepared >for complaints (or even appeals) when it wasn't sufficiently >clear. > >Seems to me like a huge opportunity to waste time, spend energy >on procedures that would be better spent on substantive work, >and drive experts away from participation and the IETF and that >it would have absolutely no advantages other than impressive >ritual correctness. YMMD. It is likely that there are non-technical considerations at play in all in "internationalization". It is not worth the effort to attempt to explain that to the IESG. The non-trivial part of this effort is to create the conditions for it to be sustainable. All it takes is one issue to cause an unwillingness to commit. >Of course not. Nor can a review team review or, by itself, a WG >decision to not proceed with a draft. An AD could take input >from any of them and use it to block a draft or could proceed >anyway (in the WG case by changing WG leadership, spinning up a >separate WG, or handle the draft as an individual submission). >Do you see enough difference there to justify quibbling over >what this is called or creating new and elaborate procedures? I >don't but, again, YMMD. Instead of looking at this in terms of working group versus directorate, I would ask about the objective(s) being sought and then try to fit them into existing processes. There would probably have to be some informal talks along the way to encourage universal acceptance. Regards, S. Moonesamy From nobody Wed Dec 5 16:04:16 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244F812D4E8; Wed, 5 Dec 2018 16:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.461 X-Spam-Level: X-Spam-Status: No, score=-3.461 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 CkDt-l_FE6Ed; Wed, 5 Dec 2018 16:04:10 -0800 (PST) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700136.outbound.protection.outlook.com [40.107.70.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E20612E043; Wed, 5 Dec 2018 16:04:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Sask0CUPbwCjCyOYzlH5zNHhuIrtANRf6R320BoOYJg=; b=b6mF6BhizdeQMbbA710rlmAkA0DbgRwxtGHbLh2nisGLCa5A+7StMIKQfasBmkoc9RpTEvku6gBNtlrjCG03LKL2Ap5ZSR5qcYych4mbkwk8SlwOLV1JSzTMotQG5McxjxxM1RVkS9FWsq6fKHQHDksH6nlLp6m9f24JLbFW8so= Received: from DM5PR21MB0762.namprd21.prod.outlook.com (10.173.172.20) by DM5PR21MB0123.namprd21.prod.outlook.com (10.173.173.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1425.2; Thu, 6 Dec 2018 00:04:03 +0000 Received: from DM5PR21MB0762.namprd21.prod.outlook.com ([fe80::c5c0:fca:6152:981a]) by DM5PR21MB0762.namprd21.prod.outlook.com ([fe80::c5c0:fca:6152:981a%14]) with mapi id 15.20.1425.006; Thu, 6 Dec 2018 00:04:03 +0000 From: Shawn Steele To: John C Klensin , Nico Williams , =?utf-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= CC: "i18nrp@ietf.org" , "idna-update@ietf.org" , "iab@iab.org" Thread-Topic: [Idna-update] [I18nrp] draft-faltstrom-unicode11-04.txt Thread-Index: AQHUjO2ZNJa5Usvb/ku5k66VcQn5KKVwzzHw Date: Thu, 6 Dec 2018 00:04:03 +0000 Message-ID: References: <20181011211736.GA2486@localhost> <62C0C9D453720E19EF649173@PSB> In-Reply-To: <62C0C9D453720E19EF649173@PSB> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=shawnste@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-12-06T00:03:59.7587138Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:b:abec:191a:9e72:ab84] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR21MB0123; 6:T4NaTfhuyviWl6pL9Rgo4sgaxuR3KAm6GlXu3JQp2G1jeZLQyih7R3p+7nRr+/DdjJudOI1RhHQhXl0s8QKSGWLaPULAFGHZmdI5MPV7hdspQQHkoX9CxvGJz7bxRqmkTJ16UaDfAqQIdQtQ9/3/yMVbIoXpLc6jRyxVJ1LSp8V5oYjXvkCWcsLOmkvyrfKSZHP0AKLg5RDawKa84zaZ95Nwr8nypv7m1fqbuCVFbWjKob6VWxkAA6bOjOpIF60DJNZ7prnDHw2CWMIwO8XDWBWZbo4NODODnkE+LLLxntcUfsj/a+gnv0px+QD+N7/rxq3QFEt3dDPRDNBLLGx646xO2K//k0dpOuRyLffEbf0KEptnTGKOp0oW+uGXaOOZ9oC8GgfIYa0Bauni123Dt5ajh1Dgq1iONfBjmL9fxcAtw0juFvAecb4lOsNg8nyINvoMMWjtOagTFxH/wcpP4w==; 5:iN0U76LLQGdg+wn+ljTX3hAIwV4Hyc8ZbW8jyp70LYNTyOObfHMzlY4STLgpYqmahsqUsjqYsNzlMRhsPeC+tywUv7S03no5lJ+jAatnR2BZBJGLNMPLKZKVR6ZshM9jTAvR5oDiJrMqnWTxa5qka/obOBSVqj0Nj94wjluyRCI=; 7:pGuC9C/UAUi37U5ccNBxMHNB539sbdZaqhnGm46oK2njdre9tjZMigvU5OXa9CIl/cJuLdAgpMX2ETjdncSiZ1LoHo2KgB52+9MyW+AR8n7tPJRX/gjfrhf1PmvdfZ4gPZWS2eT/uNhUzTju92a9cg== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 7813ee96-2e33-4fb6-811a-08d65b0e54fd x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:DM5PR21MB0123; x-ms-traffictypediagnostic: DM5PR21MB0123: x-ms-exchange-purlcount: 2 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Shawn.Steele@microsoft.com; x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230008)(999002)(6040522)(8220035)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231463)(944501520)(2018427008)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:DM5PR21MB0123; BCL:0; PCL:0; RULEID:; SRVR:DM5PR21MB0123; x-forefront-prvs: 087894CD3C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(366004)(39860400002)(136003)(396003)(199004)(189003)(6116002)(476003)(81156014)(14454004)(81166006)(97736004)(8936002)(46003)(966005)(256004)(25786009)(8990500004)(10290500003)(478600001)(72206003)(99286004)(8676002)(186003)(11346002)(10090500001)(446003)(33656002)(6506007)(229853002)(6246003)(22452003)(5660300001)(316002)(105586002)(4326008)(6436002)(106356001)(68736007)(2906002)(74316002)(9686003)(6306002)(86612001)(53936002)(86362001)(305945005)(7696005)(54906003)(486006)(76176011)(7736002)(110136005)(71190400001)(71200400001)(55016002)(102836004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR21MB0123; H:DM5PR21MB0762.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: ZyOFZa0vFAVtzcSwQ8tYpadhy/5Eu63QHzUqQptC4PMbmPRynt/OwLYTcHPJKmMd/mSeFfN1Ut2FZhktT+Mvk7l+2PdNKuTXtf7V8AN9XVZHJyeOO+h7M+T1a7jxdm+r91EWAp3Gx8CISqo5irvs7aX9Oc8hPxK2S4KgRGdQZJ0ucaFPNThflH7+zZO+Jmlx7f17fNwHPp30udblcY1JA19d5O61Ww9FHG9YAi29sudXgSF088vceN5YmyGglfMdmt3iZBlsCzWc/YqU7eIrxu2UERq/dH016RSY8M4BNfiuQUBM6YwZRpevvhK9Cp7Eg9xs2MMN6X/kdl1RB98vL43rjARAWE+NARHPvCEOS1Y= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7813ee96-2e33-4fb6-811a-08d65b0e54fd X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2018 00:04:03.2202 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR21MB0123 Archived-At: Subject: Re: [Idna-update] [I18nrp] draft-faltstrom-unicode11-04.txt 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: Thu, 06 Dec 2018 00:04:14 -0000 PiBObywgVVRTIzQ2IGFsc28gZG9lcyBhIG51bWJlciBvZiBvdGhlciB0aGluZ3MNCg0KVVRTIzQ2 IFNwZWNpZmllcyBvcHRpb25zIGZvciB0cmFuc2l0aW9uaW5nIHRvIElETkEgMjAwOC4gICgzKSBD MSwgQzIgJiBDMyBtZW50aW9uIHRoZSBkaWZmZXJlbnQgdmFyaWF0aW9ucy4gIEMzIGNvbmZvcm1h bmNlIGlzIElETkEyMDA4LCB0aGUgb3RoZXJzIHdlcmUgaW50ZW5kZWQgdG8gcHJvdmlkZSB2YXJ5 aW5nIGRlZ3JlZXMgb2YgY29tcGF0aWJpbGl0eSB3aXRoIHRoZSBvbGRlciBJRE5BMjAwMyB2ZXJz aW9uLg0KDQpUaGUgSWRuYU1hcHBpbmdUYWJsZS50eHQgZmlsZXMgaW4gaHR0cHM6Ly93d3cudW5p Y29kZS5vcmcvUHVibGljL2lkbmEvIHJlc29sdmVzIG1ha2UgaXQgcHJldHR5IHNpbXBsZSB0byBm aWd1cmUgb3V0IGlmIGNoYXJhY3RlcnMgYXJlIHZhbGlkIG9yIG1hcHBlZCwgYW5kIHdoYXQgdGhl aXIgSUROQSAyMDA4IHN0YXR1cyBpcyAoTlY4L1hWOCkgcGVyIHRoZSBJRE5BMjAwOCBydWxlcy4N Cg0KSU1PIGFjY2VwdGFuY2Ugb2YgbmV3IFVuaWNvZGUgdmVyc2lvbnMgd291bGQgYmUgZ3JlYXRs eSBzaW1wbGlmaWVkIGFuZCBmYXN0ZXIgaWYgdGhlcmUgd2FzIG1lcmVseSBhIHBvaW50ZXIgc2F5 aW5nIHRoYXQgVVRTNDYgQzMgY29uZm9ybWFuY2Ugd2l0aCB0aGUgZGF0YSBmaWxlcyBhdCAgaHR0 cHM6Ly93d3cudW5pY29kZS5vcmcvUHVibGljL2lkbmEgcHJvdmlkZSBhcHByb3ByaWF0ZSBJRE4g YmVoYXZpb3IgZm9yIGFwcGxpY2F0aW9ucy4gIChSZWdpc3RyYXJzIHNob3VsZCBvYnZpb3VzbHkg YmUgbXVjaCBtb3JlIHJlc3RyaWN0aXZlKS4gIEluIHByYWN0aWNlIGltcGxlbWVudGF0aW9ucyBw aWNrIHVwIHRoZSBuZXcgVW5pY29kZSBkYXRhIGF0IHRoZWlyIHBhY2UgYWZ0ZXIgaXQgYmVjb21l cyBhdmFpbGFibGUgYW5kIGFyZSBtdWNoIG1vcmUgY3VycmVudCB0aGFuIHRoZSBJRE4gV0cgZ3Vp ZGFuY2UuDQoNCi1TaGF3bg0KIA0KDQo= From nobody Thu Dec 6 00:23:54 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A09128CFD; Thu, 6 Dec 2018 00:23:53 -0800 (PST) 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 UiCXzkqa1Xss; Thu, 6 Dec 2018 00:23:48 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C07D127B4C; Thu, 6 Dec 2018 00:23:48 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1gUowi-0005hB-3g; Thu, 06 Dec 2018 03:23:44 -0500 Date: Thu, 06 Dec 2018 03:23:36 -0500 From: John C Klensin To: Ted Hardie cc: SM , i18nrp@ietf.org, idna-update@ietf.org Message-ID: <742AF7DA8806227F4BDD3BA8@PSB> In-Reply-To: References: <6.2.5.6.2.20181204185928.1085a3d0@elandnews.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Idna-update] [I18nrp] FWD: Re: [I18n-discuss] draft-faltstrom-unicode11, i18n "directorate", and related issues 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: Thu, 06 Dec 2018 08:23:53 -0000 Ted, I'm not sure whether we disagree or not. So let me try a shorter comment that gets to the bottom line. (1) This is going to be required to advise the ART ADs and, at their option, the IESG and/or the broader community, on i18n strategic questions. There is no requirement on anyone to take their advice and the membership is presumably recruited, appointed, and serves at the pleasure of the ART ADs. (2) This is, as Marc pointed out about PRECIS, going to get requests for help with profiles and the like. Some of those requests may come from outside the ART Area. Again, there is no requirement on anyone to take the advice that results although I would certainly hope that the community and the IESG would look on departures from it (or a deliberate effort to avoid asking) with some skepticism. That is similar to, but at least initially with far less nominal authority than or various Doctor teams. For example, I'm not anticipating an entry/question in Shepherd templates although that would clearly be up to the IESG. (3) I am imagine interactions between the or its members and the EDU team about needed and useful training activities and how to staff them. Such questions would presumably be under the supervision of the ART ADs in addition to the overall supervision of the EDU team by the IESG. I don't see anything different or problematic there and, again, no one would be obligated to take the 's advice. (4) At their discretion, the ART ADs could cut the out of the loop entirely on a particular document. I'd expect at least some of the members of that group to respond badly, either resigning, complaining loudly that the ART ADs were deliberately excluding input and then providing that input as individuals during IETF Last Call, or both, but I don't imagine the existence of the might offer the ART ADs, or at their discretion, publicly to the community, might be similar to (whether consistent or not) advice that might ordinarily, at at its discretion, come from the IAB. That is, AFAICT, no different from other directorates (or for that matter, individuals) offering strategic advice -- insofar as the IAB advice should get priority over that of others, it should be because of the quality of thinking and explanation it reflects, not because it comes _From The IAB_ or the pixie dust that is sprinkled over it every March. More generally, not only are the ART ADs (or the IESG more broadly) not required to prioritize advice from the over advice from the IAB (or vice versa), they are not required to accept either and neither the nor the IAB have any specific rights in that matter. Now, if we had a huge supply of expertise, I could see some very strong arguments, starting with just sharing the load, for trying to parse those functions into separate bodies/ teams. But we don't have such a supply -- if we did and things were working well in traditional ways, there never would have been a BOF, the non-decomposing character issue would have been addressed a couple of years ago rather than being turned into an IAB statement that arguably added to the confusion, draft-faltstrom-unicode11 would not be trying to address four versions of Unicode at once, and so on. So, do you have a suggestion -- preferably one that has not already been tried and been abandoned and does not involve Command Action or Proclamation -- for solving the problem of being unable to progress i18n documents, especially those that are intrinsically interrelated whether they say so or not? john --On Wednesday, December 5, 2018 14:55 -0800 Ted Hardie wrote: > John, > > On Wed, Dec 5, 2018 at 2:02 PM John C Klensin > wrote: > >> >> >> --On Tuesday, December 4, 2018 19:30 -0800 S Moonesamy >> wrote: >> >> > Hi John, >> > At 01:56 PM 04-12-2018, John C Klensin wrote: >> >> As the last part of the note below will make obvious (I was >> >> planning on noting it to this list separately) I decided to >> >> summarize what I believe the discussion was about to the >> >> IDNA-update, EAI, PRECIS, and IAB i18n-discuss lists to >> >> lower the odds that someone who should be participating in >> >> the discussion is accidentally left out of the loop. >> > >> > The proposal sounds like a cross between a working group >> > and a directorate. >> >> To a considerable extent, it is a cross between a working >> group, a directorate, and a review team. See my recent long >> note. >> >> > There are critical differences in membership among these > three. In the case of a working group, all IETF working > groups are open to all comers. Generally, review teams are > closed but have their work evaluated by an open group, and > they may be self-organized as well as assigned by chairs or > ADs. Directorates serve at the pleasure of specific ADs. > The accountability models in each of these is quite different > as a result of the different membership models. > > If I understand correctly from conversations with them since > yesterday, the ADs are constituting a directorate and > associating that membership model and that accountability > model with the effort. That's clear, and I'm fine with it. > Continuing to say it is a cross between or among other models > makes me concerned again, though, that there is some > mis-communication going on. > > > >> > I gather that directorate is not an exact fit if >> > it operates as a review team. >> >> But this is where we go into either a rathole or a procedural >> swamp that wastes time and frustrates some of the relevant >> experts into deciding to spend their time in other ways. >> Certainly, if they wanted to, the ART ADs could propose >> setting up three (in the extreme case) separate groups, a >> directorate to advise them on i18n strategy, a review team to >> evaluate both in-area and out-of-area (but primarily >> out-of-area) documents with i18n topics or impacts, and a WG >> to generate new i18n work and process documents. They could >> then consider the fairly small number of experts available >> (both by knowledge and ability and willingness to commit) to >> populate such groups and do i18n work and respond by (at >> least mostly) appointing the same people to the first two >> groups and encourage them to join/participate in the third. >> If only because of a shortage of volunteers, they might even >> appoint the same chairs/coordinators for all three. Then >> they could figure out a way to make it clear which hat people >> were wearing when they said something and be prepared for >> complaints (or even appeals) when it wasn't sufficiently >> clear. >> >> Seems to me like a huge opportunity to waste time, spend >> energy on procedures that would be better spent on >> substantive work, and drive experts away from participation >> and the IETF and that it would have absolutely no advantages >> other than impressive ritual correctness. YMMD. >> >> > While I generally like a good ritual (it's that background as > an anthropologist), I cannot agree that something that touches > on the accountability model is uselessly procedural. As I am > sure you are aware, some of the issues in this area have both > large sums of money and large-scale political implications at > stake; being able to describe exactly the scope of the power > allotted to a group and from whom is one way of avoiding > expensive confusion later on. > >> A directorate review cannot block a draft. >> >> Of course not. Nor can a review team review or, by itself, a >> WG decision to not proceed with a draft. An AD could take >> input from any of them and use it to block a draft or could >> proceed anyway (in the WG case by changing WG leadership, >> spinning up a separate WG, or handle the draft as an >> individual submission). Do you see enough difference there to >> justify quibbling over what this is called or creating new >> and elaborate procedures? I don't but, again, YMMD. >> >> > As Ted pointed out, it would be up to the Area >> > Director to take the decision on whether to "block" a draft. >> >> Exactly. And that decision would be subject to pushback from >> other ADs in the Area, the full IESG, and to potential >> appeals. We have lots of protection against abuse against >> unreasonable blocking behavior... by anyone or any group. >> >> If we are clear that the model is that of a directorate and >> that the ADs > are the ones responsible, I agree. In an open working group, > the mode by which one pushes back on a decision is very > different, though, which is part of why I continue to be > concerned at descriptions that make this a cross between or > among models. > > regards, > > Ted > > > > >> john >> >> From nobody Thu Dec 6 09:54:03 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 76890131159; Thu, 6 Dec 2018 09:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 janJZbm2qVAP; Thu, 6 Dec 2018 09:53:45 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 043BB131141; Thu, 6 Dec 2018 09:53:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ix.netcom.com; s=dk12062016; t=1544118825; bh=E+abGW0QYYeH6J0EvCkXbXCKPqFvuQOs+14G eN1GA68=; 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=i1DVHqsm4XuLQ82eekVCqQtzFJH2Mr7Xs r8BqktskFfIGK5N2hcyb+Zz9gp32WKmFmZ+D00mvCcEVuii19CO9P2JC6IapI+xhXEz ilCwK2EuFkVnCHmmfeO/N2fvQPkCcP/p8mZ0SPOmgw09knmnJXVg2nWacBKZjb0LGKj KlbqrNbt3mJzsl6JTZdtLWWXHyvafMQKI9wbaWO2+PHsLC9WS+4KTxQwp7pucdNyuf9 AnH203qeekbtfdP+CZwQaNuwytl8gjEtuOGY4ZzhL3Yyr+eofYE6BvBru1LOkaNWysO Ua9GeGl+kPF80ihtLSsQ4hB2xlRGFmIqCif2YGr4w== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=ix.netcom.com; b=gWTtMj0iyZNSCrh1oYzVLE2ZPQRtlN1FxBY4JoiTBwP9wMFXZh7InY0b8Pr2+QF0moTfUXFDkdoq2k3a+t2cLWK4uB8sl1Bqs/Mh417Oho1ZFOTQqCMcmJLtZO69kAu95aZp37Zx4KaR54fvzdC7xyJA8KIYg0IN0dJ4wS9J+jgWaclhUjJLS7P4pwbIf/E+8Xe/OfDacIem1Hfn+6TMFdsigaXBbRWSoJpcC8EJcPfkUbUuYGZJ5KDRP/y4fsE8LiTL6keadTBqRr+1w4orwy7q1vAdQlmgqJ1f+UJiIeD6deJVesvZW0zNPha1yS9DTE3D7M7WE/I63BcXUmfoKw==; 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.171.131] (helo=[192.168.1.111]) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1gUxqH-0002hb-Us; Thu, 06 Dec 2018 12:53:42 -0500 To: John C Klensin , Ted Hardie Cc: i18nrp@ietf.org, idna-update@ietf.org, SM References: <6.2.5.6.2.20181204185928.1085a3d0@elandnews.com> <742AF7DA8806227F4BDD3BA8@PSB> From: Asmus Freytag Message-ID: Date: Thu, 6 Dec 2018 09:53:45 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 In-Reply-To: <742AF7DA8806227F4BDD3BA8@PSB> Content-Type: multipart/alternative; boundary="------------907CCA8E3B4AF1AEB18463F1" Content-Language: en-US X-ELNK-Trace: 464f085de979d7246f36dc87813833b28d93432b0f0788b9a87c8e57057ee93a9f4acb8a53f14868350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 174.21.171.131 Archived-At: Subject: Re: [Idna-update] [I18nrp] FWD: Re: [I18n-discuss] draft-faltstrom-unicode11, i18n "directorate", and related issues 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: Thu, 06 Dec 2018 17:53:49 -0000 This is a multi-part message in MIME format. --------------907CCA8E3B4AF1AEB18463F1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit What John writes below seems to be a workable model. In practical terms, associate the with a single mailing list where all advice is posted (and all requests for input can be made) and you have the transparency and educational benefits that is so relevant in an issue like i18n. (I18n is always a bit special because it runs across other specifications while rarely being central - IDNA being an obvious exception). In my experience, with i18n, there is often a very definite "doing it this way will not work for these cases" type of review result as opposed to a "this is the one way to do it". In other words, there is a definite interplay with whoever is writing a specification. A./ On 12/6/2018 12:23 AM, John C Klensin wrote: > Ted, > > I'm not sure whether we disagree or not. So let me try a > shorter comment that gets to the bottom line. > > (1) This is going to be required to advise the ART > ADs and, at their option, the IESG and/or the broader community, > on i18n strategic questions. There is no requirement on anyone > to take their advice and the membership is presumably recruited, > appointed, and serves at the pleasure of the ART ADs. > > (2) This is, as Marc pointed out about PRECIS, going > to get requests for help with profiles and the like. Some of > those requests may come from outside the ART Area. Again, there > is no requirement on anyone to take the advice that results > although I would certainly hope that the community and the IESG > would look on departures from it (or a deliberate effort to > avoid asking) with some skepticism. That is similar to, but at > least initially with far less nominal authority than or various > Doctor teams. For example, I'm not anticipating an > entry/question in Shepherd templates although that would clearly > be up to the IESG. > > (3) I am imagine interactions between the or its > members and the EDU team about needed and useful training > activities and how to staff them. Such questions would > presumably be under the supervision of the ART ADs in addition > to the overall supervision of the EDU team by the IESG. I > don't see anything different or problematic there and, again, no > one would be obligated to take the 's advice. > > (4) At their discretion, the ART ADs could cut the > out of the loop entirely on a particular document. I'd expect > at least some of the members of that group to respond badly, > either resigning, complaining loudly that the ART ADs were > deliberately excluding input and then providing that input as > individuals during IETF Last Call, or both, but I don't imagine > the existence of the rights that do not exist today. > > (5) Strategic advice that the might offer the ART > ADs, or at their discretion, publicly to the community, might be > similar to (whether consistent or not) advice that might > ordinarily, at at its discretion, come from the IAB. That is, > AFAICT, no different from other directorates (or for that > matter, individuals) offering strategic advice -- insofar as the > IAB advice should get priority over that of others, it should be > because of the quality of thinking and explanation it reflects, > not because it comes _From The IAB_ or the pixie dust that is > sprinkled over it every March. More generally, not only are > the ART ADs (or the IESG more broadly) not required to > prioritize advice from the over advice from the IAB > (or vice versa), they are not required to accept either and > neither the nor the IAB have any specific rights in > that matter. > > Now, if we had a huge supply of expertise, I could see some very > strong arguments, starting with just sharing the load, for > trying to parse those functions into separate bodies/ teams. > But we don't have such a supply -- if we did and things were > working well in traditional ways, there never would have been a > BOF, the non-decomposing character issue would have been > addressed a couple of years ago rather than being turned into an > IAB statement that arguably added to the confusion, > draft-faltstrom-unicode11 would not be trying to address four > versions of Unicode at once, and so on. So, do you have a > suggestion -- preferably one that has not already been tried and > been abandoned and does not involve Command Action or > Proclamation -- for solving the problem of being unable to > progress i18n documents, especially those that are intrinsically > interrelated whether they say so or not? > > john > > > --On Wednesday, December 5, 2018 14:55 -0800 Ted Hardie > wrote: > >> John, >> >> On Wed, Dec 5, 2018 at 2:02 PM John C Klensin >> wrote: >> >>> >>> --On Tuesday, December 4, 2018 19:30 -0800 S Moonesamy >>> wrote: >>> >>>> Hi John, >>>> At 01:56 PM 04-12-2018, John C Klensin wrote: >>>>> As the last part of the note below will make obvious (I was >>>>> planning on noting it to this list separately) I decided to >>>>> summarize what I believe the discussion was about to the >>>>> IDNA-update, EAI, PRECIS, and IAB i18n-discuss lists to >>>>> lower the odds that someone who should be participating in >>>>> the discussion is accidentally left out of the loop. >>>> The proposal sounds like a cross between a working group >>>> and a directorate. >>> To a considerable extent, it is a cross between a working >>> group, a directorate, and a review team. See my recent long >>> note. >>> >>> >> There are critical differences in membership among these >> three. In the case of a working group, all IETF working >> groups are open to all comers. Generally, review teams are >> closed but have their work evaluated by an open group, and >> they may be self-organized as well as assigned by chairs or >> ADs. Directorates serve at the pleasure of specific ADs. >> The accountability models in each of these is quite different >> as a result of the different membership models. >> >> If I understand correctly from conversations with them since >> yesterday, the ADs are constituting a directorate and >> associating that membership model and that accountability >> model with the effort. That's clear, and I'm fine with it. >> Continuing to say it is a cross between or among other models >> makes me concerned again, though, that there is some >> mis-communication going on. >> >> >> >>>> I gather that directorate is not an exact fit if >>>> it operates as a review team. >>> But this is where we go into either a rathole or a procedural >>> swamp that wastes time and frustrates some of the relevant >>> experts into deciding to spend their time in other ways. >>> Certainly, if they wanted to, the ART ADs could propose >>> setting up three (in the extreme case) separate groups, a >>> directorate to advise them on i18n strategy, a review team to >>> evaluate both in-area and out-of-area (but primarily >>> out-of-area) documents with i18n topics or impacts, and a WG >>> to generate new i18n work and process documents. They could >>> then consider the fairly small number of experts available >>> (both by knowledge and ability and willingness to commit) to >>> populate such groups and do i18n work and respond by (at >>> least mostly) appointing the same people to the first two >>> groups and encourage them to join/participate in the third. >>> If only because of a shortage of volunteers, they might even >>> appoint the same chairs/coordinators for all three. Then >>> they could figure out a way to make it clear which hat people >>> were wearing when they said something and be prepared for >>> complaints (or even appeals) when it wasn't sufficiently >>> clear. >>> >>> Seems to me like a huge opportunity to waste time, spend >>> energy on procedures that would be better spent on >>> substantive work, and drive experts away from participation >>> and the IETF and that it would have absolutely no advantages >>> other than impressive ritual correctness. YMMD. >>> >>> >> While I generally like a good ritual (it's that background as >> an anthropologist), I cannot agree that something that touches >> on the accountability model is uselessly procedural. As I am >> sure you are aware, some of the issues in this area have both >> large sums of money and large-scale political implications at >> stake; being able to describe exactly the scope of the power >> allotted to a group and from whom is one way of avoiding >> expensive confusion later on. >> >>> A directorate review cannot block a draft. >>> >>> Of course not. Nor can a review team review or, by itself, a >>> WG decision to not proceed with a draft. An AD could take >>> input from any of them and use it to block a draft or could >>> proceed anyway (in the WG case by changing WG leadership, >>> spinning up a separate WG, or handle the draft as an >>> individual submission). Do you see enough difference there to >>> justify quibbling over what this is called or creating new >>> and elaborate procedures? I don't but, again, YMMD. >>> >>>> As Ted pointed out, it would be up to the Area >>>> Director to take the decision on whether to "block" a draft. >>> Exactly. And that decision would be subject to pushback from >>> other ADs in the Area, the full IESG, and to potential >>> appeals. We have lots of protection against abuse against >>> unreasonable blocking behavior... by anyone or any group. >>> >>> If we are clear that the model is that of a directorate and >>> that the ADs >> are the ones responsible, I agree. In an open working group, >> the mode by which one pushes back on a decision is very >> different, though, which is part of why I continue to be >> concerned at descriptions that make this a cross between or >> among models. >> >> regards, >> >> Ted >> >> >> >> >>> john >>> >>> > > > > _______________________________________________ > IDNA-UPDATE mailing list > IDNA-UPDATE@ietf.org > https://www.ietf.org/mailman/listinfo/idna-update > --------------907CCA8E3B4AF1AEB18463F1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
What John writes below seems to be a workable model.

In practical terms, associate the <whatever> with a single mailing list
where all advice is posted (and all requests for input can be made)
and you have the transparency and educational benefits that is so
relevant in an issue like i18n. (I18n is always a bit special because
it runs across other specifications while rarely being central - IDNA
being an obvious exception).

In my experience, with i18n, there is often a very definite "doing
it this way will not work for these cases" type of review result as
opposed to a "this is the one way to do it". In other words, there
is a definite interplay with whoever is writing a specification.

A./


On 12/6/2018 12:23 AM, John C Klensin wrote:
Ted,

I'm not sure whether we disagree or not.   So let me try a
shorter comment that gets to the bottom line.

(1) This <whatever> is going to be required to advise the ART
ADs and, at their option, the IESG and/or the broader community,
on i18n strategic questions.  There is no requirement on anyone
to take their advice and the membership is presumably recruited,
appointed, and serves at the pleasure of the ART ADs.

(2) This <whatever> is, as Marc pointed out about PRECIS, going
to get requests for help with profiles and the like.  Some of
those requests may come from outside the ART Area.  Again, there
is no requirement on anyone to take the advice that results
although I would certainly hope that the community and the IESG
would look on departures from it (or a deliberate effort to
avoid asking) with some skepticism.   That is similar to, but at
least initially with far less nominal authority than or various
Doctor teams. For example, I'm not anticipating an
entry/question in Shepherd templates although that would clearly
be up to the IESG.

(3) I am imagine interactions between the <whatever> or its
members and the EDU team about needed and useful training
activities and how to staff them.  Such questions would
presumably be under the supervision of the ART ADs in addition
to the overall supervision of the EDU team by the IESG.   I
don't see anything different or problematic there and, again, no
one would be obligated to take the <whatever>'s advice.

(4) At their discretion, the ART ADs could cut the <whatever>
out of the loop entirely on a particular document.   I'd expect
at least some of the members of that group to respond badly,
either resigning, complaining loudly that the ART ADs were
deliberately excluding input and then providing that input as
individuals during IETF Last Call, or both, but I don't imagine
the existence of the <whatever) would create, e.g., any appeal
rights that do not exist today.

(5) Strategic advice that the <whatever> might offer the ART
ADs, or at their discretion, publicly to the community, might be
similar to (whether consistent or not) advice that might
ordinarily, at at its discretion, come from the IAB.  That is,
AFAICT, no different from other directorates (or for that
matter, individuals) offering strategic advice -- insofar as the
IAB advice should get priority over that of others, it should be
because of the quality of thinking and explanation it reflects,
not because it comes _From The IAB_ or the pixie dust that is
sprinkled over it every March.   More generally, not only are
the ART ADs (or the IESG more broadly) not required to
prioritize advice from the <whatever> over advice from the IAB
(or vice versa), they are not required to accept either and
neither the <whatever> nor the IAB have any specific rights in
that matter.

Now, if we had a huge supply of expertise, I could see some very
strong arguments, starting with just sharing the load, for
trying to parse those functions into separate bodies/ teams.
But we don't have such a supply -- if we did and things were
working well in traditional ways, there never would have been a
BOF, the non-decomposing character issue would have been
addressed a couple of years ago rather than being turned into an
IAB statement that arguably added to the confusion,
draft-faltstrom-unicode11 would not be trying to address four
versions of Unicode at once, and so on.  So, do you have a
suggestion -- preferably one that has not already been tried and
been abandoned and does not involve Command Action or
Proclamation -- for solving the problem of being unable to
progress i18n documents, especially those that are intrinsically
interrelated whether they say so or not?

     john


--On Wednesday, December 5, 2018 14:55 -0800 Ted Hardie
<ted.ietf@gmail.com> wrote:


John,

On Wed, Dec 5, 2018 at 2:02 PM John C Klensin
<john-ietf@jck.com> wrote:



--On Tuesday, December 4, 2018 19:30 -0800 S Moonesamy
<sm+ietf@elandsys.com> wrote:


Hi John,
At 01:56 PM 04-12-2018, John C Klensin wrote:

As the last part of the note below will make obvious (I was
planning on noting it to this list separately) I decided to
summarize what I believe the discussion was about to the
IDNA-update, EAI, PRECIS, and IAB i18n-discuss lists to
lower the odds that someone who should be participating in
the discussion is accidentally left out of the loop.

The proposal sounds like a cross between a working group
and a directorate.

To a considerable extent, it is a cross between a working
group, a directorate, and a review team.   See my recent long
note.



There are critical differences in membership among these
three.  In the case of a working group, all IETF working
groups are open to all comers. Generally, review teams are
closed but have their work evaluated by an open group,  and
they may be self-organized as well as assigned by chairs or
ADs.    Directorates serve at the pleasure of specific ADs.
The accountability models in each of these is quite different
as a result of the different membership models.

If I understand correctly from conversations with them since
yesterday, the ADs are constituting a directorate and
associating that membership model and that accountability
model with the effort.  That's clear, and I'm fine with it.
Continuing to say it is a cross between or among other models
makes me concerned again, though, that there is some
mis-communication going on.




 I gather that directorate is not an exact fit if
it operates as a review team.

But this is where we go into either a rathole or a procedural
swamp that wastes time and frustrates some of the relevant
experts into deciding to spend their time in other ways.
Certainly, if they wanted to, the ART ADs could propose
setting up three (in the extreme case) separate groups, a
directorate to advise them on i18n strategy, a review team to
evaluate both in-area and out-of-area (but primarily
out-of-area) documents with i18n topics or impacts, and a WG
to generate new i18n work and process documents.  They could
then consider the fairly small number of experts available
(both by knowledge and ability and willingness to commit) to
populate such groups and do i18n work and respond by (at
least mostly) appointing the same people to the first two
groups and encourage them to join/participate in the third.
If only because of a shortage of volunteers, they might even
appoint the same chairs/coordinators for all three.  Then
they could figure out a way to make it clear which hat people
were wearing when they said something and be prepared for
complaints (or even appeals) when it wasn't sufficiently
clear.

Seems to me like a huge opportunity to waste time, spend
energy on procedures that would be better spent on
substantive work, and drive experts away from participation
and the IETF and that it would have absolutely no advantages
other than impressive ritual correctness.   YMMD.



While I generally like a good ritual (it's that background as
an anthropologist), I cannot agree that something that touches
on the accountability model is uselessly procedural. As I am
sure you are aware, some of the issues in this area have both
large sums of money and large-scale political implications at
stake; being able to describe exactly the scope of the power
allotted to a group and from whom is one way of avoiding
expensive confusion later on.


A directorate review cannot block a draft.

Of course not.  Nor can a review team review or, by itself, a
WG decision to not proceed with a draft.   An AD could take
input from any of them and use it to block a draft or could
proceed anyway (in the WG case by changing WG leadership,
spinning up a separate WG, or handle the draft as an
individual submission). Do you see enough difference there to
justify quibbling over what this is called or creating new
and elaborate procedures?  I don't but, again, YMMD.


 As Ted pointed out, it would be up to the Area
Director to take the decision on whether to "block" a draft.

Exactly.   And that decision would be subject to pushback from
other ADs in the Area, the full IESG, and to potential
appeals. We have lots of protection against abuse against
unreasonable blocking behavior... by anyone or any group.

If we are clear that the model is that of a directorate and
that the ADs

are the ones responsible, I agree.  In an open working group,
the mode by which one pushes back on a decision is very
different, though, which is part of why I continue to be
concerned at descriptions that make this a cross between or
among models.

regards,

Ted





    john






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


--------------907CCA8E3B4AF1AEB18463F1-- From nobody Thu Dec 6 13:38:26 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5170130F19; Thu, 6 Dec 2018 13:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wjO0oYkqzkp; Thu, 6 Dec 2018 13:38:20 -0800 (PST) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (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 418931311D5; Thu, 6 Dec 2018 13:38:20 -0800 (PST) Received: by mail-oi1-x233.google.com with SMTP id i6so1718029oia.6; Thu, 06 Dec 2018 13:38:20 -0800 (PST) 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=6Vhzpmiso2zBsVt8HYRQDI0z/IYmOXIuZxUKdo0KuYE=; b=K3xtBA+3jNjmm7fl5kDktPJETQrqXzvqI0AHij1Lsh4MVYjzj2e4hRtPFBbbQZ8D4L aDuPZQsh+w11A5L1xfMzeu/DUa+goJIzWXiUSqYAWgubIXIch99pc2/u0DYuQEqebZzT 793o67ogqATzzwoCsSb1+y+RAoyolFNLVQIC+iiVrxhLy3ki9755UC+9XaKrUI+QX5By G3wQo8ZsSby6EBJJY0TOV3PYpdaZeAbrbukYlAE1AYCXoi1RdKw5xYbqfsZ2D3ymzWOd ovGN2ZvVYTcWroE/vuGxdBCvOTScVUA1lFS2sSPihJRP7DC0LlN2AE+viuH3PH1nzUUO DCjw== 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=6Vhzpmiso2zBsVt8HYRQDI0z/IYmOXIuZxUKdo0KuYE=; b=nWK05tZf4pTgK8srNqDVkovGbpI3sVyFru1ZYfUYrECvc2aBOBp1N18WG6X/+x3KnK fa+TpMzF3RgduVExcBRqDBziKJ6FNidv5VygjCS8zFmgKKHiOz/DgMA5tyoNf885p7cn H2jxHh2UnYvoZoU9is7/SfWOziPpAqq+OHvaJIMkDIooH+QQGFMdDUODIUS+Sfo2d3kY s6k7DDZZfvdjNljZv8MwJEnsxSPHfghyNjjuwUp0nhW5ypu/87+b4W573ejbvyFsUl3E SqX24J51hMz7ALT+QJQUJINxv0WoWC2pMKlxCL8weLam+T2peIhWP+/egL+qgzg7dgE8 j1Ww== X-Gm-Message-State: AA+aEWa5+IYZGt+D170Bm6JEvp6jdSZWKMDh42PYrtxKD6aubUIfVrti ezmRP8VxnDwwej0VT1y8UagDP+gJGe1gWndFupNXmK7n X-Google-Smtp-Source: AFSGD/WyzGvPGLuYWOYFW1zMcXkYUxXGkHfOwr2fB/JSDF9+oQhQNjhscv3SW5v8ItDv7yvVaYgSh4ivBIc9Zhsy78Y= X-Received: by 2002:aca:c4d8:: with SMTP id u207mr18022818oif.30.1544132299306; Thu, 06 Dec 2018 13:38:19 -0800 (PST) MIME-Version: 1.0 References: <6.2.5.6.2.20181204185928.1085a3d0@elandnews.com> <742AF7DA8806227F4BDD3BA8@PSB> In-Reply-To: <742AF7DA8806227F4BDD3BA8@PSB> From: Ted Hardie Date: Thu, 6 Dec 2018 13:38:01 -0800 Message-ID: To: John C Klensin Cc: SM , i18nrp@ietf.org, idna-update@ietf.org Content-Type: multipart/alternative; boundary="0000000000002fbaaf057c6151c0" Archived-At: Subject: Re: [Idna-update] [I18nrp] FWD: Re: [I18n-discuss] draft-faltstrom-unicode11, i18n "directorate", and related issues 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: Thu, 06 Dec 2018 21:38:25 -0000 --0000000000002fbaaf057c6151c0 Content-Type: text/plain; charset="UTF-8" Howdy, On Thu, Dec 6, 2018 at 12:23 AM John C Klensin wrote: > Ted, > > I'm not sure whether we disagree or not. So let me try a > shorter comment that gets to the bottom line. > > As I said before, the ADs have described this as a directorate and have said that this will use that accountability model. I think that's clear, and I'm fine with it. Presuming that this is a general understanding, I see no reason for objecting and I do not plan to appeal. Two smaller points below. > (1) This is going to be required to advise the ART > ADs and, at their option, the IESG and/or the broader community, > on i18n strategic questions. There is no requirement on anyone > to take their advice and the membership is presumably recruited, > appointed, and serves at the pleasure of the ART ADs. > > (2) This is, as Marc pointed out about PRECIS, going > to get requests for help with profiles and the like. Some of > those requests may come from outside the ART Area. Again, there > is no requirement on anyone to take the advice that results > although I would certainly hope that the community and the IESG > would look on departures from it (or a deliberate effort to > avoid asking) with some skepticism. That is similar to, but at > least initially with far less nominal authority than or various > Doctor teams. For example, I'm not anticipating an > entry/question in Shepherd templates although that would clearly > be up to the IESG. > > (3) I am imagine interactions between the or its > members and the EDU team about needed and useful training > activities and how to staff them. Such questions would > presumably be under the supervision of the ART ADs in addition > to the overall supervision of the EDU team by the IESG. I > don't see anything different or problematic there and, again, no > one would be obligated to take the 's advice. > > I believe that the EDU team is also formally a directorate, under GEN: https://datatracker.ietf.org/group/emodir/about/ > (4) At their discretion, the ART ADs could cut the > out of the loop entirely on a particular document. I'd expect > at least some of the members of that group to respond badly, > either resigning, complaining loudly that the ART ADs were > deliberately excluding input and then providing that input as > individuals during IETF Last Call, or both, but I don't imagine > the existence of the rights that do not exist today. > > (5) Strategic advice that the might offer the ART > ADs, or at their discretion, publicly to the community, might be > similar to (whether consistent or not) advice that might > ordinarily, at at its discretion, come from the IAB. That is, > AFAICT, no different from other directorates (or for that > matter, individuals) offering strategic advice -- insofar as the > IAB advice should get priority over that of others, it should be > because of the quality of thinking and explanation it reflects, > not because it comes _From The IAB_ or the pixie dust that is > sprinkled over it every March. More generally, not only are > the ART ADs (or the IESG more broadly) not required to > prioritize advice from the over advice from the IAB > (or vice versa), they are not required to accept either and > neither the nor the IAB have any specific rights in > that matter. > > Now, if we had a huge supply of expertise, I could see some very > strong arguments, starting with just sharing the load, for > trying to parse those functions into separate bodies/ teams. > But we don't have such a supply -- if we did and things were > working well in traditional ways, there never would have been a > BOF, the non-decomposing character issue would have been > addressed a couple of years ago rather than being turned into an > IAB statement that arguably added to the confusion, > draft-faltstrom-unicode11 would not be trying to address four > versions of Unicode at once, and so on. So, do you have a > suggestion -- preferably one that has not already been tried and > been abandoned and does not involve Command Action or > Proclamation -- for solving the problem of being unable to > progress i18n documents, especially those that are intrinsically > interrelated whether they say so or not? > > I have two pieces of advice, neither of which is a suggestion for a different way forward. The first is that a task not on this list (but which was on the longer list you posted earlier) is among the most important in my opinion: develop new expertise within the IETF, either by attraction or education. If that is a task given to this directorate, then I earnestly hope that it is close to the top priority. It's not a trivial task, and I sadly have no great strategies to offer, but without it the long term prospect of effective work by the IETF in this area is dim. The second is that this list of tasks, even before that addition, is very long for the pool of folks we have at hand. Clear prioritization by the ADs to the directorate would be very useful. Without it, I suspect the pace of requests for review will create a drum-beat to which the directorate will march; that often happens to ADs with the bi-weekly telechat, and it tends to happen by default to the groups on which they rely. As I said, not a suggestion for a different way; simply my observations on this way. regards, Ted (As an individual) john > > > --On Wednesday, December 5, 2018 14:55 -0800 Ted Hardie > wrote: > > > John, > > > > On Wed, Dec 5, 2018 at 2:02 PM John C Klensin > > wrote: > > > >> > >> > >> --On Tuesday, December 4, 2018 19:30 -0800 S Moonesamy > >> wrote: > >> > >> > Hi John, > >> > At 01:56 PM 04-12-2018, John C Klensin wrote: > >> >> As the last part of the note below will make obvious (I was > >> >> planning on noting it to this list separately) I decided to > >> >> summarize what I believe the discussion was about to the > >> >> IDNA-update, EAI, PRECIS, and IAB i18n-discuss lists to > >> >> lower the odds that someone who should be participating in > >> >> the discussion is accidentally left out of the loop. > >> > > >> > The proposal sounds like a cross between a working group > >> > and a directorate. > >> > >> To a considerable extent, it is a cross between a working > >> group, a directorate, and a review team. See my recent long > >> note. > >> > >> > > There are critical differences in membership among these > > three. In the case of a working group, all IETF working > > groups are open to all comers. Generally, review teams are > > closed but have their work evaluated by an open group, and > > they may be self-organized as well as assigned by chairs or > > ADs. Directorates serve at the pleasure of specific ADs. > > The accountability models in each of these is quite different > > as a result of the different membership models. > > > > If I understand correctly from conversations with them since > > yesterday, the ADs are constituting a directorate and > > associating that membership model and that accountability > > model with the effort. That's clear, and I'm fine with it. > > Continuing to say it is a cross between or among other models > > makes me concerned again, though, that there is some > > mis-communication going on. > > > > > > > >> > I gather that directorate is not an exact fit if > >> > it operates as a review team. > >> > >> But this is where we go into either a rathole or a procedural > >> swamp that wastes time and frustrates some of the relevant > >> experts into deciding to spend their time in other ways. > >> Certainly, if they wanted to, the ART ADs could propose > >> setting up three (in the extreme case) separate groups, a > >> directorate to advise them on i18n strategy, a review team to > >> evaluate both in-area and out-of-area (but primarily > >> out-of-area) documents with i18n topics or impacts, and a WG > >> to generate new i18n work and process documents. They could > >> then consider the fairly small number of experts available > >> (both by knowledge and ability and willingness to commit) to > >> populate such groups and do i18n work and respond by (at > >> least mostly) appointing the same people to the first two > >> groups and encourage them to join/participate in the third. > >> If only because of a shortage of volunteers, they might even > >> appoint the same chairs/coordinators for all three. Then > >> they could figure out a way to make it clear which hat people > >> were wearing when they said something and be prepared for > >> complaints (or even appeals) when it wasn't sufficiently > >> clear. > >> > >> Seems to me like a huge opportunity to waste time, spend > >> energy on procedures that would be better spent on > >> substantive work, and drive experts away from participation > >> and the IETF and that it would have absolutely no advantages > >> other than impressive ritual correctness. YMMD. > >> > >> > > While I generally like a good ritual (it's that background as > > an anthropologist), I cannot agree that something that touches > > on the accountability model is uselessly procedural. As I am > > sure you are aware, some of the issues in this area have both > > large sums of money and large-scale political implications at > > stake; being able to describe exactly the scope of the power > > allotted to a group and from whom is one way of avoiding > > expensive confusion later on. > > > >> A directorate review cannot block a draft. > >> > >> Of course not. Nor can a review team review or, by itself, a > >> WG decision to not proceed with a draft. An AD could take > >> input from any of them and use it to block a draft or could > >> proceed anyway (in the WG case by changing WG leadership, > >> spinning up a separate WG, or handle the draft as an > >> individual submission). Do you see enough difference there to > >> justify quibbling over what this is called or creating new > >> and elaborate procedures? I don't but, again, YMMD. > >> > >> > As Ted pointed out, it would be up to the Area > >> > Director to take the decision on whether to "block" a draft. > >> > >> Exactly. And that decision would be subject to pushback from > >> other ADs in the Area, the full IESG, and to potential > >> appeals. We have lots of protection against abuse against > >> unreasonable blocking behavior... by anyone or any group. > >> > >> If we are clear that the model is that of a directorate and > >> that the ADs > > are the ones responsible, I agree. In an open working group, > > the mode by which one pushes back on a decision is very > > different, though, which is part of why I continue to be > > concerned at descriptions that make this a cross between or > > among models. > > > > regards, > > > > Ted > > > > > > > > > >> john > >> > >> > > > > > --0000000000002fbaaf057c6151c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

On Thu, Dec 6, 2018 at 12:23 AM John C Klensin <john-ietf@jck.com> wrote:
Ted,

I'm not sure whether we disagree or not.=C2=A0 =C2=A0So let me try a shorter comment that gets to the bottom line.


As I said before, the ADs have describ= ed this as a directorate and have said that this will use that accountabili= ty model.=C2=A0 I think that's clear, and I'm fine with it.=C2=A0 P= resuming that this is a general understanding, I see no reason for objectin= g and I do not plan to appeal.=C2=A0

Two smal= ler points below.

=C2=A0
(1) This <whatever> is going to be required to advise the ART
ADs and, at their option, the IESG and/or the broader community,
on i18n strategic questions.=C2=A0 There is no requirement on anyone
to take their advice and the membership is presumably recruited,
appointed, and serves at the pleasure of the ART ADs.

(2) This <whatever> is, as Marc pointed out about PRECIS, going
to get requests for help with profiles and the like.=C2=A0 Some of
those requests may come from outside the ART Area.=C2=A0 Again, there
is no requirement on anyone to take the advice that results
although I would certainly hope that the community and the IESG
would look on departures from it (or a deliberate effort to
avoid asking) with some skepticism.=C2=A0 =C2=A0That is similar to, but at<= br> least initially with far less nominal authority than or various
Doctor teams. For example, I'm not anticipating an
entry/question in Shepherd templates although that would clearly
be up to the IESG.

(3) I am imagine interactions between the <whatever> or its
members and the EDU team about needed and useful training
activities and how to staff them.=C2=A0 Such questions would
presumably be under the supervision of the ART ADs in addition
to the overall supervision of the EDU team by the IESG.=C2=A0 =C2=A0I
don't see anything different or problematic there and, again, no
one would be obligated to take the <whatever>'s advice.

I believe that the EDU team is also formally a directorate,= under GEN:


=C2=A0
(4) At their discretion, the ART ADs could cut the <whatever>
out of the loop entirely on a particular document.=C2=A0 =C2=A0I'd expe= ct
at least some of the members of that group to respond badly,
either resigning, complaining loudly that the ART ADs were
deliberately excluding input and then providing that input as
individuals during IETF Last Call, or both, but I don't imagine
the existence of the <whatever) would create, e.g., any appeal
rights that do not exist today.

(5) Strategic advice that the <whatever> might offer the ART
ADs, or at their discretion, publicly to the community, might be
similar to (whether consistent or not) advice that might
ordinarily, at at its discretion, come from the IAB.=C2=A0 That is,
AFAICT, no different from other directorates (or for that
matter, individuals) offering strategic advice -- insofar as the
IAB advice should get priority over that of others, it should be
because of the quality of thinking and explanation it reflects,
not because it comes _From The IAB_ or the pixie dust that is
sprinkled over it every March.=C2=A0 =C2=A0More generally, not only are
the ART ADs (or the IESG more broadly) not required to
prioritize advice from the <whatever> over advice from the IAB
(or vice versa), they are not required to accept either and
neither the <whatever> nor the IAB have any specific rights in
that matter.

Now, if we had a huge supply of expertise, I could see some very
strong arguments, starting with just sharing the load, for
trying to parse those functions into separate bodies/ teams.
But we don't have such a supply -- if we did and things were
working well in traditional ways, there never would have been a
BOF, the non-decomposing character issue would have been
addressed a couple of years ago rather than being turned into an
IAB statement that arguably added to the confusion,
draft-faltstrom-unicode11 would not be trying to address four
versions of Unicode at once, and so on.=C2=A0 So, do you have a
suggestion -- preferably one that has not already been tried and
been abandoned and does not involve Command Action or
Proclamation -- for solving the problem of being unable to
progress i18n documents, especially those that are intrinsically
interrelated whether they say so or not?


I have two pieces of advice, neither o= f which is=C2=A0 a suggestion for a different way forward.=C2=A0
=

The first is that a task not on this list (but which wa= s on the longer list you posted earlier) is among the most important in my = opinion: develop new expertise within the IETF, either by attraction or edu= cation.=C2=A0 If that is a task given to this directorate, then I earnestly= hope that it is close to the top priority.=C2=A0=C2=A0 It's not a triv= ial task, and I sadly have no great strategies to offer, but without it the= long term prospect of effective work by the IETF in this area is dim.=C2= =A0

The second is that this list of tasks, ev= en before that addition, is very long for the pool of folks we have at hand= .=C2=A0 Clear prioritization by the ADs to the directorate would be very us= eful.=C2=A0 Without it, I suspect the pace of requests for review will crea= te a drum-beat to which the directorate will march; that often happens to A= Ds with the bi-weekly telechat, and it tends to happen by default to the gr= oups on which they rely.

As I said, not a suggesti= on for a different way; simply my observations on this way.

<= /div>
regards,

Ted
(As an i= ndividual)



=C2=A0 =C2=A0 =C2=A0john


--On Wednesday, December 5, 2018 14:55 -0800 Ted Hardie
<ted.ietf@gmail.= com> wrote:

> John,
>
> On Wed, Dec 5, 2018 at 2:02 PM John C Klensin
> <john-ietf@j= ck.com> wrote:
>
>>
>>
>> --On Tuesday, December 4, 2018 19:30 -0800 S Moonesamy
>> <sm= +ietf@elandsys.com> wrote:
>>
>> > Hi John,
>> > At 01:56 PM 04-12-2018, John C Klensin wrote:
>> >> As the last part of the note below will make obvious (I w= as
>> >> planning on noting it to this list separately) I decided = to
>> >> summarize what I believe the discussion was about to the<= br> >> >> IDNA-update, EAI, PRECIS, and IAB i18n-discuss lists to >> >> lower the odds that someone who should be participating i= n
>> >> the discussion is accidentally left out of the loop.
>> >
>> > The proposal sounds like a cross between a working group
>> > and a directorate.
>>
>> To a considerable extent, it is a cross between a working
>> group, a directorate, and a review team.=C2=A0 =C2=A0See my recent= long
>> note.
>>
>>
> There are critical differences in membership among these
> three.=C2=A0 In the case of a working group, all IETF working
> groups are open to all comers. Generally, review teams are
> closed but have their work evaluated by an open group,=C2=A0 and
> they may be self-organized as well as assigned by chairs or
> ADs.=C2=A0 =C2=A0 Directorates serve at the pleasure of specific ADs.<= br> > The accountability models in each of these is quite different
> as a result of the different membership models.
>
> If I understand correctly from conversations with them since
> yesterday, the ADs are constituting a directorate and
> associating that membership model and that accountability
> model with the effort.=C2=A0 That's clear, and I'm fine with i= t.
> Continuing to say it is a cross between or among other models
> makes me concerned again, though, that there is some
> mis-communication going on.
>
>
>
>> >=C2=A0 I gather that directorate is not an exact fit if
>> > it operates as a review team.
>>
>> But this is where we go into either a rathole or a procedural
>> swamp that wastes time and frustrates some of the relevant
>> experts into deciding to spend their time in other ways.
>> Certainly, if they wanted to, the ART ADs could propose
>> setting up three (in the extreme case) separate groups, a
>> directorate to advise them on i18n strategy, a review team to
>> evaluate both in-area and out-of-area (but primarily
>> out-of-area) documents with i18n topics or impacts, and a WG
>> to generate new i18n work and process documents.=C2=A0 They could<= br> >> then consider the fairly small number of experts available
>> (both by knowledge and ability and willingness to commit) to
>> populate such groups and do i18n work and respond by (at
>> least mostly) appointing the same people to the first two
>> groups and encourage them to join/participate in the third.
>> If only because of a shortage of volunteers, they might even
>> appoint the same chairs/coordinators for all three.=C2=A0 Then
>> they could figure out a way to make it clear which hat people
>> were wearing when they said something and be prepared for
>> complaints (or even appeals) when it wasn't sufficiently
>> clear.
>>
>> Seems to me like a huge opportunity to waste time, spend
>> energy on procedures that would be better spent on
>> substantive work, and drive experts away from participation
>> and the IETF and that it would have absolutely no advantages
>> other than impressive ritual correctness.=C2=A0 =C2=A0YMMD.
>>
>>
> While I generally like a good ritual (it's that background as
> an anthropologist), I cannot agree that something that touches
> on the accountability model is uselessly procedural. As I am
> sure you are aware, some of the issues in this area have both
> large sums of money and large-scale political implications at
> stake; being able to describe exactly the scope of the power
> allotted to a group and from whom is one way of avoiding
> expensive confusion later on.
>
>> A directorate review cannot block a draft.
>>
>> Of course not.=C2=A0 Nor can a review team review or, by itself, a=
>> WG decision to not proceed with a draft.=C2=A0 =C2=A0An AD could t= ake
>> input from any of them and use it to block a draft or could
>> proceed anyway (in the WG case by changing WG leadership,
>> spinning up a separate WG, or handle the draft as an
>> individual submission). Do you see enough difference there to
>> justify quibbling over what this is called or creating new
>> and elaborate procedures?=C2=A0 I don't but, again, YMMD.
>>
>> >=C2=A0 As Ted pointed out, it would be up to the Area
>> > Director to take the decision on whether to "block"= a draft.
>>
>> Exactly.=C2=A0 =C2=A0And that decision would be subject to pushbac= k from
>> other ADs in the Area, the full IESG, and to potential
>> appeals. We have lots of protection against abuse against
>> unreasonable blocking behavior... by anyone or any group.
>>
>> If we are clear that the model is that of a directorate and
>> that the ADs
> are the ones responsible, I agree.=C2=A0 In an open working group,
> the mode by which one pushes back on a decision is very
> different, though, which is part of why I continue to be
> concerned at descriptions that make this a cross between or
> among models.
>
> regards,
>
> Ted
>
>
>
>
>>=C2=A0 =C2=A0 =C2=A0john
>>
>>




--0000000000002fbaaf057c6151c0-- From nobody Thu Dec 6 21:39:47 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88CD11271FF; Thu, 6 Dec 2018 21:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JQz34Avhq3F; Thu, 6 Dec 2018 21:39:36 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53ECA12008A; Thu, 6 Dec 2018 21:39:36 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1gV8rL-0008yA-BT; Fri, 07 Dec 2018 00:39:31 -0500 Date: Fri, 07 Dec 2018 00:39:26 -0500 From: John C Klensin To: Larry Masinter , =?UTF-8?Q?'Patrik_F=C3=A4ltstr=C3=B6m'?= , 'Asmus Freytag' cc: i18nrp@ietf.org, 'Paul Hoffman' , idna-update@ietf.org Message-ID: In-Reply-To: <055301d48dc8$0ea95120$2bfbf360$@acm.org> References: <154385119878.18333.5085298134102919486.idtracker@ietfa.amsl.com> <8E20D432-01B0-4B52-80BB-3348C5FE73AF@vpnc.org> <217ede0e-ea1f-bb31-a276-f8c618c71278@ix.netcom.com> <8885EE4C-412E-4337-A099-66354A36CEA1@vpnc.org> <48A2A546-4FEA-4060-8706-34D210B2ABAF@frobbit.se> <055301d48dc8$0ea95120$2bfbf360$@acm.org> 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] Last Call: (IDNA2008 and Unicode 11.0.0) to Informational RFC 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: Fri, 07 Dec 2018 05:39:38 -0000 Larry, The theory about registries in the current IDNA RFCs was to impose a strong requirement that they be conservative including, but not limited to, understanding the scripts they are permitting. That requirement is, I believe, consistent with both what you are saying and what Asmus appears to be saying on that subject. The details about how to best accomplish that-- to convince them to actually do so-- seem to be a more complicated matter. =20 As I've said in other, probably too-long, notes, most registries who manage zones within an enterprise or other organization have been fairly good about it; many of the second-level registries and others whose business and operational model involves selling names to unrelated parties have tended to adopt the least restrictive policies they believe they can get away with. Part of the problem with the IDNA RFCs is that the requirement for registry conservatism and responsibility is too scattered through several documents to come across as important as I think we all believe it is. draft-klensin-idna-rfc5891bis (now expired, but waiting in the wings) was intended to address that issue. I haven't looked at the text for a while but strongly suspect it does not identify and stress labels being "re-enterable" and "retypable" as you suggest. It should. If you don't mind taking a look at it, I'd appreciate recommended text. Or, if that isn't convenient, I'll try to remember to say something when I next open the document. thanks, john --On Thursday, December 6, 2018 16:59 -0800 Larry Masinter wrote: > Registries should be conservative in the sense of advising > their clients about the likely usability of the registered > name among their target audience. > I don't think the IDNA RFCs currently are conservative enough. > As I've noted before, usability includes "re-enterable" > (including "retypable") . >=20 >=20 >=20 >> -----Original Message----- >> From: i18nRP On Behalf Of Patrik >> F=C3=A4ltstr=C3=B6m Sent: Thursday, December 6, 2018 2:44 AM >> To: Asmus Freytag >> Cc: i18nrp@ietf.org; Paul Hoffman >> Subject: Re: [I18nrp] Last Call: >> > (IDNA2008 >> and Unicode 11.0.0) to Informational RFC >>=20 >> On 5 Dec 2018, at 19:03, Asmus Freytag (c) wrote: >>=20 >> >>=20 >> >> 3. Registries should not "just" allow all PVALID >> >> (etc.) code > points, but also >> include a conservative registration policy >> >>=20 >> >=20 >> > add: >> >=20 >> > "as mandated in RFCs > > Klensin's > draft >> here>." >>=20 >> Correct, I blame my Swenglish dialect for the mistake in >> wording I did. >>=20 >> paf >=20 > _______________________________________________ > i18nRP mailing list > i18nRP@ietf.org > https://www.ietf.org/mailman/listinfo/i18nrp From nobody Thu Dec 6 22:13:07 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 0FAD2124BF6; Thu, 6 Dec 2018 22:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wgdp02TkITVD; Thu, 6 Dec 2018 22:12:55 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFFB712008A; Thu, 6 Dec 2018 22:12:55 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1gV9Nc-00091i-FI; Fri, 07 Dec 2018 01:12:52 -0500 Date: Fri, 07 Dec 2018 01:12:47 -0500 From: John C Klensin To: =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= , Larry Masinter cc: i18nrp@ietf.org, idna-update@ietf.org, Asmus Freytag , Paul Hoffman Message-ID: <50A496896DE57696A5184DC2@PSB> In-Reply-To: <07CB0B3B-E48A-40CD-BBC9-E6CAA2FB29F0@frobbit.se> References: <154385119878.18333.5085298134102919486.idtracker@ietfa.amsl.com> <8E20D432-01B0-4B52-80BB-3348C5FE73AF@vpnc.org> <217ede0e-ea1f-bb31-a276-f8c618c71278@ix.netcom.com> <8885EE4C-412E-4337-A099-66354A36CEA1@vpnc.org> <48A2A546-4FEA-4060-8706-34D210B2ABAF@frobbit.se> <055301d48dc8$0ea95120$2bfbf360$@acm.org> <07CB0B3B-E48A-40CD-BBC9-E6CAA2FB29F0@frobbit.se> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Idna-update] [I18nrp] Last Call: (IDNA2008 and Unicode 11.0.0) to Informational RFC 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: Fri, 07 Dec 2018 06:12:58 -0000 --On Friday, December 7, 2018 05:43 +0100 Patrik = F=C3=A4ltstr=C3=B6m wrote: >... >> As I've noted before, usability includes "re-enterable" >> (including "retypable") . >=20 > I might not agree with this, as for example very few > characters in arabic script are "retypable" for me. So this is > at least a separate issue. But what the registry chooses, I > feel is up to them, as long as they do come up with a good > repertoire. Patrik, I think your second point ("up to them" as long as it is "good" --including sufficiently conservative) is the important one and the one on which we can all agree. But I still believe that, with appropriate qualification, Larry is still correct. The very decision to move in the direction of IDNs meant that there would be labels that would be much easier to read (and enter) for some populations and other labels that would be easier for a different population. It seems to me that we just have to accept that. One think it implies is that, if a label is written in a script one doesn't use frequently, "typing" may require a character-picker. Character-pickers are better than nothing but no fun at all, especially if one does not easily recognize the characters involved and differences between then (and, to save Asmus pointing it out, complex scripts may complicate both the recognition problem and the picking one). We also need to remember, as Ted Hardie and others have reminded us multiple times, that there are increasing moves toward voice input, a trend that will de-emphasize typing and, most likely, make the lives of those of us who can speak a given language only with horrible accents much more "interesting". However, to the extent to which one can sensibly use (including simple reading of the characters) a label at all at all, I think ability to re-enter it, to be assured that, insofar as possible, there are no other labels in the zone that can easily be mistaken for it, strings that are likely to be entered where it is is intended, etc., are as important to a conservative approach as things we've talked about more such as ensuring that strings are well-formed for the script and that interactions between RtoL characters and characters with neutral or LtoR directionality don't cause, e.g., labels to appear in orders that others might not predict. I hope Larry has a better (and shorter) way to formulate that than I do, which is why I'm hoping for text. best, john From nobody Thu Dec 6 22:16: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 81B22124BF6; Thu, 6 Dec 2018 22:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.722 X-Spam-Level: X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=frobbit.se 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 9t5VtEc2qTVP; Thu, 6 Dec 2018 22:16:06 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9932412008A; Thu, 6 Dec 2018 22:16:06 -0800 (PST) Received: from [192.165.72.241] (unknown [IPv6:2a02:80:3ffc:0:431:eda0:2df6:6662]) by mail.frobbit.se (Postfix) with ESMTPSA id 0F79B2353B; Fri, 7 Dec 2018 07:16:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=frobbit.se; s=mail; t=1544163364; bh=Jevz8T18iPB3wYIAlkoobfq/4bNH18HwjYSPKvyveJs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=iJbXZ6ZMdvS8QQTd/CQfE6SEcTgGhHB/83WSszH3oDYYa9fS0ln49VKT3LLcrH7Gr vG6bl9/J4j6ri2nJmevHB39idfiuuLWOlL07fFpKMvkfaPBeIE5rYXewJVm9y7M3ew KxHpNSdakVqXpQDTDq9pzzF2rIIi34JM9/lUAULg= From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "John C Klensin" Cc: "Larry Masinter" , i18nrp@ietf.org, idna-update@ietf.org, "Asmus Freytag" , "Paul Hoffman" Date: Fri, 07 Dec 2018 07:16:03 +0100 X-Mailer: MailMate (1.12.2r5568) Message-ID: In-Reply-To: <50A496896DE57696A5184DC2@PSB> References: <154385119878.18333.5085298134102919486.idtracker@ietfa.amsl.com> <8E20D432-01B0-4B52-80BB-3348C5FE73AF@vpnc.org> <217ede0e-ea1f-bb31-a276-f8c618c71278@ix.netcom.com> <8885EE4C-412E-4337-A099-66354A36CEA1@vpnc.org> <48A2A546-4FEA-4060-8706-34D210B2ABAF@frobbit.se> <055301d48dc8$0ea95120$2bfbf360$@acm.org> <07CB0B3B-E48A-40CD-BBC9-E6CAA2FB29F0@frobbit.se> <50A496896DE57696A5184DC2@PSB> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_3D7A819C-F71A-4D06-8F40-4DCD648AB53A_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [Idna-update] [I18nrp] Last Call: (IDNA2008 and Unicode 11.0.0) to Informational RFC 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: Fri, 07 Dec 2018 06:16:09 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_3D7A819C-F71A-4D06-8F40-4DCD648AB53A_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 7 Dec 2018, at 7:12, John C Klensin wrote: > But I still believe that, with appropriate qualification, Larry is stil= l correct. I think we dive into the details here. 1. I think the ability (for example) copy and paste, respond to, click on= , save in bookmarks etc is the most important global requirement 2. The ability to type, to enter via a keyboard, read on a bus, etc is se= condary and have localization issues so very much different than (1) My point was that because of this, I think retypable is very very very mu= ch different than other, global, requirements, and the latter should not = (I think) muddy the waters of the first requirement I list above. paf --=_MailMate_3D7A819C-F71A-4D06-8F40-4DCD648AB53A_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iG0EARECAC0WIQRUH/cJI8i4DDUU3qWsxpsaC4jXzQUCXAoQIw8ccGFmQGZyb2Ji aXQuc2UACgkQrMabGguI182uAgCfTE+Vo44l4Nzx+YPAaNGNf8c3RFgAoJh9kex+ NHBs/Y8diG2FwjF3UZvC =GoOL -----END PGP SIGNATURE----- --=_MailMate_3D7A819C-F71A-4D06-8F40-4DCD648AB53A_=-- From nobody Thu Dec 6 22:34:04 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 74918126DBF; Thu, 6 Dec 2018 22:34:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 26iqdXtjUZvA; Thu, 6 Dec 2018 22:34:00 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0121124BF6; Thu, 6 Dec 2018 22:33:59 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1gV9hz-000945-0F; Fri, 07 Dec 2018 01:33:55 -0500 Date: Fri, 07 Dec 2018 01:33:49 -0500 From: John C Klensin To: =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= cc: Larry Masinter , i18nrp@ietf.org, idna-update@ietf.org, Asmus Freytag , Paul Hoffman Message-ID: In-Reply-To: References: <154385119878.18333.5085298134102919486.idtracker@ietfa.amsl.com> <8E20D432-01B0-4B52-80BB-3348C5FE73AF@vpnc.org> <217ede0e-ea1f-bb31-a276-f8c618c71278@ix.netcom.com> <8885EE4C-412E-4337-A099-66354A36CEA1@vpnc.org> <48A2A546-4FEA-4060-8706-34D210B2ABAF@frobbit.se> <055301d48dc8$0ea95120$2bfbf360$@acm.org> <07CB0B3B-E48A-40CD-BBC9-E6CAA2FB29F0@frobbit.se> <50A496896DE57696A5184DC2@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Idna-update] [I18nrp] Last Call: (IDNA2008 and Unicode 11.0.0) to Informational RFC 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: Fri, 07 Dec 2018 06:34:02 -0000 --On Friday, December 7, 2018 07:16 +0100 Patrik = F=C3=A4ltstr=C3=B6m wrote: > On 7 Dec 2018, at 7:12, John C Klensin wrote: >=20 >> But I still believe that, with appropriate qualification, >> Larry is still correct. >=20 > I think we dive into the details here. >=20 > 1. I think the ability (for example) copy and paste, respond > to, click on, save in bookmarks etc is the most important > global requirement >=20 > 2. The ability to type, to enter via a keyboard, read on a > bus, etc is secondary and have localization issues so very > much different than (1) >=20 > My point was that because of this, I think retypable is very > very very much different than other, global, requirements, and > the latter should not (I think) muddy the waters of the first > requirement I list above. Agreed. However, I still have this strange idea (very clear in the now-ancient RFC 1591) that domains are expected to serve a community that if often not global, a concept that is consistent with Larry's more recent comment about "target audience". Within such an audience, the sort of criteria Larry is talking about are almost certainly helpful... again, as long as they don't interfere with the sort of global ones you identify above. Larry's criteria also make a strong argument for a clear target audience for a given zone or hierarchy. That is a problem for registries that want to be able to register labels from every possible script even if they put some restrictions on those labels, but we have known about that problem since the very first ICANN IDN study effort if not earlier. So I think there are global criteria (I like your list but imagine that we could improve it somewhat with more thought) that every label and FQDN should support and that there are relatively more local criteria that have to be evaluated against a target audience. I don't know if "primary" or "secondary" are quite the right category names, but I think we agree about the principle. It is also clear to me that, independent of anything that is done globally, someone is more likely to get themselves into trouble (or be tricked into it whether the tricks are intentional or not) with labels in a script that they find incomprehensible that with a more familiar one... and that is something we better just get used to because, beyond some point, technology won't help. best, john From nobody Thu Dec 6 22:42:10 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE7E128766; Thu, 6 Dec 2018 22:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 TZdV4yOTxpq9; Thu, 6 Dec 2018 22:41:58 -0800 (PST) Received: from catfish.maple.relay.mailchannels.net (catfish.maple.relay.mailchannels.net [23.83.214.32]) (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 CA0FD1277C8; Thu, 6 Dec 2018 22:41:56 -0800 (PST) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 91FB55C283F; Fri, 7 Dec 2018 06:41:54 +0000 (UTC) Received: from pdx1-sub0-mail-a80.g.dreamhost.com (unknown [100.96.36.160]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 2BDD95C4314; Fri, 7 Dec 2018 06:41:54 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a80.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Fri, 07 Dec 2018 06:41:54 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Share-Unite: 7f9b16c167cb11bf_1544164914380_790664945 X-MC-Loop-Signature: 1544164914380:882176227 X-MC-Ingress-Time: 1544164914380 Received: from pdx1-sub0-mail-a80.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a80.g.dreamhost.com (Postfix) with ESMTP id DB78780329; Thu, 6 Dec 2018 22:41:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=E+YC4ze/060GNxc1/Uvq3w5ijlU=; b=KoVORgtSJmp E0Aj9sZy30hcTGeTa7A5FSiOomxypAgfL1vePeczJBUt0tSEsNcZ2rbKQD7T4+hF tq86mk1SVnpIMV4N8spvYsB/zYntrd10G5uU1F/lq8nyJjyssaSGFREX2PPKb3tC tm39iE2On+0x0E6FUt8mmRCR7i4t8lb4= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a80.g.dreamhost.com (Postfix) with ESMTPSA id ED1828031E; Thu, 6 Dec 2018 22:41:49 -0800 (PST) Date: Fri, 7 Dec 2018 00:41:47 -0600 X-DH-BACKEND: pdx1-sub0-mail-a80 From: Nico Williams To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Cc: John C Klensin , i18nrp@ietf.org, idna-update@ietf.org, Asmus Freytag , Larry Masinter , Paul Hoffman Message-ID: <20181207064147.GT15561@localhost> References: <217ede0e-ea1f-bb31-a276-f8c618c71278@ix.netcom.com> <8885EE4C-412E-4337-A099-66354A36CEA1@vpnc.org> <48A2A546-4FEA-4060-8706-34D210B2ABAF@frobbit.se> <055301d48dc8$0ea95120$2bfbf360$@acm.org> <07CB0B3B-E48A-40CD-BBC9-E6CAA2FB29F0@frobbit.se> <50A496896DE57696A5184DC2@PSB> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrudefkedguddttdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggugfgjfgesthekredttderudenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Idna-update] [I18nrp] Last Call: (IDNA2008 and Unicode 11.0.0) to Informational RFC 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: Fri, 07 Dec 2018 06:42:00 -0000 On Fri, Dec 07, 2018 at 07:16:03AM +0100, Patrik F=E4ltstr=F6m wrote: > 1. I think the ability (for example) copy and paste, respond to, click > on, save in bookmarks etc is the most important global requirement +1. > 2. The ability to type, to enter via a keyboard, read on a bus, etc is > secondary and have localization issues so very much different than (1) The ability to type in domainnames you see in ads is not that interesting for the obvious reason that advertisers would not choose to use domainnames that their targets cannot type in! As to domainnames seen elsewhere than in ads... typing them in is still not that interesting: there's always OCR (just point your smartphone at it and click) and QR codes (same thing). Besides, not concerning ourselves so much with the ability to type in a domainname is a very good simplification to make. In general most of us cannot type in more than a very small number of scripts -- the ability to type in any domainname is basically an oxymoron. We couldn't even require that users only ever see A-labels, which most users (perhaps!) could type in, because that would utterly defeat the whole point of IDNA. > My point was that because of this, I think retypable is very very very > much different than other, global, requirements, and the latter should > not (I think) muddy the waters of the first requirement I list above. +1. Nico --=20 From nobody Thu Dec 6 22:45:26 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C23124BF6 for ; Thu, 6 Dec 2018 22:45:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.959 X-Spam-Level: X-Spam-Status: No, score=-18.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 1NNDPPYTsUqs for ; Thu, 6 Dec 2018 22:45:16 -0800 (PST) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 403421277C8 for ; Thu, 6 Dec 2018 22:45:14 -0800 (PST) Received: by mail-ot1-x333.google.com with SMTP id i20so2907831otl.0 for ; Thu, 06 Dec 2018 22:45:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lQYORK9SqR2gq2rMuzvmBXKTX8a3SzoLdbNNAwfDLAk=; b=fx9r6zTVW+Ed2I4sck6sln16ljjtqbfs1MboZVPYfbCcKO8B8FChK4xqxEb6oStH7D klRBkqmcmvo2H4ZCw990eRfRKL56LekzFcwgF56e8y3bisagtPnzCeAMVyT5RUe+HxrN AgALWuyzqNJoVcQgQZ20MZ76Epf5JnVCaBfR6oKqAOYCGtfsJI/+r1+3PdXXQKgYOxEx MAgl5K+HQd/gDzQlZaO8p7O6S1yeBgsEmCpApWbmM1yGZjS3U99wcD16MDpLvueSMoPb 3819s7O8tph7DhgF185yLUnA0kMOaE/Yn8mYaSFQ4ZG2Qc+XRx3z1NBCcEZUvTnU5hei pKWQ== 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=lQYORK9SqR2gq2rMuzvmBXKTX8a3SzoLdbNNAwfDLAk=; b=FTsp3oh3wZAdroNNCePTozZpddTuVKDV/NF7AZ0jQIvRyfg3GhRPkmreAbjcXSlpb2 P65iskD3swUdJ3O8IntrZUdIJyAB20tpC8fq7JSQHDaNc4tWhk/S1BlO2phbB038yxTa IwgxUx790PLvmec5vHpFU6m5UU6lj6aGdjHCJM02uU9EXM2ilPLUf2qAxEoN80hklF70 /A0YU4IQZ510hnvtSjjDm58Ex9iruN9os79Yy6GCv3//M7L/pb2g/DjV3kWeGwgUPxk1 yjQjbyFNjUMhUZkPWYQhbruOQvu9DWyFKLcGFW1Oq5IRqhCAPC1WCruobWuyqEzRvLK4 cJmg== X-Gm-Message-State: AA+aEWbuJswriRMEM4eyCIXYHgyUjfmyjXDhXeXIx0YLbwUBdIZJJlcx y7YlRnMNCROMAzUmgUW0C8vDqg4WOfZBFiHTBqU2qA== X-Google-Smtp-Source: AFSGD/V0uqOtPpCj2pZr4fhdAoFhPA/M62ZhX+dFNlAZ9ULiZH7hbEENaT90xobzgo1XRtjPyLmwpPYy5BFRFzH9vio= X-Received: by 2002:a9d:d6d:: with SMTP id 100mr655406oti.69.1544165113256; Thu, 06 Dec 2018 22:45:13 -0800 (PST) MIME-Version: 1.0 References: <217ede0e-ea1f-bb31-a276-f8c618c71278@ix.netcom.com> <8885EE4C-412E-4337-A099-66354A36CEA1@vpnc.org> <48A2A546-4FEA-4060-8706-34D210B2ABAF@frobbit.se> <055301d48dc8$0ea95120$2bfbf360$@acm.org> <07CB0B3B-E48A-40CD-BBC9-E6CAA2FB29F0@frobbit.se> <50A496896DE57696A5184DC2@PSB> <20181207064147.GT15561@localhost> In-Reply-To: <20181207064147.GT15561@localhost> From: Vint Cerf Date: Fri, 7 Dec 2018 01:45:02 -0500 Message-ID: To: nico@cryptonector.com Cc: paf=40frobbit.se@dmarc.ietf.org, Asmus Freytag , i18nrp@ietf.org, LMM@acm.org, Paul Hoffman , Klensin John , idna-update@ietf.org Content-Type: multipart/alternative; boundary="0000000000000d4049057c68f54d" Archived-At: Subject: Re: [Idna-update] [I18nrp] Last Call: (IDNA2008 and Unicode 11.0.0) to Informational RFC 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: Fri, 07 Dec 2018 06:45:18 -0000 --0000000000000d4049057c68f54d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The ability to type in domainnames you see in ads is not that interesting for the obvious reason that advertisers would not choose to use domainnames that their targets cannot type in! VGC: I am not so sure advertisers are that smart... v On Fri, Dec 7, 2018 at 1:42 AM Nico Williams wrote: > On Fri, Dec 07, 2018 at 07:16:03AM +0100, Patrik F=C3=A4ltstr=C3=B6m wrot= e: > > 1. I think the ability (for example) copy and paste, respond to, click > > on, save in bookmarks etc is the most important global requirement > > +1. > > > 2. The ability to type, to enter via a keyboard, read on a bus, etc is > > secondary and have localization issues so very much different than (1) > > The ability to type in domainnames you see in ads is not that > interesting for the obvious reason that advertisers would not > choose to use domainnames that their targets cannot type in! > > As to domainnames seen elsewhere than in ads... typing them in is still > not that interesting: there's always OCR (just point your smartphone at > it and click) and QR codes (same thing). > > Besides, not concerning ourselves so much with the ability to type in a > domainname is a very good simplification to make. In general most of us > cannot type in more than a very small number of scripts -- the ability > to type in any domainname is basically an oxymoron. We couldn't even > require that users only ever see A-labels, which most users (perhaps!) > could type in, because that would utterly defeat the whole point of > IDNA. > > > My point was that because of this, I think retypable is very very very > > much different than other, global, requirements, and the latter should > > not (I think) muddy the waters of the first requirement I list above. > > +1. > > Nico > -- > > _______________________________________________ > IDNA-UPDATE mailing list > IDNA-UPDATE@ietf.org > https://www.ietf.org/mailman/listinfo/idna-update > --=20 New postal address: Google 1875 Explorer Street, 10th Floor Reston, VA 20190 --0000000000000d4049057c68f54d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= The ability to type in domainnames you see in ads is not that
int= eresting for the obvious reason that advertisers would not
choose to use= domainnames that their targets cannot type in!

VGC:= I am not so sure advertisers are that smart...

v<= /div>


O= n Fri, Dec 7, 2018 at 1:42 AM Nico Williams <nico@cryptonector.com> wrote:
On Fri, Dec 07, 2018 at 07:16:03AM +0100, Patrik F=C3=A4lts= tr=C3=B6m wrote:
> 1. I think the ability (for example) copy and paste, respond to, click=
> on, save in bookmarks etc is the most important global requirement

+1.

> 2. The ability to type, to enter via a keyboard, read on a bus, etc is=
> secondary and have localization issues so very much different than (1)=

The ability to type in domainnames you see in ads is not that
interesting for the obvious reason that advertisers would not
choose to use domainnames that their targets cannot type in!

As to domainnames seen elsewhere than in ads... typing them in is still
not that interesting: there's always OCR (just point your smartphone at=
it and click) and QR codes (same thing).

Besides, not concerning ourselves so much with the ability to type in a
domainname is a very good simplification to make.=C2=A0 In general most of = us
cannot type in more than a very small number of scripts -- the ability
to type in any domainname is basically an oxymoron.=C2=A0 We couldn't e= ven
require that users only ever see A-labels, which most users (perhaps!)
could type in, because that would utterly defeat the whole point of
IDNA.

> My point was that because of this, I think retypable is very very very=
> much different than other, global, requirements, and the latter should=
> not (I think) muddy the waters of the first requirement I list above.<= br>
+1.

Nico
--

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


--
New postal address:
Google
1875 Explorer Street, 10th Floor=
Reston, VA 20190
--0000000000000d4049057c68f54d-- From nobody Thu Dec 6 22:50:32 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B92312875B; Thu, 6 Dec 2018 22:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 1rT4mdZjiYGl; Thu, 6 Dec 2018 22:50:22 -0800 (PST) Received: from golden.birch.relay.mailchannels.net (golden.birch.relay.mailchannels.net [23.83.209.73]) (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 9515E126DBF; Thu, 6 Dec 2018 22:50:21 -0800 (PST) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 3A6DB283A8D; Fri, 7 Dec 2018 06:50:20 +0000 (UTC) Received: from pdx1-sub0-mail-a80.g.dreamhost.com (unknown [100.96.19.78]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id A8FE6283A7E; Fri, 7 Dec 2018 06:50:16 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a80.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Fri, 07 Dec 2018 06:50:19 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Spicy-Tangy: 09a666ab3997ffb6_1544165417000_3149186966 X-MC-Loop-Signature: 1544165417000:1412774020 X-MC-Ingress-Time: 1544165416999 Received: from pdx1-sub0-mail-a80.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a80.g.dreamhost.com (Postfix) with ESMTP id 4F0968031E; Thu, 6 Dec 2018 22:50:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=bwE0GNMMzH8J7d dOxm1s+j25eOc=; b=oiQ3P6yDmyar1FnGNHR/zDn5fsVUPBFBZjqdup/vrr5PMv SjlmYI5GZin6EXIwMQdaUYjhbRfh9GL/nKltDj1JaOt80kaB7VHneNtjT9ymsdBH snZdBp8NgxjmNhvTS1RnSjcsrYkj77Uym0X7Oz431dU7Nxd07h2g1hU+TxDh8= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a80.g.dreamhost.com (Postfix) with ESMTPSA id E11CA8030B; Thu, 6 Dec 2018 22:50:10 -0800 (PST) Date: Fri, 7 Dec 2018 00:50:08 -0600 X-DH-BACKEND: pdx1-sub0-mail-a80 From: Nico Williams To: Vint Cerf Cc: paf=40frobbit.se@dmarc.ietf.org, Asmus Freytag , i18nrp@ietf.org, LMM@acm.org, Paul Hoffman , Klensin John , idna-update@ietf.org Message-ID: <20181207065006.GV15561@localhost> References: <8885EE4C-412E-4337-A099-66354A36CEA1@vpnc.org> <48A2A546-4FEA-4060-8706-34D210B2ABAF@frobbit.se> <055301d48dc8$0ea95120$2bfbf360$@acm.org> <07CB0B3B-E48A-40CD-BBC9-E6CAA2FB29F0@frobbit.se> <50A496896DE57696A5184DC2@PSB> <20181207064147.GT15561@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrudefkedguddtudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgepud Archived-At: Subject: Re: [Idna-update] [I18nrp] Last Call: (IDNA2008 and Unicode 11.0.0) to Informational RFC 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: Fri, 07 Dec 2018 06:50:25 -0000 On Fri, Dec 07, 2018 at 01:45:02AM -0500, Vint Cerf wrote: > > The ability to type in domainnames you see in ads is not that > > interesting for the obvious reason that advertisers would not > > choose to use domainnames that their targets cannot type in! > > VGC: I am not so sure advertisers are that smart... I am quite certain that they are, or if not, will be. They spend lots of money, and they hate to spend it badly. They even spend lots of money on how to spend lots more money well. Nico -- From nobody Thu Dec 6 23:27:09 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7C8124BF6; Thu, 6 Dec 2018 23:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ftBzxfpOljVe; Thu, 6 Dec 2018 23:27:05 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D832126DBF; Thu, 6 Dec 2018 23:27:05 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1gVAXM-00099t-Lf; Fri, 07 Dec 2018 02:27:00 -0500 Date: Fri, 07 Dec 2018 02:26:55 -0500 From: John C Klensin To: Nico Williams , Vint Cerf cc: =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= , Asmus Freytag , i18nrp@ietf.org, LMM@acm.org, Paul Hoffman , idna-update@ietf.org Message-ID: In-Reply-To: <20181207065006.GV15561@localhost> References: <8885EE4C-412E-4337-A099-66354A36CEA1@vpnc.org> <48A2A546-4FEA-4060-8706-34D210B2ABAF@frobbit.se> <055301d48dc8$0ea95120$2bfbf360$@acm.org> <07CB0B3B-E48A-40CD-BBC9-E6CAA2FB29F0@frobbit.se> <50A496896DE57696A5184DC2@PSB> <20181207064147.GT15561@localhost> <20181207065006.GV15561@localhost> 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] [I18nrp] Last Call: (IDNA2008 and Unicode 11.0.0) to Informational RFC 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: Fri, 07 Dec 2018 07:27:07 -0000 --On Friday, December 7, 2018 00:50 -0600 Nico Williams wrote: > On Fri, Dec 07, 2018 at 01:45:02AM -0500, Vint Cerf wrote: >> > The ability to type in domainnames you see in ads is not >> > that interesting for the obvious reason that advertisers >> > would not choose to use domainnames that their targets >> > cannot type in! >> >> VGC: I am not so sure advertisers are that smart... > > I am quite certain that they are, or if not, will be. They > spend lots of money, and they hate to spend it badly. They > even spend lots of money on how to spend lots more money well. Nico, While I tend to agree with Vint -- not because of smartness or the lack thereof but because many advertisers have, empirically, found it much cheaper to register a lot of domain names than to spend time and energy trying to protect trademarks, worrying about competitors trying to capture or squat on names, etc.-- this is not a problem we need to solve. There are many reasons why we should encourage both registrants and registries to be conservative, whether the advice we give about conservatism involves only the global criteria that Patrik believes (and I agree) should be primary or we expand that advice to include some or all of the considerations Larry, Asmus, and I have been advocating. If the labels that are actually registered (whether actively used or not) are a subset of what our conservative guidance would suggest, that is great and no harm has been done. On the other hand, we've seen names registered, and registered as SLDs as well as further down in the tree, that clearly won't meet even global criteria for conservatism and responsible behavior. much less guidance focused on relevant target communities. Some of those registrations have clearly been the result of a shortage of thinking or an excess of cleverness or cuteness, not just the result of various forms of malice. There has been a lot of the latter too and we can at least hope that more conservative registry policies would stop some of it. So I don't think an argument that we don't need to say something (and say it very clearly) about the importance of conservative behavior holds up ... and I hope you were not intending to make that argument. best, john From nobody Fri Dec 7 00:41:49 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E5712875B; Fri, 7 Dec 2018 00:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 KRpn5LUpr1_U; Fri, 7 Dec 2018 00:41:46 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17E29128766; Fri, 7 Dec 2018 00:41:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ix.netcom.com; s=dk12062016; t=1544172106; bh=pV67Q3G67DqRvI+ElkqlGGfA2tQE98Mwe0gh rTMvleE=; 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=g+mSmuwVGlY4eLkUmiLpuh/dcebBN+mof iKMN7HX2QdLEF8t7f0X4WpumFSSCcqP1ZoNx62N182jJzjB6pECHE5SqISRoAWF830I LdN2RIEau9eSQsh2VADvbEWi0sxLzvBkrvydO4g53aqAuHlZWZ9Wm+wC7mrWNa5UrqQ keUQQJlYIbNknTA+mHDZnUFkG+/Yjkpkh+E7PvttqqGLiuu2tKOwlgC7xnAU0QfUaHH hk1D4dVoEd8bXqb9hivjVtBCjEDOheo3uT32CGVL5lHoDMtIHLVInEjbpRizie2i+HW nelcycZOa9xvV7xMkzpBP3pDJC099PdYUpIEMkzlg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=ix.netcom.com; b=YgCPjfh/bTefKjth/+Xo0m4P5UWlUndEPwQeN6Qxf1gcBnAOP/maNAtyh9BaqAYta183OrFWawFevQ8difcVXtdLT2o848S1KKVIsRMLpuw1Y0uTUJIDTrL0SRs9x+SANG2W5dmUkyHHRmvay7esYyhe0PDC6pR7GamozRLmQENfcDcv5bTQrDqsqVYiR6rLuOLgyaM9Qv04ACBiPA0WgNqDtbSkGzh9KuoFHjF0q6jhqfFr3wReojnSoRuFwNTilLwroSFsB0F0SKCOSrZQ4bZWBKnzOgjFByus5p+MVjksuoybOzhEXz4ymdOkkXb4aeeyk6KLGIDgksuRg6cHjQ==; 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.171.131] (helo=[192.168.1.111]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1gVBhg-0001hQ-D1; Fri, 07 Dec 2018 03:41:44 -0500 To: John C Klensin , Larry Masinter , =?UTF-8?B?J1BhdHJpayBGw6RsdHN0csO2bSc=?= Cc: i18nrp@ietf.org, 'Paul Hoffman' , idna-update@ietf.org References: <154385119878.18333.5085298134102919486.idtracker@ietfa.amsl.com> <8E20D432-01B0-4B52-80BB-3348C5FE73AF@vpnc.org> <217ede0e-ea1f-bb31-a276-f8c618c71278@ix.netcom.com> <8885EE4C-412E-4337-A099-66354A36CEA1@vpnc.org> <48A2A546-4FEA-4060-8706-34D210B2ABAF@frobbit.se> <055301d48dc8$0ea95120$2bfbf360$@acm.org> From: "Asmus Freytag (c)" Message-ID: <4ba2e08c-48de-e68d-d761-bd27c13eda02@ix.netcom.com> Date: Fri, 7 Dec 2018 00:41:48 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E7EBC23B236005A12CC57FDF" Content-Language: en-US X-ELNK-Trace: 464f085de979d7246f36dc87813833b28d93432b0f0788b9f47340de9550aa4afcc9f05cefcfe93c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 174.21.171.131 Archived-At: Subject: Re: [Idna-update] [I18nrp] Last Call: (IDNA2008 and Unicode 11.0.0) to Informational RFC 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: Fri, 07 Dec 2018 08:41:48 -0000 This is a multi-part message in MIME format. --------------E7EBC23B236005A12CC57FDF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/6/2018 9:39 PM, John C Klensin wrote: > Part of the problem with the IDNA RFCs is that the requirement > for registry conservatism and responsibility is too scattered > through several documents to come across as important as I think > we all believe it is. draft-klensin-idna-rfc5891bis (now > expired, but waiting in the wings) was intended to address that > issue. I haven't looked at the text for a while but strongly > suspect it does not identify and stress labels being > "re-enterable" and "retypable" as you suggest. It should. If > you don't mind taking a look at it, I'd appreciate recommended > text. Or, if that isn't convenient, I'll try to remember to > say something when I next open the document. To "typable", you might add "processable" and "renderable", not to mention "human-readable". (Where multiple languages/scripts are supported, "typable" should obviously mean"typable by a native user of that language/script"). Allowing certain specialized or historical forms that are not part of the modern orthographic repertoire would allow characters that are unlikely to be supported by keyboards (or even fonts). (Some such characters are effectively not recognized by modern readers, or simply mistaken for more familiar characters). Allowing "do not use" sequences renders labels not processable by processes that do expect data to not contain effectively deprecated content.  (They are also structurally unsound, see next). Allowing structurally unsound sequences for any of the fifteen or so complex scripts risks data not being renderable, as neither layout systems or fonts are (universally) expecting to deal with them (or do it differently in unpredictable ways). T Allowing arbitrary sequences can lead to strings that human readers are not prepared to recognize because they violate deep-seated assumption of what is possible. Linearly progressing, non-connecting scripts tend to not have that issue; ASCII certainly doesn't, but already with Latin combining marks you enter territory where fully random sequences can't be supported. Then you get into the issue of substitutable code points/labels that should not be simultaneously allowed (aka "blocked" variants) -- the other type of variants ("allocatable") is more of a usability issue, which for some scripts can be critical but is not strictly required under the heading of "Conservatism". Allowing two labels that even reasonably observant readers will substitute for one another, because different abstract text elements in Unicode may have identical (or very near identical) appearance when presented in typical user interfaces, adds no value, only security risks. (Yes this is a subset of the wider issue of labels that are merely similar, but that's not an excuse to take well-known an unambiguous cases off the table at the policy level). Spelling out these considerations would go beyond what is currently scattered through the IDNA RFCs, but would be a first step to putting the Registries on notice what their responsibility actually entails. Now that we have the Root Zone LGR giving practical examples (and the emerging reference LGRs doing the same for the second level), there's less excuse for registries not doing the right thing - good approximate solutions exist. A./ --------------E7EBC23B236005A12CC57FDF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 12/6/2018 9:39 PM, John C Klensin wrote:
Part of the problem with the IDNA RFCs is that the requirement
for registry conservatism and responsibility is too scattered
through several documents to come across as important as I think
we all believe it is.   draft-klensin-idna-rfc5891bis (now
expired, but waiting in the wings) was intended to address that
issue.  I haven't looked at the text for a while but strongly
suspect it does not identify and stress labels being
"re-enterable" and "retypable" as you suggest.   It should.  If
you don't mind taking a look at it, I'd appreciate recommended
text.   Or, if that isn't convenient, I'll try to remember to
say something when I next open the document.

To "typable", you might add "processable" and "renderable", not to mention "human-readable". (Where multiple languages/scripts are supported, "typable" should obviously mean"typable by a native user of that language/script").

Allowing certain specialized or historical forms that are not part of the modern orthographic repertoire would allow characters that are unlikely to be supported by keyboards (or even fonts). (Some such characters are effectively not recognized by modern readers, or simply mistaken for more familiar characters).

Allowing "do not use" sequences renders labels not processable by processes that do expect data to not contain effectively deprecated content.  (They are also structurally unsound, see next).

Allowing structurally unsound sequences for any of the fifteen or so complex scripts risks data not being renderable, as neither layout systems or fonts are (universally) expecting to deal with them (or do it differently in unpredictable ways). T

Allowing arbitrary sequences can lead to strings that human readers are not prepared to recognize because they violate deep-seated assumption of what is possible. Linearly progressing, non-connecting scripts tend to not have that issue; ASCII certainly doesn't, but already with Latin combining marks you enter territory where fully random sequences can't be supported.

Then you get into the issue of substitutable code points/labels that should not be simultaneously allowed (aka "blocked" variants) -- the other type of variants ("allocatable") is more of a usability issue, which for some scripts can be critical but is not strictly required under the heading of "Conservatism".

Allowing two labels that even reasonably observant readers will substitute for one another, because different abstract text elements in Unicode may have identical (or very near identical) appearance when presented in typical user interfaces, adds no value, only security risks. (Yes this is a subset of the wider issue of labels that are merely similar, but that's not an excuse to take well-known an unambiguous cases off the table at the policy level).

Spelling out these considerations would go beyond what is currently scattered through the IDNA RFCs, but would be a first step to putting the Registries on notice what their responsibility actually entails.

Now that we have the Root Zone LGR giving practical examples (and the emerging reference LGRs doing the same for the second level), there's less excuse for registries not doing the right thing - good approximate solutions exist.

A./


--------------E7EBC23B236005A12CC57FDF-- From nobody Fri Dec 7 00:49:13 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8DB128BCC; Fri, 7 Dec 2018 00:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 1XtOGEdnpCcQ; Fri, 7 Dec 2018 00:49:02 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACF1D12875B; Fri, 7 Dec 2018 00:49:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ix.netcom.com; s=dk12062016; t=1544172542; bh=P8jbf8FuFNEIwFI6U7+y/21AdyJbiZREOzeb LgKcfo8=; 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=EbRHAY5L0TPwv2YTP04FZO+g0vXtAwugc h7p3EAAmnSIgrO0W255sQrOVrQokiXNdlsPh12k1A3iYFarefodzVEg0Ok9Hjs59F5i bLY5QMHNDXDqQWiGz75XJKlFy2thkNBuvYHXEGAZtzFBWg6Qu5Hd5h4UoVrqDSjpPTR yDLbStoEAxQdsBf1eKSW6xWfSlA9or1LgudhRWBK7fbdIm2HrLcujhT0/DB+qxoLvt5 wXsbb4bKVZI4BxUt00cijOYR/+ESiURusonhMBlMgry8vPAYgBhFFcO82MGcuMFlc4+ xTWdHqMVszZOfLPQg3q7WoHOuihvykD48dNEVomFA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=ix.netcom.com; b=VGEckXV9ilZHf57gnz7na3vURIhK7BwjU+5u4PQg64WCe2o1itIA2N1mdOeu6VGbBZg4V7sRLQkcYd0vgFp6PewiQNHLeleiIbXwhwYolOZl4S+Lyu5WCLeHWc3QwxspjLaPe9Q8vDYv3WP7npehff7ZFqjWsuS/jwtFNsxstCOeVLCEk18nAofjnBZ+pCovJS30oUvQvx6uo17HDGOTjiJLDgvlynP5kedADHMZIhbJ5Y6O+IV7TU2ImFanO3OP3NVIg8stsQCswG0jBbjrXPg7lzhu3e4OHCax1HOh5awiI0xcPNhEdnJP8eQjI5HSCGEjZNLHTVKY+BvfDIBYXQ==; 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.171.131] (helo=[192.168.1.111]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1gVBoi-00032P-NB; Fri, 07 Dec 2018 03:49:00 -0500 To: =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= , John C Klensin Cc: Larry Masinter , i18nrp@ietf.org, idna-update@ietf.org, Paul Hoffman References: <154385119878.18333.5085298134102919486.idtracker@ietfa.amsl.com> <8E20D432-01B0-4B52-80BB-3348C5FE73AF@vpnc.org> <217ede0e-ea1f-bb31-a276-f8c618c71278@ix.netcom.com> <8885EE4C-412E-4337-A099-66354A36CEA1@vpnc.org> <48A2A546-4FEA-4060-8706-34D210B2ABAF@frobbit.se> <055301d48dc8$0ea95120$2bfbf360$@acm.org> <07CB0B3B-E48A-40CD-BBC9-E6CAA2FB29F0@frobbit.se> <50A496896DE57696A5184DC2@PSB> From: "Asmus Freytag (c)" Message-ID: Date: Fri, 7 Dec 2018 00:49:04 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8B0677611F5CA844553A9896" Content-Language: en-US X-ELNK-Trace: 464f085de979d7246f36dc87813833b28d93432b0f0788b93885a904c614c1822ac72db6c3babba6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 174.21.171.131 Archived-At: Subject: Re: [Idna-update] [I18nrp] Last Call: (IDNA2008 and Unicode 11.0.0) to Informational RFC 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: Fri, 07 Dec 2018 08:49:05 -0000 This is a multi-part message in MIME format. --------------8B0677611F5CA844553A9896 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/6/2018 10:16 PM, Patrik Fältström wrote: > On 7 Dec 2018, at 7:12, John C Klensin wrote: > >> But I still believe that, with appropriate qualification, Larry is still correct. > I think we dive into the details here. > > 1. I think the ability (for example) copy and paste, respond to, click on, save in bookmarks etc is the most important global requirement > > 2. The ability to type, to enter via a keyboard, read on a bus, etc is secondary and have localization issues so very much different than (1) A longer reply to this in my prev. note, but I emphatically disagree. If you are dealing with a foreign language / script to you, then you will be reduced to selecting or perhaps copying; but for your own language and script (and for too many of the modern scripts) there are many possible sequences that so deeply violate the reader's expectation (or the systems' expectations) that they can effectively not be understood (read and remembered) by the users or displayed or processed by the system (or not reliably so across systems). For many scripts, allowing too much will make labels every bit as unusable as allowing too little. > > My point was that because of this, I think retypable is very very very much different than other, global, requirements, and the latter should not (I think) muddy the waters of the first requirement I list above. Your item (1) addresses much more the level of implementation of the user presentation of IDNs, and less what should be allowed in IDN labels. Apples and oranges, it seems to me. Item 1 is what the UASG should be concerned with, Item 2 is what IDNA should be concerned with (at the guidance level). A./ --------------8B0677611F5CA844553A9896 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 12/6/2018 10:16 PM, Patrik Fältström wrote:
On 7 Dec 2018, at 7:12, John C Klensin wrote:


But I still believe that, with appropriate qualification, Larry is still correct.

I think we dive into the details here.

1. I think the ability (for example) copy and paste, respond to, click on, save in bookmarks etc is the most important global requirement

2. The ability to type, to enter via a keyboard, read on a bus, etc is secondary and have localization issues so very much different than (1)

A longer reply to this in my prev. note, but I emphatically disagree.

If you are dealing with a foreign language / script to you, then you will be reduced to selecting or perhaps copying; but for your own language and script (and for too many of the modern scripts) there are many possible sequences that so deeply violate the reader's expectation (or the systems' expectations) that they can effectively not be understood (read and remembered) by the users or displayed or processed by the system (or not reliably so across systems).

For many scripts, allowing too much will make labels every bit as unusable as allowing too little.


My point was that because of this, I think retypable is very very very much different than other, global, requirements, and the latter should not (I think) muddy the waters of the first requirement I list above.

Your item (1) addresses much more the level of implementation of the user presentation of IDNs, and less what should be allowed in IDN labels. Apples and oranges, it seems to me.

Item 1 is what the UASG should be concerned with, Item 2 is what IDNA should be concerned with (at the guidance level).

A./

--------------8B0677611F5CA844553A9896-- From nobody Fri Dec 7 00:52:28 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB576129C6B; Fri, 7 Dec 2018 00:52:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 SG6H641_RhCW; Fri, 7 Dec 2018 00:52:17 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B465D130DFA; Fri, 7 Dec 2018 00:52:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ix.netcom.com; s=dk12062016; t=1544172737; bh=cbv3HJYUqqhjfNIIF46BlaToiGkG9ej6W1h6 sAJon24=; 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=RE8NMzdNck8xtleUThsedtc4efZVbL7bG WyC+aIhe4IAmIzLUrUJ5ySJmd8+gyfr14MdE+P8BIkZqTky7o+/ur5hlRz35JWN9+An kdtjFEncrAHMOnXD53WT8AF+c1hQ0tBVIjjkIGUPqPtJ9HDXAJESAGEaf+S+UoxuAMi rpfSQWxOupcxUtsnPc0u2megb1iqSDJvQm/As4m67Sju1GAuE2KIBzD+XN4s7DITCkx B09POL2bMUccAN6pjvncCqQTTiea0J81ad+F5VbE+tG9EOZxgfy65E7y0VIKiUbU12O XWUkXoyrJh7jbXdAmvay3U+9kdTgWut4wDXBD273w== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=ix.netcom.com; b=JNOA3MwVBvu+KY795yWJDDGw7ZB6HAgOt6Q6J3A+Gbd7TAxTTUHzb5SkVjXlTWocD0IsaQOg12024kUSjqjv0RDU3Kt4agCSZbqHnbo9mREpg0QT0GXBjRCT4BQLqsY9hPLvxjRsBgWzW2JHIuBhVM6mqfwNIGLMNgOm3lZ4seEfg1PGOsFS5ifDIf/lFLMjoAIQd/0q+noGsPXMR4CLE4HAKPkEZb9heAyWVyLGH3chsKlDSnsn4BvVJFKl8aDTm7sskyIzP8i1HHdGpnGqUgYCoF4q34ODsPlEjb6hBXb+T6c91nL58l50rSJFzm/h/kT9AOj2H4J2Gw1NMgtG6Q==; 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.171.131] (helo=[192.168.1.111]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1gVBrs-0003m8-EN; Fri, 07 Dec 2018 03:52:16 -0500 To: Nico Williams , Vint Cerf Cc: paf=40frobbit.se@dmarc.ietf.org, i18nrp@ietf.org, LMM@acm.org, Paul Hoffman , Klensin John , idna-update@ietf.org References: <8885EE4C-412E-4337-A099-66354A36CEA1@vpnc.org> <48A2A546-4FEA-4060-8706-34D210B2ABAF@frobbit.se> <055301d48dc8$0ea95120$2bfbf360$@acm.org> <07CB0B3B-E48A-40CD-BBC9-E6CAA2FB29F0@frobbit.se> <50A496896DE57696A5184DC2@PSB> <20181207064147.GT15561@localhost> <20181207065006.GV15561@localhost> From: "Asmus Freytag (c)" Message-ID: Date: Fri, 7 Dec 2018 00:52:20 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 In-Reply-To: <20181207065006.GV15561@localhost> Content-Type: multipart/alternative; boundary="------------0F09836A6D04F18F7B402CFE" Content-Language: en-US X-ELNK-Trace: 464f085de979d7246f36dc87813833b28d93432b0f0788b9a8c8b054378cac633bdda558333dd308350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 174.21.171.131 Archived-At: Subject: Re: [Idna-update] [I18nrp] Last Call: (IDNA2008 and Unicode 11.0.0) to Informational RFC 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: Fri, 07 Dec 2018 08:52:27 -0000 This is a multi-part message in MIME format. --------------0F09836A6D04F18F7B402CFE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 12/6/2018 10:50 PM, Nico Williams wrote: > On Fri, Dec 07, 2018 at 01:45:02AM -0500, Vint Cerf wrote: >>> The ability to type in domainnames you see in ads is not that >>> interesting for the obvious reason that advertisers would not >>> choose to use domainnames that their targets cannot type in! >> VGC: I am not so sure advertisers are that smart... > I am quite certain that they are, or if not, will be. They spend lots > of money, and they hate to spend it badly. They even spend lots of > money on how to spend lots more money well. > > Nico It may not be advertisers that use such 'broken' labels. All sorts of mischief can be created with stuff that your system won't let you type (even if you are a native user on a "native" system). A./ --------------0F09836A6D04F18F7B402CFE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 12/6/2018 10:50 PM, Nico Williams wrote:
On Fri, Dec 07, 2018 at 01:45:02AM -0500, Vint Cerf wrote:

The ability to type in domainnames you see in ads is not that
interesting for the obvious reason that advertisers would not
choose to use domainnames that their targets cannot type in!

VGC: I am not so sure advertisers are that smart...

I am quite certain that they are, or if not, will be.  They spend lots
of money, and they hate to spend it badly.  They even spend lots of
money on how to spend lots more money well.

Nico

It may not be advertisers that use such 'broken' labels. All sorts of mischief can be created with stuff that your system won't let you type (even if you are a native user on a "native" system).

A./

--------------0F09836A6D04F18F7B402CFE-- From nobody Fri Dec 7 08:42:26 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6654130E89; Fri, 7 Dec 2018 08:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 5wKy0nR_EKc0; Fri, 7 Dec 2018 08:42:22 -0800 (PST) Received: from insect.birch.relay.mailchannels.net (insect.birch.relay.mailchannels.net [23.83.209.93]) (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 B0D83130E83; Fri, 7 Dec 2018 08:42:21 -0800 (PST) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id D4F33124E4A; Fri, 7 Dec 2018 16:42:15 +0000 (UTC) Received: from pdx1-sub0-mail-a36.g.dreamhost.com (unknown [100.96.33.121]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 73282124D1D; Fri, 7 Dec 2018 16:42:14 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a36.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Fri, 07 Dec 2018 16:42:15 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Macabre-Glossy: 4a0287e84c980b47_1544200934881_1817130719 X-MC-Loop-Signature: 1544200934880:2945621577 X-MC-Ingress-Time: 1544200934880 Received: from pdx1-sub0-mail-a36.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a36.g.dreamhost.com (Postfix) with ESMTP id 085B9802E9; Fri, 7 Dec 2018 08:42:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Dl0uDB6x2CJpwe 4LLS1tGsZ0NAE=; b=VHgS/N2eTWApI3jMdbd6vvQbc/clxzd+zfbyLho8uALnDq 9aAceINnk+lOEgWRUN9ppNTOHWm2zju1PqzPjhCKI4PegW9ACE2WbbgusSS1elss HUFgBrOciTAK7fHc6/PizVWJRAykMPAXeoelZwN+HkJb4TvcNOCBIFV2+FQv4= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a36.g.dreamhost.com (Postfix) with ESMTPSA id D3D7B802E2; Fri, 7 Dec 2018 08:42:09 -0800 (PST) Date: Fri, 7 Dec 2018 10:42:07 -0600 X-DH-BACKEND: pdx1-sub0-mail-a36 From: Nico Williams To: John C Klensin Cc: Vint Cerf , Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= , Asmus Freytag , i18nrp@ietf.org, LMM@acm.org, Paul Hoffman , idna-update@ietf.org Message-ID: <20181207164206.GW15561@localhost> References: <48A2A546-4FEA-4060-8706-34D210B2ABAF@frobbit.se> <055301d48dc8$0ea95120$2bfbf360$@acm.org> <07CB0B3B-E48A-40CD-BBC9-E6CAA2FB29F0@frobbit.se> <50A496896DE57696A5184DC2@PSB> <20181207064147.GT15561@localhost> <20181207065006.GV15561@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrudefledgkeelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: Re: [Idna-update] [I18nrp] Last Call: (IDNA2008 and Unicode 11.0.0) to Informational RFC 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: Fri, 07 Dec 2018 16:42:24 -0000 On Fri, Dec 07, 2018 at 02:26:55AM -0500, John C Klensin wrote: > While I tend to agree with Vint -- not because of smartness or > the lack thereof but because many advertisers have, empirically, > found it much cheaper to register a lot of domain names than to > spend time and energy trying to protect trademarks, worrying > about competitors trying to capture or squat on names, etc.-- But what has that got to do with whether advertisers are smart enough to use domainnames in advertisements that users can type in? > this is not a problem we need to solve. There are many reasons Good. Not having to solve it is a big win. > why we should encourage both registrants and registries to be > conservative, whether the advice we give about conservatism Indeed. I've long been saying that registries should produce policies appropriate to their domains. > involves only the global criteria that Patrik believes (and I > agree) should be primary or we expand that advice to include > some or all of the considerations Larry, Asmus, and I have been > advocating. If the labels that are actually registered (whether > actively used or not) are a subset of what our conservative > guidance would suggest, that is great and no harm has been done. Yes. Registrants might not agree, but they can always negotiate with the registries or pick a registry that works for them. > On the other hand, we've seen names registered, and registered > as SLDs as well as further down in the tree, that clearly won't > meet even global criteria for conservatism and responsible > behavior. much less guidance focused on relevant target > communities. Some of those registrations have clearly been the > result of a shortage of thinking or an excess of cleverness or > cuteness, not just the result of various forms of malice. There > has been a lot of the latter too and we can at least hope that > more conservative registry policies would stop some of it. So > I don't think an argument that we don't need to say something > (and say it very clearly) about the importance of conservative > behavior holds up ... and I hope you were not intending to make > that argument. I only said that we shouldn't have to address the side-of-the-bus problem. You seem to have read into that more than I wrote, or perhaps you're remembering things I've said before? Registry policies that apply all the way down the tree would be an innovation. I'm not sure how I feel about that yet. I do recognize the problems with confusables, but as I've said before, that feels like a losing battle. Nico -- From nobody Fri Dec 7 08:46:09 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABE8130E8D; Fri, 7 Dec 2018 08:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 ydwjPvFV49V6; Fri, 7 Dec 2018 08:45:57 -0800 (PST) Received: from ladybird.maple.relay.mailchannels.net (ladybird.maple.relay.mailchannels.net [23.83.214.98]) (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 17F17130E8B; Fri, 7 Dec 2018 08:45:57 -0800 (PST) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 999F0283970; Fri, 7 Dec 2018 16:45:55 +0000 (UTC) Received: from pdx1-sub0-mail-a36.g.dreamhost.com (unknown [100.96.30.62]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 1BA34283724; Fri, 7 Dec 2018 16:45:55 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a36.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Fri, 07 Dec 2018 16:45:55 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Versed-Army: 788b113317dfddff_1544201155443_3340140798 X-MC-Loop-Signature: 1544201155443:1374311343 X-MC-Ingress-Time: 1544201155443 Received: from pdx1-sub0-mail-a36.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a36.g.dreamhost.com (Postfix) with ESMTP id BDB5A802EA; Fri, 7 Dec 2018 08:45:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Atp1orYllMtftz erhf9Hnyz46pQ=; b=a65S/0vatIvokQlxyG7dB9l0imu5Vt2/pFw7s98ShJEip2 wTn9iz771W26sx8IACyorKKJ4dpztT2iSxohmH65Mo7OTw/FZ1QEz/yw4tGOYGj6 3SVtNzXrrmleQGuwRKOvqNtrRMXBNbT32mc1C81UYZsMOeNmSuO4bIgPxskNU= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a36.g.dreamhost.com (Postfix) with ESMTPSA id CED7A802E6; Fri, 7 Dec 2018 08:45:49 -0800 (PST) Date: Fri, 7 Dec 2018 10:45:47 -0600 X-DH-BACKEND: pdx1-sub0-mail-a36 From: Nico Williams To: "Asmus Freytag (c)" Cc: Vint Cerf , paf=40frobbit.se@dmarc.ietf.org, i18nrp@ietf.org, LMM@acm.org, Paul Hoffman , Klensin John , idna-update@ietf.org Message-ID: <20181207164546.GX15561@localhost> References: <48A2A546-4FEA-4060-8706-34D210B2ABAF@frobbit.se> <055301d48dc8$0ea95120$2bfbf360$@acm.org> <07CB0B3B-E48A-40CD-BBC9-E6CAA2FB29F0@frobbit.se> <50A496896DE57696A5184DC2@PSB> <20181207064147.GT15561@localhost> <20181207065006.GV15561@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrudefledgleduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: Re: [Idna-update] [I18nrp] Last Call: (IDNA2008 and Unicode 11.0.0) to Informational RFC 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: Fri, 07 Dec 2018 16:45:59 -0000 On Fri, Dec 07, 2018 at 12:52:20AM -0800, Asmus Freytag (c) wrote: > On 12/6/2018 10:50 PM, Nico Williams wrote: > >On Fri, Dec 07, 2018 at 01:45:02AM -0500, Vint Cerf wrote: > >>>The ability to type in domainnames you see in ads is not that > >>>interesting for the obvious reason that advertisers would not > >>>choose to use domainnames that their targets cannot type in! > >>VGC: I am not so sure advertisers are that smart... > > > >I am quite certain that they are, or if not, will be. They spend > >lots of money, and they hate to spend it badly. They even spend lots > >of money on how to spend lots more money well. > > It may not be advertisers that use such 'broken' labels. All sorts of > mischief can be created with stuff that your system won't let you type > (even if you are a native user on a "native" system). Anyone who wants their target audience to be able to type in a label will pick labels wisely. Anyone who does not care whether their target audience is able to type in a label will be free to construct more interesting labels. I see nothing wrong with that. Of course, we weren't discussing malicious use of confusables. That's another story. Nico -- From nobody Fri Dec 7 10:19:58 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF1A130FE4; Fri, 7 Dec 2018 10:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.461 X-Spam-Level: X-Spam-Status: No, score=-3.461 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 XqoIjIF2Ssgp; Fri, 7 Dec 2018 10:19:52 -0800 (PST) Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-eopbgr720097.outbound.protection.outlook.com [40.107.72.97]) (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 E0082130FB4; Fri, 7 Dec 2018 10:19:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3biDsRDsAMzY+BfBzku4Me3lLZo0OFiFg3iinu+HzlM=; b=PiU9WmrTxlh3FRrIoADu+2TWamdnua/RfXGzyOyiUXyqtkBjiyphPAqSn6hPaxJ3tdTL0HVYAggGgM4TwF6vUaSLl3vfTtG0xcxuMmdauSdVJ5qQYh++50L2aBArw7s0FNjTnUR2TYRNKlhWbkq0O67HvuQEprfrUS9XIpj8NIk= Received: from MWHPR21MB0767.namprd21.prod.outlook.com (10.173.51.21) by MWHPR21MB0143.namprd21.prod.outlook.com (10.173.52.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1425.1; Fri, 7 Dec 2018 18:19:50 +0000 Received: from MWHPR21MB0767.namprd21.prod.outlook.com ([fe80::f5b1:1a63:ddc1:c44a]) by MWHPR21MB0767.namprd21.prod.outlook.com ([fe80::f5b1:1a63:ddc1:c44a%17]) with mapi id 15.20.1425.009; Fri, 7 Dec 2018 18:19:50 +0000 From: Shawn Steele To: John C Klensin , =?utf-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= , Larry Masinter CC: "i18nrp@ietf.org" , "idna-update@ietf.org" , Asmus Freytag , Paul Hoffman Thread-Topic: [Idna-update] [I18nrp] Last Call: (IDNA2008 and Unicode 11.0.0) to Informational RFC Thread-Index: AQHUjfPflcATwHfj802clQL9UlFOEaVzlc9A Date: Fri, 7 Dec 2018 18:19:50 +0000 Message-ID: References: <154385119878.18333.5085298134102919486.idtracker@ietfa.amsl.com> <8E20D432-01B0-4B52-80BB-3348C5FE73AF@vpnc.org> <217ede0e-ea1f-bb31-a276-f8c618c71278@ix.netcom.com> <8885EE4C-412E-4337-A099-66354A36CEA1@vpnc.org> <48A2A546-4FEA-4060-8706-34D210B2ABAF@frobbit.se> <055301d48dc8$0ea95120$2bfbf360$@acm.org> <07CB0B3B-E48A-40CD-BBC9-E6CAA2FB29F0@frobbit.se> <50A496896DE57696A5184DC2@PSB> In-Reply-To: <50A496896DE57696A5184DC2@PSB> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:2:b9b5:ca80:c5af:b24c] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0143; 6:1RxjAOnQY/3Lv/4e2h9UcJdFYEk0upWVu4vAp356iu1Ycgc9SAH9bNfm0gU28PG6uiwEDBioBe1f5Cvw0LEMUuOAQXJC9ZLfzlMXqN+cTeWRAaq3MSXZc2d7drRg8/LVEkT6QY3zz9IWFCpbzTQFHmGv3Ewy3Zi9r8yEtqN+Sgu2suIB4h0Y0M6mcuosjo5/kB+XP1bIPjUG3QZ3X2YZHVJP6y866QD41loP59DM+4xVdOo19y/sezUqHvUkvDpIcAm+rNKQnorLS4QM2peVWBMa6iNw50tGRACsArWVzWTNa1tr4RgB31gLqFD5ctenAlLHrh1YnaHIqrh6ILO5Gflv7mp5BinUHJyQGIAePnWzSc//LleSThFSRTIR/rMg8ReA92ChxzSbYJp6KkiD9hmivPu5dD/qKIOEWi4xUG9dmvGF3iUmxQlpJ++TqWs+PGADa521KFe1y4DcWP9iyA==; 5:AFa1Xl+X1jHSc4YnFLIXpAFxAPZ6vDdBCjxridtJMBtydbf5HnwpqON4cCbuNe0kJVA1g+VMNxzWnB3ZiED57khj+Kr4KNzSOKz52vTtfXr7nHRhRTHCpKlR6nxNK5UfilgBAu/KKLuYF8n6mdzyJPrW92+x9s7FQLBNpvifvcE=; 7:7GqHHJB5sDnsaoNbWhuNsRqvUSVsmaf+IYxVaMuizXFD/gRXiVbcOsxkbQV4HhEFQcD9vD13u5nAMoRJU1lhj7X17ylsbRDtxMfmXDnliPS06W8b+7oDK9XFsYMC2pnivj9liHdz2mZSVSNh25esBw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 34b1e3a4-f415-46fb-a090-08d65c7093b3 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MWHPR21MB0143; x-ms-traffictypediagnostic: MWHPR21MB0143: x-ms-exchange-purlcount: -3 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Shawn.Steele@microsoft.com; x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230011)(999002)(6040522)(8220035)(2401047)(8121501046)(5005006)(3231466)(944501520)(2018427008)(10201501046)(3002001)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:MWHPR21MB0143; BCL:0; PCL:0; RULEID:; SRVR:MWHPR21MB0143; x-forefront-prvs: 0879599414 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(346002)(396003)(39860400002)(376002)(199004)(189003)(14454004)(478600001)(97736004)(25786009)(5660300001)(106356001)(6436002)(68736007)(72206003)(105586002)(86612001)(102836004)(6506007)(7696005)(99286004)(76176011)(10290500003)(74316002)(86362001)(4326008)(93886005)(10090500001)(110136005)(22452003)(54906003)(316002)(229853002)(9686003)(55016002)(53936002)(6246003)(8936002)(81156014)(8676002)(81166006)(6116002)(186003)(46003)(305945005)(71200400001)(71190400001)(446003)(11346002)(33656002)(7736002)(8990500004)(256004)(486006)(2906002)(476003); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0143; H:MWHPR21MB0767.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: CSXGQ6Lv8OZtM+Imc1vYbQA6sraI0j2sGFGMU57WKu0YIX/VDkIJx02W3Py67v1C5xdCWdPfLrM0hzHJZmC5UOrP/0gIcHVVS/r7Pt+i9cPsGhbG3JGIq/na6+AuQ2uREbV1OvLssM5Wor0QXmWJrTSsghNbYBv291fSqElg+JTEOF9h5YqgvTAGfKCJqAkOOmE+nq6c3PjtFn6Mu1lx01MxUmoFTUSxzE8AB0gpTk1JcZg/IYxr0WAH5d65wFr9Sg4vLclVYjJkQJagQ5OETsxflRpXOgTigA5SPB75eQLhxzLZCIuu7BGE5YGtOv+F8c9YQreXaOHfnyqol4+mBdMlEaUrqB6twkYOv93UoJQ= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 34b1e3a4-f415-46fb-a090-08d65c7093b3 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Dec 2018 18:19:50.1900 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0143 Archived-At: Subject: Re: [Idna-update] [I18nrp] Last Call: (IDNA2008 and Unicode 11.0.0) to Informational RFC 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: Fri, 07 Dec 2018 18:19:56 -0000 Pi4uLg0KPj4gQXMgSSd2ZSBub3RlZCBiZWZvcmUsIHVzYWJpbGl0eSBpbmNsdWRlcyAicmUtZW50 ZXJhYmxlIg0KPj4gKGluY2x1ZGluZyAicmV0eXBhYmxlIikgLg0KPiANCj4gSSBtaWdodCBub3Qg YWdyZWUgd2l0aCB0aGlzLCBhcyBmb3IgZXhhbXBsZSB2ZXJ5IGZldyBjaGFyYWN0ZXJzIGluIA0K PiBhcmFiaWMgc2NyaXB0IGFyZSAicmV0eXBhYmxlIiBmb3IgbWUuIFNvIHRoaXMgaXMgYXQgbGVh c3QgYSBzZXBhcmF0ZSANCj4gaXNzdWUuIEJ1dCB3aGF0IHRoZSByZWdpc3RyeSBjaG9vc2VzLCBJ IGZlZWwgaXMgdXAgdG8gdGhlbSwgYXMgbG9uZyBhcyANCj4gdGhleSBkbyBjb21lIHVwIHdpdGgg YSBnb29kIHJlcGVydG9pcmUuDQoNCklNTyB0aGF0J3Mgbm90IGEgcmVxdWlyZW1lbnQgZm9yIG5v bi1sYW5ndWFnZS1zcGVha2Vycy4gIFRoZSBpbnRlbnQgb2YgSUROIGlzIHRvIGVuYWJsZSBsYW5n dWFnZSBjb21tdW5pdGllcyB0byB1c2UgdGhlaXIgb3duIHNlcnZpY2VzLCBub3QgbmVjZXNzYXJp bHkgdGhhdCBhbGwgcmVzb3VyY2VzIGJlIGFjY2Vzc2libGUgdG8gdXNlcnMgb2YgYW55IG90aGVy IGxhbmd1YWdlLg0KDQpSZXNvdXJjZXMgdGhhdCBhcmUga2VlbiB0byBwcm92aWRlIGNvbnRlbnQg bW9yZSBicm9hZGx5IHdvdWxkLCBJIHRoaW5rLCBiZXN0IGJlIHNlcnZlZCBieSB1c2luZyBtdWx0 aXBsZSBuYW1lcywgd2l0aCBsb2NhbGl6ZWQgb25lcyBmb3IgbmF0aXZlIHNwZWFrZXIgdXNhYmls aXR5IGFuZCBwZXJoYXBzIGFuIEFTQ0lJIG9uZSBmb3IgdGhlIGludGVybmF0aW9uYWwgYXVkaWVu Y2UuDQoNCkkgY291bGQgZXZlbiBpbWFnaW5lIHNvbWV0aGluZyBsaWtlIGEgY29tcGFueSB3aXRo IGEgTW9uZ29saWFuIFVSTCBmb3IgTW9uZ29saWFuIHNwZWFrZXJzLCBhIFNpbXBsaWZpZWQgQ2hp bmVzZSBVUkwgZm9yIHRoZSByZXN0IG9mIHRoZWlyIENoaW5lc2UgY3VzdG9tZXJzLCBhbmQgYW4g QVNDSUkgVVJMIGZvciB0aGVpciBpbnRlcm5hdGlvbmFsIHBhcnRuZXJzLg0KDQotU2hhd24NCg== From nobody Fri Dec 7 10:24:08 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 9F8DC130F93; Fri, 7 Dec 2018 10:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.638 X-Spam-Level: X-Spam-Status: No, score=-1.638 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 lxPQ9O4XJXCP; Fri, 7 Dec 2018 10:23:59 -0800 (PST) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 050A0130F99; Fri, 7 Dec 2018 10:23:56 -0800 (PST) Received: by mail-pg1-x531.google.com with SMTP id y4so2052641pgc.12; Fri, 07 Dec 2018 10:23:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-language:thread-index; bh=JBpEv0D44kqBUsCRDOVu0DlXBXJGG7Y0u7QtiGI18Bk=; b=apsILcQED1EqZ5+TrmMcKJd4vP1b1Lby1mC5TDcWb4lZEmLWQvESQFJqSqzvRnung4 Zojd+LevZBiolWUn6qoZwuNTyABMk+Ptl9MKEwO0ShXz1/e2A4G/n0JoCJLXp5oM0osr kVygUX+04hHHyuPlLNdZakQTshYcL9Y5Z6G0VLsi1rJb9INj19pehhOX9/ILWE7PRyiK F8OyedxDp3cmVjBa+Bu6y23x9gd1uwKlkABLebCyucfzhbNUUrFuKMRiqOiJhuRu6xvL JYv50o8bDvQvw+cdt/E5+GaXITMeABorkVDUj5aNrVRWrTsoO+qIHHwwGKljf8wk0RNq paAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:content-language:thread-index; bh=JBpEv0D44kqBUsCRDOVu0DlXBXJGG7Y0u7QtiGI18Bk=; b=B3JbuA6grgPhDfuEeFWAlXf0vQ1jSA7z9nANFOiNVTYK1DS+yX4zQE1sR8PCTiEDc7 gfqrHCU9DGYVCjFRWqfnAjsbKUL9+PqW3cQUH0bMUASHb1MXjJnS6JGIdhHX36PuyBoh TWRZQb+bIzj/8Q19gi0/XD/6YrRa4G3GfDoQGls/IiTTFDWzAckw1HG4eLF6iw/HmVHP nD/Sb5q/zJlaUXGsNFX13PDeHK1RhK/0t9ixmyXcBneKYIfC2uB0dNnila7oY+S0JAlX dCWpMsiA3Cwcvwu3gZWsAGClzvQP/OwXNXYUmD0/KYe/DHXIc+ZjXI0/e6/ZOv1v0k/l mzUQ== X-Gm-Message-State: AA+aEWb6ufFY4aPYjQr/+NteDL5wRjO8Q5yr/4F/ri7/FHOvQSSTEeZT F5RhCDTHcJBQ7sHryHbCo2M= X-Google-Smtp-Source: AFSGD/VvLkYr94cIZWFaltBZ/YjUKDy0iNaCcpSYQaWPAWRtyzvYXv2REDGSpX0jHZHZLKGXyCeZrg== X-Received: by 2002:a63:5455:: with SMTP id e21mr2924800pgm.316.1544207035173; Fri, 07 Dec 2018 10:23:55 -0800 (PST) Received: from TVPC (c-24-6-174-39.hsd1.ca.comcast.net. [24.6.174.39]) by smtp.gmail.com with ESMTPSA id v14sm10358664pgf.3.2018.12.07.10.23.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Dec 2018 10:23:53 -0800 (PST) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: "'Asmus Freytag \(c\)'" , =?utf-8?Q?'Patrik_F=C3=A4ltstr=C3=B6m'?= , "'John C Klensin'" Cc: , , "'Paul Hoffman'" References: <154385119878.18333.5085298134102919486.idtracker@ietfa.amsl.com> <8E20D432-01B0-4B52-80BB-3348C5FE73AF@vpnc.org> <217ede0e-ea1f-bb31-a276-f8c618c71278@ix.netcom.com> <8885EE4C-412E-4337-A099-66354A36CEA1@vpnc.org> <48A2A546-4FEA-4060-8706-34D210B2ABAF@frobbit.se> <055301d48dc8$0ea95120$2bfbf360$@acm.org> <07CB0B3B-E48A-40CD-BBC9-E6CAA2FB29F0@frobbit.se> <50A496896DE57696A5184DC2@PSB> In-Reply-To: Date: Fri, 7 Dec 2018 10:23:53 -0800 Message-ID: <005401d48e5a$02d08d90$0871a8b0$@acm.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0055_01D48E16.F4ADE9D0" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us thread-index: AQLuHH7V14krpZsNZ4Fo+NzUu7802gGsbo1pAc2pzv8Bi4XfCAIpje2WAfWJ+7wBzjyAXAG8g2e4AkfNvv0DFpL47wJLefS0Ak+F4gICCo1moQC5ku1oAf4uqzSiZSE4EA== Archived-At: Subject: Re: [Idna-update] [I18nrp] Last Call: (IDNA2008 and Unicode 11.0.0) to Informational RFC 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: Fri, 07 Dec 2018 18:24:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0055_01D48E16.F4ADE9D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Look at RFC1736 , Functional Recommendations for Internet Resource = Locators=E2=80=9D, section 4.6: Locators are human transcribable https://tools.ietf.org/html/rfc1736#section-4.6 Users can copy Internet locators from one medium to another (such as voice to paper, or paper to keyboard) without loss or corruption of information. This process is not required to be comfortable. Changing Internet locators to allow for Internationalization need not = necessarily eliminate this valuable property. Larry -- https://LarryMasinter.net =20 From: Asmus Freytag (c) =20 Sent: Friday, December 7, 2018 12:49 AM To: Patrik F=C3=A4ltstr=C3=B6m ; John C Klensin = Cc: Larry Masinter ; i18nrp@ietf.org; idna-update@ietf.org; = Paul Hoffman Subject: Re: [I18nrp] Last Call: = (IDNA2008 and Unicode 11.0.0) to Informational RFC =20 On 12/6/2018 10:16 PM, Patrik F=C3=A4ltstr=C3=B6m wrote: On 7 Dec 2018, at 7:12, John C Klensin wrote: =20 But I still believe that, with appropriate qualification, Larry is still = correct. =20 I think we dive into the details here. =20 1. I think the ability (for example) copy and paste, respond to, click = on, save in bookmarks etc is the most important global requirement =20 2. The ability to type, to enter via a keyboard, read on a bus, etc is = secondary and have localization issues so very much different than (1) A longer reply to this in my prev. note, but I emphatically disagree. If you are dealing with a foreign language / script to you, then you = will be reduced to selecting or perhaps copying; but for your own = language and script (and for too many of the modern scripts) there are = many possible sequences that so deeply violate the reader's expectation = (or the systems' expectations) that they can effectively not be = understood (read and remembered) by the users or displayed or processed = by the system (or not reliably so across systems). For many scripts, allowing too much will make labels every bit as = unusable as allowing too little. =20 =20 My point was that because of this, I think retypable is very very very = much different than other, global, requirements, and the latter should = not (I think) muddy the waters of the first requirement I list above. Your item (1) addresses much more the level of implementation of the = user presentation of IDNs, and less what should be allowed in IDN = labels. Apples and oranges, it seems to me. Item 1 is what the UASG should be concerned with, Item 2 is what IDNA = should be concerned with (at the guidance level). A./ ------=_NextPart_000_0055_01D48E16.F4ADE9D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Look at RFC1736 = , Functional Recommendations for Internet Resource Locators=E2=80=9D, = section 4.6: Locators are human = transcribable

https://tools.ie= tf.org/html/rfc1736#section-4.6

=C2=A0=C2=A0 Users can copy Internet locators from one medium to = another (such as

=C2=A0=C2=A0 voice = to paper, or paper to keyboard) without loss or corruption = of

=C2=A0=C2=A0 = information.=C2=A0 This process is not required to be = comfortable.

Changing Internet locators to allow for = Internationalization need not necessarily eliminate this valuable = property.

Larry
--
https://LarryMasinter.net

 

From: Asmus Freytag (c) = <asmusf@ix.netcom.com>
Sent: Friday, December 7, 2018 = 12:49 AM
To: Patrik F=C3=A4ltstr=C3=B6m = <paf@frobbit.se>; John C Klensin = <john@jck.com>
Cc: Larry Masinter <LMM@acm.org>; = i18nrp@ietf.org; idna-update@ietf.org; Paul Hoffman = <paul.hoffman@vpnc.org>
Subject: Re: [I18nrp] Last Call: = <draft-faltstrom-unicode11-05.txt> (IDNA2008 and Unicode 11.0.0) = to Informational RFC

 

On = 12/6/2018 10:16 PM, Patrik F=C3=A4ltstr=C3=B6m = wrote:

On 7 Dec 2018, at =
7:12, John C Klensin =
wrote:
 
But I still believe =
that, with appropriate qualification, Larry is still =
correct.
 
I =
think we dive into the details =
here.
 
1. I think the =
ability (for example) copy and paste, respond to, click on, save in =
bookmarks etc is the most important global =
requirement
 
2. The =
ability to type, to enter via a keyboard, read on a bus, etc is =
secondary and have localization issues so very much different than =
(1)

A longer reply to this in my prev. = note, but I emphatically disagree.

If you are dealing = with a foreign language / script to you, then you will be reduced to = selecting or perhaps copying; but for your own language and script (and = for too many of the modern scripts) there are many possible sequences = that so deeply violate the reader's expectation (or the systems' = expectations) that they can effectively not be understood (read and = remembered) by the users or displayed or processed by the system (or not = reliably so across systems).

For many scripts, allowing = too much will make labels every bit as unusable as allowing too = little.

 
 
My point was that because of this, I =
think retypable is very very very much different than other, global, =
requirements, and the latter should not (I think) muddy the waters of =
the first requirement I list above.

Your = item (1) addresses much more the level of implementation of the user = presentation of IDNs, and less what should be allowed in IDN labels. = Apples and oranges, it seems to me.

Item 1 is what the = UASG should be concerned with, Item 2 is what IDNA should be concerned = with (at the guidance = level).

A./

------=_NextPart_000_0055_01D48E16.F4ADE9D0-- From nobody Mon Dec 10 00:41: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 D27A0130F02; Mon, 10 Dec 2018 00:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTQ7iFXJAzEc; Mon, 10 Dec 2018 00:41:20 -0800 (PST) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-eopbgr1400110.outbound.protection.outlook.com [40.107.140.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CB82130F00; Mon, 10 Dec 2018 00:41:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=28zXJ9UOljSzVlgt1efi+L01QGNDILumOLrAVN/2AKU=; b=pjazawUhZCNdoghvcrrY26Ma20QEOt/61cMyrgvIk7rlwQEb9GKQTnhhvsHRu1XntrFK0jeBFvNNrsiRbuQo3dWgSQ78mJb26Gnq7o8qo7nBd1nEzSvUtiY20HOAlO2myu1Nn98lGs+Kn5I+yru/HU/vw1TGMV4jZZEibqevpxs= Received: from OSAPR01MB4434.jpnprd01.prod.outlook.com (20.179.176.23) by OSAPR01MB2675.jpnprd01.prod.outlook.com (52.134.248.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1404.19; Mon, 10 Dec 2018 08:41:17 +0000 Received: from OSAPR01MB4434.jpnprd01.prod.outlook.com ([fe80::7847:bb06:297e:c78b]) by OSAPR01MB4434.jpnprd01.prod.outlook.com ([fe80::7847:bb06:297e:c78b%5]) with mapi id 15.20.1404.026; Mon, 10 Dec 2018 08:41:17 +0000 From: =?utf-8?B?TWFydGluIEouIETDvHJzdA==?= To: Nico Williams CC: "i18nrp@ietf.org" , "idna-update@ietf.org" Thread-Topic: [I18nrp] [Idna-update] Last Call: (IDNA2008 and Unicode 11.0.0) to Informational RFC Thread-Index: AQHUkGQdu2kB38MsU0uVdCn1+RWw0g== Date: Mon, 10 Dec 2018 08:41:17 +0000 Message-ID: References: <48A2A546-4FEA-4060-8706-34D210B2ABAF@frobbit.se> <055301d48dc8$0ea95120$2bfbf360$@acm.org> <07CB0B3B-E48A-40CD-BBC9-E6CAA2FB29F0@frobbit.se> <50A496896DE57696A5184DC2@PSB> <20181207064147.GT15561@localhost> <20181207065006.GV15561@localhost> <20181207164546.GX15561@localhost> In-Reply-To: <20181207164546.GX15561@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: KAWPR01CA0073.jpnprd01.prod.outlook.com (2603:1096:402:b::33) To OSAPR01MB4434.jpnprd01.prod.outlook.com (2603:1096:604:60::23) authentication-results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [133.2.210.64] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; OSAPR01MB2675; 6:ee1ZmAAQe0x34HTfJpiJJpuP63JZOLu/BjDCdVs2LHeU0IO38do140qX9v4kod7KhR8njcGWmOsTsVzWKp0XYcn2XNHANUkq3r9dgZQHdTozQdau4zOe99jtbF7GCIJM8h/TqAvM2HfRsDWk2UP3xVZWR3GMVvm20hOK8Oc+GQ6DfsT3ngot1KSFFQwNZRXDNRRTzX43Lf8Z1/joxUdc9mxVxIfykwSwr4ChTYztRGl7Ige2E6wyXV0v+ulNJIiFadOmgSRsVxNjlwdCrOBh+Fle0gjzcx/Gxx/wmhcT/K+8XSVmCt9XS8uiXfAEi2/q9ylwea1+aic+CDe8vLvar4e1XcoZOKdKkKXYIHbKC5tChWmUNzLDlY/otyIHv2E9NUQHdE4ihO2mIGmq2aiOX2OyTs14qxAydqhryqMWWUZDybM9be+t5QaRWmHw9WB+nciJZi8nr47spwZl0WdkhA==; 5:DnvwzxZMVUJ4/WYpjmEsPDz9O7ggKh2Jiwpxi8uvJk+tOydEfSbVRYiPPHcnMaqi17+B2A2HD6/GBc8Tc8g3GH9REXbOseKLzeN1Ej728KBWNfbQujQc/dhOOEiPnbgPznqiupkJgYDYjCvQhizcZUycwrVXtIm78hlurPq88TI=; 7:j5aq0e7eH56+v2QtHjjFn0NlKBrNHMDeqQvgBoUNuk4/BVBLqyaUHOaNxIsDJxSoxxc54GLO5mCUI7sTJ2QpTH2rg+xbrSEcFf/8cfq1GNH+XUKIvdPdQ3lUkxKHGA9FjMxlpJssmrH5KwzTU13jiQ== x-ms-office365-filtering-correlation-id: a2a2d7ce-fc2f-45e6-3706-08d65e7b404c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(7021145)(8989299)(5600074)(711020)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7025125)(7024125)(7027125)(7023125)(2017052603328)(7153060)(7193020); SRVR:OSAPR01MB2675; x-ms-traffictypediagnostic: OSAPR01MB2675: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231455)(999002)(944501520)(52105112)(3002001)(148016)(149066)(150057)(6041310)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(2016111802025)(6043046)(201708071742011)(7699051)(76991095); SRVR:OSAPR01MB2675; BCL:0; PCL:0; RULEID:; SRVR:OSAPR01MB2675; x-forefront-prvs: 08828D20BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(366004)(39840400004)(396003)(136003)(199004)(189003)(786003)(6506007)(6116002)(316002)(53546011)(53936002)(11346002)(93886005)(6512007)(476003)(8676002)(386003)(102836004)(14444005)(508600001)(4326008)(81156014)(3846002)(6246003)(76176011)(256004)(14454004)(446003)(26005)(68736007)(52116002)(5660300001)(31696002)(186003)(2906002)(15650500001)(8936002)(85182001)(74482002)(99286004)(86362001)(54906003)(2616005)(97736004)(66066001)(6436002)(71200400001)(81166006)(486006)(71190400001)(25786009)(6916009)(305945005)(229853002)(85202003)(106356001)(105586002)(6486002)(31686004)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:OSAPR01MB2675; H:OSAPR01MB4434.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) x-microsoft-antispam-message-info: rktVrDaQSUXbHw743Iqxypm8oma9RMuWE/MYg2wAZ6X9F0LZVnQBRzUN5FQyHQng/gfalhTaZ6pj4lL3rHnWhEX+75XnUZeaK+hn+jURZa77HBKfjsIocYdMbHRVFdCTGld+flTMNQP+3muzzdid9SP1hruI0XzG8UeK+lZD3ZZ8x4YTBQpzkiTXg2+6dpSEJ3HDhyeMuoRHxrxxDmb2Zm+Cfg/2vt0Vpj/L6i7lprXljhtUrAbO+/+PSuzeWr4yaVvd7MQllASnjGKNb4Nebh1iAfTgM+/1yG9qIeUJl2xOuO5noS4pwKIAOYvMYve94z6KCTmAkyEZyXTkCeB3hQdvVeb5R9XraXdtV26JyxY= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <7CE3E1620AA2354484ABD36C6D85C063@jpnprd01.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: a2a2d7ce-fc2f-45e6-3706-08d65e7b404c X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2018 08:41:17.4572 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSAPR01MB2675 Archived-At: Subject: Re: [Idna-update] [I18nrp] Last Call: (IDNA2008 and Unicode 11.0.0) to Informational RFC 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, 10 Dec 2018 08:41:23 -0000 DQoNCk9uIDIwMTgvMTIvMDggMDE6NDUsIE5pY28gV2lsbGlhbXMgd3JvdGU6DQo+IE9uIEZyaSwg RGVjIDA3LCAyMDE4IGF0IDEyOjUyOjIwQU0gLTA4MDAsIEFzbXVzIEZyZXl0YWcgKGMpIHdyb3Rl Og0KPj4gT24gMTIvNi8yMDE4IDEwOjUwIFBNLCBOaWNvIFdpbGxpYW1zIHdyb3RlOg0KPj4+IE9u IEZyaSwgRGVjIDA3LCAyMDE4IGF0IDAxOjQ1OjAyQU0gLTA1MDAsIFZpbnQgQ2VyZiB3cm90ZToN Cj4+Pj4+IFRoZSBhYmlsaXR5IHRvIHR5cGUgaW4gZG9tYWlubmFtZXMgeW91IHNlZSBpbiBhZHMg aXMgbm90IHRoYXQNCj4+Pj4+IGludGVyZXN0aW5nIGZvciB0aGUgb2J2aW91cyByZWFzb24gdGhh dCBhZHZlcnRpc2VycyB3b3VsZCBub3QNCj4+Pj4+IGNob29zZSB0byB1c2UgZG9tYWlubmFtZXMg dGhhdCB0aGVpciB0YXJnZXRzIGNhbm5vdCB0eXBlIGluIQ0KPj4+PiBWR0M6IEkgYW0gbm90IHNv IHN1cmUgYWR2ZXJ0aXNlcnMgYXJlIHRoYXQgc21hcnQuLi4NCj4+Pg0KPj4+IEkgYW0gcXVpdGUg Y2VydGFpbiB0aGF0IHRoZXkgYXJlLCBvciBpZiBub3QsIHdpbGwgYmUuICBUaGV5IHNwZW5kDQo+ Pj4gbG90cyBvZiBtb25leSwgYW5kIHRoZXkgaGF0ZSB0byBzcGVuZCBpdCBiYWRseS4gIFRoZXkg ZXZlbiBzcGVuZCBsb3RzDQo+Pj4gb2YgbW9uZXkgb24gaG93IHRvIHNwZW5kIGxvdHMgbW9yZSBt b25leSB3ZWxsLg0KPj4NCj4+IEl0IG1heSBub3QgYmUgYWR2ZXJ0aXNlcnMgdGhhdCB1c2Ugc3Vj aCAnYnJva2VuJyBsYWJlbHMuIEFsbCBzb3J0cyBvZg0KPj4gbWlzY2hpZWYgY2FuIGJlIGNyZWF0 ZWQgd2l0aCBzdHVmZiB0aGF0IHlvdXIgc3lzdGVtIHdvbid0IGxldCB5b3UgdHlwZQ0KPj4gKGV2 ZW4gaWYgeW91IGFyZSBhIG5hdGl2ZSB1c2VyIG9uIGEgIm5hdGl2ZSIgc3lzdGVtKS4NCj4gDQo+ IEFueW9uZSB3aG8gd2FudHMgdGhlaXIgdGFyZ2V0IGF1ZGllbmNlIHRvIGJlIGFibGUgdG8gdHlw ZSBpbiBhIGxhYmVsDQo+IHdpbGwgcGljayBsYWJlbHMgd2lzZWx5Lg0KDQpZZXMuIE15IHdheSB0 byBzYXkgdGhpcyBpcyB0aGF0IG5vdCBhbGwgYWR2ZXJ0aXNlcnMgYXJlIHRoYXQgc21hcnQsIGJ1 dCANCnRob3NlIHRoYXQgYXJlbid0IHdpbGwgc29vbmVyIG9yIGxhdGVyIGRpc2FwcGVhciAoKiku IFNpbWlsYXIgZm9yIA0Kbm9uLWFkdmVydGlzZXJzOiBJZiB0aGV5IGNvbWUgdXAgd2l0aCBhIGdv b2QgZG9tYWluIG5hbWUsIG9yIChwYXJ0IG9mKSANCmFuIFVSSSwgdGhleSdsbCBiZSByZW1lbWJl cmVkIGFuZCBmb3VuZCBlYXNpbHksIGlmIHRoZXkgZG9uJ3QsIHRoZXknbGwgDQpqdXN0IGJlIGln bm9yZWQuDQoNCkkgZG9uJ3QgdGhpbmsgdGhlIElFVEYgc2hvdWxkIGJlIGRvaW5nIHRoZSBhZHZl cnRpc2Vycycgd29yaywgYW5kIGV2ZW4gDQppZiB3ZSB3b3VsZCwgSSBmZWVsIHZlcnkgc3Ryb25n bHkgdGhhdCBub25lIG9mIHRoaXMgd291bGQgYmVsb25nIGludG8gDQpQYXRyaWsncyBkcmFmdCwg d2hpY2ggaXMgYWJvdXQgdGhlIHVwZGF0ZSBvZiB0aGUgcmVwZXJ0b2lyZS4NCg0KPiBBbnlvbmUg d2hvIGRvZXMgbm90IGNhcmUgd2hldGhlciB0aGVpciB0YXJnZXQgYXVkaWVuY2UgaXMgYWJsZSB0 byB0eXBlDQo+IGluIGEgbGFiZWwgd2lsbCBiZSBmcmVlIHRvIGNvbnN0cnVjdCBtb3JlIGludGVy ZXN0aW5nIGxhYmVscy4NCj4gDQo+IEkgc2VlIG5vdGhpbmcgd3Jvbmcgd2l0aCB0aGF0Lg0KDQpN ZSBuZWl0aGVyLg0KDQo+IE9mIGNvdXJzZSwgd2Ugd2VyZW4ndCBkaXNjdXNzaW5nIG1hbGljaW91 cyB1c2Ugb2YgY29uZnVzYWJsZXMuICBUaGF0J3MNCj4gYW5vdGhlciBzdG9yeS4NCg0KWWVzIGlu ZGVlZC4NCg0KUmVnYXJkcywgICBNYXJ0aW4uDQoNCigqKSBPZiBjb3Vyc2UsIGJlY2F1c2UgYWR2 ZXJ0aXNpbmcgaXMgYSByYXRoZXIgdmFndWUgYW5kIGZ1enp5IGJ1c2luZXNzLCANCnRoZSBlbGlt aW5hdGlvbiBkb2Vzbid0IHdvcmsgdmVyeSBxdWlja2x5IDotKC4NCg== From nobody Mon Dec 10 01:10:09 2018 Return-Path: X-Original-To: idna-update@ietfa.amsl.com Delivered-To: idna-update@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98556130EEC; Mon, 10 Dec 2018 01:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FROM_EXCESS_BASE64=0.979, 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 (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3b845374_9Ae; Mon, 10 Dec 2018 01:10:00 -0800 (PST) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-eopbgr1400124.outbound.protection.outlook.com [40.107.140.124]) (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 C6B34127B92; Mon, 10 Dec 2018 01:09:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pL3lThpvkLJt0U1ypVAin2W+WAI8EpAGS6KHMQoguS4=; b=Bm2ENjNQne5SUW3l5B9OhDjo4LdDWjsfG2s7IAiW8P1LGT9lTGDgPbHeXtlMlDyIjWanRke3jNI1HSBNhL8ykfgu7/m9Tlzza1xZt4OJYT/qlROmbyCmNgpTvRNjwMOe/AXkLtqh7rOYcsjkquBo/MbooooJCuCQf7TVWWdwJBQ= Received: from OSAPR01MB4434.jpnprd01.prod.outlook.com (20.179.176.23) by OSAPR01MB3956.jpnprd01.prod.outlook.com (20.178.103.205) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1404.22; Mon, 10 Dec 2018 09:09:57 +0000 Received: from OSAPR01MB4434.jpnprd01.prod.outlook.com ([fe80::7847:bb06:297e:c78b]) by OSAPR01MB4434.jpnprd01.prod.outlook.com ([fe80::7847:bb06:297e:c78b%5]) with mapi id 15.20.1404.026; Mon, 10 Dec 2018 09:09:57 +0000 From: =?utf-8?B?TWFydGluIEouIETDvHJzdA==?= To: Larry Masinter , "'Asmus Freytag (c)'" , =?utf-8?B?J1BhdHJpayBGw6RsdHN0csO2bSc=?= , 'John C Klensin' CC: "i18nrp@ietf.org" , "idna-update@ietf.org" , 'Paul Hoffman' Thread-Topic: [I18nrp] Last Call: (IDNA2008 and Unicode 11.0.0) to Informational RFC Thread-Index: AQHUkGgel3laR4rYMU2ltkhXEDpUVQ== Date: Mon, 10 Dec 2018 09:09:57 +0000 Message-ID: <0ddefbd1-d4e4-b2bd-5206-9c2d1fe9defd@it.aoyama.ac.jp> References: <154385119878.18333.5085298134102919486.idtracker@ietfa.amsl.com> <8E20D432-01B0-4B52-80BB-3348C5FE73AF@vpnc.org> <217ede0e-ea1f-bb31-a276-f8c618c71278@ix.netcom.com> <8885EE4C-412E-4337-A099-66354A36CEA1@vpnc.org> <48A2A546-4FEA-4060-8706-34D210B2ABAF@frobbit.se> <055301d48dc8$0ea95120$2bfbf360$@acm.org> <07CB0B3B-E48A-40CD-BBC9-E6CAA2FB29F0@frobbit.se> <50A496896DE57696A5184DC2@PSB> <005401d48e5a$02d08d90$0871a8b0$@acm.org> In-Reply-To: <005401d48e5a$02d08d90$0871a8b0$@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: KAWPR01CA0085.jpnprd01.prod.outlook.com (2603:1096:402:c::21) To OSAPR01MB4434.jpnprd01.prod.outlook.com (2603:1096:604:60::23) authentication-results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [133.2.210.64] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; OSAPR01MB3956; 6:MmlrH46Mho2owgo3ufcCocdspaAlIR0dfq6gBQexswBA8KwuPuttFyBLVhE8bNEQttrJ8uV2fVMseSA35KyUJ1/sTfsw1YAhMjuTYYy1Qdh1EX5v0pyxfp/mxT4muaXg6VCFf3DgNrloPlfUgUoKOVo72Yk2lGRT1SRLG1F3oSgD6zQXlop7Zgdw+42xwVbaD+1LybfZj7U+dgrduG41cmFGW5UKWSIHMKdpSNil9xL5ZKCvFh3ApB28iMMMORJ63vDv434qyDZOF8JQRgxcn6q08SZ0rzLJU3ORSlvkJpYmerKBtiuH0xznbcqL2XIL9igDGpG6yXfksA44e1h71HbCsLjA8qCydJJcES9WsjrENX+mjaS87QYGEI+2WccjL4uui12ULB9VYyDWivNO/rHD7vkt4j+lEQOB2KLPqLtAXS+XAcH2NNt4sd2hU6gXn20TGGBGsJgOU+bNjjs4hQ==; 5:WBjopBA7YkWUvcWZtBbNuvm3auZvVq43LmFk6R1w97VEKH4mAWLxALP+tCN4XBqZ07MH3XzAE+kPYNpcvoXcHLXKnGDNAIs37PIS89yeqddp6V8qnfbZEg/zfLyPs8A0Ks6svYdFfl8eM6lV0MiPl92d10lPl4QxjstZWpP+eD4=; 7:Vqsm4J8WNlR1aVFzP4PHoTOUPraX88pAPYx201NiYFyGylLSZf8QZTj7malPl/BIbvHHv6//pv0ZVWGywIOdjIF63heWixC+tUxSw0MTVYZfkTM1NJsyWRMZhgqrQsSjWKxW0wAIj3IU8bk0vSfJyQ== x-ms-office365-filtering-correlation-id: d0d90b1a-fd34-48d3-d02f-08d65e7f414e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7025125)(7024125)(7027125)(7023125)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:OSAPR01MB3956; x-ms-traffictypediagnostic: OSAPR01MB3956: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(3230017)(999002)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231472)(944501520)(52105112)(148016)(149066)(150057)(6041310)(2016111802025)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(6043046)(201708071742011)(7699051)(76991095); SRVR:OSAPR01MB3956; BCL:0; PCL:0; RULEID:; SRVR:OSAPR01MB3956; x-forefront-prvs: 08828D20BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(136003)(346002)(376002)(39840400004)(189003)(199004)(66066001)(53546011)(11346002)(476003)(8676002)(6506007)(786003)(386003)(31686004)(186003)(8936002)(76176011)(52116002)(486006)(6116002)(3846002)(86362001)(316002)(575784001)(102836004)(229853002)(97736004)(99286004)(26005)(6486002)(2616005)(446003)(31696002)(6436002)(66574011)(68736007)(25786009)(81166006)(81156014)(6306002)(6512007)(966005)(85182001)(4326008)(71190400001)(256004)(6246003)(508600001)(93886005)(5660300001)(71200400001)(53936002)(85202003)(7736002)(2906002)(105586002)(305945005)(106356001)(74482002)(54906003)(14454004)(110136005); DIR:OUT; SFP:1102; SCL:1; SRVR:OSAPR01MB3956; H:OSAPR01MB4434.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) x-microsoft-antispam-message-info: dLKDuA1gfy8k7iEvhPG2hpGIuo/rQ3awhUpW7HmiOaHPHFzPCry4whPlTWSPCznjAv2UywM54rAD+Fb9GtjFqBW63mEsVhyV0X7tGz3xLte4QQIOXxKs9NUC2ZVEo/M0dd8GNwXrvreLO48sdPAnAJiXMRVjLuP2Hog+VyxddaDALRc/O5MtgPEUx31c6dRKgwXN23c1cVtC6I9qfFol430nRZBGJrGSXPk5DUp5I0AFHuU+0sK9MJRvW5RTe0f15FkMxKz2FTizX9bHp0SNOoiEEGJuLN1azS6YlZMBdcYiUBwIS7n6j+TUEiTc3oNYD77FwHgSeWsGJpRDV5eJfBy276G7+hAHEhI6Mjj5kiA= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <648AFDABD2A9C04485C19E32DFF9F385@jpnprd01.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: d0d90b1a-fd34-48d3-d02f-08d65e7f414e X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2018 09:09:57.1076 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSAPR01MB3956 Archived-At: Subject: Re: [Idna-update] [I18nrp] Last Call: (IDNA2008 and Unicode 11.0.0) to Informational RFC 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, 10 Dec 2018 09:10:09 -0000 DQoNCk9uIDIwMTgvMTIvMDggMDM6MjMsIExhcnJ5IE1hc2ludGVyIHdyb3RlOg0KPiBMb29rIGF0 IFJGQzE3MzYgLCBGdW5jdGlvbmFsIFJlY29tbWVuZGF0aW9ucyBmb3IgSW50ZXJuZXQgUmVzb3Vy Y2UgTG9jYXRvcnPigJ0sIHNlY3Rpb24gNC42OiBMb2NhdG9ycyBhcmUgaHVtYW4gdHJhbnNjcmli YWJsZQ0KPiANCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzE3MzYjc2VjdGlvbi00 LjYNCj4gDQo+ICAgICBVc2VycyBjYW4gY29weSBJbnRlcm5ldCBsb2NhdG9ycyBmcm9tIG9uZSBt ZWRpdW0gdG8gYW5vdGhlciAoc3VjaCBhcw0KPiANCj4gICAgIHZvaWNlIHRvIHBhcGVyLCBvciBw YXBlciB0byBrZXlib2FyZCkgd2l0aG91dCBsb3NzIG9yIGNvcnJ1cHRpb24gb2YNCj4gDQo+ICAg ICBpbmZvcm1hdGlvbi4gIFRoaXMgcHJvY2VzcyBpcyBub3QgcmVxdWlyZWQgdG8gYmUgY29tZm9y dGFibGUuDQo+IA0KPiBDaGFuZ2luZyBJbnRlcm5ldCBsb2NhdG9ycyB0byBhbGxvdyBmb3IgSW50 ZXJuYXRpb25hbGl6YXRpb24gbmVlZCBub3QgbmVjZXNzYXJpbHkgZWxpbWluYXRlIHRoaXMgdmFs dWFibGUgcHJvcGVydHkuDQoNCkFuZCBpdCBkb2Vzbid0LiBQZW9wbGUgZ2V0IGNvbmZ1c2VkIGJl Y2F1c2UgdGhleSB0aGluayBkaWZmZXJlbnRseSBhYm91dCANCnNjcmlwdHMgdGhleSBhcmUgbm90 IGZhbWlsaWFyIHdpdGggKHdoZXJlIHRoZXkgb2Z0ZW4gYXNzdW1lIHRoZSB3b3JzdCwgDQphbmQg YXJlIGV4cGxpY2l0IGFib3V0IGl0KSB0aGFuIGFib3V0IHNjcmlwdHMgdGhleSBhcmUgZmFtaWxp YXIgd2l0aCANCih3aGVyZSB0aGV5IG1ha2UgdGhlIHJpZ2h0IGFzc3VtcHRpb25zIGltcGxpY2l0 bHksIG9mdGVuIHdpdGhvdXQgZXZlbiANCmJlaW5nIGFibGUgdG8gc2F5IHdoYXQgdGhlc2UgYXNz dW1wdGlvbnMgYXJlKS4NCg0KSSBoYXZlIGp1c3Qgc2VhcmNoZWQgdGhyb3VnaCBhbGwgb2YgUkZD IDM5ODYsIGJ1dCBJIGhhdmUgbm93aGVyZSBmb3VuZCANCmFueXRoaW5nIHRlbGxpbmcgcGVvcGxl IG5vdCBmYW1pbGlhciB3aXRoIEFTQ0lJIHRoYXQgdGhleSBzaG91bGQgYmUgDQpjYXJlZnVsIG5v dCB0byBjcmVhdGUgZG9tYWluIGxhYmVscyBzdWNoIGFzICJMMENBVDBSIi4gVGhhdCdzIGJlY2F1 c2UgDQp3cml0ZXJzIG9mIFJGQyAzOTg2IGFzc3VtZWQgdGhhdCBpdCB3b3VsZCBiZSBxdWl0ZSBv YnZpb3VzIHRoYXQgbGV0dGVycyANCmFuZCAobW9yZS1vci1sZXNzKSBsb29rYWxpa2UgZGlnaXRz IHNob3VsZG4ndCBiZSBtaXhlZCBuZWVkbGVzc2x5LiBBbmQgDQpldmVuIG1vcmUsIG5vd2hlcmUg aW4gUkZDIDM5ODYgZG9lcyBpdCBzYXkgdG8gYmUgY2FyZWZ1bCBub3QgdG8gY29uZnVzZSANCidi JywgJ2QnLCAncCcsIGFuZCAncScsIGV2ZW4gaWYgdGhlc2UgY2hhcmFjdGVycyBsb29rIHF1aXRl IHRoZSBzYW1lIHVwIA0KdG8gb25seSBhIHJvdGF0aW9uL3JlZmxlY3Rpb24uIChJIHJlbWVtYmVy ZWQgYmVpbmcgY29uZnVzZWQgYWJvdXQgdGhlc2UgDQpmb3IgYSB3aGlsZSBpbiBwcmltYXJ5IHNj aG9vbC4pDQoNClRoZSBzYW1lIGlzIHRydWUgZm9yIG90aGVyIHNjcmlwdHMuIFVzZXJzIG9mIEph cGFuZXNlIGtub3cgdG8gbm90IG1peCB1cCANCkthbmppLCBIaXJhZ2FuYSwgYW5kIEthdGFrYW5h IG5lZWRsZXNzbHkgKCopLiBVc2VycyBvZiBhbnkgc2NyaXB0IGtub3cgDQp3aGVyZSB0aGUgcG90 ZW50aWFsIGNvbmZ1c2FibGVzIGFyZSwgYW5kIGhvdyB0byBkZWFsIHdpdGggdGhlbSBpbiBkYWls eSANCmxpZmUuIFRoZXJlIGlzIG5vIG5lZWQgdG8gdGVsbCB0aGVtIGFib3V0IHRoZSBkZXRhaWxz Lg0KDQpXaGF0IGlzIGRlc2lyYWJsZSBhcmUgcmVzdHJpY3Rpb25zIHN1Y2ggYXMgdGhvc2UgdGhh dCBBc211cyBoYXMgDQpkZXNjcmliZWQsIG9uIHRoZSByZWdpc3RyeSBsZXZlbCwgdG8gaGVscCBh dm9pZCBpbmFkdmVydGVudCBvciBtYWxpY2lvdXMgDQpjb2xsaXNpb25zLCBhbmQgdG8gYnVmZmVy IGZvciBjYXNlcyB3aGVyZSByZXBlcnRvaXJlLW9ubHkgbGltaXRhdGlvbnMgDQphcmUgbm90IGVu b3VnaC4NCg0KQnV0IHRoZXNlIGFyZSBzZXBhcmF0ZSBmcm9tIHRoZSBkcmFmdCB1bmRlciBkaXNj dXNzaW9uIG5vdy4NCg0KUmVnYXJkcywgICBNYXJ0aW4uDQo=