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

[Dave Rice <[e-mail]>]

Hi Adam,
Comments are in-line below.
tl;dr Most comments are responded to within https://github.com/cellar-wg/ebml-specification/pull/313 <https://github.com/cellar-wg/ebml-specification/pull/313> and there’s a call for feedback of others in regards to your comment on §17.1.

> On Dec 17, 2019, at 12:28 AM, Adam Roach via Datatracker <[e-mail]> wrote:
> 
> 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).

I started a pull request at with proposed changes referenced below.
Here I changed the sentence to:

> A Float Element stores a floating-point number in binary interchange format as defined in [@!IEEE.754.1985].

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

I believe that “NOT RECOMMENDED” is preferred here, so changed the “MAY” to “could”.

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

I understand the request and the reason for it and am interested in assessing rough consensus amongst the other authors before making this change. These elements have been long-associated with these particular vint expressions of the Element IDs, so I have some concerns that a global change of Element ID reference from VINT to the Element Data of that VINT would confuse readers.

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

Good catch. Changed to:
> Table 3: Examples of valid and invalid 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.

In our markdown these are listed in `2^7-2` format and the translation to RFC adds in the parenthesis. Surrounding the minus sign with spaces appears to fix the issue and the resulting RFC text shows:

 0 to 2^7 - 2

> ---------------------------------------------------------------------------
> 
> 
> §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…

I chose the first suggestion.

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

Yes exactly. In the prior version of xml2rfc, the section cross-reference could be labelled, but we switched to rewriting these cross-references to be simply the section name, but missed that fix for this one. Thanks for catching it.

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

Added.

Thanks so much,
Dave Rice