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

Carsten Bormann <cabo@tzi.org> Sun, 11 April 2021 16:51 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 71C533A14B5 for <cbor@ietfa.amsl.com>; Sun, 11 Apr 2021 09:51:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level:
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 EVYs5_tZPqxL for <cbor@ietfa.amsl.com>; Sun, 11 Apr 2021 09:51:20 -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 9E06C3A14B3 for <cbor@ietf.org>; Sun, 11 Apr 2021 09:51:20 -0700 (PDT)
Received: from [192.168.217.118] (p548dc178.dip0.t-ipconnect.de [84.141.193.120]) (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 4FJHv94fwxzydC; Sun, 11 Apr 2021 18:51:17 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <20210411161045.9648FF40799@rfc-editor.org>
Date: Sun, 11 Apr 2021 18:51:16 +0200
Cc: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, christoph.vigano@uni-bremen.de, "Murray S. Kucherawy" <superuser@gmail.com>, Francesca Palombini <francesca.palombini@ericsson.com>, Barry Leiba <barryleiba@computer.org>, =?utf-8?Q?Christian_Ams=C3=BCss?= <christian@amsuess.com>
X-Mao-Original-Outgoing-Id: 639852676.652444-d6cfa777d0736a44fd295fd3a9a7f983
Content-Transfer-Encoding: quoted-printable
Message-Id: <4986660B-EDCC-4D07-A74E-BBEBE698721D@tzi.org>
References: <20210411161045.9648FF40799@rfc-editor.org>
To: cbor@ietf.org, smbarte2@illinois.edu
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/12YE-suaunQV5PnZ8KYeT7ZmzuA>
Subject: Re: [Cbor] [Technical Errata Reported] RFC8610 (6527)
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: Sun, 11 Apr 2021 16:51:25 -0000

Hi Sean,

thank you for submitting this errata report.

Without going into all the details here:

CDDL imports JSON syntax (Section 7 of RFC 8259) for text strings, and that has been somewhat simplified in the ABNF (which allows more than the RFC 8259 rules then actually allow).
However, there is one omission in the ABNF: the \u syntax, which is somewhat complicated in JSON because it is followed either by 4 hex digits that are not in the range d800 to dfff or by 4 hex digits in the range d800 to dbff, another \u, and four more hex digits dc00 to dfff.
Someone needs to sit down and write up the ABNF for that (or find some ABNF that already has done the work).

I’m not sure this update should all be put into an errata item; maybe we should pursue writing this up in a document that updates RFC 8610 that could then also add a less unwieldy syntax for non-BMP code points such as the ubiquitous \u{…}.

It seems people haven’t used a lot of \u notation with CDDL before: except for the C0 control characters not covered by JSON escapes, the literal character usually works well enough.

Grüße, Carsten


> On 2021-04-11, at 18:10, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> 
> The following errata report has been submitted for RFC8610,
> "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6527
> 
> --------------------------------------
> Type: Technical
> Reported by: Sean Bartell <smbarte2@illinois.edu>
> 
> Section: B
> 
> Original Text
> -------------
>     SESC = "\" (%x20-7E / %x80-10FFFD)
> 
> Corrected Text
> --------------
>     SESC = "\" (%x22 / %x27 / %x2F / %x5C / %x62 / %x66 / %x6E / %x72 / %x74 / %x75 4HEXDIG )
> 
> Notes
> -----
> The ABNF rule for string escape codes should specify which escape codes are allowed, and also specify that "\u" must be followed by four hex digits. My suggested correction is based on JSON, but with the addition of "\'" (single quote) for use in text-based byte strings (section G.2). (Presumably, characters outside the BMP must be escaped using a surrogate pair, as in JSON.)
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC8610 (draft-ietf-cbor-cddl-08)
> --------------------------------------
> Title               : Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures
> Publication Date    : June 2019
> Author(s)           : H. Birkholz, C. Vigano, C. Bormann
> Category            : PROPOSED STANDARD
> Source              : Concise Binary Object Representation Maintenance and Extensions
> Area                : Applications and Real-Time
> Stream              : IETF
> Verifying Party     : IESG