[Cbor] ref'' and standins (draft-bormann-cbor-e-ref, draft-bormann-cbor-yang-standin)

Christian Amsüss <christian@amsuess.com> Wed, 06 March 2024 16:37 UTC

Return-Path: <christian@amsuess.com>
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 8C2A7C14F5FD for <cbor@ietfa.amsl.com>; Wed, 6 Mar 2024 08:37:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 UO1cJWOWxAew for <cbor@ietfa.amsl.com>; Wed, 6 Mar 2024 08:37:12 -0800 (PST)
Received: from smtp.akis.at (smtp.akis.at [IPv6:2a02:b18:500:a515::f455]) (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 D2F3BC14F5F6 for <cbor@ietf.org>; Wed, 6 Mar 2024 08:37:09 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com ([IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by smtp.akis.at (8.17.1/8.17.1) with ESMTPS id 426Gb5mI018837 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 6 Mar 2024 17:37:05 +0100 (CET) (envelope-from christian@amsuess.com)
X-Authentication-Warning: smtp.akis.at: Host [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd] claimed to be poseidon-mailhub.amsuess.com
Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id D96CC34DDA; Wed, 6 Mar 2024 17:37:03 +0100 (CET)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:c5d5:80a7:cc71:c616]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 92FF431AA3; Wed, 6 Mar 2024 17:37:03 +0100 (CET)
Received: (nullmailer pid 7506 invoked by uid 1000); Wed, 06 Mar 2024 16:37:03 -0000
Date: Wed, 06 Mar 2024 17:37:03 +0100
From: Christian Amsüss <christian@amsuess.com>
To: cabo@tzi.org, cbor@ietf.org
Message-ID: <Zeibr_uvEqKkSLSX@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="LGA9qdqRNYfk9d50"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/PWoT5TCtn9MyS_B2X31SBBo11lc>
Subject: [Cbor] ref'' and standins (draft-bormann-cbor-e-ref, draft-bormann-cbor-yang-standin)
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, 06 Mar 2024 16:37:14 -0000

Hello Carsten, group,

looking at both e-ref and standins in close succession, I think there is
a commonality that can be exploited.

Currently, ref'' is limited to use within EDN (except when expressed as
`CPA999(["ref", "filename.diag")`), and pulls a value from a file.
Stand-in tags are CBOR tags that suply infromation in an equivalent but
more efficient format (which is also what ref does, even though none of
the tags defined in standin currently considers context in its
conversion).

The common pattern is that there is a CBOR item (or pseudoitem, in the
ref'' case) that really means what is referenced in its description.

Other occurrences where we have similar mechanisms are bare hash
values from notable-tags (which are not explicit about standing in for
the hash's content, but AIU worked that way in their original use case),
and packed-by-reference, which produces something similar using
`TBD1114(1, "http://example.com/path", simple(0))` (although the
identifier does not describe a CBOR item here, but 1-long item list
whose only item is the desired item).

Could this be generalized in the yang-standin document, or (if it
exceeds its scope) in a generalized stand-in concept? Then, ref'' could
be redefined to merely be a short-hand for some tag around the given URI
reference, and serve as a hint to the reader that this kind of stand-in
is better resolved before processing the document.

Best regards
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom