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