Re: [Cbor] Review of draft-bormann-cbor-cddl-control-01

Carsten Bormann <cabo@tzi.org> Wed, 02 September 2020 11:02 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 D0E403A0EEA; Wed, 2 Sep 2020 04:02:42 -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 Ufh6m5zH0ASC; Wed, 2 Sep 2020 04:02:40 -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 B82D73A0EE9; Wed, 2 Sep 2020 04:02:39 -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 4BhLct1HXSzyY6; Wed, 2 Sep 2020 13:02:38 +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: <01b601d67e79$594d2960$0be77c20$@augustcellars.com>
Date: Wed, 02 Sep 2020 13:02:37 +0200
Cc: draft-bormann-cbor-cddl-control@ietf.org, cbor@ietf.org
X-Mao-Original-Outgoing-Id: 620737357.553142-17c2b2fb8bf3381136985158db309c15
Content-Transfer-Encoding: quoted-printable
Message-Id: <5AC11A42-DBE3-4297-B750-F37F6C1DECF0@tzi.org>
References: <01b601d67e79$594d2960$0be77c20$@augustcellars.com>
To: Jim Schaad <ietf@augustcellars.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/C0mz6ePjKrsamEU6BMK2YYo-qCo>
Subject: Re: [Cbor] Review of draft-bormann-cbor-cddl-control-01
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: Wed, 02 Sep 2020 11:02:43 -0000

Hi Jim,

thank you for the comments!

> On 2020-08-30, at 04:57, Jim Schaad <ietf@augustcellars.com> wrote:
> 
> A couple of comments on this document.  It is very possible that I have
> already made this comments and they are on your to do list.
> 
> 1.  Abstract needs to be expanded to identify what operators are in this
> document.

Done.

> 2. Bikeshed topic - I don't really like the name of the .feature control.
> The problem is that the definition of a feature is not at all clear from the
> name of the control.  Among other things it does not say which extension
> points are targeted.   I don't know that I have a good suggestion at this
> point but something long the lines of .map-extensions is a much tighter
> description of what is here.

I really like that name, and (once you know what the .feature control does) something clumsy like map-extensions is further away from being readable than .feature.

> 3.  Section 2.1 - I just ran into a potential issue with RFC 8610 that is
> highlighted here.    On my system I would expect the result to be b =
> "foo\r\n  bar\r\n  baz\r\n".  Both "\n" and "\r\n" are considered as legal
> inside of a byte string value and I did not find text to resolve it for the
> non-hex/base64 case (where it is not relevant).  

Indeed, this is not specified in RFC 8610, which I consider a todo.
I wrote draft-bormann-dispatch-modern-network-unicode to address this class of problem, but that hasn’t seen recent updates (it will, soon).
For now, I have updated the comment to say that the equivalent is for \n-newline systems.

> 4. Section 4 - Define behavior .feature is referenced outside of a map key.
> Or are there other places where it can be used and thus these need to be
> enumerated.

It can be used anywhere.
No need to enumerate because it literally is anywhere.

Where does it say map key?
Oh, that’s the example.

(The biggest real-life example that I know of, https://github.com/one-data-model/SDF/blob/master/sdf-feature.cddl , also uses keys map entries, but also map values and generic values in an any-like construct.)
I copied over a type extension example.

> 5. Acknowledgements - I think this does not read correctly as it says that I
> suggested improvements on .feature rather than the document as a whole which
> is what I think you meant to say.

Swapped.

> 6. Section 3 - The description says that following is legal, but does not
> give a clue on what the correct behavior would be:
> 
> Value = text . abnf "full-date\n"
> 
> The text says that it is followed by zero or more rules, I would assume that
> at least one rule would be required and the given target name must exist as
> a rulename for a rule.  I think you might want to switch from element to
> rulename in this text as well.  Element would allow for
> 
> Value = text .abnf "(WSP / CRLF WSP”)

(If WSP and CRLF are defined below(*) and the position of the quote is fixed.)
Is that a problem?

Zero rules make sense in very simple applications such as:

Number = text .abnf “1*%x30-39"

If we change element to rulename, that usage of course goes away.

(*) Added a sentence making this clearer.

Changes are in https://tools.ietf.org/rfcdiff?url2=draft-bormann-cbor-cddl-control-02.txt

Grüße, Carsten