Re: [Cbor] 🔔 WGLC on draft-ietf-cbor-tags-oid-02

Carsten Bormann <> Fri, 15 January 2021 21:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 368423A11C0; Fri, 15 Jan 2021 13:07:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.219
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fMv1hs2gvz8W; Fri, 15 Jan 2021 13:07:05 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6322D3A11BD; Fri, 15 Jan 2021 13:07:05 -0800 (PST)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4DHYdz36yXz10CX; Fri, 15 Jan 2021 22:07:03 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Carsten Bormann <>
In-Reply-To: <>
Date: Fri, 15 Jan 2021 22:07:02 +0100
Cc: "" <>, "" <>
X-Mao-Original-Outgoing-Id: 632437622.7501301-1b53219f2f5efa4246c5e891523527a1
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Francesca Palombini <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Cbor] 🔔 WGLC on draft-ietf-cbor-tags-oid-02
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 15 Jan 2021 21:07:08 -0000

Hi Francesca,

thank you for this review. 

> * I am not sure (and please correct me if I am wrong!) there ever was a conclusion to Jim's comment about not seeing the necessity of going below one layer for maps and arrays:  - this was discussed at an interim:  And I see the text Jim referred to was clarified, but as shepherd I'd like to see more opinions on this point: anybody else seeing a problem with Carsten's point of "if you don't need all bstr tagged, don't use the tag on the map/array" ? Anybody agrees with Jim and would rather this being a 1-level tag?

I haven’t seen support for this, so I consider this a wontfix.

> * Update references to RFC 8949


(Note that we have a downref to RFC 6256 SDNV; I wonder why that isn’t in the downref list .)

> * normative references X.660, X.680 and X.690 are missing links

I didn’t want to innovate here, but RFC 8951 has (inconsistent) ones to X.68x (why is the X.680 one different from the others?).

I went with:

(Wow, the last bib entry for X.660 was in RFC 5280!)

> * add a reference to IANA PEN registry


> "the first byte of each SDNV cannot be 0x80 (which would be a
>   leading zero in SDNV's base-128 arithmetic)."
> "this requirement requires
>      expressing the integer values in their shortest form, with no
>      leading zeroes"
> * I would suggest reversing this sentence: "the first byte cannot be a leading zero in SDNV's base-128 arithmetic, so it cannot take value 0x80", possibly mentioning the requirement on the integer values being expressed in their shortest form. By the way, does this requirement comes from BER OID rules? Can you add some reference to where this is specified?

RFC 6256 says “Section of X.690”, which contains the bullet:

c) bits 7 to 1 of the first subsequent octet shall not all be zero.

Reference added.

> "except for the last byte, where it must be
>   unset" 
> * either replace "must" with "is" or with "MUST" (I would suggest is, because the normative MUST before covers the requirement already)

“is” it is.

> "its first byte" and "its last byte" 
> * I would replace "its" by "the tag's" for clarity.

“the byte string’s", actually.  Done.

> * It seems to me that this document could benefit from a more expanded terminology section. In particular, I would quickly summarize the terms used from X.690 - e.g. arc - and SDNV.

Well, I put this in the “Object Identifier” section:

We also use the term "arc" when the focus is on the edge of the tree
labeled by such an integer value, as well as in the sense of a "long
arc", i.e. a (sub)sequence of such integer values.)

The terminology of X.660 is really confused (they try to maintain the illusion the edges are labeled by Unicode strings), so this is probably the best we can do.

I also added a pointer to RFC 6256 in the terminology section.

> * Some introductory text for the examples in Section 3 would have been good.

I added a sentence.

> * I am a bit unsure about the reasoning behind section 4 "Discussion". Is this not background? Then in my opinion it would fit better in section 2.

I moved it so it is now section 2.2 (initiating some renumbering of sections).

> * I would have merged section 3 and 6 in one section “Examples”

I moved what was Section 6 to a Section 4.1, titled:

4.1.  Tag factoring example: X.500 Distinguished Name

Separating the basic usage examples (now Section 2.2) and the tag factoring usage example (now Section 4.1) probably helps the user.  If you insist, we can of course reorder and merge back.


Thank you again, I think the document is better now…

I have made the updated version available at (pregenerated HTML at as indicated in the README; diff at in rfcdiff format).

The plan is to submit -04 after a quick re-check of these updates.

Grüße, Carsten