Re: [Cbor] 🔔 WG adoption call on draft-richardson-cbor-file-magic
Michael Richardson <mcr+ietf@sandelman.ca> Thu, 18 February 2021 17:11 UTC
Return-Path: <mcr+ietf@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 0D4093A149F for <cbor@ietfa.amsl.com>; Thu, 18 Feb 2021 09:11:58 -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 xxxxH4N1msIq for <cbor@ietfa.amsl.com>; Thu, 18 Feb 2021 09:11:55 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFE7A3A1486 for <cbor@ietf.org>; Thu, 18 Feb 2021 09:11:55 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id D9EF93899D; Thu, 18 Feb 2021 12:15:42 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Y6gBLnpNM-c3; Thu, 18 Feb 2021 12:15:42 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4A5E23899A; Thu, 18 Feb 2021 12:15:42 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 72D9812F; Thu, 18 Feb 2021 12:11:53 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Alexander Pelov <a@ackl.io>, cbor@ietf.org
In-Reply-To: <CACQW0Ep6DdtBwvRiDMELKgNwUoSG98e4Bky8bQaLgWdhmfqDxA@mail.gmail.com>
References: <YCwajOdK//yoqe20@hephaistos.amsuess.com> <F4EA7DDD-93BB-4629-81EB-AEAC6E4B6183@island-resort.com> <CAN40gSu5D4QhJgzNpbjEr=Dq2Wp__3tAESCLUHGiJoQWLWa5MQ@mail.gmail.com> <CACQW0Ep6DdtBwvRiDMELKgNwUoSG98e4Bky8bQaLgWdhmfqDxA@mail.gmail.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Thu, 18 Feb 2021 12:11:53 -0500
Message-ID: <9811.1613668313@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/O3K5mMxn5t-rjk-tgmK3btcO-o4>
Subject: Re: [Cbor] 🔔 WG adoption call on draft-richardson-cbor-file-magic
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: Thu, 18 Feb 2021 17:12:02 -0000
Alexander Pelov <a@ackl.io> wrote: > On a second note, the document is mentioning "protocol" and "file > encoding" somewhat interchangeably. Maybe I'm missing something here. Generally, a CBOR Protocol, or CBOR-based Protocol is a way to do something using CBOR. The thing using the CBOR (e.g. COSE, or a RATS EAT), is the Protocol, and that document needs to explain things. The thing that is sent over the wire, the Protocol, need not include the entire file encoding. (X509 PEM files are seldom sent over the wire in their base64 form; TLS and SIME sends the DER, for instance) That's why the discussion was about CBOR Sequence vs using a Tag to wrap the item. It seems to me, that a 12-byte CBOR Sequence preceeding the item is really easy to remove. > Also, I suppose that is obvious, but just to make it clear, it would be > good to put a clarification that this is not a mandatory way of storing > CBOR. That's why the intended status is BCP, not standards track. -- Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
- [Cbor] 🔔 WG adoption call on draft-richardson-cbo… Christian Amsüss
- [Cbor] Why 0x42_4F_52 (was Re: 🔔 WG adoption call… Laurence Lundblade
- Re: [Cbor] 🔔 WG adoption call on draft-richardson… Laurence Lundblade
- Re: [Cbor] 🔔 WG adoption call on draft-richardson… Ira McDonald
- Re: [Cbor] 🔔 WG adoption call on draft-richardson… Alexander Pelov
- Re: [Cbor] 🔔 WG adoption call on draft-richardson… Marco Tiloca
- Re: [Cbor] 🔔 WG adoption call on draft-richardson… Michael Richardson
- Re: [Cbor] Why 0x42_4F_52 (was Re: 🔔 WG adoption … Michael Richardson
- Re: [Cbor] Why 0x42_4F_52 (was Re: 🔔 WG adoption … Laurence Lundblade
- Re: [Cbor] Why 0x42_4F_52 (was Re: 🔔 WG adoption … Michael Richardson
- Re: [Cbor] 🔔 WG adoption call on draft-richardson… Christian Amsüss