Re: [Cbor] 7049bis: The concept of "optional tagging" is not really used in practice #126

Henk Birkholz <> Sun, 03 November 2019 17:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B5A7120048 for <>; Sun, 3 Nov 2019 09:05:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 lLFmoPqFh7GC for <>; Sun, 3 Nov 2019 09:04:57 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 957DB120044 for <>; Sun, 3 Nov 2019 09:04:55 -0800 (PST)
Received: from ( []) by (8.15.2/8.15.2/Debian-10) with ESMTPS id xA3H4rsM015453 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Sun, 3 Nov 2019 18:04:54 +0100
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 14.3.468.0; Sun, 3 Nov 2019 18:04:48 +0100
To: Laurence Lundblade <>, Christophe Lohr <>
CC: <>
References: <> <> <>
From: Henk Birkholz <>
Message-ID: <>
Date: Sun, 3 Nov 2019 18:04:47 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: []
Archived-At: <>
Subject: Re: [Cbor] 7049bis: The concept of "optional tagging" is not really used in practice #126
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: Sun, 03 Nov 2019 17:05:01 -0000

Hi Laurence,

please see below.

On 03.11.19 17:45, Laurence Lundblade wrote:
> I’m not really a data structure scientist or such, but I think I can see 
> Christophe’s point
> Maybe CBOR-based (and JSON-based) protocols don’t have a formal schema 
> language, but these protocols rely on ordering and such. For example in 
> a COSE_Sign1 it is expected that the first data item is the protected 
> headers, the second the unprotected headers, the third the payload and 
> the fourth the signature. I don’t think you can call them self-describing.
> It seems like CBOR and JSON say “no schema’” to distance from the horror 
> of XML schemas, but in reality CDDL and prose protocol specs are schemas 
> in spirit.
> Maybe a key question here is whether you can say in CDDL “this next item 
> must always be interpreted as a date even though it will never have a 
> date tag”.

I would not use the term "interpretation" here. CDDL is a language, it 
in unambiguous in that regard. But I think it can do exactly what you 
mean :-) It describes the structure of CBOR/JSON messages/documents - if 
it precise enough, CBOR tags are not needed, but to ensure that 
precision you need a dedicated authority, I think.

If CDDL doesn’t have than, then you can’t describe some
> CBOR-protocols with it. CWT would be one of those protocols as it 
> forbids adding the tag to dates.
> To summarize what I understand about tagging:
>     The designer of a new CBOR data item type like a date format will
>     generally register a tag for it. These new data types can be really
>     simple, like epoch dates or really complex like COSE_Sign1.
>     The designer of a protocol using a new data type will indicate in
>     their protocol for each occurrence of it whether the tag must be
>     present or not (never saying the tag may or may not be present). The
>     designer will typically require the tag only when necessary to
>     disambiguate the type of the data item.
>     The implementor of a general purpose library to generate one of
>     these new data item types must give the caller the option to include
>     or not include the tag. Maybe this is just by never automatically
>     outputting the tag and having a distinct output tag function.
>     The implementor of a general purpose library to decode one of these
>     new data types must allow the caller to say that the next data item
>     should be decoded as this new data type whether or not it is tagged.
>     Maybe it even errors out if it is tagged for the cases where the
>     protocol document says no tag should be used.
> What I don’t know is whether CDDL can describe all this desired behavior.
> LL
>> On Oct 24, 2019, at 1:50 AM, Christophe Lohr 
>> < 
>> <>> wrote:
>> On 23/10/2019 13:38, Carsten Bormann wrote:
>>> Section 3.4 talks about "optional tagging" as a secondary purpose of 
>>> tags. But in today's CBOR protocols, tags are rarely "optional" in 
>>> the sense that they can simply be left out without a change in 
>>> semantics, as 3.4 para 3 implies.
>>> This concept comes up again in 4.2.2, where "optional tagging" is 
>>> outlawed in deterministic encoding (but then the text goes on to 
>>> explain that protocols might choose to retain tags, but doesn't say why).
>> To be honest, I don't really understand how much optional are tags.
>> A CDD rule with tags matchs cbor items with tags and reject cbor items
>> without tags. Tags are not optional from the data-model point of view.
>> Moreover, please consider this CDDL objective:
>> (
>>    3.  Data must be able to be decoded without a schema description.
>>        *  Similar to JSON, encoded data should be self-describing so
>>           that a generic decoder can be written.
>> Well, how to do this without putting tags everywhere for everything?
>> (Or I need more explanation about what is "self-describing" and what is
>> a "schema description")
>> Let say I receive data. How may I know that this number is a temperature
>> and not a distance, and that this byte-string is an uuid and not a small
>> picture?
>> The first way is to have a schema (written or not): That is to say a
>> certain preliminary knowledge of expected data which tell me that this
>> number at this place or associated to this map-key is a temperature.
>> The second way is to decorate data with tags, all data.
>> A third way is a compromise between the two first ones: I have a certain
>> level of preliminary knoledge of what data are (a kind of schema
>> description), with possibly some missing parts that are filled by tags.
>> But the only way to decode data _without_ a schema description is to
>> have tags everywhere for everything.
>> Surprisingly, json has no tags and is claimed to be self-describing. Is
>> it really? I'm lost.
>> My feeling is that this objective CBOR should be not so demanding.
>> Best regards,
>> Christophe
>> _______________________________________________
>> CBOR mailing list
>> <>
> _______________________________________________
> CBOR mailing list