Re: [Cbor] Invalid Tag Values

Carsten Bormann <> Thu, 24 June 2021 19:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D81013A2834 for <>; Thu, 24 Jun 2021 12:21:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MZkEJDlQRG_F for <>; Thu, 24 Jun 2021 12:21:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 79FD73A2832 for <>; Thu, 24 Jun 2021 12:21:42 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4G9qkX2vsfz2xHd; Thu, 24 Jun 2021 21:21:40 +0200 (CEST)
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: Thu, 24 Jun 2021 21:21:40 +0200
X-Mao-Original-Outgoing-Id: 646255300.015118-3b6aec86f4b8f9b77147aef4fc57a81d
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Kio Smallwood <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Cbor] Invalid Tag Values
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: Thu, 24 Jun 2021 19:21:51 -0000

Hi Kio,

> I'm having trouble understanding the rationale of intentionally invalid tags as documented here[1]
> Under what circumstances would an encoder produce these tags

Never.  They are explicitly reserved so that an implementation has a selection of tag numbers that it can use internally, such as in order to mark the absence of a tag.

> and what should a decoder do when encountering them?

Mark the data item as invalid.
I don’t think a more rigorous response (rejecting the data item the same way that a non-well-formed input would be) would be out of line, as the tag numbers are explicitly marked as “not to occur in interchange”.
(RFC 8949 just doesn’t have a category between non-well-formed and invalid that we could use here.)

> Since I'm working on that part of the decoder[2] anyway I thought I'd better check.

Thank you a lot for doing this!

If you have suggestions how the text in -notable-tags could be made even more explicit about this, please tell us.

Grüße, Carsten