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

[Dave Rice <[e-mail]>]

> On Dec 17, 2019, at 2:56 PM, Adam Roach <[e-mail]> wrote:
> 
> Dave --
> 
> Thanks for the quick response! The issues that the PR addresses look good to me. Two comments inline below.
> 
> On 12/17/19 9:27 AM, Dave Rice wrote:
>> 
>>> 
>>> 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.
>>> 
> 
> 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>.

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