Re: [Cellar] On the multiplicity of Info elements

[Dave Rice <[e-mail]>]

> On Jan 11, 2016, at 11:18 AM, Timothy B. Terriberry <[e-mail]> wrote:
> 
> Dave Rice wrote:
>> Listing reasons to not have a CRC Child Element seems awkward.
>> Realistically I think the primary reason that CRC elements are not
>> used is because many muxers don’t support adding them, although the
>> EBML specification has long contained: "All level 1 elements SHOULD
>> include a CRC-32.” Instead of addressing reasons why not I added
> 
> So this is really, "SHOULD, unless it is too much work for you to bother”?

That does seem honest. ;)

From a sample set of 59,881 Matroska files uploaded to archive.org only 119 of them include CRC-32 Elements. Almost 0.2%! Additionally the webm Document Type lists the CRC-32 Element as unsupported. So I think it’s true that it’s rarely bothered with. The implementation of CRC-32 Elements does add many complications and perhaps demand has been too low to resolve them. Moritz may have comments here.

> I say this as someone who has had every SHOULD in one of my own drafts systematically dissected with the question, "Why not MUST? When would it be okay to violate this SHOULD?" late in the review process. I am trying to save you pain further down the line.

Historically both Matroska and EBML specs have said that "All level 1 elements should include a CRC-32” with a lower-case “should” (that ’should’ was capitalized in a recent review); however the 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 alone may not make good language within an RFC.

On the other hand, through discussion here, I do see the use of CRC-32 Elements to be more meaningful especially in the two use cases of the CELLAR working group title: archiving and transmission. 

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.

For any webm lurkers, was there any reason (that could be useful here) to set the CRC-32 Element to “Unsupported” within the webm specification?

Other suggestions?

Dave Rice