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

Carsten Bormann <cabo@tzi.org> Fri, 04 September 2020 00:42 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63D43A1407 for <cbor@ietfa.amsl.com>; Thu, 3 Sep 2020 17:42:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 mcTte-4eMVKR for <cbor@ietfa.amsl.com>; Thu, 3 Sep 2020 17:42:19 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B374D3A140A for <cbor@ietf.org>; Thu, 3 Sep 2020 17:42:09 -0700 (PDT)
Received: from [192.168.217.102] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BjJlz5lplz10Ht; Fri, 4 Sep 2020 02:42:07 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <20200904001702.6E249F40781@rfc-editor.org>
Date: Fri, 4 Sep 2020 02:42:07 +0200
Cc: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, christoph.vigano@uni-bremen.de, "Murray S. Kucherawy" <superuser@gmail.com>, Barry Leiba <barryleiba@computer.org>, Francesca Palombini <francesca.palombini@ericsson.com>, Jim Schaad <ietf@augustcellars.com>, eds@reric.net, cbor@ietf.org
X-Mao-Original-Outgoing-Id: 620872927.303256-ad134aa1b7e970e9d4d739b8ef8c2b44
Content-Transfer-Encoding: quoted-printable
Message-Id: <ABA95628-D8A6-4E8F-A3CD-B51EF5B9ADF9@tzi.org>
References: <20200904001702.6E249F40781@rfc-editor.org>
To: RFC Errata System <rfc-editor@rfc-editor.org>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/zT6XwA_HZ9fAixmeZFLXMtuZv_M>
Subject: Re: [Cbor] [Technical Errata Reported] RFC8610 (6278)
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Sep 2020 00:42:22 -0000

On 2020-09-04, at 02:17, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> 
> Between draft 6 and 7 of the RFC, the ASCII DELETE character 0x7F was excluded from the character set allowed in text literals.  I believe it should also be excluded from the character set of bytestring literals.

I agree.  DEL (0x7F, also known as rubout) was removed based on a comment from Adam Roach:

https://mailarchive.ietf.org/arch/msg/cbor/jzJ297jNm5EoJkJj-n8R43QSOP4/
(Search for “7F”)

Which we implemented in:

https://github.com/cbor-wg/cddl/commit/bf3946

… apparently missing out on BCHAR, as Adam also happened to do.
(Note that BCHAR had gained 0x7F with
https://github.com/cbor-wg/cddl/commit/33b98a
where we added beyond-ASCII characters; this also gave it to SCHAR as well as SESC.)

Note that we never worried to exclude C1 control characters or other characters that might look weird in a specification (trying to do that exhaustively is just a bottomless pit).  So I believe the practical effect of missing out excluding 0x7F from BCHAR is near nil (except maybe in an obfuscated CDDL contest).
But it sure would be nice to be consistent (even if it is not *required* to be consistent here).

My verdict would be: Hold for document update.

Grüße, Carsten