Re: [Cbor] Genart last call review of draft-ietf-cbor-file-magic-11

Carsten Bormann <cabo@tzi.org> Wed, 20 April 2022 16:13 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 8605A3A1181; Wed, 20 Apr 2022 09:13:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfIiz6pow8ej; Wed, 20 Apr 2022 09:13:15 -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 558FB3A1171; Wed, 20 Apr 2022 09:13:09 -0700 (PDT)
Received: from [192.168.217.118] (p5089ad4f.dip0.t-ipconnect.de [80.137.173.79]) (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 4Kk5LV2sf0zDCbv; Wed, 20 Apr 2022 18:13:06 +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: <165005936672.2625.12393739876567977480@ietfa.amsl.com>
Date: Wed, 20 Apr 2022 18:13:06 +0200
Cc: gen-art@ietf.org, cbor@ietf.org, draft-ietf-cbor-file-magic.all@ietf.org, last-call@ietf.org
X-Mao-Original-Outgoing-Id: 672163986.2036231-d843ff7237b9f8cd82a700a3b38be58c
Content-Transfer-Encoding: quoted-printable
Message-Id: <8FD4D045-6EDE-4BE1-B2E9-905FF08B7A18@tzi.org>
References: <165005936672.2625.12393739876567977480@ietfa.amsl.com>
To: Pete Resnick <resnick@episteme.net>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/0GLYj5Bmh7X6fbDtXyWOGgicGck>
Subject: Re: [Cbor] Genart last call review of draft-ietf-cbor-file-magic-11
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, 20 Apr 2022 16:13:19 -0000

Hi Pete,

thank you for this review.

I have collected my proposed changes based on these and other comments in 

https://github.com/cbor-wg/cbor-magic-number/pull/21

under the commit
https://github.com/cbor-wg/cbor-magic-number/pull/21/commits/e476afb


> Nits/editorial comments:
> 
> Section 1 could use a solid edit. Here are some editorial issues that stuck out
> to me (as always, just suggested changes):
> 
> Paragraph 3 (this one is a content problem rather than strictly nits, but also
> isn't a technical issue with the document):
> 
> OLD
> 
>                                 For instance, in classical MacOS, a
>   resource fork was maintained that includes media type ("MIME type")
>   information and therefore ideally never needs to know anything about
>   the file.
> 
> NEW
> 
>                                 For instance, in classical MacOS, a
>   resource fork was maintained separately from the file data that
>   included file type information and therefore the OS ideally never
>   needed to know anything about the file data contents to determine the
>   media type.

Thanks!  (Slightly modified.)

> No "But" is required at the beginning of paragraph 4.
> 
> Paragraph 5: Change "file" to "file contents". (For what it's worth, I disagree
> with the paragraph, in that I think it's actually worse to keep the media type
> information in the data portion of the file, but I don't have a problem with
> you disagreeing with that in the introduction.)
> 
> Paragraph 8: Change the colon to a semicolon.
> 
> Paragraph 9: Replace "A third" with "An additional".
> 
> Swap paragraphs 9 & 10.
> 
> Paragraphs 13 & 14 seem confusing, if not contradictory.

I have merged them and removed the seeming contradiction.
> 
> Move paragraph 14 up after paragraph 8.
> 
> The last paragraph repeats the information in the 9th paragraph.

Actually, not really, as the last paragraph is about identified content-formats only.
I have merged the paragraph with 10 (was 9).

> Section 2.1, last paragraph: Change "has already been allocated" to "is
> described".

I’m not sure the registry “describes” anything; I have changed this to “has pro-actively been allocated”.

> Appendix C, last paragraph before C.1: This is a repeat of the last paragraph
> of section 2.3. I don't think it's necessary to repeat.

I think it is worth saying that this is the same as with Labeled CBOR Sequence, so I just shortened the text a bit.

Grüße, Carsten