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

Laurence Lundblade <lgl@island-resort.com> Wed, 06 November 2019 20:18 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 066941200A4 for <cbor@ietfa.amsl.com>; Wed, 6 Nov 2019 12:18:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 0bYgAMyiVM70 for <cbor@ietfa.amsl.com>; Wed, 6 Nov 2019 12:18:03 -0800 (PST)
Received: from p3plsmtpa06-04.prod.phx3.secureserver.net (p3plsmtpa06-04.prod.phx3.secureserver.net [173.201.192.105]) (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 F037312004A for <cbor@ietf.org>; Wed, 6 Nov 2019 12:18:02 -0800 (PST)
Received: from [10.122.0.182] ([45.56.150.85]) by :SMTPAUTH: with ESMTPA id SRkfiex5Er3FgSRkgija5p; Wed, 06 Nov 2019 13:18:02 -0700
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Laurence Lundblade <lgl@island-resort.com>
In-Reply-To: <E7C97A51-BE67-4752-ADE6-A985E0B8A7AF@tzi.org>
Date: Wed, 6 Nov 2019 12:18:00 -0800
Cc: cbor@ietf.org, Christophe Lohr <christophe.lohr@imt-atlantique.fr>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DD122452-435D-447C-92C8-EEFBA51048C0@island-resort.com>
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> <B86EE13B-12C9-4918-8BE9-5E4BEBF3B779@tzi.org> <3F9E4E02-7A86-4954-8E31-0E28D2B2FCDA@island-resort.com> <E7C97A51-BE67-4752-ADE6-A985E0B8A7AF@tzi.org>
To: Carsten Bormann <cabo@tzi.org>
X-Mailer: Apple Mail (2.3445.104.11)
X-CMAE-Envelope: MS4wfA6x4hdFjUPJCvkciC2AtcGLky0QjE14DdBp3F4+mA/S80GG5f4y6/1vpiEr8vfHP6bgdzetxoDhzDXhnHEJVm1vLmB4RoQaOVR6aGphB8bT7W7KY88U usMhglUo6gywKfDWMbBs2Fzl/kypJqpnfvZ3y93p8Ri/BX00+z1fY3hMMjODZoVkOKlNkV+T4p/g1eRI7nGR1A5dX6I20UqPd1j35J+3PGcXd02IBUGdKcQC
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/r_Axlh3zj5-VjLroVqIBEEWy-6U>
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: Wed, 06 Nov 2019 20:18:05 -0000

Thanks for all the explanations and comments and pointing out things I missed when I read CDDL.

One more observation.

Seems like this is all about defining new registered data types, very similar to a typedef in C.

For example, this is about a data type for temperature, but not indication whether the temperature is of the turkey in the oven or of the Chernobyl reactor core.  To distinguish reactor core from turkey it is by the ordering in an array or the key/label in a map, never the tag. In C it is the variable name.

LL



> On Nov 4, 2019, at 8:34 AM, Carsten Bormann <cabo@tzi.org>; wrote:
> 
> On Nov 4, 2019, at 17:28, Laurence Lundblade <lgl@island-resort.com>; wrote:
>> 
>> Was thinking more like COSE:
>> 
>> decfrac = [
>>              e10: int,
>>              m: integer
>>           ]
>> 
>> decfrac_tagged = #6.4(decfrac)
> 
> That kind of style was written when we didn’t have the unwrap operator.
> 
> RFC 8610 says:
> 
>                  decfrac = #6.4([e10: int, m: integer])
> 
> Which is exactly what is called “decfrac_tagged” in the above.
> If you don’t want the tag, just write ~decfrac, and you have what you called decfrac in your example.
> 
> (And the fact that the unwrap convention works universally obviates the need to come up with noisy conventions such as _tagged.)
> 
>> That way you can say exactly which you want in CDDL without constructing the CDDL for the non-tagged form. Will also help make it clear that  protocol designers need to be clear and pick one.
>> 
>> Maybe even ask that every new registered data type have CDDL like this published suitable for normative reference as a requirement for getting into the IANA registry?
> 
> Requiring this would create too much coupling.
> Suggesting this is a good job for the DE :-)
> 
> (“suitable for normative reference” is a different issue, though.)
> 
> Grüße, Carsten
> 
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor