[Cbor] Re: New Version Notification for draft-amsuess-cbor-packed-shuffle-00.txt

Mikolai Gütschow <mikolai.guetschow@tu-dresden.de> Mon, 29 July 2024 13:58 UTC

Return-Path: <mikolai.guetschow@tu-dresden.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 2F2CDC1CAE72 for <cbor@ietfa.amsl.com>; Mon, 29 Jul 2024 06:58:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tu-dresden.de
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZk4g8KGANMP for <cbor@ietfa.amsl.com>; Mon, 29 Jul 2024 06:58:38 -0700 (PDT)
Received: from mailout3.zih.tu-dresden.de (mailout3.zih.tu-dresden.de [141.30.67.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E74C7C16943B for <cbor@ietf.org>; Mon, 29 Jul 2024 06:58:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tu-dresden.de; s=dkim2022; h=Content-Type:In-Reply-To:From:References:To: Subject:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=IedydpHWQe1rr/9O2gqlXZXPs4kSeCTUnQqO+kQ/xkU=; b=xNYX/p9dXIEJ2ACnggmgSsQFRU g5zIbgnUZvpExraVsNZ+0AtnWoT6D5a3jbTfd/VyrV9dZnAs2bpYlVXDAQUmmA+39DYFl5gYp4ERV DVfAosv9IlS3l1ymUROf2Wnx35xuJZh70s5vczEqP4MRam5pPwSg/b9h3JqNptODKtcg8pDS3fhzJ tzV2cxcMgPD+jzP81bBr59KmaPTVj7hkQ6BzP341v4lZBXAiTfUknDb+3Y2dakVvyKXysGX0OITpS mPa3MvQhX2pYrpxko/G+Va7+DAfBWCE5mT6Ay+rEp3KOx/JYPXAh566MwJOu+4txnLAhqqx2fdGD3 bCgdS+eg==;
Received: from [172.26.35.116] (helo=msx.tu-dresden.de) by mailout3.zih.tu-dresden.de with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <mikolai.guetschow@tu-dresden.de>) id 1sYQtH-00Bosm-8D for cbor@ietf.org; Mon, 29 Jul 2024 15:58:19 +0200
Received: from [141.76.40.222] (141.76.40.222) by MSX-T316.msx.ad.zih.tu-dresden.de (172.26.35.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Mon, 29 Jul 2024 15:58:14 +0200
Message-ID: <47bcaa3f-4634-42a1-8b58-6c61c3d5f303@tu-dresden.de>
Date: Mon, 29 Jul 2024 15:58:13 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: cbor@ietf.org
References: <172225254112.1670668.426150452467911958@dt-datatracker-659f84ff76-9wqgv> <ZqeAfDBdaUP4P0s_@hephaistos.amsuess.com>
Content-Language: en-US, de-DE
From: Mikolai Gütschow <mikolai.guetschow@tu-dresden.de>
In-Reply-To: <ZqeAfDBdaUP4P0s_@hephaistos.amsuess.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms040503080207010309020204"
X-ClientProxiedBy: msx-l319.msx.ad.zih.tu-dresden.de (172.26.34.119) To MSX-T316.msx.ad.zih.tu-dresden.de (172.26.35.116)
X-TUD-Virus-Scanned: mailout3.zih.tu-dresden.de
Message-ID-Hash: FPJFSN7Q2QBQ5PONUA3TUQP3PDBRL2KP
X-Message-ID-Hash: FPJFSN7Q2QBQ5PONUA3TUQP3PDBRL2KP
X-MailFrom: mikolai.guetschow@tu-dresden.de
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
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Cbor] Re: New Version Notification for draft-amsuess-cbor-packed-shuffle-00.txt
List-Id: "Concise Binary Object Representation (CBOR)" <cbor.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/fNfLm7h7Y9NdJF2cE7QuizNebjg>
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>

Hi Christian,

thanks for sharing the draft, looks interesting!

Two thoughts that came up while I was reading through it:

(1) CPA115 for 's' (shuffle), nice one.

(2) For packed CBOR, we propose tag CPA113 and CPA1113 for combined or 
split shared item and argument item table. In your draft, you expect the 
argument list as an _optional_ second item:

---
Packed-Shuffle = #6.<cpa115>([
        shuffle-shared,
        ?shuffle-argument,
        rump])
---

That makes me wonder if packed CBOR should do the same only with CPA113. 
On the pro side, the table setup would save one byte, while consuming 
the CBOR stream would require going over the second list item once to 
find out if there is a third one in case the outer array uses indefinite 
length encoding (which it really shouldn't do, but which is currently 
not restricted AFAIK. I'm also not sure if it is actually possible in 
the data model of CBOR to distinguish between those two types of arrays)

Should we be consistent here and in draft-cbor-packed?

Best
Mikolai



On 7/29/24 13:43, Christian Amsüss wrote:
> Hi CBOR group,
> 
> On Mon, Jul 29, 2024 at 04:29:01AM -0700, internet-drafts@ietf.org wrote:
>> Name:     draft-amsuess-cbor-packed-shuffle
>> Revision: 00
>> Title:    Packed CBOR: Table permutations
>> Status:   https://datatracker.ietf.org/doc/draft-amsuess-cbor-packed-shuffle/
>>
>> Abstract:
>>
>>     Packed CBOR is a compression mechanism for Concise Binary Object
>>     Representation (CBOR) that can be used without a decompression step.
>>     This document introduces a means for altering configured tables to
>>     optimize the use of efficient encoding points by shuffling around
>>     entries in the packing tables.
> 
> This happened while playing around with imported table setups.
> 
> It is probably too early for general discussion, but if you're exploring
> which table setup mechanisms would work best when, it may be an option
> worth considering.
> 
> Best regards
> Christian
> 
> 
> _______________________________________________
> CBOR mailing list -- cbor@ietf.org
> To unsubscribe send an email to cbor-leave@ietf.org

-- 
Mikolai Gütschow
TU Dresden, Chair of Distributed and Networked Systems
https://tu-dresden.de/cs/netd/about/team/guetschow