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

Anders Rundgren <anders.rundgren.net@gmail.com> Wed, 19 March 2025 04:41 UTC

Return-Path: <anders.rundgren.net@gmail.com>
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 4CE76E5B1D5; Tue, 18 Mar 2025 21:41:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 uKsZdOzAPqLL; Tue, 18 Mar 2025 21:40:59 -0700 (PDT)
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 887AFE5B1D0; Tue, 18 Mar 2025 21:40:59 -0700 (PDT)
Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-43cfecdd8b2so29970165e9.2; Tue, 18 Mar 2025 21:40:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742359258; x=1742964058; darn=ietf.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=RRHN9g2hAM2Sq8zHDTGZx1RSVWT4rUZg4WP5RHLyws8=; b=VHYE9V9vp8IqaIUSXQZSPXcmdeklXX5qr5E2b5VeVSgppX2YiFtnr4KWz/sTggWU6w i5nIHKEHkSMeS6HJ4Iv+u8Vl8q0LiIrMMbA7Xz4MLOD/Jd25DwP186PAuj2680vs+pBt aw+UQmyOH1leaq/IWgeRyfkeUgradV9WN0zQOs2HfSrh9ITpXA5BmUQT8dj++eV3UnsV 9rG2rubdQX3cGW8KQaH4gEFEZ+kbzbOIR/EClBG2fScbQnuNEG2/m4lsh7iB99Eu9FCc mLpiaEwH4XB95gvlDjbGMj4qGoVfroV9y7240XOdNdmev4SivIvD+p4yI4QD5JaOg3C9 KNzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742359258; x=1742964058; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=RRHN9g2hAM2Sq8zHDTGZx1RSVWT4rUZg4WP5RHLyws8=; b=S827CP6aPj32Jtq6OmjSN9jVNEhPQcvqurGF8eUZBCusVypD8ABid1g4Z5nvLGCuTn 9rpNt826cANrAs898tQqRQ+spiHKCnH7ARe0NipkLsMtdF7z2yj/3+uTwylKGoUk2PC4 BUuZn6l+xDmSlc7V3ADO3q6xweiVP5xQNwaLwlZt0b8x5MyXq2vqebiXy3eRNmIVcmVY 4Bq9cM52o7rxV+KIJr5opiu7xviycpI7SME6BTj4Lp4MqyOLuZG7AXPHUxL6nUSEQRQ3 07ZFOTe6xfGxGcP7gLYOHxX9j127oK0KKzLuXnP+yBqYGXg2U9GzqaWfvwOH66McB/NI NIXg==
X-Forwarded-Encrypted: i=1; AJvYcCXnfWqxZ9olZct8vvFb95e6+xPwgbJ1jq8B3nquGe8IAhH1HBKHmT54R6eemqAPDHv1fyGSwyhL3GZG0RGx2mWyvfdR@ietf.org
X-Gm-Message-State: AOJu0Yz4m2NEsrMiPIVTAuTO0RAlgIM8rVYRLCC+PmmQDeuuwqEvAEHp ITIM6BsOtlYo8DXdHsqGwhBfrgdbtOd/MbPiU5sD9nl1H64jCkWG
X-Gm-Gg: ASbGncvXlYaVSEmSaL/8gKGZZfjQGeCCvLtvHv4D13ybydDpp/Z8tGTQHcVNqqU4H6A 0Q0fp0EeNlhTS/84LWIsLy+FzHh0BVDwxz0OieGoWYTxjASASaz3/uDjAq2pD17CdPae4kfmDil cYPhEFcMXytqxdU9/r/0LyT7Dpev5jBir+DekV6+J9RidYrb7OPd+r3E1GWL/+Sst3XDgQjxVhm a+L20Z23Yw6+U8DGcKUYEO043JqWhT2Z2SNsxEb0/f7WCvFNOZ1BRiYNOQvomHg5pfMe/5nFtmd skaRu9rFoRSBwgdPDLPIxkbiD/9dp34hkNyB3rtrwj46TFRR+fXsdCfxg4DYxObRZEdJmNIJrHI bLKPuzStfZj8fH4iNfjb+2GhD1c7nTq3BH/VswJrI4Q==
X-Google-Smtp-Source: AGHT+IHxgjouHg4MHQhIl0J8PfQwgdJvpuO39B/OED99XpPntY3h+RN+xlB3y70d6+n3eB6npSP8BA==
X-Received: by 2002:a05:600c:4f86:b0:43c:f1cd:3d78 with SMTP id 5b1f17b1804b1-43d4379750cmr7078955e9.12.1742359258153; Tue, 18 Mar 2025 21:40:58 -0700 (PDT)
Received: from ?IPV6:2a01:e0a:e1b:64b0:9e4:818e:6b14:fb64? ([2a01:e0a:e1b:64b0:9e4:818e:6b14:fb64]) by smtp.googlemail.com with ESMTPSA id 5b1f17b1804b1-43d43f55750sm6947205e9.21.2025.03.18.21.40.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Mar 2025 21:40:57 -0700 (PDT)
Message-ID: <f9203c29-d650-45b0-bb3f-19c7c48a6bc0@gmail.com>
Date: Wed, 19 Mar 2025 05:40:56 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Carsten Bormann <cabo@tzi.org>
References: <Z8oi3HMTum5eriSw@hephaistos.amsuess.com> <17058d6a-a7bb-477c-ad46-3069bf776f16@gmail.com> <3481F8E6-B230-4587-A914-818404C2912C@tzi.org>
Content-Language: en-US
From: Anders Rundgren <anders.rundgren.net@gmail.com>
In-Reply-To: <3481F8E6-B230-4587-A914-818404C2912C@tzi.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Message-ID-Hash: 6KJPGJCROUUPZTOQJIRYX2X5LWHND6PV
X-Message-ID-Hash: 6KJPGJCROUUPZTOQJIRYX2X5LWHND6PV
X-MailFrom: anders.rundgren.net@gmail.com
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/YhwrEI_xD6KS5usynnoTycw1FAc>
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 18:47, Carsten Bormann wrote:
> 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.

Well, the line

"2. If floating-point numbers are emitted"

is a bit of a riddle.  I guess this is where deterministic encoding and representation MAY differ.

Anders

I'm confident that the intended audience ("market" as I say) for U-CBOR compatible tools, won't ever have to bother about such issues.  Through state-of-the-art, OO API concepts and encapsulation, this lot should be equally unaware of ALDR as well.  In its latest incarceration, even the media type question was reduced to zero, as is already the case for comparable systems using JSON, like Open API:
https://www.ietf.org/archive/id/draft-rundgren-universal-cbor-06.html#name-media-type

> 
> GrĂĽĂźe, Carsten
> 
>