IETF Logo Mail Archive

Re: [I18ndir] [art] Fwd: New Version Notification for draft-bray-unichars-04.txt

Carsten Bormann <cabo@tzi.org> Wed, 20 September 2023 04:37 UTC

Return-Path: <cabo@tzi.org>
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 7512BC151082; Tue, 19 Sep 2023 21:37:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuAUjbbR7Wwq; Tue, 19 Sep 2023 21:37:23 -0700 (PDT)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1864BC15106F; Tue, 19 Sep 2023 21:37:20 -0700 (PDT)
Received: from smtpclient.apple (p548dc15c.dip0.t-ipconnect.de [84.141.193.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Rr5NZ2BC3zDCf7; Wed, 20 Sep 2023 06:37:18 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAChr6Syxofvsz6bzw7sZcNNbQHw0KnBgTFfAmAmz8gRcQQwnBg@mail.gmail.com>
Date: Wed, 20 Sep 2023 06:37:07 +0200
Cc: Asmus Freytag <asmusf@ix.netcom.com>, "Manger, James" <James.H.Manger=40team.telstra.com@dmarc.ietf.org>, Tim Bray <tbray@textuality.com>, ART Area <art@ietf.org>, "i18ndir@ietf.org" <i18ndir@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E20C6F72-C895-4EBB-B076-A3C317445049@tzi.org>
References: <169479938668.18742.9199862891950651366@ietfa.amsl.com> <CAHBU6ivzUV947N+n7AoYkCFT3ZfaLobCQ4fBXw3dvkqTT=LBAw@mail.gmail.com> <SY4PR01MB5980D8DDE229D1C57AEDFB55E5FBA@SY4PR01MB5980.ausprd01.prod.outlook.com> <CAChr6SzRa8F+OrELa8N3rAMLmxdvr-g5c0i_9ESnWnwZY-iA4A@mail.gmail.com> <CAChr6Sy05spOW9nsy36kYr8Ob6OYS7vCgrEVPhhWs9Pe4LkpNA@mail.gmail.com> <2e6c2d13-9fc9-d320-3803-2b9a4df3b042@ix.netcom.com> <CAChr6Swr5tS2-wW8dZ0A4J7_Jd+RoHZNJkzhNfcVTi84oDvOPA@mail.gmail.com> <1d19f72f-8c41-f10c-831c-8e5cea347478@ix.netcom.com> <CAChr6Syxofvsz6bzw7sZcNNbQHw0KnBgTFfAmAmz8gRcQQwnBg@mail.gmail.com>
To: Rob Sayre <sayrer@gmail.com>
X-Mailer: Apple Mail (2.3731.700.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18ndir/QWktbaPV7MPtOr7rdy-XpVxUZwA>
Subject: Re: [I18ndir] [art] Fwd: New Version Notification for draft-bray-unichars-04.txt
X-BeenThere: i18ndir@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 20 Sep 2023 04:37:26 -0000

On 19. Sep 2023, at 23:30, Rob Sayre <sayrer@gmail.com> wrote:
> 
> It depends on whether the document is prescriptive or descriptive.

As we have heard, it is neither.
It is intended as a reference document for defining new protocols.
It fails at doing this properly.

> I thought "unicode-code-points = %x0-10FFFF" was pretty sharp, because that is the limit for IETF protocols. It's what JSON does.

(ECMA’s view of JSON.  IETF has made clear that usage of code points that are not valid for Unicode characters generates unpredictable results, which is, from a protocol design or RFC 9431 point of view, indistinguishable from not valid.)

> It's infuriating Unicode,

(It’s not Unicode at all.)

> but the IETF can't legislate it away. It can only make better things, like I-JSON or CBOR.

Right.  So why even discuss this item of toxic waste in a document that is intended to guide development of new protocols?

Grüße, Carsten

v2.23.0 | Report a Bug | By Email