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

Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Sun, 03 November 2019 21:07 UTC

Return-Path: <henk.birkholz@sit.fraunhofer.de>
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 4E25B1200CE for <cbor@ietfa.amsl.com>; Sun, 3 Nov 2019 13:07:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wAOQmuySeRJ for <cbor@ietfa.amsl.com>; Sun, 3 Nov 2019 13:07:00 -0800 (PST)
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (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 1970F1200C1 for <cbor@ietf.org>; Sun, 3 Nov 2019 13:06:59 -0800 (PST)
Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id xA3L6v1F031813 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Sun, 3 Nov 2019 22:06:58 +0100
Received: from [192.168.16.50] (79.234.112.245) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.468.0; Sun, 3 Nov 2019 22:06:52 +0100
To: Laurence Lundblade <lgl@island-resort.com>, Carsten Bormann <cabo@tzi.org>
CC: <cbor@ietf.org>, Christophe Lohr <christophe.lohr@imt-atlantique.fr>
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> <8B119642-7D8D-4BEF-AD75-0AC9935BCD7C@island-resort.com>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <3a7e36aa-a93b-feb7-0bf2-8745e8997699@sit.fraunhofer.de>
Date: Sun, 3 Nov 2019 22:06:51 +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: <8B119642-7D8D-4BEF-AD75-0AC9935BCD7C@island-resort.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [79.234.112.245]
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/PBiAfauI0_rpg1oX4aqP3VnYpV4>
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:07:03 -0000

Well there is this for starters

> https://tools.ietf.org/html/rfc8610#appendix-D


On 03.11.19 22:02, Laurence Lundblade wrote:
> 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 
>> <mailto: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
>>
>>
> 
> 
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor
>