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

[Adam Roach <[e-mail]>]

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 <[e-mail] 
>> <mailto:[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.
>
>>>> §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.
>
> Dave Rice