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

Carsten Bormann <cabo@tzi.org> Thu, 26 August 2021 18: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 2FB1E3A1949; Thu, 26 Aug 2021 11:00:30 -0700 (PDT)
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 mTv2wQb1ZxVH; Thu, 26 Aug 2021 11:00:24 -0700 (PDT)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 583503A1943; Thu, 26 Aug 2021 11:00:23 -0700 (PDT)
Received: from [192.168.217.118] (p548dcf6e.dip0.t-ipconnect.de [84.141.207.110]) (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 4GwVxc2ttQz2xM5; Thu, 26 Aug 2021 20:00:20 +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: <874kbcaoic.fsf@hobgoblin.ariadne.com>
Date: Thu, 26 Aug 2021 20:00:20 +0200
Cc: Bernard Aboba <bernard.aboba@gmail.com>, art@ietf.org, draft-ietf-cbor-file-magic.all@ietf.org, cbor@ietf.org
X-Mao-Original-Outgoing-Id: 651693619.840584-fe364df5b66a61ad9e7c464ceb779871
Content-Transfer-Encoding: quoted-printable
Message-Id: <16A0ECBB-AB9D-455D-B5B6-83F21E37E731@tzi.org>
References: <874kbcaoic.fsf@hobgoblin.ariadne.com>
To: "Dale R. Worley" <worley@ariadne.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/9RpIOap1po-kqWiWKSt_x72lPyM>
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 18:00:31 -0000

On 2021-08-26, at 05:11, Dale R. Worley <worley@ariadne.com> wrote:
> 
> 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.  

I can see what you mean.

Typically, specs like this start as a trial balloon, keeping the design space wide open, and encouraging discussion.
Once this discussion happens, it focuses on the normative parts of the text, which then get all the attention.
Once those are consensus, nobody wants to disturb that by changing the introductory parts and the discussion parts.

> 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."

It seems a major editorial round is in order.

> 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.

No, we are quite interested in giving actionable guidelines; the “floating an idea” phase is over.  But the text may indeed not reflect that.

> 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.

If the data is a CBOR sequence, tagging any one of the items doesn’t tell you much about the others.  So for CBOR sequences, the 55800 approach is the one I’d recommend.  For single-item files, both approaches are open (tag-wrapping and turning the single item into a sequence by prepending a 55800 data item), and it depends on details of the circumstances which one one would select.

Grüße, Carsten