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

From: Adam Roach via Datatracker <[email-masked]>
Date: Mon, 16 Dec 2019 21:28:43 -0800

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.

---

From: Dave Rice <[email-masked]>
Date: Tue, 17 Dec 2019 10:27:09 -0500

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

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

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

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.

Good catch. Changed to:
> Table 3: Examples of valid and invalid Element IDs

> 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

>   An EBML Document comprises only two components…

I chose the first suggestion.

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.

Added.

Thanks so much,
Dave Rice

---

From: Adam Roach <[email-masked]>
Date: Tue, 17 Dec 2019 13:56:02 -0600

Dave --

Thanks for the quick response! The issues that the PR addresses look 
good to me. Two comments inline below.

>> scope in the Introduction.

I didn't see a response to this discuss point. See also the GENART 
review, which raises this issue in some detail.

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

Given that information, I imagine that the better path would be revising 
the IANA instructions to operate on VINTs ("MUST be between 0x81 and 
0xFE") instead of VINT element data. This should be very 
straightforward, as the encoding of VINTs results in contiguous ranges 
that should be easy for IANA to deal with.

/a

---

From: Dave Rice <[email-masked]>
Date: Tue, 17 Dec 2019 16:16:00 -0500

> On Dec 17, 2019, at 2:56 PM, Adam Roach <[email-masked]> wrote:
> 
> Dave --
> 
> Thanks for the quick response! The issues that the PR addresses look good to me. Two comments inline below.
> 
> I didn't see a response to this discuss point. See also the GENART review, which raises this issue in some detail.

IIUC, this issue is discussed in https://github.com/cellar-wg/ebml-specification/pull/311/files <https://github.com/cellar-wg/ebml-specification/pull/311/files>.

> Given that information, I imagine that the better path would be revising the IANA instructions to operate on VINTs ("MUST be between 0x81 and 0xFE") instead of VINT element data. This should be very straightforward, as the encoding of VINTs results in contiguous ranges that should be easy for IANA to deal with.

Thanks. I’ve updated the section to use the VINT value rather than the decimal of the Element Data of that VINT. The commit is at https://github.com/cellar-wg/ebml-specification/pull/313/commits/948291dfddefa02f857c83a7155519b980d9b2f6 <https://github.com/cellar-wg/ebml-specification/pull/313/commits/948291dfddefa02f857c83a7155519b980d9b2f6>.

Dave Rice

---

From: Adam Roach <[email-masked]>
Date: Tue, 17 Dec 2019 15:37:49 -0600

Thanks for your responses. Modulo the comment I left in github [1], 
these two PRs (combined with the other PR you cited in an earlier 
message) address the concerns I had. I'll clear my DISCUSS when a new 
version with these PRs incorporated is put in the i-d repository.

Thanks!

/a

____
[1] 
https://github.com/cellar-wg/ebml-specification/pull/313/commits/948291dfddefa02f857c83a7155519b980d9b2f6#r359039422

On 12/17/19 3:16 PM, Dave Rice wrote:
>
>
>> On Dec 17, 2019, at 2:56 PM, Adam Roach <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Dave --
>>
> IIUC, this issue is discussed in 
> https://github.com/cellar-wg/ebml-specification/pull/311/files.
>
>>>> §17.1:
>>>>
>>> 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.
>>
>> Given that information, I imagine that the better path would be 
>> revising the IANA instructions to operate on VINTs ("MUST be between 
>> 0x81 and 0xFE") instead of VINT element data. This should be very 
>> straightforward, as the encoding of VINTs results in contiguous 
>> ranges that should be easy for IANA to deal with.
>
> Thanks. I’ve updated the section to use the VINT value rather than the 
> decimal of the Element Data of that VINT. The commit is at 
> https://github.com/cellar-wg/ebml-specification/pull/313/commits/948291dfddefa02f857c83a7155519b980d9b2f6.
>
> Dave Rice

---

From: Dave Rice <[email-masked]>
Date: Tue, 17 Dec 2019 21:17:31 -0500

Hi Adam,

> On Dec 17, 2019, at 4:37 PM, Adam Roach <[email-masked]> wrote:
> 
> Thanks for your responses. Modulo the comment I left in github [1], these two PRs (combined with the other PR you cited in an earlier message) address the concerns I had. I'll clear my DISCUSS when a new version with these PRs incorporated is put in the i-d repository.

Thanks, this comment addresses your github comment and references the other reserved one-octet Element ID value: https://github.com/cellar-wg/ebml-specification/pull/313/commits/689cbdb6882bc409628774cfa2854ee981d3ce87 <https://github.com/cellar-wg/ebml-specification/pull/313/commits/689cbdb6882bc409628774cfa2854ee981d3ce87>.

Also, to be clear what hex ranges are not valid for use as Element IDs, I restated these ranges specifically within this section at https://github.com/cellar-wg/ebml-specification/pull/313/commits/06d1960f9208e58f56972870b72f2c95fe1d8fe3 <https://github.com/cellar-wg/ebml-specification/pull/313/commits/06d1960f9208e58f56972870b72f2c95fe1d8fe3>.

Dave

> Thanks!
> 
> /a
> 
> 
> ____
> [1] https://github.com/cellar-wg/ebml-specification/pull/313/commits/948291dfddefa02f857c83a7155519b980d9b2f6#r359039422 <https://github.com/cellar-wg/ebml-specification/pull/313/commits/948291dfddefa02f857c83a7155519b980d9b2f6#r359039422>
> 
>>> On Dec 17, 2019, at 2:56 PM, Adam Roach <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Dave --
>>> 
> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar

---

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

Hi Adam,

> On Dec 17, 2019, at 9:17 PM, Dave Rice <[email-masked]> wrote:
> 
> Hi Adam,
> 
>> On Dec 17, 2019, at 4:37 PM, Adam Roach <[email-masked] <mailto:[email-masked]>> wrote:
>> 

Version 16 at https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/16 is posted and should address all comments presented below. Thanks much for your review.
Dave Rice

>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/cellar <https://www.ietf.org/mailman/listinfo/cellar>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/cellar <https://www.ietf.org/mailman/listinfo/cellar>