Subject: [Cellar] Barry Leiba's No Objection on draft-ietf-cellar-ebml-15: (with COMMENT)

From: Barry Leiba via Datatracker <[email-masked]>
Date: Wed, 18 Dec 2019 21:45:33 -0800

Barry Leiba has entered the following ballot position for
draft-ietf-cellar-ebml-15: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This was a very difficult read: I found a lot of the document to be convoluted
and hard to follow, and I considered balloting Abstain, as I’m not sure that
DISCUSS is appropriate for my complaints, but I can’t really say that I have
“no objection”.  In the end I decided to go with a “No Objection” ballot, to
call out the worst of the issues, and to hope that you will consider the
changes I suggest and that others will follow the text more easily than I could.

— Section 4.1 —

   Each Variable Size Integer begins with a VINT_WIDTH which consists of
   zero or many zero-value bits.  The count of consecutive zero-values
   of the VINT_WIDTH plus one equals the length in octets of the
   Variable Size Integer.  For example, a Variable Size Integer that
   starts with a VINT_WIDTH which contains zero consecutive zero-value
   bits is one octet in length and a Variable Size Integer that starts
   with one consecutive zero-value bit is two octets in length.  The
   VINT_WIDTH MUST only contain zero-value bits or be empty.

I found this very hard to follow, and had to read it several times before I
understood what you’re getting at.  I found things such as “zero or many
zero-value bits” to be confusing.  May I suggest alternative text, which
describes the concept and then gets to the details?:

NEW
Each Variable Size Integer begins with a VINT_WIDTH followed by a VINT_MARKER. 
VINT_WIDTH is a sequence of zero or more bits of value 0, and is terminated by
the VINT_MARKER, which is a single bit of value 1.  The total number of bits
(VINT_WIDTH and VINT_MARKER combined) is the number of octets of the Variable
Size Integer.

Thus, the single bit “1” describes a Variable Size Integer with a length of one
octet.  The sequence of bits “01” describes a Variable Size Integer with a
length of two octets.  “001” describes a Variable Size Integer with a length of
three octets, and so on, with each additional 0-bit adding one octet to the
length of the Variable Size Integer. END

I, at least, find that easier to follow.  Does it work for you?

For the next paragraph, which limits the length under various circumstances, I
suggest putting it in terms of the number of octets in the integer, rather than
the number of bits in the VINT_WIDTH, which might be better put into Section
4.3, rather than 4.1.  Text such as, “A Variable Size Integer in an EBML Header
can be at most 4 octets long, except [...] , where it can be up to 8 octets
long,” is easier to understand than the text explaining limits on the number of
bits in VINT_WIDTH.

— Section 4.4 —
Table 2 and the text that introduces it would be better if they talked about
the integer that’s represented (2), rather than the binary value (0b10 in the
text and 10 in the table), considering that it is a Variable Size INTEGER, yes?

— Section 6.2 —

   An EBML Element with an unknown Element Data Size
   is referred to as an Unknown-Sized Element.  A Master Element MAY be
   an Unknown-Sized Element; however an EBML Element that is not a
   Master Element MUST NOT be an Unknown-Sized Element.  Master Elements
   MUST NOT use an unknown size unless the unknownsizeallowed attribute
   of their EBML Schema is set to true (see Section 11.1.5.10).

This also seems confusing and perhaps contradictory because of how it uses the
BCP 14 key words.  May I suggest this, which neither uses nor needs the key
words?:

NEW
   An EBML Element with an unknown Element Data Size
   is referred to as an Unknown-Sized Element.  Only a Master Element
   is allowed to be of unknown size, and it can only be so if the
   unknownsizeallowed attribute of its EBML Schema is set to true
   (see Section 11.1.5.10).
END

— Section 7.7 —

   The Master Element MAY also use an unknown length.

The “MAY” isn’t really correct, is it?  There are restrictions that make it not
entirely optional, as noted in the next sentence.  I suggest not using BCP 14
here, and just saying, “The Master Element may be of unknown length.”

   The Master Element contains zero, one, or many other elements.

Does this mean anything more than the simpler, “The Master Element contains
zero or more other elements.”?  As written, one tends to ask what “many” means
here.

— Section 8.2 —

   The EBML Body MUST NOT contain any data that is not
   part of an EBML Element.

Why is this repetition needed?  Doesn’t the similar sentence in Section 8 cover
this?

— Section 10 —

   An EBML Document handles 2 different versions: the version of the
   EBML Header and the version of the EBML Body.  Both versions are
   meant to be backward compatible.

I don’t see how that’s practical, as, taken strictly, it means you’ll never be
able to make a significant change that is not backward compatible, so you’ll be
stuck with errors or limitations forever.  Are you sure you won’t need to allow
for incompatible versions at some point?

— Section 17.1 —

   Values from 1 to 126 are to
   be allocated according to the "RFC Required" policy [RFC8126].

Why did you choose that policy?  Are you aware that this allows registrations
from non-IETF-stream RFCs?  In particular, anyone can get an RFC published in
the Independent stream with a very light level of review.  Did you consider
IETF Review, which requires an RFC in the IETF stream (including Informational
and Experimental RFCs)?  Or even Standards Action, which requires
standards-track RFCs?

The same comment applies to "matroska" and "webm" in Section 17.2.

---

From: Dave Rice <[email-masked]>
Date: Fri, 20 Dec 2019 16:08:21 -0500

Hi Barry,
Thanks for your review. Comments are below, including nudges to Michael Richardson and Steve Lhomme for review. My comments below refer to work that is reviewable within a pull request at https://github.com/cellar-wg/ebml-specification/pull/316/files, though in a few parts below I call for greater discussion.

