[Cellar] Adam Roach's Discuss on draft-ietf-cellar-ebml-15: (with DISCUSS and COMMENT)

[Adam Roach via Datatracker <[e-mail]>]

Adam Roach has entered the following ballot position for
draft-ietf-cellar-ebml-15: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks to the authors and the participants of the CELLAR working group for
the work that has gone into documenting the EBML format. I have a handful
of comments that I believe need to be addressed prior to publication, and
a handful of suggestions for improvement.

---------------------------------------------------------------------------

Abstract:

I see that the Introduction has been revised to address Ben Campbell's AD
review comment regarding the document positioning itself as a general-purpose
data format rather than being scoped to its use in Matroska. The Abstract
still claims the much broader scope -- please update it to match the reduced
scope in the Introduction.

---------------------------------------------------------------------------

§7.3:

>  A Float Element stores a floating-point number as defined in
>  [IEEE.754.1985].

This is not sufficiently precise to interoperate, as IEEE-754 defines multiple
floating-point representations at each bit length. To differentiate from,
e.g., decimal representation and arithmetic format (neither of which are
probably what you want), please specify the use of "binary interchange
format" (unless some other format is intended).

---------------------------------------------------------------------------

§14.1.3:

>  For String Elements and UTF-8 Elements the length of Element Data MAY
>  be reduced by adding Null Octets
...
>  Note that this method is NOT RECOMMENDED.

These two normative statements conflict with each other: when using RFC 2119
language, MAY is a very different level than "NOT RECOMMENDED" (which is
equivalent to "SHOULD NOT"). Please pick one, and eliminate the other.

---------------------------------------------------------------------------

§17.1:

>  The VINT Data value of one-octet Element IDs MUST be between 0x01 and
>  0x7E.  These items are valuable because they are short, and need to
>  be used for commonly repeated elements.  Values from 1 to 126 are to
>  be allocated according to the "RFC Required" policy [RFC8126].

This, combined with the values that are being registered, is extremely
confusing, and I don't know how IANA is supposed to understand what's going on
without reading and understanding the VINT bit encoding scheme (which is way
too much to ask of them). This is because of the document-wide practice
of speaking of IDs in their VINT-encoded values (e.g., 0xBF) instead of their
data values (e.g., 63 or 0x3F), including in the initial registry in this section.

Please either revise the prose to speak in terms of VINT-encoded values
(e.g., "MUST be between 0x81 and 0xFE"), or revise the registration
tables to indicate the VINT data values (e.g., "0x3F" for CRC-32).


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

§5:

>              Table 3: Examples of valid and invalid VINTs

This label is a bit confusing, as all the shown VINTs are valid;
they're just not valid for use as Element IDs.

---------------------------------------------------------------------------

§6.3:

>                 +--------------+----------------------+
>                 | Octet Length | Possible Value Range |
>                 +==============+======================+
>                 | 1            | 0 to 2^(7-2)         |
>                 +--------------+----------------------+
>                 | 2            | 0 to 2^(14-2)        |
>                 +--------------+----------------------+
>                 | 3            | 0 to 2^(21-2)        |
>                 +--------------+----------------------+
>                 | 4            | 0 to 2^(28-2)        |
>                 +--------------+----------------------+
>                 | 5            | 0 to 2^(35-2)        |
>                 +--------------+----------------------+
>                 | 6            | 0 to 2^(42-2)        |
>                 +--------------+----------------------+
>                 | 7            | 0 to 2^(49-2)        |
>                 +--------------+----------------------+
>                 | 8            | 0 to 2^(56-2)        |
>                 +--------------+----------------------+

I think the value ranges here are indicated incorrectly. If I understand the
encoding scheme correctly, the range for one octet is 0 through 126,
which is "0 to (2^7)-2" rather than "0 to 2^(7-2)" (which means 0 through 32).

The other lengths have identical errors.

---------------------------------------------------------------------------


§8:

>  An EBML Document is comprised of only two components, an EBML Header

Please change to either of the following:

   An EBML Document is composed of only two components...

   An EBML Document comprises only two components...

---------------------------------------------------------------------------

§11.1.5.2:

>  A path with a EBMLGlobalParent defines a
>  Section 11.3.

This doesn't parse. I think you mean:

  A path with a EBMLGlobalParent defines a Global Element; see Section 11.3.

---------------------------------------------------------------------------

§ 11.1.5.12:

>  A boolean to express if an EBML Element is defined as an Identically
>  Recurring Element or not.

As the term "Identically Recurring Element" has not been defined prior to this
section, A forward reference to 11.1.16 would be very useful here.