Re: [Cellar] AD review: draft-ietf-cellar-matroska

"Murray S. Kucherawy" <superuser@gmail.com> Mon, 26 December 2022 00:51 UTC

Return-Path: <superuser@gmail.com>
X-Original-To: cellar@ietfa.amsl.com
Delivered-To: cellar@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B53DEC14CEED for <cellar@ietfa.amsl.com>; Sun, 25 Dec 2022 16:51:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yf-eQs7j0mci for <cellar@ietfa.amsl.com>; Sun, 25 Dec 2022 16:51:32 -0800 (PST)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01FEEC14F74A for <cellar@ietf.org>; Sun, 25 Dec 2022 16:51:31 -0800 (PST)
Received: by mail-ed1-x52c.google.com with SMTP id c17so13977716edj.13 for <cellar@ietf.org>; Sun, 25 Dec 2022 16:51:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=v9u1LcI8mfeL89k9706F7PmqiHgW/07GjTs6Z5EtH8Y=; b=Ynyq2se2c1Cl6O4Hm9Igm0yrwnrRqpLqkTgmKRzbku9EdZg+d4Gfuy4kbrCDoqeBsE f6NRLyVWwuexzsekd7JsL286eWyD6a55VxGNhITGiWpvntYARsVBjU4/jok87VcL+ogL h5g5G3O5AWJQf6OFyUvdp2Xf50khQqFsNhSoDkYBvvdEo9V2QbjnnP8co7gi1qu9p9Z1 HnWiNaWZIzLWz9KT0FIm03q21Q2JPR+7vn0bF/L2e9lKky3c+dvvuWg5x+iRBID3oh03 PfXc1zf2ScVYx9OXGbKThW1tYmjAeF2yEyS6L+t37JGCEfeXAglcJZkR6NeQUNIiNoN3 IRdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=v9u1LcI8mfeL89k9706F7PmqiHgW/07GjTs6Z5EtH8Y=; b=E7W2YialAbFitMTNNlHJAYbeII4YdaUmzhjGAWcBiWMxmLHJFV1kL0aKqjq23eV8s/ pmBR4oO7tmBhrwymTAl7CBnPdv94zkfQAsY5d65WeKC613vz7lS3B+PmzEMdYu0nr4bg fKa7+EvgDJklULsXfnisrVYpo5R6vFOidvcBi1AlaaaeFhcKNS0T/V7RSGuYCQsox3/P FNfd7c+vM9B2PxV/7CZ5k6czrHyXYScJ2cNN62lcL0de76GqOYXxTC3cCKu0M12YD6uf jKaY++w6UDWCUCqNJe8bKQUa9sZFo4V9GqH4uFDFkqw+WRnGBfH5e8zK474Nw+mfz5d9 onew==
X-Gm-Message-State: AFqh2krOwZS5sxXnk3/QxI7ByW77DgVlnpSvk+pZfLdEKRgBn5q91Itc BKg9FdnUTonelAoJqRfAAqzeBxgxW6emlQUJ2khNunTAQu+jmQ==
X-Google-Smtp-Source: AMrXdXsij2CSlRfRKlGEaeEl8X2014Db4G1TIij5VVU6voIKfmGOLBxPi0sfIzReBk4EWEpdfW1Vmd164lH6LYoo9wE=
X-Received: by 2002:aa7:d04d:0:b0:46c:cff7:f80d with SMTP id n13-20020aa7d04d000000b0046ccff7f80dmr1867111edo.361.1672015888304; Sun, 25 Dec 2022 16:51:28 -0800 (PST)
MIME-Version: 1.0
References: <CAL0qLwaWoj105GWaF4rPCFYg=d5yQTG-H5vQF0MtWApd3Tt96A@mail.gmail.com>
In-Reply-To: <CAL0qLwaWoj105GWaF4rPCFYg=d5yQTG-H5vQF0MtWApd3Tt96A@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Sun, 25 Dec 2022 16:51:15 -0800
Message-ID: <CAL0qLwaCJn=8CEEmX1YSSJhjdrPzi2O7HkTN-dmMXh6+S4TAoQ@mail.gmail.com>
To: Codec Encoding for LossLess Archiving and Realtime transmission <cellar@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000014cf6305f0b089dc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/3rFzHwpdX5xB09ytrgyFrqk3uIc>
Subject: Re: [Cellar] AD review: draft-ietf-cellar-matroska
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Codec Encoding for LossLess Archiving and Realtime transmission <cellar.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cellar>, <mailto:cellar-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cellar/>
List-Post: <mailto:cellar@ietf.org>
List-Help: <mailto:cellar-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cellar>, <mailto:cellar-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Dec 2022 00:51:32 -0000

Sorry, I appear to have found a "Send" button before I was done.

One thing before I continue:  I know this is a lot of feedback, but this
document was quite well done.  I know less than I'd like to about this area
of material, and this was an interesting read and generally easy to
understand.  I don't think we're far from being able to send it on toward
publication.

Now, picking up where I left off:

On Sun, Dec 25, 2022 at 4:05 PM Murray S. Kucherawy <superuser@gmail.com>
wrote:

> [...]
>
> Section 5.1.4.1.7:
>
> OLD:
>

Set to 1 if that track is suitable for users with hearing impairments, set
to 0 if it is unsuitable for users with hearing impairments.

NEW:
>

Set to 1 if and only if that track is suitable for users with hearing
impairments.

Section 5.1.4.1.8 through 5.1.4.1.11:

* Same suggestion.

Section 5.1.4.1.13:

* I don't understand this use of SHOULD.

Sections 5.1.4.1.15, 5.1.4.1.16, 5.1.4.1.29:

* "ie" should be "i.e.,"

Section 5.1.4.1.31.1:

* "whether... or not" is redundant; you can drop the "or not"

Section 5.1.4.1.31.2:

* Some fields in this table seem to have run into the next row.

* Why list the value of 2 at all?  Why not leave it out like other
undefined values?

Section 5.1.4.1.31.5:

* The fact that this is an "old" and "bogus" value makes me wonder if the
registry being created to record these codes should have a "Status" column,
where this one could be marked "obsolete" or "deprecated".

Section 5.1.4.1.31.43:

* I think the "must not" needs to be "MUST NOT", and the other "must"s
should be "MUST"s.

Section 5.1.4.1.34.3:

* "... SHOULD NOT be used" why?

Section 5.1.4.1.34.9:

* Do Matroska implementations have to implement support for all of these?

Sections 5.1.5.1.1, 5.1.5.1.2.8, 5.1.7.1.4.3:

* "ie" should be "i.e.,"

Section 5.1.8.1.1:

* "If empty or not present..." for something with minOccurs 1 seems like a
contradiction.

Section 6.2:

* If I include a CRC-32 element at the root, do things break?  I'm
wondering about this SHOULD again.

Section 8:

* "needs" should be "need"

* I can't parse the second paragraph's first sentence.

Section 10:

* The second paragraph of this section repeats in Section 10.3.  Is that
necessary?

Section 11.1.3:

* The "MAY" at the end seems wrong.  Suggest "might".

Section 20:

* "it's" should be "its"

Section 22.1:

* Some of these seem like they should be in the sections where the elements
they reference are defined, rather than being collected here.

* The second-last of these isn't a recommendation, it's a requirement.

Section 23.1:

* This doesn't seem to be an appropriate use of SHOULD.  There's no
interoperability concern being described.

Section 25.3:

* Why is this section separate from Section 22.1?

Section 27.3 (redux):

* Security Considerations sections of media type registrations (per Section
4.6 of RFC 6838) need to talk, at a minimum, about whether the content of
the media type's payload includes data that could be executed directly on
the receiving platform.  Section 26 doesn't talk about this, so you might
want to include a sentence or two on that topic.

* I mentioned before that Interoperability Considerations is where we
expect backward compatibility to be described when older versions of a
specification exist.  With respect to that requirement, is there anything
that needs to be said in the registrations about what's in Section 28?

Section 30:

* I think the following references might need to be normative, since they
refer to things that weren't clearly optional in Matroska: [Blowfish],
[DivXTrickTrack], [DivXWorldFonts], [FIPS.197], [FIPS.46-3], [FourCC-RGB],
[FourCC-YUV], [MatroskaCodec], [MatroskaTags], [SP.800-38A], [SP.800-67],
[Twofish], [WebM-Enc], [WebVTT].

-MSK