> On Dec 19, 2019, at 12:45 AM, Barry Leiba via Datatracker <[email-masked]> wrote:
> 

Yes, I think that’s helpful. I changed the term ‘begins’ and ‘describes’ to ’starts’, so there’s a little rewording but I have it now as:

NEW
Each Variable Size Integer starts with a VINT\_WIDTH followed by a
VINT\_MARKER. VINT\_WIDTH is a sequence of zero or more bits of value
`0`, and is terminated by the VINT\_MARKER, which is a single bit of
value `1`. The total number of bits (VINT\_WIDTH and VINT\_MARKER combined) is the number of octets in length of the Variable Size Integer.

Thus, the single bit `1` starts a Variable Size Integer with a length of one octet.  The sequence of bits `01` starts a Variable Size Integer with a length of two octets. `001` starts a Variable Size Integer with a length of three octets, and so on, with each additional 0-bit adding one octet to the length of the Variable Size Integer. END

> long,” is easier to understand than the text explaining limits on the number of

I agree with your rewording but prefer to split this paragraph and move it to section 8.1 which pertains to the “EBML Header” and 8.2 which pertains to “EBML Body”. After rewording the content is:

Added to 8.1
Elements within an EBML Header can be at most 4 octets long, except for the EBML Element with Element Name EBML and Element ID `0x1A45DFA3` (see (#ebml-element)), which can be up to 8 octets long.

Added to 8.2
Within the EBML Body, the maximum octet length allowed for any Element ID is set by the EBMLMaxIDLength Element and the maximum octet length allowed for any Element Data Size is set by the EBMLMaxSizeLength Element.

> text and 10 in the table), considering that it is a Variable Size INTEGER, yes?

That makes sense, I rewrote to focus on integer and parenthetically mentioned the binary value since the VINT is expressed in binary (though I added a hex representation as well).

>   unknownsizeallowed attribute of its EBML Schema is set to true

I updated the section as suggested in the pull request.

> here, and just saying, “The Master Element may be of unknown length.”

I reworded this sentence with the prior one to avoid the use of MAY. The new paragraph is:

A Master Element MUST declare a length in octets from zero to VINTMAX or be of unknown length. See (#element-data-size) for rules that apply to elements of unknown length.

> zero or more other elements.”?  As written, one tends to ask what “many” means

I updated the sentence as suggested in the pull request.

> Why is this repetition needed?  Doesn’t the similar sentence in Section 8 cover

True. I removed this repetitive statement.

> for incompatible versions at some point?

Nudging to Steve for review/comment. This part was written at:
https://github.com/cellar-wg/ebml-specification/commit/f9820d50d5279e11efbb6cdd70dd8021b8a05dc9
https://github.com/cellar-wg/ebml-specification/commit/10d359d637af02c15b1c3191e260707adf0c29dc

> The same comment applies to "matroska" and "webm" in Section 17.2.

Nudging to Michael, who recommended this policy here.

Best Regards,
Dave Rice

---

From: Barry Leiba <[email-masked]>
Date: Fri, 20 Dec 2019 16:40:48 -0500

Thanks, Dave, and I appreciate your addressing my concerns (and
accepting most of my text!).  We're good on all the items you handled.

Barry

---

From: Dave Rice <[email-masked]>
Date: Sun, 22 Dec 2019 15:50:55 -0500

Hi Barry,

> On Dec 20, 2019, at 4:40 PM, Barry Leiba <[email-masked]> wrote:
> 

Version 16 at https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/16 is posted and addresses everything you listed below, except your comments on Section 10 and Section 17.1. Nudges to Michael Richardson and Steve Lhomme on these points.

Dave

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

---

From: Steve Lhomme <[email-masked]>
Date: Tue, 24 Dec 2019 10:49:33 +0100

Hi,

> https://github.com/cellar-wg/ebml-specification/commit/10d359d637af02c15b1c3191e260707adf0c29dc

We are not entirely stuck with past issues. For example we can bump
DocTypeReadVersion to mark that a file cannot be read by parsers meant
for older versions of the file. That breaks backward compatibility for
the reader. The old files should always be readable by new code, even
if it means checking the DocType version to see how a value was
implemented and may have changed.

In 17 years of Matroska we hardly ever had such issues. We added
SimpleBlock when the BlockGroup was deemed too big when unnecessary,
but we always kept the old system in place. Forcing backward
compatibility is not a big burden when adding things. It just means
you have to pick a default value that matches the old files or not set
a value that old parser may misinterpret. It also means you can't
change defined values (in an enumerate) but just add some.

In the end it forces extra thinking to make sure you don't break
anything. But it's really not hard, EBML can be extended and tells old
parsers what to do with unknown data. It's different than other
formats with hardcoded sizes for structures or the size of structures
not stored at all.

> > and Experimental RFCs)?  Or even Standards Action, which requires

For Matroska that's probably not an issue. It's OK if it's extended
independently.

For the IDs in the EBML Header I don't have a strong opinion. If
someone defines extra data in the header that only them plan to use,
why not. If they make it public through the IETF it's already a better
step. The problem is if there's a collision between 2 independent
extensions or a planned addition to the format and an extension. In
this case the first published should have priority.

There can be an issue if someone just comes and assign *all* the
remaining one-octet IDs in their EBML extension and there's nothing
left for the main EBML. Does the "light review" cover this kind of
problem ? Otherwise we probably need to raise the level of scrutiny.

-- 
Steve Lhomme
Matroska association Chairman