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

From: Michael Richardson <[email-masked]>
Date: Mon, 10 May 2021 10:16:18 -0400

Steve Lhomme <[email-masked]> wrote:
    > As pointed out by [Paul Foley](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):

    >> 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.

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 )

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 10 May 2021 17:43:44 -0500

Adding our Loyal AD ... because I could be wrong, and he would know ...

On Mon, May 10, 2021 at 9:16 AM Michael Richardson <[email-masked]> wrote:

>     > As pointed out by [Paul Foley](
> 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):
>

That would be perfect (if we were doing an EBML-bis document, but I 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

> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar
>

---

From: Steve Lhomme <[email-masked]>
Date: Sun, 16 May 2021 15:42:13 +0200

On 2021-05-11 0:43, Spencer Dawkins at IETF wrote:
> On Mon, May 10, 2021 at 9:16 AM Michael Richardson <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
>     Steve Lhomme <[email-masked]
>     <mailto:[email-masked]>> 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.
> 
> 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 ?

> 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.
> 
> 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.
> 
>     ( https://en.wikipedia.org/wiki/Interrupt
>     <https://en.wikipedia.org/wiki/Interrupt> )
> 
>     --
>     ] [email-masked] <mailto:[email-masked]>
>     http://www.sandelman.ca/ <http://www.sandelman.ca/>        |   ruby
>     on rails    [
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/cellar>
> 
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sun, 16 May 2021 13:29:02 -0500

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 <[email-masked]> wrote:

> https://mailarchive.ietf.org/arch/msg/cellar/z_INjU-Vc9FOTDZs9AhdRRjrIig/
> >     <

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 18 May 2021 10:41:09 -0700

Sorry for the delay replying here.

On Mon, May 10, 2021 at 3:44 PM Spencer Dawkins at IETF <
[email-masked]> wrote:

> 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

It's possible I don't have all the context I need here, in which case this
answer will be nonsense and I'll need ask for more details, but running
with what I've got:

I think you could do an "updates" document to EBML that just makes IANA
registry/policy amendments if you want to do that.  Smaller documents tend
to result in faster processing by the IESG.  The cases where this tends not
to work is where the number of "updates" documents gets large enough that
teasing out reality becomes difficult; at that point it becomes better to
just issue a complete "bis" document.

If you put EBML-specific IANA actions in the Matroska document, and they
are not clearly related, you might encounter some resistance of the form
"What the heck is this doing here?" from the IESG or other reviewers.

If that's not a helpful answer, let me know and I'll get Spencer to give me
more context.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 18 May 2021 10:51:05 -0700

> case he needed to tell us what the current answer is.

An "updates" or "bis" document just to resolve one or two errata might
raise some eyebrows.  How many do you want to handle?  Is there any pending
update you could fold into such a document?  Or to put it another way,
what's wrong with leaving it as a small number of errata for now?

Whether you do a full "bis" document or an "updates" depends on how big the
aggregate change(s) you have in mind are.  I'm happy to be an advocate for
either; just depends on how big the final "diff" to the existing document
would be.

-MSK

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 18 May 2021 12:59:02 -0500

Hi, Murray,

(replying here - I think this email is more relevant)

On Tue, May 18, 2021 at 12:51 PM Murray S. Kucherawy <[email-masked]>
wrote:

>> 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
> Whether you do a full "bis" document or an "updates" depends on how big
> the aggregate change(s) you have in mind are.  I'm happy to be an advocate
> for either; just depends on how big the final "diff" to the existing
> document would be.
>

This is helpful.

What we're looking at in this thread is a small number of errors for EBML
(that haven't been entered as errata for the RFC yet), and a change to the
IANA instructions for one of the registries in .
https://www.iana.org/assignments/ebml/ebml.xhtml.

Does that sound OK as an Updates RFC to you?

(depending on the final "diff", of course!)

Best,

Spencer

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 18 May 2021 11:29:16 -0700

> (depending on the final "diff", of course!)

I'd have to see it to say for sure, but I would start this by writing an
"updates" RFC.  If it starts to become bigger than the kind of thing you
would be comfortable patching into some source code, you might consider
just doing a whole "bis" document that includes all of your corrections.  I
would surmise that the inflection point between the two choices is when the
size of the "updates" document exceeds the size that the diff of the "bis"
document would be.  When you cross that boundary, consider switching to the
latter.

Since you can always get the final XML back from the RFC Editor, doing a
"bis" document isn't as much of a burden as you might think.  The
datatracker certainly does make it easy for someone to just review the diff
to the previous RFC, and the IESG loves it when you make things easy on
them.  ;-)

I can anticipate, however, some resistance just on the basis that we're
already talking about a "bis" document for an RFC that's not even a year
old, so we should be prepared to talk about why this is necessary.

-MSK

---

From: Michael Richardson <[email-masked]>
Date: Fri, 21 May 2021 14:19:51 -0400

Murray S. Kucherawy <[email-masked]> wrote:
    > It's possible I don't have all the context I need here, in which case
    > this answer will be nonsense and I'll need ask for more details, but
    > running with what I've got:

I think you got it right.

    > registry/policy amendments if you want to do that.  Smaller documents
    > tend to result in faster processing by the IESG.  The cases where this
    > tends not to work is where the number of "updates" documents gets large
    > enough that teasing out reality becomes difficult; at that point it
    > becomes better to just issue a complete "bis" document.

I think we are still in the updates space.

    > If you put EBML-specific IANA actions in the Matroska document, and
    > they are not clearly related, you might encounter some resistance of
    > the form "What the heck is this doing here?" from the IESG or other
    > reviewers.

I think we have slightly bit more than than the IANA action changes.
I think that we should do this updates document, but not rush it, aiming to
get it to IESG by the end of the summer.

I think it will be about four pages long.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide