Subject: [Cellar] IANA considerations for EBML?

From: Dave Rice <[email-masked]>
Date: Wed, 6 Jul 2016 20:33:30 -0400

Hi all,
Regarding RFC5226, https://tools.ietf.org/html/rfc5226, should the EBML RFC include any IANA considerations? A suggestion for a generic EBML mime type?
Dave Rice

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 06 Jul 2016 19:53:44 -0500

Hi,

All Internet Drafts need an IANA considerations section, even if they 
have no such considerations. In that case, the section can simply say 
something to the effect of "This document makes no requests of IANA.".

I wouldn't invent considerations unless you are pretty sure they are 
real. If you think there might be some by by the time the draft becomes 
an RFC, it's not unheard of to mark the section as TBD in an early 
revision of a draft.

Thanks,

Ben.

On 6 Jul 2016, at 19:33, Dave Rice wrote:

> Hi all,
> Regarding RFC5226, https://tools.ietf.org/html/rfc5226, should the 
> EBML RFC include any IANA considerations? A suggestion for a generic 
> EBML mime type?
> Dave Rice
> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar

---

From: Moritz Bunkus <[email-masked]>
Date: Thu, 7 Jul 2016 09:50:16 +0200

Hey,

I'm not convinced that we need a MIME type for EBML. This is a bit
different than XML (there's a MIME type for XML). With XML it makes
sense to have tools that can deal with the general container format
(XML) even if they cannot deal with the specific XML application
(e.g. namespaces, XSD style sheets). This is possible as XML's structure
can be understood at a basic level without knowing anything about the
intended use as there are special characters at the container level (<,
>) which must not occur in the content unless they're escaped.

This does not apply to EBML. If you don't know the specific EBML
application (e.g. the Matroska schema) then you cannot determine the
EBML document's structure safe for the EBML header. Hence you cannot
write a general tool showing you an tree of all EBML elements for any
EBML file.

This would be a vote for including a section stating that we don't
require anything from the IANA.

Kind regards,
mosu

---

From: Ashley Blewer <[email-masked]>
Date: Thu, 7 Jul 2016 08:16:52 -0400

Agreeing with the above and adding "This document makes no requests of
IANA." We can update later if necessary.

Ashley Blewer

---

From: Steve Lhomme <[email-masked]>
Date: Tue, 12 Jul 2016 20:42:10 +0200

I agree too. Although an EBML document, unless there's junk in it, can
be fully parsed. IMO a MIME type would imply that it should be used
regardless of the EBML format. But that's not what we want. Each
DocType should have its own matching MIME type.

-- 
Steve Lhomme
Matroska association Chairman

---

From: Dave Rice <[email-masked]>
Date: Tue, 12 Jul 2016 14:48:25 -0400

> On Jul 12, 2016, at 2:42 PM, Steve Lhomme <[email-masked]> wrote:
> 
> be fully parsed.

But if you have an unknown sized Element, then how would you know when it ends. IIUC semantic-aware EBML parsing and non-semantic-aware EBML parsing differ at Elements with unknown sizes.

> IMO a MIME type would imply that it should be used

+1

---

From: Steve Lhomme <[email-masked]>
Date: Tue, 12 Jul 2016 20:52:17 +0200

> But if you have an unknown sized Element, then how would you know when it ends. IIUC semantic-aware EBML parsing and non-semantic-aware EBML parsing differ at Elements with unknown sizes.

You can still find the ID+Size of that element. You will never be able
to go back to an upper level Element after that, though.

---

From: Dave Rice <[email-masked]>
Date: Tue, 12 Jul 2016 15:13:36 -0400

> On Jul 12, 2016, at 2:52 PM, Steve Lhomme <[email-masked]> wrote:
> 

In the present EBML spec, after https://github.com/Matroska-Org/ebml-specification/pull/50/files#diff-01f3b0f2fbf3e44327e6072f64ddc8a0:

"When EBML is used in transmission or streaming, data that is not part of an EBML Element is permitted to be present within a Master-element. In this case, the reader should skip data until a valid Element ID of the same level or the next greater level of the Master-element is found."

You may have
<masterelement size="unknown">
	<junk/>
	<childelement/>
</masterelement>

The <junk> may contain things that look like elements. If enough junk you'll even be likely to false-identify a Void Element. It isn't possible to know what is junk and what isn't within an unknown-sized element without the semantics.

---

From: Steve Lhomme <[email-masked]>
Date: Tue, 12 Jul 2016 21:25:05 +0200

That's why I said "unless there's junk in it".

Anyway my real point is that MIME type should follow the semantic, not the
underlying format.
Le 12 juil. 2016 21:13, "Dave Rice" <[email-masked]> a écrit :

> >> But if you have an unknown sized Element, then how would you know when
> it ends. IIUC semantic-aware EBML parsing and non-semantic-aware EBML
> parsing differ at Elements with unknown sizes.
> >
> In the present EBML spec, after
> https://github.com/Matroska-Org/ebml-specification/pull/50/files#diff-01f3b0f2fbf3e44327e6072f64ddc8a0
> :
>
> "When EBML is used in transmission or streaming, data that is not part of
> an EBML Element is permitted to be present within a Master-element. In this
> case, the reader should skip data until a valid Element ID of the same
> level or the next greater level of the Master-element is found."
>
> You may have
> The <junk> may contain things that look like elements. If enough junk
> you'll even be likely to false-identify a Void Element. It isn't possible
> to know what is junk and what isn't within an unknown-sized element without
> the semantics.
>