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

Laurence Lundblade <lgl@island-resort.com> Sun, 03 November 2019 21:02 UTC

Return-Path: <lgl@island-resort.com>
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 E876E1200CE for <cbor@ietfa.amsl.com>; Sun, 3 Nov 2019 13:02:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 yHltrcGk0w3c for <cbor@ietfa.amsl.com>; Sun, 3 Nov 2019 13:02:17 -0800 (PST)
Received: from p3plsmtpa08-06.prod.phx3.secureserver.net (p3plsmtpa08-06.prod.phx3.secureserver.net [173.201.193.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE6D31200C1 for <cbor@ietf.org>; Sun, 3 Nov 2019 13:02:17 -0800 (PST)
Received: from [10.122.0.22] ([45.56.150.85]) by :SMTPAUTH: with ESMTPA id RN0qiNlpIksi3RN0qi1Hpi; Sun, 03 Nov 2019 14:02:17 -0700
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <8B119642-7D8D-4BEF-AD75-0AC9935BCD7C@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4772C1B3-3AC1-43A3-AE80-A83692423BB4"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sun, 3 Nov 2019 13:02:16 -0800
In-Reply-To: <CBC1EF6C-FAF5-4AC9-B0DC-C3FD2ED8B88D@tzi.org>
Cc: Christophe Lohr <christophe.lohr@imt-atlantique.fr>, cbor@ietf.org
To: Carsten Bormann <cabo@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> <CBC1EF6C-FAF5-4AC9-B0DC-C3FD2ED8B88D@tzi.org>
X-Mailer: Apple Mail (2.3445.104.11)
X-CMAE-Envelope: MS4wfBGFX0Nw9F0SAlY0QQlz97h469bxm2/93oHJn4mMUl5lBUsqByuuIdB2mqsKEPcpLA9eNzet1HpolKuM1FSkWmKTZQIZINDIi4qSyDrYL6g/j2KSX9V1 B2PnCH4/gJfSWp80qca5swhhT7U//8XgkikoDorfe7d72bVoee2d+8/iM/JmqbgnBBhHh0nSuj2E8unKDL5XTIhU8PKi0wbpZJ8xMendHww5nrYmQrQA6WEj
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/naAdT8ST4agyyY5X3GLVMRLLg9s>
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 21:02:20 -0000

OK. I understand.  To use it one of these new types in CDDL, particularly those with a internal structure, you make a pair of CDDL headers, one for tagged and one for untagged that describe it like COSE did (from 8152):

   COSE_Messages = COSE_Untagged_Message / COSE_Tagged_Message

   COSE_Untagged_Message = COSE_Sign / COSE_Sign1 /
       COSE_Encrypt / COSE_Encrypt0 /
       COSE_Mac / COSE_Mac0

   COSE_Tagged_Message = COSE_Sign_Tagged / COSE_Sign1_Tagged /
       COSE_Encrypt_Tagged / COSE_Encrypt0_Tagged /
       COSE_Mac_Tagged / COSE_Mac0_Tagged

   ...

   COSE_Sign1_Tagged = #6.18(COSE_Sign1)

   COSE_Sign1 = [
       Headers,
       payload : bstr / nil,
       signature : bstr
   ]

Would be cool if there were standard CDDL definitions ready for normative reference for all the “tagged” data types defined in 7049 / 7049bis.

LL


> On Nov 3, 2019, at 8:59 AM, Carsten Bormann <cabo@tzi.org>; wrote:
> 
> 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
> 
>