From nobody Tue Apr 6 14:02:22 2021 Return-Path: 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 EE9543A30BB for ; Tue, 6 Apr 2021 14:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 p_TMXzlMO7iS for ; Tue, 6 Apr 2021 14:02:16 -0700 (PDT) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 730B13A30B9 for ; Tue, 6 Apr 2021 14:02:16 -0700 (PDT) Received: by mail-pj1-x1029.google.com with SMTP id ot17-20020a17090b3b51b0290109c9ac3c34so75997pjb.4 for ; Tue, 06 Apr 2021 14:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=esUDwr7M5RMxtZlIyh+bNfUDkQTLbGt4SrMTwNTZrdg=; b=koDFGqtoYeDWMtVBrksvON69Gn/kHNdRuMWVkjKFCO+t6K+eWaKO8OQUDHzvDVJtzK e30PpI+ebcQk5F6uSTuZJHREAULpxBFVwII7Mtply1qrsjfc/zfLrxrARopyrn3JY0qz tZvu3dzcPttAIt94GWxeitFeGKRgfde+BYtcMpLgbS+3BDczv6B2voOZRA1qhzYGpdw5 JLV/77y0+R9VATiwwYTb5FUa+m1p2P7ZN9mpjmo9TdyxtP2/3ArxB/uVwadlONcxHtXp T94DeGMEfm1HYlsDvfz07p7PNVOHsk+/zU6SurAtNUDBUQoh3Cd+YFuHefD56mMLvXH+ s0CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=esUDwr7M5RMxtZlIyh+bNfUDkQTLbGt4SrMTwNTZrdg=; b=n/50MYgChPy5gqcIZSwuWMW4jHGCcDh7U/A5kgyZlPwGjYf/TndXPg6yvKEdqaUkU6 95O4JUSOlWU7Fx3BkSIJ+qKgW/dM7iJDJjL3M2wI7DVltLuwYcmUQXFXK/W0b/oMSFhn Rf6npoIx0lq9gtLl+zJRJGrS0GQEKiV0xhdz301XMTH9YKKr4UVWVnGqK/CYHO+lWbSA aT3KHtCGv761148u6P2zAEl88xgvvpeSamMf/bd2/6Ag9fiAUVxgr89pATDJzenJA7Ss akiyrLW34x1bY7a7YKoYfolVtSgopi9MFm6Y1Q4DvV0cWqscBLYB0W22hLEEhjCqEebZ ozBQ== X-Gm-Message-State: AOAM531bvPA1qPdXv54wBjhF3BzYmB3SxQGvj0PJ6um5MmK3nav+1caQ Yo2cbIkSKCzxsBJG0PweDHXcnWhpAS+GSP3/rLFdtItCkq2ugA== X-Google-Smtp-Source: ABdhPJxdBdKgTA/bJ9BOs/h1Piegz9e+R4vZFs2TdnfgNwqz89o9hHvUjzx+baBVjGghpPnSAxO5cr2JXPvTXWtetnY= X-Received: by 2002:a17:902:263:b029:e7:35d8:4554 with SMTP id 90-20020a1709020263b02900e735d84554mr106670plc.83.1617742935313; Tue, 06 Apr 2021 14:02:15 -0700 (PDT) MIME-Version: 1.0 References: <161ED597-9822-41BC-9B1B-311DBBD26BE6@mothers-arms.co.uk> In-Reply-To: <161ED597-9822-41BC-9B1B-311DBBD26BE6@mothers-arms.co.uk> From: Emile Cormier Date: Tue, 6 Apr 2021 18:02:04 -0300 Message-ID: To: Kio Smallwood Cc: cbor@ietf.org Content-Type: multipart/alternative; boundary="000000000000ff51fe05bf5420d2" Archived-At: Subject: Re: [Cbor] Consolidated set of tags for containers X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2021 21:02:21 -0000 --000000000000ff51fe05bf5420d2 Content-Type: text/plain; charset="UTF-8" On Tue, Apr 6, 2021 at 2:19 PM Kio Smallwood wrote: > I'm quite happy with this. Especially the use of abstract data types. > > I would like to add that Sets already have a tag of 258 > Thanks! I've added a reference to tag 258 to my draft. https://github.com/ecorm/cbor-map-like/blob/with-lists/README.md Would it be worth considering how to handle multiple tags that fulfil the > same role e.g. tag 258 and 144? > I'd say that a decoder should treat them as being synonymous. One thing that should be considered is removing the tags for uniform keys and arbitrary values. That would reduce the number of allotted tags from 24 to 20 (in my "with-lists" variant, that is). However, the logic for decoding each trait would become more complex, as it would no longer be "one-hot" bit encoding (in EE parlance). A small lookup table could take care of associating traits with tag values. Such a table would only be 20 bytes if traits are packed into bits. Cheers, Emile Cormier --000000000000ff51fe05bf5420d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Apr 6, 2021 at 2:19 PM Kio Smallwood <kio@mothers-arms.co.uk> wrote:
I'm quite happy with = this. Especially the use of abstract data types.

I would like to ad= d that Sets already have a tag of 258

=
Thanks! I've added a reference to tag 258 to my draft. https://g= ithub.com/ecorm/cbor-map-like/blob/with-lists/README.md

=
Would it be wo= rth considering how to handle multiple tags that fulfil the same role e.g. = tag 258 and 144?

I'd say that= a decoder should treat them as being synonymous.

= One thing that should be considered is removing the tags for uniform keys a= nd arbitrary values. That would reduce the number of allotted tags from 24 = to 20 (in my "with-lists" variant, that is). However, the logic f= or decoding each trait would become more complex, as it would no longer be = "one-hot" bit encoding (in EE parlance). A small lookup table cou= ld take care of associating traits with tag values. Such a table would only= be 20 bytes if traits are packed into bits.

C= heers,
Emile Cormier
--000000000000ff51fe05bf5420d2--