Re: [Cbor] [Technical Errata Reported] RFC8610 (6278)

Doug Ewell <> Sat, 05 September 2020 18:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1CE6F3A0F0C for <>; Sat, 5 Sep 2020 11:51:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WkSrGQoun8St for <>; Sat, 5 Sep 2020 11:51:06 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 836213A0F08 for <>; Sat, 5 Sep 2020 11:51:06 -0700 (PDT)
Received: from DESKTOPLPOB1E4 ([]) by :SMTPAUTH: with ESMTPSA id EdHEk1dF4IY3yEdHFkUcJ8; Sat, 05 Sep 2020 11:51:06 -0700
X-CMAE-Analysis: v=2.3 cv=Q+asHL+a c=1 sm=1 tr=0 a=9XGd8Ajh92evfb2NHZFWmw==:117 a=9XGd8Ajh92evfb2NHZFWmw==:17 a=IkcTkHD0fZMA:10 a=nORFd0-XAAAA:8 a=lSwEIb3ZGhIDtIUBu0IA:9 a=QEXdDO2ut3YA:10 a=AYkXoqVYie-NGRFAsbO8:22
From: "Doug Ewell" <>
To: "'Carsten Bormann'" <>
Cc: "'RFC Errata System'" <>, "'Barry Leiba'" <>, "'Henk Birkholz'" <>, "'Jim Schaad'" <>, <>, <>, "'Murray S. Kucherawy'" <>, <>, "'Francesca Palombini'" <>
References: <000001d68260$096e6770$1c4b3650$> <>
In-Reply-To: <>
Date: Sat, 5 Sep 2020 12:51:05 -0600
Message-ID: <000001d683b5$837e73b0$8a7b5b10$>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQNTdV+PunJjQxGK5dyncFu9G3rL9QKn7mLGpks9YyA=
Content-Language: en-us
X-CMAE-Envelope: MS4wfKcrgLqr6sZx1eFgIpljw14zTQAlFPvNfpxToEc/XiSHS2NTZgw8IB0l/HPX7MVrFVYAJENRviOVlfNZ/Mljmgrl+7spg7TUNJfV8lvpqxQlYjqvGFVU 5gn9mtPlTi2tclH2uS7TSvzYbl9X1zrih4WIYeEkZJUcxyZu63DMcuDN396h0T4uL5qplofJ+WRkDxUt+bl26cOaJY9IG6d8Ek6eJ8FCc3e7La7hc8rSIZhv qX8D/4mp5Vj1YQHYCDbj9a9FHr/fCosxmSSw4zMAHmoy1TaqIUfHBGCgGa0KN/kLMfgKkly1cB8wjlSPnvegKkCvFFTc/6UaAC8R1EiZ2Gb7xn6keENzJMwa /E0Wb1Gem1UUR5HRhRbErtOKD5RwpqJQuE3v9HEQAPjDSSBvkbdAusS0+Q8/1wIthYOf6m8Bf88DwYuRZ0LVm9iJ2mgnDJkU6fOZ9u0/Vc3NGEwhiP14W3HA 1ThRtJSlc0vx9GQ7
Archived-At: <>
X-Mailman-Approved-At: Sat, 05 Sep 2020 12:19:57 -0700
Subject: Re: [Cbor] [Technical Errata Reported] RFC8610 (6278)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 05 Sep 2020 18:51:09 -0000

Carsten Bormann wrote:

> The below is exactly what should never happen: having to encode
> detailed (and somewhat arcane) knowledge about a standard in the
> bowels of another, mostly unrelated standard. I think we hit the right
> balance  with VCHAR and SCHAR, we just forget to fix BCHAR.  But we
> can discuss that when we do the bis...

To be sure, it should not be necessary to specify this stuff in CBOR. This and other Unicode-specific rules should be part of the ABNF spec (Section B.1, "Core Rules") to go with all the ASCII-specific rules already there.

Ending the range of allowable characters at 10FFFD solves only a tiny part of the "exclude noncharacters" problem. If we don't want to solve the whole problem, then don't solve any of it: just end the range at 10FFFF and pretend we don't know about noncharacters.

For that matter, even the value 10FFFD (or 10FFFF) can be considered detailed (and somewhat arcane) knowledge about Unicode. Removing that is left as an exercise.

Doug Ewell | Thornton, CO, US |