From nobody Fri Aug 2 14:15:50 2019 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 C5A8D1200E9; Fri, 2 Aug 2019 14:15:48 -0700 (PDT) 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, SPF_HELO_NONE=0.001, SPF_NONE=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 j96j4ie18NFv; Fri, 2 Aug 2019 14:15:46 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 159C512013B; Fri, 2 Aug 2019 14:15:46 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1htets-0000Gm-Ge; Fri, 02 Aug 2019 17:15:44 -0400 Date: Fri, 02 Aug 2019 17:15:38 -0400 From: John C Klensin To: i18ndir@ietf.org, idna-update@ietf.org Message-ID: <54A888A04C434DE23AAB1A67@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] FWD: Last Calls on two IDNA documents 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, 02 Aug 2019 21:15:49 -0000 For those who don't follow the IETF-announce list and are interested, Last Calls were announced today on draft-klensin-idna-unicode-review and draft-klensin-idna-rfc5891bis. The former is the clarification to the "new Unicode version" review process discussed extensively while we were working on the Unicode 11.0 and 12.0 updates and IANA tables early in the year (and on draft-faltstrom-unicode11 and draft-faltstrom-unicode12). The latter is a significantly updated version of clarification to the "registry restrictions" material that has been kicking around for a few years. If you have comments, please follow the Last Call instructions included below. best, john ---------- Forwarded Message ---------- Date: Friday, August 2, 2019 09:08 -0700 From: The IESG To: IETF-Announce Cc: barryleiba@gmail.com, draft-klensin-idna-unicode-review@ietf.org, resnick@episteme.net Subject: Last Call: (IDNA Review for New Unicode Versions) to Proposed Standard The IESG has received a request from an individual submitter to consider the following document: - 'IDNA Review for New Unicode Versions' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-08-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The standards for Internationalized Domain Names in Applications (IDNA) require a review of each new version of Unicode to determine whether incompatibilities with prior version or other issues exist and, where appropriate, to allow the IETF to decide on the trade-offs between compatibility with prior IDNA versions and compatibility with Unicode going forward. That requirement, and its relationship to tables maintained by IANA, has caused significant confusion in the past. This document makes adjustments to the review procedure based on experience and updates IDNA, specifically RFC 5892, to reflect those changes and clarify the various relationships involved. It also makes other minor adjustments to align that document with experience. The file can be obtained via https://datatracker.ietf.org/doc/draft-klensin-idna-unicode-revi ew/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-klensin-idna-unicode-revi ew/ballot/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ---------- End Forwarded Message ---------- ---------- Forwarded Message ---------- Date: Friday, August 2, 2019 13:30 -0700 From: The IESG To: IETF-Announce Cc: draft-klensin-idna-rfc5891bis@ietf.org, barryleiba@gmail.com, resnick@episteme.net Subject: Last Call: (Internationalized Domain Names in Applications (IDNA): Registry Restrictions and Recommendations) to Proposed Standard The IESG has received a request from an individual submitter to consider the following document: - 'Internationalized Domain Names in Applications (IDNA): Registry Restrictions and Recommendations' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-08-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The IDNA specifications for internationalized domain names combine rules that determine the labels that are allowed in the DNS without violating the protocol itself and an assignment of responsibility, consistent with earlier specifications, for determining the labels that are allowed in particular zones. Conformance to IDNA by registries and other implementations requires both parts. Experience strongly suggests that the language describing those responsibilities was insufficiently clear to promote safe and interoperable use of the specifications and that more details and discussion of circumstances would have been helpful. Without making any substantive changes to IDNA, this specification updates two of the core IDNA documents (RFC 5980 and 5891) and the IDNA explanatory document (RFC 5894) to provide that guidance and to correct some technical errors in the descriptions. The file can be obtained via https://datatracker.ietf.org/doc/draft-klensin-idna-rfc5891bis/ When IESG discussion has begun, it can be tracked via https://datatracker.ietf.org/doc/draft-klensin-idna-rfc5891bis/b allot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc5894: Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale (Informational - IETF stream) rfc1591: Domain Name System Structure and Delegation (Informational - Legacy stream) _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ---------- End Forwarded Message ---------- From nobody Sat Aug 3 16:53:46 2019 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 4B704120143; Sat, 3 Aug 2019 16:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_MUA_EUDORA=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 lmUGqx4zatRY; Sat, 3 Aug 2019 16:53:34 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (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 D4DEC1200F7; Sat, 3 Aug 2019 16:53:34 -0700 (PDT) Received: from 89-85-78-42.abo.bbox.fr ([89.85.78.42]:63491 helo=DESKTOP-K3JO9LD.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.92) (envelope-from ) id 1hu3q7-0004eq-CJ; Sun, 04 Aug 2019 01:53:33 +0200 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 04 Aug 2019 01:53:13 +0200 To: John C Klensin ,i18ndir@ietf.org,idna-update@ietf.org From: "J-F C. Morfin" In-Reply-To: <54A888A04C434DE23AAB1A67@PSB> References: <54A888A04C434DE23AAB1A67@PSB> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - morfin.org X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: host.presenceweb.org: jefsey@jefsey.com X-Source: X-Source-Args: X-Source-Dir: Message-Id: <20190803235334.D4DEC1200F7@ietfa.amsl.com> Archived-At: Subject: Re: [Idna-update] FWD: Last Calls on two IDNA documents 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: Sat, 03 Aug 2019 23:53:38 -0000 John, all of us trust Patrick's and your competence and wiseness IRT iDNs. And thank you for your constant updating. However, I observe that the retained solution regularly calls for updates. I am considering a polynym (strict lingual synonyms) oriented DDDS service (bigdata multilingual database labels for cross-origin data). A first idea is to build it on a similar basis as iDNs. However concerns are about Unicode stability over decades. The need is for a string in any language returning the its polynym in any other language indicated by its langtag. Would you have a better suggestion? The project is to try to locate the service at a meditarean group of universities. Best jfc At 23:15 02/08/2019, John C Klensin wrote: >For those who don't follow the IETF-announce list and are >interested, Last Calls were announced today on >draft-klensin-idna-unicode-review and >draft-klensin-idna-rfc5891bis. The former is the clarification >to the "new Unicode version" review process discussed >extensively while we were working on the Unicode 11.0 and 12.0 >updates and IANA tables early in the year (and on >draft-faltstrom-unicode11 and draft-faltstrom-unicode12). The >latter is a significantly updated version of clarification to >the "registry restrictions" material that has been kicking >around for a few years. > >If you have comments, please follow the Last Call instructions >included below. > >best, > john > > >---------- Forwarded Message ---------- >Date: Friday, August 2, 2019 09:08 -0700 >From: The IESG >To: IETF-Announce >Cc: barryleiba@gmail.com, >draft-klensin-idna-unicode-review@ietf.org, resnick@episteme.net >Subject: Last Call: >(IDNA Review for New Unicode Versions) to Proposed Standard > > >The IESG has received a request from an individual submitter to >consider the following document: - 'IDNA Review for New Unicode >Versions' as >Proposed Standard > >The IESG plans to make a decision in the next few weeks, and >solicits final comments on this action. Please send substantive >comments to the ietf@ietf.org mailing lists by 2019-08-30. >Exceptionally, comments may be sent to iesg@ietf.org instead. In >either case, please retain the beginning of the Subject line to >allow automated sorting. > >Abstract > > > The standards for Internationalized Domain Names in >Applications (IDNA) require a review of each new version of >Unicode to determine whether incompatibilities with prior >version or other issues exist and, where appropriate, to >allow the IETF to decide on the trade-offs between >compatibility with prior IDNA versions and compatibility with >Unicode going forward. That requirement, and its relationship to > tables maintained by IANA, has caused significant confusion >in the past. This document makes adjustments to the review >procedure based on experience and updates IDNA, specifically >RFC 5892, to reflect those changes and clarify the various >relationships involved. It also makes other minor >adjustments to align that document with experience. > > > > >The file can be obtained via >https://datatracker.ietf.org/doc/draft-klensin-idna-unicode-revi >ew/ > >IESG discussion can be tracked via >https://datatracker.ietf.org/doc/draft-klensin-idna-unicode-revi >ew/ballot/ > > >No IPR declarations have been submitted directly on this I-D. > > > > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/ietf-announce > >---------- End Forwarded Message ---------- > > > >---------- Forwarded Message ---------- >Date: Friday, August 2, 2019 13:30 -0700 >From: The IESG >To: IETF-Announce >Cc: draft-klensin-idna-rfc5891bis@ietf.org, >barryleiba@gmail.com, resnick@episteme.net >Subject: Last Call: >(Internationalized Domain Names in Applications (IDNA): Registry >Restrictions and Recommendations) to Proposed Standard > > >The IESG has received a request from an individual submitter to >consider the following document: - 'Internationalized Domain >Names in Applications (IDNA): Registry > Restrictions and Recommendations' > as Proposed Standard > >The IESG plans to make a decision in the next few weeks, and >solicits final comments on this action. Please send substantive >comments to the ietf@ietf.org mailing lists by 2019-08-30. >Exceptionally, comments may be sent to iesg@ietf.org instead. In >either case, please retain the beginning of the Subject line to >allow automated sorting. > >Abstract > The IDNA specifications for internationalized domain names >combine rules that determine the labels that are allowed in >the DNS without violating the protocol itself and an >assignment of responsibility, consistent with earlier >specifications, for determining the labels that are allowed >in particular zones. Conformance to IDNA by registries and >other implementations requires both parts. Experience >strongly suggests that the language describing those >responsibilities was insufficiently clear to promote safe and >interoperable use of the specifications and that more details >and discussion of circumstances would have been helpful. >Without making any substantive changes to IDNA, this >specification updates two of the core IDNA documents (RFC >5980 and 5891) and the IDNA explanatory document (RFC 5894) to >provide that guidance and to correct some technical errors in the > descriptions. > > >The file can be obtained via >https://datatracker.ietf.org/doc/draft-klensin-idna-rfc5891bis/ > >When IESG discussion has begun, it can be tracked via >https://datatracker.ietf.org/doc/draft-klensin-idna-rfc5891bis/b >allot/ > > >No IPR declarations have been submitted directly on this I-D. > > >The document contains these normative downward references. >See RFC 3967 for additional information: > rfc5894: Internationalized Domain Names for Applications >(IDNA): Background, Explanation, and Rationale (Informational - >IETF stream) rfc1591: Domain Name System Structure and >Delegation (Informational - Legacy stream) > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/ietf-announce > >---------- End Forwarded Message ---------- > > > > >_______________________________________________ >IDNA-UPDATE mailing list >IDNA-UPDATE@ietf.org >https://www.ietf.org/mailman/listinfo/idna-update From nobody Sat Aug 3 21:10:14 2019 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 A071B12002F; Sat, 3 Aug 2019 21:10:06 -0700 (PDT) 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, SPF_HELO_NONE=0.001, SPF_NONE=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 WMRlNlvt1RIu; Sat, 3 Aug 2019 21:10:04 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D544B120018; Sat, 3 Aug 2019 21:10:04 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1hu7qM-0006O6-U4; Sun, 04 Aug 2019 00:10:02 -0400 Date: Sun, 04 Aug 2019 00:09:57 -0400 From: John C Klensin To: "J-F C. Morfin" cc: i18ndir@ietf.org, idna-update@ietf.org Message-ID: References: <54A888A04C434DE23AAB1A67@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: Re: [Idna-update] FWD: Last Calls on two IDNA documents 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: Sun, 04 Aug 2019 04:10:07 -0000 --On Sunday, August 4, 2019 01:53 +0200 "J-F C. Morfin" wrote: > John, > all of us trust Patrick's and your competence and wiseness IRT > iDNs. And thank you for your constant updating. However, I > observe that the retained solution regularly calls for updates. Thanks although more eyes --and different perspectives-- on this stuff are always helpful. Put differently, while I'm glad you trust us, I don't :-(. And it does indeed call for updates. > I am considering a polynym (strict lingual synonyms) oriented > DDDS service (bigdata multilingual database labels for > cross-origin data). A first idea is to build it on a similar > basis as iDNs. However concerns are about Unicode stability > over decades. First of all, if you are building a new system, you don't need the baggage that IDNs/ IDNA are carrying around as the result of the DNS not being well-designed for non-ASCII labels at the beginning and of many legacy applications that are even less well designed and implemented for those situations. > The need is for a string in any language returning the its > polynym in any other language indicated by its langtag. Would > you have a better suggestion? The project is to try to locate > the service at a meditarean group of universities. You are facing several problems. One is Unicode itself. As "universal" coding systems goes, it is probably as good or better than anything else we can easily imagine, but its design and implementation involved design choices that are not optimal for all purposes (or all languages and writing systems). A different system might do better for some of those choices, but would almost certainly be worse for others. That is one of the reasons for the update problem: as long as new code points (or at least new code points that are not symbols or otherwise excluded from "words") are being added, some decisions about the properties associated with code points are going to involve tradeoffs and those tradeoffs may not be optimal for IDNs, for your system, or for any other one with its own set of constraints and desirable characteristics. So, if one is going to have strict stability and forward compatibility for identifiers or other strings, especially if more than just code point assignments are involved, regular review of properties and property assignments would seem to be a requirement. If you can define things so that all you care about is stability of the code point assignments and binding to abstract characters themselves, and you have no need to define or enforce equivalence of different encodings of "the same" string or character within that string, then there is probably no issue. The second problem is one with which I believe you are familiar because you've raised equivalent issues before in other contexts. While some technical terms that were invented only very recently do work, there are many terms, both mononyms and polynyms, for which exact and unique translations do not exist or are controversial. If you want to check that out further, looking at the EUROVOC and AGROVOC multilingual controlled vocabularies might be a start. Those two examples are, however, specialized vocabularies; more traditional multilingual thesauri pose even more complex problems. best, john' > Best > jfc From nobody Mon Aug 5 03:40:07 2019 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 AF72A12015A for ; Mon, 5 Aug 2019 03:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl header.b=rbB/WR/c; dkim=pass (1024-bit key) header.d=nlnetlabs.nl header.b=rbB/WR/c 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 vaUmybxxHTvs for ; Mon, 5 Aug 2019 03:40:03 -0700 (PDT) Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [185.49.140.10]) (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 7257D12012D for ; Mon, 5 Aug 2019 03:40:03 -0700 (PDT) Received: by dicht.nlnetlabs.nl (Postfix, from userid 58) id F08E32A603; Mon, 5 Aug 2019 12:39:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1565001596; bh=wwOj4hXJq6/ITUmf6HISj/eA+0wM/jOwUfqw7ouhFC4=; h=To:Subject:From:In-reply-to:References:Date; b=rbB/WR/c8u+vS7+ZE+QjCgSCWz9WOumT+wnfH/7PQuZiMFPvwe0HVRvhFm1w6S8qD qRinVonAFrDmpoOAwcUX97g1+FFQeF5RqzUSzLGG3r6QosbFZQfJcfXvsvue1dSwLg 1RIJMyAjCr7bYUTMU3+ll7+zxeJ9xIYHB1qTw+kM= Received: from bela.nlnetlabs.nl (bela.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:15]) by dicht.nlnetlabs.nl (Postfix) with ESMTPS id 7759F2A601 for ; Mon, 5 Aug 2019 12:39:56 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=pass (p=none dis=none) header.from=NLnetLabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=pass smtp.mailfrom=jaap@NLnetLabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1565001596; bh=wwOj4hXJq6/ITUmf6HISj/eA+0wM/jOwUfqw7ouhFC4=; h=To:Subject:From:In-reply-to:References:Date; b=rbB/WR/c8u+vS7+ZE+QjCgSCWz9WOumT+wnfH/7PQuZiMFPvwe0HVRvhFm1w6S8qD qRinVonAFrDmpoOAwcUX97g1+FFQeF5RqzUSzLGG3r6QosbFZQfJcfXvsvue1dSwLg 1RIJMyAjCr7bYUTMU3+ll7+zxeJ9xIYHB1qTw+kM= Received: from bela.nlnetlabs.nl (localhost [127.0.0.1]) by bela.nlnetlabs.nl (8.15.2/8.15.2) with ESMTPS id x75AdsYF022733 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Mon, 5 Aug 2019 12:39:56 +0200 (CEST) (envelope-from jaap@NLnetLabs.nl) Received: from bela.nlnetlabs.nl (jaap@localhost) by bela.nlnetlabs.nl (8.15.2/8.15.2/Submit) with ESMTP id x75AdsBh022730 for ; Mon, 5 Aug 2019 12:39:54 +0200 (CEST) (envelope-from jaap@NLnetLabs.nl) Message-Id: <201908051039.x75AdsBh022730@bela.nlnetlabs.nl> X-Authentication-Warning: bela.nlnetlabs.nl: jaap owned process doing -bs To: idna-update@ietf.org From: Jaap Akkerhuis In-reply-to: References: Comments: In-reply-to John C Klensin message dated "Thu, 20 Jun 2019 18:52:03 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22728.1565001594.1@bela.nlnetlabs.nl> Date: Mon, 05 Aug 2019 12:39:54 +0200 Archived-At: Subject: Re: [Idna-update] Updating the review procedure in RFC 5892 for new Unicode versions 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, 05 Aug 2019 10:40:05 -0000 I have reviewed this document and do support the piblication. I specifically like that it explains the confusion about the non-authoritaive IANA IDNA tables. jaap From nobody Mon Aug 5 04:35:03 2019 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 BF214120194; Mon, 5 Aug 2019 04:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl header.b=AUXnP0HV; dkim=pass (1024-bit key) header.d=nlnetlabs.nl header.b=AUXnP0HV 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 94_fPGHswVtY; Mon, 5 Aug 2019 04:35:00 -0700 (PDT) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (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 ABE6E120176; Mon, 5 Aug 2019 04:35:00 -0700 (PDT) Received: by dicht.nlnetlabs.nl (Postfix, from userid 58) id 97BBE2A7B2; Mon, 5 Aug 2019 13:34:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1565004867; bh=GiXoR5ULhq6kKAO/XPv71TUjjodm0mYmbprChpwWI4E=; h=To:cc:Subject:From:In-reply-to:References:Date; b=AUXnP0HVzflf+ZHLdgFT+6I5jqFvVAkRkOBYndygQXQ+aLVt/fmh4lu6zwqRF5041 LWGQbPyuwZJKVHf+LlQ6+a9RfENFAfxaRGT4Cq8STnEo6tf8xXuDLfJHg1T64YGiGM HmayldWqT2bbQwlgiR2lESMvOc1X1HTiBybz498c= Received: from bela.nlnetlabs.nl (bela.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:15]) by dicht.nlnetlabs.nl (Postfix) with ESMTPS id 03B672A7B0; Mon, 5 Aug 2019 13:34:27 +0200 (CEST) Authentication-Results: dicht.nlnetlabs.nl; dmarc=pass (p=none dis=none) header.from=NLnetLabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=pass smtp.mailfrom=jaap@NLnetLabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1565004867; bh=GiXoR5ULhq6kKAO/XPv71TUjjodm0mYmbprChpwWI4E=; h=To:cc:Subject:From:In-reply-to:References:Date; b=AUXnP0HVzflf+ZHLdgFT+6I5jqFvVAkRkOBYndygQXQ+aLVt/fmh4lu6zwqRF5041 LWGQbPyuwZJKVHf+LlQ6+a9RfENFAfxaRGT4Cq8STnEo6tf8xXuDLfJHg1T64YGiGM HmayldWqT2bbQwlgiR2lESMvOc1X1HTiBybz498c= Received: from bela.nlnetlabs.nl (localhost [127.0.0.1]) by bela.nlnetlabs.nl (8.15.2/8.15.2) with ESMTPS id x75BYQIP050344 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 5 Aug 2019 13:34:26 +0200 (CEST) (envelope-from jaap@NLnetLabs.nl) Received: from bela.nlnetlabs.nl (jaap@localhost) by bela.nlnetlabs.nl (8.15.2/8.15.2/Submit) with ESMTP id x75BYOHe050341; Mon, 5 Aug 2019 13:34:24 +0200 (CEST) (envelope-from jaap@NLnetLabs.nl) Message-Id: <201908051134.x75BYOHe050341@bela.nlnetlabs.nl> X-Authentication-Warning: bela.nlnetlabs.nl: jaap owned process doing -bs To: John C Klensin cc: i18ndir@ietf.org, idna-update@ietf.org From: Jaap Akkerhuis In-reply-to: <54A888A04C434DE23AAB1A67@PSB> References: <54A888A04C434DE23AAB1A67@PSB> Comments: In-reply-to John C Klensin message dated "Fri, 02 Aug 2019 17:15:38 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <50339.1565004864.1@bela.nlnetlabs.nl> Date: Mon, 05 Aug 2019 13:34:24 +0200 Archived-At: Subject: Re: [Idna-update] FWD: Last Calls on two IDNA documents 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, 05 Aug 2019 11:35:02 -0000 I'm fine with draft-klensin-idna-rfc5891bis-04.txt. Nit: I couldn't help notice a typo on Page 3 where RFC 1501 is mentioned while c;early 1591 is meant. jaap From nobody Mon Aug 5 06:55:07 2019 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 99A74120227; Mon, 5 Aug 2019 06:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 rsKH05CB8ZoD; Mon, 5 Aug 2019 06:55:04 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3EE2120225; Mon, 5 Aug 2019 06:55:03 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1hudS2-000ChQ-I8; Mon, 05 Aug 2019 09:55:02 -0400 Date: Mon, 05 Aug 2019 09:54:57 -0400 From: John C Klensin To: Jaap Akkerhuis cc: i18ndir@ietf.org, idna-update@ietf.org Message-ID: In-Reply-To: <201908051134.x75BYOHe050341@bela.nlnetlabs.nl> References: <54A888A04C434DE23AAB1A67@PSB> <201908051134.x75BYOHe050341@bela.nlnetlabs.nl> 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] FWD: Last Calls on two IDNA documents 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, 05 Aug 2019 13:55:05 -0000 --On Monday, August 5, 2019 13:34 +0200 Jaap Akkerhuis wrote: > I'm fine with draft-klensin-idna-rfc5891bis-04.txt. > > Nit: I couldn't help notice a typo on Page 3 where RFC 1501 is > mentioned while c;early 1591 is meant. Jaap, Glad you couldn't help noticing. I obviously didn't. Fixed in working copy. thanks for catching that and thanks for the careful reading. john From nobody Mon Aug 5 07:05:53 2019 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 8C7DC1201EC for ; Mon, 5 Aug 2019 07:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 prnW-bjX8IAv for ; Mon, 5 Aug 2019 07:05:50 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95F3612018A for ; Mon, 5 Aug 2019 07:05:50 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1hudcS-000Cis-Fk; Mon, 05 Aug 2019 10:05:48 -0400 Date: Mon, 05 Aug 2019 10:05:43 -0400 From: John C Klensin To: Jaap Akkerhuis cc: idna-update@ietf.org, =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= Message-ID: <6997E405970BEB5C16A7292C@PSB> In-Reply-To: <201908051039.x75AdsBh022730@bela.nlnetlabs.nl> References: <201908051039.x75AdsBh022730@bela.nlnetlabs.nl> 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] Updating the review procedure in RFC 5892 for new Unicode versions 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, 05 Aug 2019 14:05:52 -0000 --On Monday, August 5, 2019 12:39 +0200 Jaap Akkerhuis wrote: > I have reviewed this document and do support the piblication. I > specifically like that it explains the confusion about the > non-authoritaive IANA IDNA tables. Thanks. It started becoming obvious to Patrik and myself when the complaints about not updating the tables stopping work started becoming loud over a year ago, more clear when the IAB issued the statement that I interpreted as "just get on with it", and completely obvious when in-depth discussions of draft-faltstrom-unicode11 started, that a clarification was overdue. If this clarification does not end that confusion, the IETF should consider taking that IANA registry and tables down entirely, perhaps replacing them with entries in some version control system that are "owned" by the designated expert who creates them. But let's hope that this will suffice. thanks again, john From nobody Tue Aug 6 04:46:21 2019 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 C235E1200D5; Tue, 6 Aug 2019 04:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.073 X-Spam-Level: X-Spam-Status: No, score=-0.073 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BIGNUM_EMAILS=1.825, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 dA14Vgby4B6j; Tue, 6 Aug 2019 04:46:03 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3538012007C; Tue, 6 Aug 2019 04:46:03 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1huxuj-000GJF-Gu; Tue, 06 Aug 2019 07:46:01 -0400 Date: Tue, 06 Aug 2019 07:45:56 -0400 From: John C Klensin To: John Levine , ietf@ietf.org cc: idna-update@ietf.org, i18ndir@ietf.org Message-ID: In-Reply-To: <20190806051430.5F8187AD3C0@ary.qy> References: <20190806051430.5F8187AD3C0@ary.qy> 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] Last Call: (Internationalized Domain Names in Applications (IDNA): Registry Restrictions and Recommendations) to Proposed Standard 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, 06 Aug 2019 11:46:06 -0000 (sdding the IDNA-update and directorate lists back in because I know there are people on both who are critical parts of this conversation but who are not on the IETF list.) --On Tuesday, August 6, 2019 01:14 -0400 John Levine wrote: > In article > <156477784250.20958.8001683910411638971.idtracker@ietfa.amsl.c > om> you write: >> >> The IESG has received a request from an individual submitter >> to consider the following document: - 'Internationalized >> Domain Names in Applications (IDNA): Registry >> Restrictions and Recommendations' >> as Proposed Standard > > This document fills a longstanding need and definitely needs > to be published. But I have a few suggestions. > > Section 4 on "For-Profit Domains" contrasts normal zones which > have names that are of use to the zone's owner, and commercial > zones where more names mean more money and says (I > paraphrase), hey you greedy slobs, don't register junk names. > While I certainly agree with the sentiment, in its current > form I don't think the intended audience is likely to take the > hint. I would shrink the section and just note that zones are > managed in different ways and the ones which have a financial > or other incentive to maximize the number of names present a > potential quality problem. Then say something like that zones > and registries have reputations, and zones with poor quality > names tend to earn poor reputations, which has led to > resolution issues as client systems block them in self-defense. I'll think about this and discuss it with Asmus and others but, as you will see below, there more I've though about the change you suggest the less I think it is desirable As discussed in other notes, part of the problem is that I/we wanted to avoid getting into "public domain" terminology, especially because there are some ccTLDs and maybe still some gTLDs who behave in an exemplary way. There have certainly been corporate and academic domains whose naming rules have been dominated by a dangerous excess of cuteness and cleverness. Borrowing from your paragraph above, it would be nice to say "if you are inclined to behave like a greedy slob, then ..." but that definitely would not fly. I am also concerned that Getting this perfectly (or even nearly so) right would require much more text and that more text would reduce the number of readers. Possibly more important, your assumption about the intended audience may be a little bit different from mine. Based on watching different subsets of the groups of people whom you describe as greedy (I'll skip having an opinion about the "slob" part) ignore DNS identifier issues in favor selling more names, ignore ICANN Board resolutions and other advice, ignore SSAC advice, ignore IAB advice, ignore 1591, market names using fear or extortionist tactics, and so on, I'd assume that the odds of their paying any attention to anything this document says that would inconvenience them --wherever it falls between a hint and rude and explicit language and loud screaming-- is about zero. Instead, I think one audience for that and some other sections of the document is actually those commercial (sic) zone operators who are trying, hard, to find a good balance between being profitable and being responsible to the Internet. Some of their staff and Board members will read this document and try to understand it ("hints" or not) and maybe it will leverage continuing good or improved behavior. If the document did nothing else, that would be worthwhile. There is also another audience. As you know from other contexts, I believe the whole domain names market is looking more and more like a house of cards and that, sooner or later, there will be incidents, probably ones in which someone is harmed, that get enough public attention that people or groups with authority feel compelled to Do Something. Whether the relevant groups are ICANN leadership, government regulators in one or more countries, or something else, careful and reasoned explanations about which behaviors are reasonable and which ones are not are the Internet's best protections against damaging overreactions. > Section 5 refers to draft-klensin-idna-unicode-review which > updates RFC 5892. It is also in last call so I'd suggest > treating the two drafts as a bundle and replace the paragraph > with a reference to the RFC. Under any normal circumstances, great (and obvious) idea. When the recent history of IDNA documents (and i18n documents more generally), including the first draft of this one being posted early in 2017 and its taking until now to get serious review and a Last Call, is considered, I think it is better to keep them formally separate. If they go through the works together, we will certainly fix the references. But, if something ties one of them up, whether to hold the other one up as a result -- despite the reference, they really are independent -- should be a substantive decision by the IESG with community input rather than a decisions the RFC Production Center makes on a procedural basis. > Section 5.1 updates RFC 5890 section 4.2 to say in part "A 63 > octet A-label cannot represent more than 58 Unicode code > points ..." which is true, but is easy to miss the point that > the UTF-8 version is likely to be a lot more than 58 octets. > I'd change it to something like "A 63 octet A-label can > represent up to 58 Unicode code points, each of whose UTF-8 > encoding can take up to four octets..." Thought about doing something like that, but (i) there is --quite deliberately and after discussion in the WG-- no UTF-8 dependency or requirement in the IDNA specs. Use of UTF-8, rather than some other encoding form, is probably a good recommendation or requirement, but not in IDNA itself, so getting significantly into that here would require considerable foundation that does not now exist. Also note that, while the code points far enough out in the Unicode range to require four octets each a label consisting entirely of code points from the ASCII repertoire other than a single "extended Latin" one is actually shorter in UTF-8 than in A-label form. Unless you see reasons I don't, let's not go there. thanks for the review, best, john From nobody Tue Aug 6 08:32:41 2019 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 DC73212036D for ; Tue, 6 Aug 2019 08:32:32 -0700 (PDT) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=S11Ll0ce; dkim=pass (1536-bit key) header.d=taugh.com header.b=SRQbnCU9 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 A48gy-oY2XZ1 for ; Tue, 6 Aug 2019 08:32:30 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 E40131201A2 for ; Tue, 6 Aug 2019 08:32:29 -0700 (PDT) Received: (qmail 86433 invoked from network); 6 Aug 2019 15:32:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1519d.5d499d8b.k1908; i=johnl-iecc.com@submit.iecc.com; bh=LwWAKBeVIoKKLK4IcWPIkzuNvQQX9veco5dl5yNUYMs=; b=S11Ll0ceac30xUAggYiMIw+wGORiM3WDuDyobkN+E1eSHCmeO9yYdhz1B31Uu96GX8XShYmmLFAjt4fNmAjfSSS7pCnbpH11Rm8IAtiFcRXI6CdKErFcYNVlGuAE1SxWbfF4t+nyiQLZ/p1nzc1r9SpKRCfpS3Lvm54ob7P+2s6/6f4pK4NNSO/LcAgdztLI+Ik1zT8qdZ2ypiUhnrobtwtFRQm4u+obHMsFvMXmXXk3OBdCwpfbp2pXtPgt1pBd DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1519d.5d499d8b.k1908; olt=johnl-iecc.com@submit.iecc.com; bh=LwWAKBeVIoKKLK4IcWPIkzuNvQQX9veco5dl5yNUYMs=; b=SRQbnCU9yJFAgJbgsH2qon6rSMtcxtzSow8G3/JZo415TkzmG11iPKUsRAAMA24oGIINZ4mXTx6BEeqAKeWyI7raeVR/BbbJ4n5LeUiX2C04rpWxiFph+y+e0F3OdMkMNmBLkybqdpSse6rAxn19uauxOlr+aQlqa+P7aeZuYZrd4jiulI2OLzdhlsYqPBtLPXFxTtW9ERhCrPWDMNGg5dKjM+EboeKy4/IEk+6tDSMYW+HcM43l26MDniQTk5wf Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 06 Aug 2019 15:32:26 -0000 Date: 6 Aug 2019 11:32:26 -0400 Message-ID: From: "John R Levine" To: "John C Klensin" Cc: "IETF general list" , idna-update@ietf.org, i18ndir@ietf.org In-Reply-To: References: <20190806051430.5F8187AD3C0@ary.qy> User-Agent: Alpine 2.21.9999 (OSX 337 2019-05-05) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [Idna-update] Last Call: (Internationalized Domain Names in Applications (IDNA): Registry Restrictions and Recommendations) to Proposed Standard 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, 06 Aug 2019 15:32:33 -0000 On Tue, 6 Aug 2019, John C Klensin wrote: >> Section 4 on "For-Profit Domains" contrasts normal zones which >> have names that are of use to the zone's owner, and commercial >> zones where more names mean more money ... > I am also concerned that Getting this perfectly (or even nearly > so) right would require much more text and that more text would > reduce the number of readers. I agree that shorter is better. How about observing that names that don't follow conservative rules are often treated as risky by applications such as web and mail, which take countermeasures such as showing them as A-labels and making links not clickable. You can use this M3AAWG BCP as a reference https://www.m3aawg.org/sites/default/files/m3aawg-unicode-best-practices-2016-02.pdf If we can figure out some way to say this concisely, security systems aggregate data and a TLD with a lot of risky names is likely to be treated as risky overall. >> Section 5.1 updates RFC 5890 section 4.2 to say in part "A 63 >> octet A-label cannot represent more than 58 Unicode code >> points ..." ... > > Thought about doing something like that, but (i) there is > --quite deliberately and after discussion in the WG-- no UTF-8 > dependency or requirement in the IDNA specs. Ah, never noted that. So mostly never mind, although I still prefer "up to 58 code points" rather than "limited to 58 code points" to make it less likely that people will leap to wrong conclusions. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly PS: > There is also another audience. As you know from other contexts, I > believe the whole domain names market is looking more and more like > a house of cards and that, sooner or later, there will be incidents, > probably ones in which someone is harmed, ... I agree it's a house of cards, but I think it's likely to implode mostly silently. There have now been 52 vanity TLDs whose owners have handed them back to ICANN, who has shut them all down since they were all empty. There's one dead non-vanity TLD, the bizarrely managed and tiny .web, which is now frozen in EBERO. I expect that we'll see more frozen corpses, but with few enough names overall that nobody will care. From nobody Thu Aug 29 18:23:08 2019 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 58FB412013B; Thu, 29 Aug 2019 18:23:00 -0700 (PDT) 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, SPF_HELO_NONE=0.001, SPF_NONE=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 UpIvykQA8Ggx; Thu, 29 Aug 2019 18:22:59 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EF821201C6; Thu, 29 Aug 2019 18:22:59 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1i3Vcw-0004mB-1l; Thu, 29 Aug 2019 21:22:58 -0400 Date: Thu, 29 Aug 2019 21:22:52 -0400 From: John C Klensin To: idna-update@ietf.org, i18ndir@ietf.org Message-ID: <270C0552743AE7F0A0C13B44@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] IDNA documents nearing end of IETF Last Call 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, 30 Aug 2019 01:23:01 -0000 Hi. The IETF Last Calls on draft-klensin-idna-rfc5891bis and draft-klensin-idna-unicode-review close tomorrow, 30 August 2019 (less than 23 hours from now). There have been no comments (other than IANA sign-off on both) since before the middle of the month. New versions have been posted reflecting the discussions on all comments made before that time. This note is an informal heads-up: if anyone feels a need to take one last look at them before Pete assembles a final shepherd's report and Barry starts the IESG final review process, please do so _really_ soon. best, john