Re: [Cellar] On the multiplicity of Info elements

"Timothy B. Terriberry" <tterribe@xiph.org> Mon, 11 January 2016 21:44 UTC

Return-Path: <tterribe@xiph.org>
X-Original-To: cellar@ietfa.amsl.com
Delivered-To: cellar@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983AE1A9308 for <cellar@ietfa.amsl.com>; Mon, 11 Jan 2016 13:44:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.313
X-Spam-Level:
X-Spam-Status: No, score=-5.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
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 RXC0qopwmwCE for <cellar@ietfa.amsl.com>; Mon, 11 Jan 2016 13:44:04 -0800 (PST)
Received: from smtp.mozilla.org (mx2.scl3.mozilla.com [63.245.214.156]) (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 421FC1A9300 for <cellar@ietf.org>; Mon, 11 Jan 2016 13:44:04 -0800 (PST)
Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id 7F32FC2875 for <cellar@ietf.org>; Mon, 11 Jan 2016 21:44:03 +0000 (UTC)
X-Virus-Scanned: amavisd-new at mozilla.org
Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx2.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHxRgZ67WUw3 for <cellar@ietf.org>; Mon, 11 Jan 2016 21:44:03 +0000 (UTC)
Received: from [10.252.27.21] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 6BAB8BFFA6 for <cellar@ietf.org>; Mon, 11 Jan 2016 21:44:03 +0000 (UTC)
Message-ID: <56942223.3090907@xiph.org>
Date: Mon, 11 Jan 2016 13:44:03 -0800
From: "Timothy B. Terriberry" <tterribe@xiph.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26
MIME-Version: 1.0
To: cellar@ietf.org
References: <CAHUoETLC4dQQ7=TOuTXZ3aDjKCCJgz2s-8Gb33MoSAP3hgRQiQ@mail.gmail.com> <BEA72D66-EA3D-4CF0-987D-836E95287F39@dericed.com> <20151230091811.GA19636@bunkus.org> <CAOXsMFLCbe-W=h+tQpdRa8Nh0jz=xdbZTXEmoXsgQTbA=4OPCQ@mail.gmail.com> <C0E5EBA2-2A56-46F9-A049-629EFB11F280@dericed.com> <CAOXsMF+gc0d2LEisfHm0jnjDGQKcYquEMBt7FnZ_uuSNF=C0iw@mail.gmail.com> <568AC10F.9030303@gmx.de> <CAOXsMFKJJhzU-3CYqguDePY42T+Vvhx9ytAfvoM6xyqaZY+N4g@mail.gmail.com> <FCC4DC05-44CD-4C2B-8C59-8E3E5B494DC0@dericed.com> <568D6710.8000605@gmx.de> <692F039A-180D-4535-B4A1-529A777573F5@dericed.com> <5693D5D6.6030709@xiph.org> <F6B37DB3-EDCB-4BD2-9B0D-F8A4F353F36E@dericed.com>
In-Reply-To: <F6B37DB3-EDCB-4BD2-9B0D-F8A4F353F36E@dericed.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/cellar/GN9iQ5aYFWE2v0F0aEwkHw_90cU>
Subject: Re: [Cellar] On the multiplicity of Info elements
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Jan 2016 21:44:05 -0000

Dave Rice wrote:
> implementation of this recommendation has been minimal.  To change
> the SHOULD to a MUST, would invalidate approximately 99.8% of
> Matroska files and 100% of webm files. I realize that this reason

Well, in the IETF (in contrast with the traditional approach of, say, 
MPEG) we are allowed to specify requirements on muxers separately from 
demuxers. So it's perfectly permissible to say a muxer MUST include CRCs 
while simultaneously saying a demuxer MUST be able to read a file 
without them. Then you wouldn't invalidate the existing media, just the 
existing software that produced them.

However, if you don't think it's worth trying to force muxers to change 
their implementation (or don't believe that a SHOULD or MUST in a spec 
will actually cause them to change), then perhaps the most appropriate 
level for this requirement is MAY?

> Perhaps the recommendation for CRC-32 usage (in Level 1 Elements and
> Identically-Recurring Elements) should be removed from the EBML
> Specification and moved to the Matroska EBML Schema.

That might also be reasonable (I hold no strong opinion).