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

Steve Lhomme <slhomme@matroska.org> Thu, 29 December 2022 17:50 UTC

Return-Path: <slhomme@matroska.org>
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 34214C14CF06 for <cellar@ietfa.amsl.com>; Thu, 29 Dec 2022 09:50:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.893
X-Spam-Level:
X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20210112.gappssmtp.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 Deo5Nxm42iTM for <cellar@ietfa.amsl.com>; Thu, 29 Dec 2022 09:50:16 -0800 (PST)
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 6BE11C14CF15 for <cellar@ietf.org>; Thu, 29 Dec 2022 09:50:16 -0800 (PST)
Received: by mail-wm1-x333.google.com with SMTP id b24-20020a05600c4a9800b003d21efdd61dso13696451wmp.3 for <cellar@ietf.org>; Thu, 29 Dec 2022 09:50:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20210112.gappssmtp.com; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=uyou30bO+3Cn9+PVW1Gli7nSiFIE0V9CJniCeCdZfp4=; b=lfHq1SzhdJqnieZkQ2CJwbqMMWDFMyRvODm9PUXttnPhwgS0EzYJNbc+EIyN0x+hFg g0+FFWIm/2O+XzF0GhAOxMmTh8X5nwgCVm9s6oZ1ZOMqScCxgzZfGyuvWg5lEbUcLSa9 zXvHPfGYAn0uFEE7q6t0YRpGQ9TCR+AJKRlcu1H6Lr5hQZYWqmKHLx4a7wOtJSZe8u3N ZyopCg3t0EvtrvkZMzlPxb4C7N9twH61vnB+ybd3wOXg/k8bynP/aslJ6ffXq8zKygp3 JSPx/8n3fLdtuc5mw5V4hxJ+GWZemj2PHBh1tspTHYqHf59jciSWL12Ava/sNGTZzBUH 3/mg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=uyou30bO+3Cn9+PVW1Gli7nSiFIE0V9CJniCeCdZfp4=; b=iWmuTvkmdQV0ng1Ea1AD0JuAe8poK65Yt7JhybzQ5PtZaXc2cFG0yiMhb4+iENhLXZ YheH5U9upYASdNkt6+ITEAE5748qTApT/6XtTRPZiFAuPcURzVmTFumVAh1MGGvOENL3 zen9yinOQhmCje5I/+mHYqsYevF32F6Cn4Ng3TrbsD97BImuzowx3HX+qX52auE1Sekj /H6L9Mbu0fS94b6adTqRQQrkszBALBULsgg2gg2HPwcqk4EAqs++xoNzSEV5SIB+lUpJ AOe+IDB0GBdaRDFXjBf0nOX0Oaif/yIjMnTvB5eG2V4zPsg7b3YIt2EJZMjeMtScgj38 4lFg==
X-Gm-Message-State: AFqh2koGDE4v94DuJj7d1/PPBBqZXzNoTO0yJQUaEGzsTfooPODF5F9v oZkWxc07d8mZARDepB60oS3/LA==
X-Google-Smtp-Source: AMrXdXu2Kwd5+z1sLaEL5QGbynGKX6bpHgx8DnMEqRCQx35baO5iCXtvkfBnEVWJ9lkS/3PCMMXRgg==
X-Received: by 2002:a05:600c:3d86:b0:3d1:e04f:9bfa with SMTP id bi6-20020a05600c3d8600b003d1e04f9bfamr21705566wmb.28.1672336214165; Thu, 29 Dec 2022 09:50:14 -0800 (PST)
Received: from smtpclient.apple (2a01cb0c0020e9003d37c748f4917c57.ipv6.abo.wanadoo.fr. [2a01:cb0c:20:e900:3d37:c748:f491:7c57]) by smtp.gmail.com with ESMTPSA id l42-20020a05600c1d2a00b003d23928b654sm33422231wms.11.2022.12.29.09.50.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Dec 2022 09:50:13 -0800 (PST)
From: Steve Lhomme <slhomme@matroska.org>
Message-Id: <DB79FD52-21ED-49CB-A107-A817DE87E606@matroska.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_403008ED-2AFB-4FC3-9211-EBB1DE6984DB"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\))
Date: Thu, 29 Dec 2022 18:50:02 +0100
In-Reply-To: <CAL0qLwaCJn=8CEEmX1YSSJhjdrPzi2O7HkTN-dmMXh6+S4TAoQ@mail.gmail.com>
Cc: Codec Encoding for LossLess Archiving and Realtime transmission <cellar@ietf.org>
To: "Murray S. Kucherawy" <superuser@gmail.com>
References: <CAL0qLwaWoj105GWaF4rPCFYg=d5yQTG-H5vQF0MtWApd3Tt96A@mail.gmail.com> <CAL0qLwaCJn=8CEEmX1YSSJhjdrPzi2O7HkTN-dmMXh6+S4TAoQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3731.300.101.1.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/Ey270BWeIF2LF_2UbM3i3qvLY5o>
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: Thu, 29 Dec 2022 17:50:18 -0000

Hi Murray,

Thanks for taking the time to read this lengthy document and for all your comments.

I address all of them in Pull Requests on our GitHub. You can find the list at https://github.com/ietf-wg-cellar/matroska-specification/labels/ADReview

Only the last item in your list is not addressed: which part is considered normative or not. For example the DivX parts can’t really be normative, as the specs are not even available anymore. Some of the other documents are work in progress in the CELLAR group.

There’s also the question whether all the encryption algorithms are mandatory to support. Given the ContentEncodings parent is not. It can be not present in files (and that’s usually the case). Support for non mandatory elements is optional. Only a set of elements need to be supported for minimum proper support.

Steve

> On 26 Dec 2022, at 01:51, Murray S. Kucherawy <superuser@gmail.com> wrote:
> 
> 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 <mailto: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
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar