Re: [Cbor] I-D Action: draft-ietf-cbor-file-magic-06.txt

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 10 November 2021 22:44 UTC

Return-Path: <mcr@sandelman.ca>
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 330753A1443 for <cbor@ietfa.amsl.com>; Wed, 10 Nov 2021 14:44:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 L5D8bHUBXnPi for <cbor@ietfa.amsl.com>; Wed, 10 Nov 2021 14:44:29 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00:e000:2bb::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34C743A11F7 for <cbor@ietf.org>; Wed, 10 Nov 2021 14:44:28 -0800 (PST)
Received: from dooku.sandelman.ca (desktop4.sandelman.ca [209.87.249.16]) by relay.sandelman.ca (Postfix) with ESMTPS id 470471F47B for <cbor@ietf.org>; Wed, 10 Nov 2021 22:44:25 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 264F41A0548; Wed, 10 Nov 2021 17:44:23 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: cbor@ietf.org
In-reply-to: <YYKYIzFFIGWVqNK8@hephaistos.amsuess.com>
References: <163484662604.2786.6905890868276647458@ietfa.amsl.com> <YYKYIzFFIGWVqNK8@hephaistos.amsuess.com>
Comments: In-reply-to Christian =?us-ascii?Q?=3D=3Fiso-8859-1=3FQ=3FAms=3D?= =?us-ascii?Q?FCss=3F=3D?= <christian@amsuess.com> message dated "Wed, 03 Nov 2021 15:09:39 +0100."
X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3
X-Attribution: mcr
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Wed, 10 Nov 2021 17:44:23 -0500
Message-ID: <403793.1636584263@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/Vdfa-dp2Q-cpW5srVW4d4zQwtMY>
Subject: Re: [Cbor] I-D Action: draft-ietf-cbor-file-magic-06.txt
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
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, 10 Nov 2021 22:44:34 -0000

I really didn't have the focus last week to understand your observation.

Christian Amsüss <christian@amsuess.com> wrote:
    >> A diff from the previous version is available at:
    >> https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-file-magic-06

    > The example has now become inconsistent, mixing the CBOR Tag Wrapped
    > and CBOR Tags for Content Formats parts:



    >> to translate the Content-Format number registered for
    >> application/senml+cbor, the number 112, into the tag 1668546560+112 =
    >> 1668546672.
    >>
    >> 55799(1668546672([{0: "current", 6: 3, 2: 1.5}]))

    > puts CBOR data into the content-format generated item, whereas Appendix
    > A says:

    >> The tag content tagged with tag number [...] is a byte string that is
    >> to be interpreted as a representation of the content format
    >> NNNNNNNN-1668546560.

    > which would look like 55799(1668546672(h'a30067...')).

    > My understanding so far was that with the current appendix, all data
    > would be bstr-valued, and if a) the content format is CBOR based, and
    > b) the transport coding is "identity", and c) the representation is
    > actually well-formed in the advertised content format, only then will
    > the byte string (happen to) be valid CBOR, but still encoded in a byte
    > string.

I finally understand the problem you are describing (ENOCOFFEE!)
Some CoAP Content Formats are CBOR, but not all of them are.
For an abitrary Content Format, we can't run the proceedure.
But, the example in section 2.2.1 does exactly this.

However, all of the CoAP payloads are valid bstr, so the example says to do
that for the two things that it has shown.

When Carsten suggested the Content-Format -> Tag, I didn't htink that some
content format isn't CBOR.
(Sacrilege! How dare CoAP be profaned with non-CBOR content!)^K

It seems that we need to choose:

a) them all to be bstr'ed
b) for only those that happen to be CBOR to be acceptable
c) some combination of the above, as appropriate.

I think that having them all bstr'ed for storage on disk is not particularly
useful to existing programs.  We can carry PKIX certificates in CoAP
(draft-ietf-anima-constrained-voucher and draft-ietf-ace-est-coaps), but
I wouldn't want to store that on disk bstr'ed.

So I would go for (b), and we should fix the Appendix.
Carsten messaged me that he had some slides in the works for Thursday.

--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-