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

Carsten Bormann <cabo@tzi.org> Sun, 03 November 2019 16:59 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 F33561200CC for <cbor@ietfa.amsl.com>; Sun, 3 Nov 2019 08:59:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 tKKuVmWSi00K for <cbor@ietfa.amsl.com>; Sun, 3 Nov 2019 08:59:44 -0800 (PST)
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 462F712008F for <cbor@ietf.org>; Sun, 3 Nov 2019 08:59:44 -0800 (PST)
Received: from [192.168.217.102] (p548DC893.dip0.t-ipconnect.de [84.141.200.147]) (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 475hxB1wNgzyfw; Sun, 3 Nov 2019 17:59:42 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <87889E65-0152-455A-A6B7-C5F336DC97A4@island-resort.com>
Date: Sun, 3 Nov 2019 17:59:41 +0100
Cc: Christophe Lohr <christophe.lohr@imt-atlantique.fr>, cbor@ietf.org
X-Mao-Original-Outgoing-Id: 594493179.809954-6fcbf509bcbe4a2f3a262a3fa1536a55
Content-Transfer-Encoding: quoted-printable
Message-Id: <CBC1EF6C-FAF5-4AC9-B0DC-C3FD2ED8B88D@tzi.org>
References: <92400DAA-A713-4905-A721-34B138E25192@tzi.org> <ed45e995-1858-3169-1be6-0cce5ce37ce3@imt-atlantique.fr> <87889E65-0152-455A-A6B7-C5F336DC97A4@island-resort.com>
To: Laurence Lundblade <lgl@island-resort.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/WXfdpt6ckt_dm8waLOQqF3AlaZs>
Subject: Re: [Cbor] 7049bis: The concept of "optional tagging" is not really used in practice #126
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: Sun, 03 Nov 2019 16:59:47 -0000

Hi Laurence,

CDDL does not describe behavior, but the shape of data.

> 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”.

CDDL can say “this item is a number”.  It does not tell you how to “interpret” things, that would be the job of a language that transforms the data just received into data that is used by an application.

> If CDDL doesn’t have than, then you can’t describe some CBOR-protocols with it.

You sure can “describe” the shape of data in CBOR protocols, but you will also need some information about how you plan to interpret the data.

> CWT would be one of those protocols as it forbids adding the tag to dates.

(For the exp, nbf, and iat claims, or claim numbers 4 to 6:) Yes, the CWT RFC (RFC 8392) tells you that the value here is a number, not a tagged date.

> 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.

Right.  If you need to register for CWT a new claim that could either take a number (such as the longitude of the satellite that this claim is about) or a date/time (such as the time the satellite was launched), then a tag could be useful to make that distinction.  

That example is a bit contrived, because it’s just not as usual to have a choice between a number and a date.  More likely might be a choice between a date/time represented as a Tag 1 and a Tag 1001.  The encoding could choose to leave off the tag from the number that is the enclosed item of Tag 1, so you would have a choice between a number and a Tag 1001.

> 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.

Right.

> What I don’t know is whether CDDL can describe all this desired behavior.

CDDL can describe the shape of the data interchanged, but it can’t describe the mapping to application semantics.  It can provide hints, and that’s one of the things that the unwrap operator is good for: When you apply it to a tag, this is a hint that you do not just want the data shape of that tag’d enclosed item, but also its semantics.

Grüße, Carsten