Subject: Re: [Cellar] My review of the EBML-specifications

From: Steve Lhomme <[email-masked]>
Date: Sun, 10 Mar 2019 14:19:51 +0100

Le mer. 27 févr. 2019 à 16:46, Michael Richardson <[email-masked]> a écrit :
>
> Steve Lhomme <[email-masked]> wrote:
>     >> I didn't think of this as a courtesy. After all, if these are distinct
>     >> namespaces with the potential for overlapping, then resynchronisation
>     >> might be affected (in case of errors). In order to prevent this, the
>     >> ID of the `EBML` element (`0x1A45DFA3`) should not be allowed to be
>     >> reused by any EBML Schema.
>
>     > The resynchronization is indeed a good case for avoiding reuse. I'm less sure
>     > about the sub element IDs of the EBML header. On one hand there's not many so
>     > it's not a big restriction on the main EBML-based format. On the other hand
>     > the number might grow in the future and collide with EBML-based formats that
>     > used the same IDs.
>
> Should the resynchronization goals be stated somewhere?

Not sure, it seems like an algorithm that could be done in different
ways. For example you can take the size in account (like we do in
libebml) to find proper resynchronzation points and allow any upper
elements to the context you last had (we also do in libebml). Or you
could just look for any top level element and stick to that.

>     > IMO it still goes down to the namespace. The ID makes sense at one level and
>     > none at any other level. So reusing the ID should not be an issue. This is by
>     > design. The same ID in different places could be used and this is fine.
>
>     > So IMO we should add a note that the 0x1A45DFA3 cannot be used anywhere in
>     > the EBML-based format, as well as the EBML global elements.
>
> Exactly.

Done in 7f78a306748d2f44098df72527989e96396bbb22