[Cbor] Invariants (Re: packed review (was: Re: Reminder and call for agenda: CBOR WG Virtual Meeting on 2022-06-01))

Carsten Bormann <cabo@tzi.org> Wed, 29 June 2022 14:00 UTC

Return-Path: <cabo@tzi.org>
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 16B36C157B4D for <cbor@ietfa.amsl.com>; Wed, 29 Jun 2022 07:00:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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
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 hqc1nBxNEqA3 for <cbor@ietfa.amsl.com>; Wed, 29 Jun 2022 07:00:16 -0700 (PDT)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94769C14F612 for <cbor@ietf.org>; Wed, 29 Jun 2022 06:59:58 -0700 (PDT)
Received: from [192.168.217.118] (p5089ad4f.dip0.t-ipconnect.de [80.137.173.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4LY34X4T8xzDClK; Wed, 29 Jun 2022 15:59:56 +0200 (CEST)
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: <YrwFarI3RecBziqP@hephaistos.amsuess.com>
Date: Wed, 29 Jun 2022 15:59:56 +0200
Cc: cbor@ietf.org
X-Mao-Original-Outgoing-Id: 678203996.219952-a3523dbe9359fed2a83e427faab2b370
Content-Transfer-Encoding: quoted-printable
Message-Id: <77712BCC-A209-469B-BC62-38CE7C546BDB@tzi.org>
References: <CALaySJLPtUjdfVss17noK=18RyczpcCGNu=im8CBpiQz=WiLWA@mail.gmail.com> <CALaySJKUNh-AkJa87sCDpzf9OHV8H367VQyzyozXCCXxphUARw@mail.gmail.com> <CALaySJ+P2sP7BU7bNSxRJBByyp04rzVZuukq_e+9wbb5WPRSFQ@mail.gmail.com> <CALaySJKxht1gd1+3mNiAH-kLUAxjdPPk3doK50C_xS74LG+YTQ@mail.gmail.com> <CALaySJJjSHT2q_wpZQ9QFhLSxGuhffWwb=9P1XDUFTsheOvPZA@mail.gmail.com> <5A9B396E-1D9F-455C-949F-9B4C89AA510C@tzi.org> <CALaySJ+Sp=hmc4-kp1UrYPf0BxMtQy4aS+LiCfkREYqmip1Q6w@mail.gmail.com> <B9E21E1E-164D-4306-88D7-A88DC76080A9@tzi.org> <YrmJV7OwrbOI/zKe@hephaistos.amsuess.com> <861D3104-8C33-4819-9488-1885F94C973F@tzi.org> <YrwFarI3RecBziqP@hephaistos.amsuess.com>
To: Christian Amsüss <christian@amsuess.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/a1PMAbqHnq7O-uDJC7SA5kztM0o>
Subject: [Cbor] Invariants (Re: packed review (was: Re: Reminder and call for agenda: CBOR WG Virtual Meeting on 2022-06-01))
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.39
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, 29 Jun 2022 14:00:21 -0000

I think we are discussing an extension point for cbor-packed, the function tag.

Any proposal for this extension point will need to define what is invariant over the time this extension point is exercised more and more.

What seems very important for me is that new function tags can be defined in such a way that an unpacker can find out whether something is being used as a function tag or not.

The current proposal does this by giving the function tag role exactly to the dominating side of the packed reference tag (type-0: argument, type-1: reference tag content = rump).

This is a bit hard to visualize sometimes because there are always two tags: The (non-extensible) reference tag, and the function tag pointed to by the reference tag.  By making reference tags non-extensible, we make sure that all implementations know when these are active.

This approach does not allow to freely evaluate tags occurring anywhere.
That is hard to make extensible in such a way that false interoperability can be detected.
It also probably requires a more complex processing model.

http://notes.ietf.org/notes-cbor-not-interim-2022-06-29

Grüße, Carsten