[Cbor] Re: đź”” WGLC on draft-ietf-cbor-cde-08

Carsten Bormann <cabo@tzi.org> Tue, 18 March 2025 17:47 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: cbor@mail2.ietf.org
Delivered-To: cbor@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 86EF4E0F476; Tue, 18 Mar 2025 10:47:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.189
X-Spam-Level:
X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIv2FRUg1vbK; Tue, 18 Mar 2025 10:47:22 -0700 (PDT)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 67E14E0F471; Tue, 18 Mar 2025 10:47:22 -0700 (PDT)
Received: from [192.168.217.145] (p548dc3ec.dip0.t-ipconnect.de [84.141.195.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4ZHK6c0F4bzDCfY; Tue, 18 Mar 2025 18:47:20 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <17058d6a-a7bb-477c-ad46-3069bf776f16@gmail.com>
Date: Tue, 18 Mar 2025 18:47:19 +0100
X-Mao-Original-Outgoing-Id: 764012839.392814-d5428eac449372681343d68f4536795e
Content-Transfer-Encoding: quoted-printable
Message-Id: <3481F8E6-B230-4587-A914-818404C2912C@tzi.org>
References: <Z8oi3HMTum5eriSw@hephaistos.amsuess.com> <17058d6a-a7bb-477c-ad46-3069bf776f16@gmail.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Message-ID-Hash: OSJ2JPFBF3V5GVQ2TTPPMHEJRKS2AQV5
X-Message-ID-Hash: OSJ2JPFBF3V5GVQ2TTPPMHEJRKS2AQV5
X-MailFrom: cabo@tzi.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-cbor.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: CBOR <cbor@ietf.org>, draft-ietf-cbor-cde@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Cbor] Re: đź”” WGLC on draft-ietf-cbor-cde-08
List-Id: "Concise Binary Object Representation (CBOR)" <cbor.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/1ELhw9HmWpWQv5XUN1l55i1-HKY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Owner: <mailto:cbor-owner@ietf.org>
List-Post: <mailto:cbor@ietf.org>
List-Subscribe: <mailto:cbor-join@ietf.org>
List-Unsubscribe: <mailto:cbor-leave@ietf.org>

On 2025-03-18, at 18:03, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
> 
> In RFC 8949 4.2.2 Rule 2 is a "friendly advice".  I.e. non-normative.

That numbered list is preceded by:

      Example rules for this are:

Please read.

The thing we didn’t have when we wrote this is a strong terminology distinguishing deterministic encoding from deterministic representation.  That led to the phrase "protocol's deterministic encoding” in the sentence leading up to this (what these are examples for), which in today’s terminology would be “application protocol’s ALDR rules”.

What you didn’t quote was the text in 4.2.1:

      Floating-point values also MUST use the shortest form that
      preserves the value, e.g., 1.5 is encoded as 0xf93e00 (binary16)
      and 1000000.5 as 0xfa49742408 (binary32)

> In draft-ietf-cbor-cde-08 the same text is "stronger" but still non-normative.  No SHOULD or MUST in sight.

Not needed, see above.

> That is, CDE effectively MUST be accompanied by a derived document in order to provide a normative deterministically encoding standard.

No.

> Since dCBOR is the only derived CDE document, dCBOR effectively becomes the norm.

No, not at all.

> Not that I actually care about CDE, but this situation appears pretty absurd seen from my watchtower.

It sure is absurd to come to this misinterpretation.

GrĂĽĂźe, Carsten