IETF Logo Mail Archive

Re: [I18ndir] draft-faltstrom-unicode12 or draft-faltstrom-unicode14?

Patrik Fältström <patrik@frobbit.se> Mon, 04 October 2021 02:31 UTC

Return-Path: <patrik@frobbit.se>
X-Original-To: i18ndir@ietfa.amsl.com
Delivered-To: i18ndir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F419F3A0E63 for <i18ndir@ietfa.amsl.com>; Sun, 3 Oct 2021 19:31:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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=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 NSaQrFyUan1s for <i18ndir@ietfa.amsl.com>; Sun, 3 Oct 2021 19:31:32 -0700 (PDT)
Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.176]) (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 55BF13A0E5E for <i18ndir@ietf.org>; Sun, 3 Oct 2021 19:31:32 -0700 (PDT)
Received: from [192.165.72.128] (unknown [IPv6:2a02:80:3ffc:0:e980:c3fd:a7d0:35e8]) by mail.frobbit.se (Postfix) with ESMTPSA id A1A1D2168E; Mon, 4 Oct 2021 04:31:29 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=frobbit.se; s=mail; t=1633314689; bh=q9WxhLbOOFrfc/IWmkjMFyZF/OnvStFa5SuUAXDzj8M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sXHqv2S4Y08Ts2cWcak7ME6RUYHynmJnEa6eOlwRGl/XKY6/NTxW9N8vG7YD4TPNl tFwNWK5OLiLdiF/2g3c2uxDXuDfsHdgd1Gh+jLOxj6yBjrw8UXzizB6HvxItrMmqYf fuc7I7BQ5aIPne8/w6RQpEsKftKPxEF8rS1ZskjA=
From: Patrik Fältström <patrik@frobbit.se>
To: Asmus Freytag <asmusf@ix.netcom.com>
Cc: i18ndir@ietf.org
Date: Mon, 04 Oct 2021 04:31:29 +0200
X-Mailer: MailMate (1.14r5820)
Message-ID: <36BA4ABD-E15D-4330-914C-59B91FC4C023@frobbit.se>
In-Reply-To: <18d6ee4f-2ea6-5c1d-991a-648dec3fe887@ix.netcom.com>
References: <776E4588-A1E1-484D-85BC-F31D8CE99309@vpnc.org> <35F7535E905846332A210F35@PSB> <18d6ee4f-2ea6-5c1d-991a-648dec3fe887@ix.netcom.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_249B09EF-B90E-49FB-97F1-F81410A0FEDC_="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18ndir/sboJmXx4HCa7HtIEOfzeBGcZ_JA>
Subject: Re: [I18ndir] draft-faltstrom-unicode12 or draft-faltstrom-unicode14?
X-BeenThere: i18ndir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Internationalization Directorate <i18ndir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i18ndir>, <mailto:i18ndir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i18ndir/>
List-Post: <mailto:i18ndir@ietf.org>
List-Help: <mailto:i18ndir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i18ndir>, <mailto:i18ndir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Oct 2021 02:31:40 -0000

On 4 Oct 2021, at 4:26, Asmus Freytag wrote:

> Now, my thought was, if Unicode can flag all the additions/changes in terms easily digestible from the IDNA2008 perspective, and does so in the context of its BETA process, then any glaring issue can be handled by whoever is interested in a follow up. Either try to get properties modified/changes retracted in the Unicode process via a public review comment, or issue an exception on the IETF side -- before the characters get deployed.

I have no issues producing a list during the BETA process. In fact I do, to prepare on the upcoming version of Unicode.

The big thing is not that, but the review process as laid out in RFC 8753.

Given some code points get added with derived property value PVALID, which ones should be PVALID and which ones should undergo a specific review?

That I feel is our job in IETF according to RFC 8753.

My suggestion:

1. Let this draft be published (I tried 6 months ago, but no response, nothing happened)

2. Unicode 13 and 14 we follow RFC 8753 and learn how it goes

   Patrik

v2.23.0 | Report a Bug | By Email