Subject: Re: [Cellar] IANA Considerations for EBML

From: Steve Lhomme <[email-masked]>
Date: Tue, 28 Aug 2018 21:06:50 +0200

2018-07-17 7:09 GMT+02:00 Michael Richardson <[email-masked]>:
>
> Dave Rice <[email-masked]> wrote:
>     > I might be mistaken here, but from the draft the process of
>     > registering an Element ID via IANA only seems interested in the
>     > Element ID itself. For a curious onlooker of the IANA registrations it
>     > might be helpful to see what the associated DocType is so that the
>     > context and semantics could be understood, otherwise the registration
>     > only seems to indicate that somewhere someone registered it via
>     > first-come first-serve.
>
> I've been reading ebml more deeply in the last two weeks, and I actually have
> significant concerns.  I don't really understand what is going on.
>
> We have a virtual interim on the 31st, and I'd like to discuss this
> in person, perhaps. Earlier 1:1 if you think you could help me.
>
> In particular, I have no idea what the binary format of EBML even is!
> I thought I'd just missed the description before...
>
>     > Additionally I think I’d prefer (except for the IDs used by EBML
>     > itself) that the combination of DocType and ElementID be required as
>     > unique rather than only the ElementID itself. This seems analogous to
>     > how the same node name is allowed in various XML Schemas but don’t
>     > necessarily have any relation to one another in semantics.
>
> That's a choice.
> Given 2^35 ElementIDs, I don't see why you'd want to complicate your life
> that way.

Yes but Class A (1 octet) elements are rare and the most likely to be
used for each EBML-based format. Matroska uses a lot of them. That
will leave almost none left for the other formats.

>     > Is it acceptable to extend the IANA Considerations section to clarify
>     > the required information for registrations? From the discussion in the
>     > pull request these scenarios seem to be:
>
> If you want to make the ElementID a function of DocType, then put all the
> ElementID allocations into the document that defines that DocType.
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        | network architect  [
> ]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [
>

-- 
Steve Lhomme
Matroska association Chairman

---

From: Michael Richardson <[email-masked]>
Date: Tue, 28 Aug 2018 18:20:47 -0400

> will leave almost none left for the other formats.

I think that the way to do this is to have each DocType (such as Matroska)
create a new registry for Element IDs used in the DocumentBody.

In each of the registries that are created, I think that the Element IDs
used/defined in the EBML document should also be reserved.  This is just
to avoid any confusion.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Moritz Bunkus <[email-masked]>
Date: Wed, 29 Aug 2018 07:19:18 +0200

Hey,

Yes, I completely agree with this proposal.

Kind regards
Mosu