Re: [Cbor] Review draft-bormann-cbor-tags-oid-07

Carsten Bormann <cabo@tzi.org> Fri, 03 July 2020 22:47 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 0CA283A0A2B; Fri, 3 Jul 2020 15:47:46 -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 yClhaMYd_afD; Fri, 3 Jul 2020 15:47:43 -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 A08133A0A27; Fri, 3 Jul 2020 15:47:41 -0700 (PDT)
Received: from [172.16.42.112] (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 49z98X03MgzyVf; Sat, 4 Jul 2020 00:47:39 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <000801d65169$5915dfb0$0b419f10$@augustcellars.com>
Date: Sat, 04 Jul 2020 00:47:39 +0200
Cc: draft-bormann-cbor-tags-oid@ietf.org, cbor@ietf.org
X-Mao-Original-Outgoing-Id: 615509259.561434-dd21459be295ed41f94a64164a33f254
Content-Transfer-Encoding: quoted-printable
Message-Id: <5E9374BB-8893-4CB5-9548-672BC9556E55@tzi.org>
References: <000801d65169$5915dfb0$0b419f10$@augustcellars.com>
To: Jim Schaad <ietf@augustcellars.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/VWBPAY5TxHrAFQozUXPeFJtCw84>
Subject: Re: [Cbor] Review draft-bormann-cbor-tags-oid-07
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, 03 Jul 2020 22:47:46 -0000

Hi Jim,

thank you for this flash override review :-)

> On 2020-07-03, at 20:39, Jim Schaad <ietf@augustcellars.com> wrote:
> 
> * Section 1 - There has been a recent argument on one of the mailing lists
> about the question between the value of an encoding and the contents of the
> value of the encoding.  I think that it needs to be highlighted that this is
> referring to the V portion of TLV for BER.  "The contents of these
> encodings..." is mostly likely going to cause somebody to have the same
> problem.

I added »(the "value" part of BER's
type-length-value structure)«.

> * Section 1 - last sentence - What it is being referred to here?

Last sentence:

It is intended as the reference document for the IANA registration of
the tags so defined.

It = this document?

Or did you mean the penultimate sentence?  That needed to be fixed; done.

> * Section 2 - What is a "primary integer"?  Is this one that has not yet
> gone to high school?

I have no idea.  ASN.1 term?  Ah right, X.660.  Since arcs can be identified both by its actual integer value and (not necessarily unambiguous) secondary identifiers, the integer value is called “primary” integer value.  Fixed this by adding explanation and getting rid of the “primary” elsewhere. 

> * Section 2.1 - I don't think it is the tag that is invalid, but rather the
> value in the tag that is invalid.  

Well, the value (tag content) is a byte string, and there are no validity requirements on byte strings.  It is that tag formed out of tag number and tag content that is invalid.

> The "tagged value"?  

We now call that “tag content” in 7049bis.

> (Is this a
> well-formed error?)

No, a validity error.

> * You need to update references and text to the CBOR bis document.

Eventually…  But yes, using the terms from 7049bis helps. Fixed.

> * Section 5 - Does it make any sense to allow the tags to be specified in a
> nested manner?  TBD110(X) [TBD111(Y)] ?

Not sure how that would work.
Can you give an example?

I was thinking about stacking tags to deepen their effect into arrays and maps, but haven’t quite figured that out either.

> * Section 5 - One way to handle the problem would be to define a new tag
> which cancels any tag inheritance as a general purpose thing.  This might
> also be useful for other tags which might be defined in this way in the
> future.

Yes, but if you generate an example, that becomes unwieldy as well (the neutralizer needs to be inserted in awkward places; the CDDL will be horrendous).
So instead of starting out with an infinitely deep effect that then needs to be stopped, I was thinking about one-deep plus a way to extend that.
But first we need a few good examples.

> * Section 7 - I would agree that having an operator that parses string
> dotted format does not make any sense.  It might be useful to include the
> .oid operator however which has the property of doing the magic.

Done.

> * Section 7 - I need an example of .sdnv because I am having a problem
> figuring out how it would be used.

If there is a .fooseq, there should be a .foo for exactly one foo.

RFC5050blockflags-encoded = bytes .sdnv block-flags
block-flags = uint .bits &(
Block-must-be-replicated-in-every-fragment:       0
Transmit-status-report-if-block-cant-be-processed:       1
Delete-bundle-if-block-cant-be-processed:       2
Last-block:       3
Discard-block-if-it-cant-be-processed:       4
Block-was-forwarded-without-being-processed:       5
Block-contains-an-EID-reference-field:       6
)

Well, yeah, any reasonable spec would just carry the uint.

> * Section 7 - If we do nesting behavior on these tags, then a control
> operator to make A relative to B would be useful as well.

Again, if you have an example for that, I’m all ears.

I pushed an update to https://github.com/cabo/cbor-oid/tree/cleanup; view formatted at https://raw.githack.com/cabo/cbor-oid/cleanup/draft-bormann-cbor-tags-oid.html — plaintext diff at

https://tools.ietf.org/rfcdiff?url1=draft-bormann-cbor-tags-oid-07.txt&url2=https://raw.githubusercontent.com/cabo/cbor-oid/cleanup/draft-bormann-cbor-tags-oid.txt

Grüße, Carsten