Re: [Cellar] IANA considerations for EBML?

[Steve Lhomme <[e-mail]>]

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" <[e-mail]> a écrit :

>
> > On Jul 12, 2016, at 2:52 PM, Steve Lhomme <[e-mail]> wrote:
> >
> > 2016-07-12 20:48 GMT+02:00 Dave Rice <[e-mail]>:
> >>
> >>> On Jul 12, 2016, at 2:42 PM, Steve Lhomme <[e-mail]>
> wrote:
> >>>
> >>> I agree too. Although an EBML document, unless there's junk in it, can
> >>> 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.
> >
> > 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.
>
> 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.
>
> >>> 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.
> >>
> >> +1
> >>
> >>> 2016-07-07 14:16 GMT+02:00 Ashley Blewer <[e-mail]>:
> >>>> Agreeing with the above and adding "This document makes no requests of
> >>>> IANA." We can update later if necessary.
> >>>>
> >>>> Ashley Blewer
> >>>>
> >>>> On Thu, Jul 7, 2016 at 3:50 AM, Moritz Bunkus <[e-mail]>
> wrote:
> >>>>>
> >>>>> 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
> >>>>>
> >>>>> _______________________________________________
> >>>>> Cellar mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/cellar
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Cellar mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/cellar
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Steve Lhomme
> >>> Matroska association Chairman
> >>>
> >>> _______________________________________________
> >>> Cellar mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/cellar
> >>
> >
> >
> >
> > --
> > Steve Lhomme
> > Matroska association Chairman
>
>