Re: [Cbor] [art] Artart early review of draft-ietf-cbor-file-magic-02

worley@ariadne.com Thu, 26 August 2021 03:11 UTC

Return-Path: <worley@ariadne.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 699333A10F5 for <cbor@ietfa.amsl.com>; Wed, 25 Aug 2021 20:11:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=comcastmailservice.net
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 OoAbjIklQNdg for <cbor@ietfa.amsl.com>; Wed, 25 Aug 2021 20:11:45 -0700 (PDT)
Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36CF63A10EE for <cbor@ietf.org>; Wed, 25 Aug 2021 20:11:44 -0700 (PDT)
Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-05v.sys.comcast.net with ESMTP id J5ilmiik7K3eXJ5nqmBoEX; Thu, 26 Aug 2021 03:11:42 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1629947502; bh=gj1gjgKeN5pSyLPavarGCwSNqkCCd6EKSKXGVgw1erk=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=YRcGoGO8LvxuKcyCz97+kzIO3M7ep4fM6DdI8O6Vnfa2PW0UbVGge9X2bn1xIkPLn e+rNDvwenAC8/ol4vb132OZXf3MeV6Q5Co/zjdrioXF4iG/ZJFVuBXauMNLdCVQnrV CeAu9SYqEUDvlCnZKqtE1IdGhGmalxsvhu+RMANtkWVF5DQH5w4reZLGHEDAQS2vPK QoXELcuPaFFvmf765zo+nkeUHrimLkxt37KlrEDeaCNkiuR5I9O2TvcvtHVM6+STHG A70p/2RUJgGoeGJbjafszTtjVjCnPHhYQEjKuMpSJr52DzNsZzn4/JlS3Vg7apz+4z lTT74xyXB6d1g==
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430::327]) by resomta-ch2-11v.sys.comcast.net with ESMTPA id J5nom00LlkJw7J5npmH8F7; Thu, 26 Aug 2021 03:11:42 +0000
X-Xfinity-VMeta: sc=-100.00;st=legit
Received: from hobgoblin.ariadne.com (localhost [127.0.0.1]) by hobgoblin.ariadne.com (8.16.1/8.16.1) with ESMTPS id 17Q3BemW009401 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 25 Aug 2021 23:11:40 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.16.1/8.16.1/Submit) id 17Q3BdSw009398; Wed, 25 Aug 2021 23:11:39 -0400
From: worley@ariadne.com (Dale R. Worley)
To: Bernard Aboba <bernard.aboba@gmail.com>
Cc: art@ietf.org, cbor@ietf.org, draft-ietf-cbor-file-magic.all@ietf.org
In-Reply-To: <162801879089.20863.15297297905691186349@ietfa.amsl.com> (noreply@ietf.org)
Sender: worley@ariadne.com (Dale R. Worley)
Date: Wed, 25 Aug 2021 23:11:39 -0400
Message-ID: <874kbcaoic.fsf@hobgoblin.ariadne.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/TcnUrs5ZoQ7tAnPTAlGC6Vhipr0>
Subject: Re: [Cbor] [art] Artart early review of draft-ietf-cbor-file-magic-02
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, 26 Aug 2021 03:11:51 -0000

There's an odd characteristic about this document, not in its content,
but in its style.  It's written as a proposal (a word which is used
several times), and yet it's intended to be a BCP, which tells people
what do to.  And various passages are written as if the reader is a
co-designer.  For instance,

   A magic number is ideally a unique fingerprint, present in the first
   4 or 8 bytes of the file, which does not change when the contents
   change, and does not depend upon the length of the file.

(Though it would be more accurate to say, "... present at a defined
location in the first few bytes of the file ...".)  If this was a
specification, it would say essentially the same fact as "This scheme
has the desired property of magic numbers of having a unique fingerprint
at a fixed location near the beginning of the data."

I get the sense that the authors are ambivalent whether they are saying
what implementers should do, or just floating an idea.  Though I don't
know if that is accurate.

As far as content goes, I favor the "tag wrapped" version over the "tag
sequence", as it has assured upward-compatibility (if the implementation
follows the requirement to ignore unknown tags).  In particular, if the
data consists of a sequence of CBOR items, each one could be tagged (if
they might differ) or only the first one be tagged (if they don't).  But
that's a different matter.

Dale