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

[Dave Rice <[e-mail]>]

Hi Magnus,

> On Dec 19, 2019, at 9:02 AM, Magnus Westerlund via Datatracker <[e-mail]> wrote:
> 
> Magnus Westerlund 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:
> ----------------------------------------------------------------------
> 
> 1. Section 5:
> 
>   The Element ID is encoded as a Variable Size Integer.
> 
>    +-----------------------+-------------------------+---------------+
>    | VINT Length in octets |  Range of Possible IDs  | Number of IDs |
>    +=======================+=========================+===============+
>    |           1           |       0x81 - 0xFE       |           126 |
>    +-----------------------+-------------------------+---------------+
>    |           2           |     0x407F - 0x7FFE     |        16,256 |
>    +-----------------------+-------------------------+---------------+
>    |           3           |   0x203FFF - 0x3FFFFE   |     2,080,768 |
>    +-----------------------+-------------------------+---------------+
>    |           4           | 0x101FFFFF - 0x1FFFFFFE |   268,338,304 |
>    +-----------------------+-------------------------+---------------+
> 
> To me it appears that this whole section can't decide if the Element ID is
> encoded integer using VINT or an VINT format octet sequence that is self
> describing in length? If it is the first then the above quoted table would to
> me state that the IDs are 1-126 for 1 octet, and the second two-octet
> 127-16382. But based on later section it is actually the later. As the ID
> values defined in Section 11.2 for the various elements are actually the
> encoded form rather than a representation of the Integer value encoded. This
> needs to be clarified.

Thanks, this topic came up in Adam Roach’s review [1] as well and ended with a use of an Element ID as a VINT format octet sequence. I have rewritten this section in the referenced pull request [2] according to your suggestions and comments.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 1. Section 5:
> 
> Any Element ID with the VINT_DATA
>   component set as all zero values or all one values MUST be ignored.
> 
> What does it mean to ignore an Element ID in the general case. Can you really
> say this in the general case, rather than state that it is not a valid Element
> ID? Or is the intention that an Element ID with all data is the equivalent to
> padding and simply skipped and a parser needs to expect to find the real
> Element ID in the next octet sequence? Considering the Element Length that do
> allow zero values and non-efficient encoding, if the element should be ignored
> or not depends on the expected element to find by the parser.
> 
> I might have missed some later explanation of this, as I didn't manage to read
> the whole document in detail.

I considered changing this sentence from saying that such an Element ID should be ignored to simply asserting that it is not valid; however the prior sentence "The bits of the VINT\_DATA component of the Element ID MUST NOT be all `0` values or all `1` values.” already makes this clear. Thus I simply removed the sentence in the second commit of the pull request. I think this sentence is okay to remove as there are later statements in Section 7.7 that make the same point more clearly about skipping invalid data.

Thanks much,
Dave

[1] https://mailarchive.ietf.org/arch/msg/cellar/yvXmJPWGkUISXbdt0aZ-UkC57I8
[2] https://github.com/cellar-wg/ebml-specification/pull/315/files