Re: [Idna-update] FWD: Last Calls on two IDNA documents
"J-F C. Morfin" <jfc@morfin.org> Sat, 03 August 2019 23:53 UTC
Return-Path: <jfc@morfin.org>
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 <jfc@morfin.org>) 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 <john-ietf@jck.com>, i18ndir@ietf.org, idna-update@ietf.org
From: "J-F C. Morfin" <jfc@morfin.org>
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: <https://mailarchive.ietf.org/arch/msg/idna-update/5m5qZkl9IKdLJWNoGgyvPfP8uHI>
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" <idna-update.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idna-update>, <mailto:idna-update-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idna-update/>
List-Post: <mailto:idna-update@ietf.org>
List-Help: <mailto:idna-update-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idna-update>, <mailto:idna-update-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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 <iesg-secretary@ietf.org> >To: IETF-Announce <ietf-announce@ietf.org> >Cc: barryleiba@gmail.com, >draft-klensin-idna-unicode-review@ietf.org, resnick@episteme.net >Subject: Last Call: <draft-klensin-idna-unicode-review-02.txt> >(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' <draft-klensin-idna-unicode-review-02.txt> 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 <iesg-secretary@ietf.org> >To: IETF-Announce <ietf-announce@ietf.org> >Cc: draft-klensin-idna-rfc5891bis@ietf.org, >barryleiba@gmail.com, resnick@episteme.net >Subject: Last Call: <draft-klensin-idna-rfc5891bis-04.txt> >(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' > <draft-klensin-idna-rfc5891bis-04.txt> 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
- [Idna-update] FWD: Last Calls on two IDNA documen… John C Klensin
- Re: [Idna-update] FWD: Last Calls on two IDNA doc… John C Klensin
- Re: [Idna-update] FWD: Last Calls on two IDNA doc… J-F C. Morfin
- Re: [Idna-update] FWD: Last Calls on two IDNA doc… Jaap Akkerhuis
- Re: [Idna-update] FWD: Last Calls on two IDNA doc… John C Klensin