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

Carsten Bormann <cabo@tzi.org> Tue, 13 April 2021 14:03 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 D03D63A1869 for <cbor@ietfa.amsl.com>; Tue, 13 Apr 2021 07:03:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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=unavailable 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 vUM7rIy6AIQf for <cbor@ietfa.amsl.com>; Tue, 13 Apr 2021 07:03:35 -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 0684E3A185B for <cbor@ietf.org>; Tue, 13 Apr 2021 07:03:34 -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 4FKS4h3J5wz16gW; Tue, 13 Apr 2021 16:03:32 +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: <513F7F4F-E791-4B96-AF3E-42A7B1447EF7@ericsson.com>
Date: Tue, 13 Apr 2021 16:03:31 +0200
Cc: Barry Leiba <barryleiba@computer.org>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, "smbarte2@illinois.edu" <smbarte2@illinois.edu>, "cbor@ietf.org" <cbor@ietf.org>, "Murray S. Kucherawy" <superuser@gmail.com>, =?utf-8?Q?Christian_Ams=C3=BCss?= <christian@amsuess.com>, "christoph.vigano@uni-bremen.de" <christoph.vigano@uni-bremen.de>
X-Mao-Original-Outgoing-Id: 640015410.918579-b669c03b34cf301f7491abee4101bd23
Content-Transfer-Encoding: quoted-printable
Message-Id: <46AD6448-751D-42BB-A7E9-655D5A98D9B9@tzi.org>
References: <20210411161045.9648FF40799@rfc-editor.org> <4986660B-EDCC-4D07-A74E-BBEBE698721D@tzi.org> <2E410DD1-D0E2-4137-B7E7-7FB18CF71971@tzi.org> <CALaySJJAzJgtQY9wuF1dgCQRfTSAz3Ofva-N-EwqcFGo_d6XEw@mail.gmail.com> <513F7F4F-E791-4B96-AF3E-42A7B1447EF7@ericsson.com>
To: Francesca Palombini <francesca.palombini=40ericsson.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/7-0jAM5C56Q89XVkCLqHWo2kMX0>
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: Tue, 13 Apr 2021 14:03:43 -0000

Hi Francesca,

I must admit that I’m not really comfortable with the errata process.

This errata report points to a problem with the ABNF definition of CDDL that keeps it from upholding the promise in Section 3.1 (top of page 16).
(Note that the note in the same paragraph is also about ABNF, but about how CDDL is different from ABNF, not about details of using the JSON string form and describing that in ABNF.  This stuff is all so meta...)

So is an update necessary?  The problem does not break existing specifications, as far as I know.  I would expect that implementers of CDDL will want to do something similar to what I did for the cddlc tool; the conflict between ABNF spec and text needs to be resolved in some way and a search for a minimal way to do so will come up with a solution similar to mine.
It is less clear that this minimal way is what we actually want to limit ourselves to.
But we *could* apply this hot fix and think about better ways to handle literals later, in CDDL 2.0 — draft-bormann-cbor-cddl-freezer has a Section 3 about literal syntax.

On the other hand, a workaround for this gap will be available with .cat, which I think we will be moving forward even faster than the next CDDL version.  Having an errata report that is not just rejected but acknowledges the problem and possibly points to this workaround for now would be helpful to users.

Grüße, Carsten


> On 2021-04-13, at 15:29, Francesca Palombini <francesca.palombini=40ericsson.com@dmarc.ietf.org> wrote:
> 
> I agree with Barry in that this seems to require more thinking and broader review and consensus. Carsten, you seem to imply that this should instead be rejected, with the motivation that it would need a new document (updating 8610), is that right ?
> 
> (For everybody not familiar with the errata status definition: https://www.rfc-editor.org/errata-definitions/
> Hold for document update: “The erratum is not a necessary update to the RFC. However, any future update of the document might consider this erratum, and determine whether it is correct and merits including in the update.”
> Rejected: “The erratum [...] proposes a change to the RFC that should be done by publishing a new RFC that replaces the current RFC. In the latter case, if the change is to be considered for future updates of the document, it should be proposed using channels other than the errata process, such as a WG mailing list.”)
> 
> Francesca
> 
> On 13/04/2021, 15:07, "Barry Leiba" <barryleiba@computer.org> wrote:
> 
>    Indeed, this one screams "Hold for Document Update" to me, as it's
>    something that rather more complex.  It's clear that this isn't just
>    an "oops" when we published, but, rather a (valid) rethinking that
>    needs broader review and consensus on the solution.
> 
>    Barry
> 
>    On Tue, Apr 13, 2021 at 8:13 AM Carsten Bormann <cabo@tzi.org> wrote:
>> 
>> On 2021-04-11, at 18:51, Carsten Bormann <cabo@tzi.org> wrote:
>>> 
>>> 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 was too lazy to find some ABNF so I wrote my own.
>> 
>> 76c76,84
>> < SESC = "\" (%x20-7E / %x80-10FFFD)
>> ---
>>> 
>>> SESC = "\" ( %x22 / %x2F / %x5C / %x62 / %x66 / %x6E / %x72 / %x74 /
>>>             (%x75 hexchar) )
>>> 
>>> hexchar = ((DIGIT / "A"/"B"/"C" / "E"/"F") 3HEXDIG) /
>>>           ("D"
>>>            (( %x30-37 2HEXDIG ) /
>>>             (("8"/"9"/"A"/"B") 2HEXDIG "\" %x75 "D"
>>>              ("C"/"D"/"E"/"F") 2HEXDIG )))
>> 79c87
>> < BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / CRLF
>> ---
>>> BCHAR = %x20-26 / %x28-5B / %x5D-10FFFD / SESC / "\'" / CRLF
>> 
>> 
>> The second change is necessary as SESC is now narrowly restricted to the escape combinations that JSON allows in text strings, and \' is not among those.
>> 
>> You can play with this changed grammar in cddlc version 0.0.3 (`gem update` if needed).
>> 
>>> 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{…}.
>> 
>> I’m still not entirely sure we want to handle this as a bog-standard errata item.
>> Opinions welcome.
>> 
>> Grüße, Carsten
>> 
> 
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor