Re: [Cellar] [ietf-wg-cellar/ebml-specification] EBML ID 0x80 is marked invalid/reserved but it's used in Matroska (#407)

Hi, Steve,

(adding Murray to the CC list, because I'm invoking his wisdom on the
question we're talking about)

On Sun, May 16, 2021 at 8:42 AM Steve Lhomme <slhomme@matroska.org> wrote:

> On 2021-05-11 0:43, Spencer Dawkins at IETF wrote:
> > Adding our Loyal AD ... because I could be wrong, and he would know ...
> >
> > On Mon, May 10, 2021 at 9:16 AM Michael Richardson <mcr@sandelman.ca
> > <mailto:mcr@sandelman.ca>> wrote:
> >
> >
> >     Steve Lhomme <notifications@github.com
> >     <mailto:notifications@github.com>> wrote:
> >          > As pointed out by [Paul
> >     Foley](
> https://mailarchive.ietf.org/arch/msg/cellar/z_INjU-Vc9FOTDZs9AhdRRjrIig/
> >     <
> https://mailarchive.ietf.org/arch/msg/cellar/z_INjU-Vc9FOTDZs9AhdRRjrIig/
> >),
> >     the 0x80 is EBML ID is said to be invalid in the [RFC
> >     text](https://datatracker.ietf.org/doc/html/rfc8794#section-5
> >     <https://datatracker.ietf.org/doc/html/rfc8794#section-5>):
> >
> >          >> The bits of the VINT_DATA component of the Element ID MUST
> >     NOT be all
> >          >> "0" values or all "1" values.
> >
> >          > But in Matroska we use 0x80 for `ChapterDisplay`.
> >
> >          > I think the all 0 rules should be removed. In particular
> >     because 0x80
> >          > is the value that should be used when all VINT_DATA bits are
> >     0, per
> >          > this rule:
> >
> >          >> The VINT_DATA component of the Element ID MUST be encoded at
> >     the shortest valid length.
> >
> >          > Changing this text means also editing the IANA registry which
> >     lists all
> >          > the variants of 0 bits as reserved.
> >
> >     I'm not sure how to deal with this.
> >     It may be that we can put these IANA instructions into the Matroska
> >     document.
> >     Obviously, they would ideally go into an EBML-bis document, and that
> >     would be
> >     something we'd do if we were revising it now.
> >
> >
> > That would be perfect (if we were doing an EBML-bis document, but I
>
> What would be an EBML-bis document ? A revision to the RFC comparable to
> the errata or something that would result in a new RFC ?
>

This is always the question, when we have accepted Errata for a published
RFC - does the working group publish

   - an RFC that only contains the sections that the fix for the Errata
   touches (so, the new RFC Updates the previous RFC), or
   - an RFC that contains all the sections of the original RFC, whether
   they contain fixes for the Errata or not (so, the new RFC Obsoletes the
   previous RFC)

Guidance from the IESG about what is preferred has changed over time, so I
wanted Murray to be aware that the question was coming up in CELLAR, in
case he needed to tell us what the current answer is.

Does that make sense?

Best,

Spencer

> > predict that the answer is - the EBML document is a Proposed Standard,
> > so any Proposed Standard that (reasonably) updates the instructions to
> > IANA should be OK. This update is relevant for Matroska, which is also
> > targeting publication as a Proposed Standard, so that's a fine place to
> > put the updated IANA instructions.
> >
> > The EBML RFC IANA instructions would be outdated, but the point of IANA
> > registries is that the IANA registries are up to date, and you don't
> > have to chase (in some cases) a few dozen RFCs to find all the rules.
> >
> > Murray, is that about right?
> >
> > Best,
> >
> > SPencer
> >
> >     IANA instructions are a bit weird in that they are in essence,
> >     edge-triggered, and once processed in a document, they change.
> >
> >     ( https://en.wikipedia.org/wiki/Interrupt
> >     <https://en.wikipedia.org/wiki/Interrupt> )
> >
> >     --
> >     ]               Never tell me the odds!                 | ipv6 mesh
> >     networks [
> >     ]   Michael Richardson, Sandelman Software Works        |    IoT
> >     architect   [
> >     ] mcr@sandelman.ca <mailto:mcr@sandelman.ca>
> >     http://www.sandelman.ca/ <http://www.sandelman.ca/>        |   ruby
> >     on rails    [
> >
> >     _______________________________________________
> >     Cellar mailing list
> >     Cellar@ietf.org <mailto:Cellar@ietf.org>
> >     https://www.ietf.org/mailman/listinfo/cellar
> >     <https://www.ietf.org/mailman/listinfo/cellar>
> >
> >
> > _______________________________________________
> > Cellar mailing list
> > Cellar@ietf.org
> > https://www.ietf.org/mailman/listinfo/cellar
> >
>
>
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar
>