[Cellar] [IANA #1161138] Protocol Action: 'Extensible Binary Meta Language' to Proposed Standard (draft-ietf-cellar-ebml-17.txt)

["Amanda Baber via RT" <[e-mail]>]

Hi Dave,

In the registry, should we use the description "Not valid for use as an Element ID" for all of these? If not, can you give us the exact text that should be used for each entry?

If more specific text than "Not valid for use as an Element ID" should be used for these, should more text also be added for the ranges currently described as "Not valid for use as an Element ID"? 

I should add that any information presented in the registry should also be included in or referenced from the IANA Considerations section.

thanks,

Amanda Baber
Lead IANA Services Specialist

On Fri Jan 31 16:21:20 2020, [e-mail] wrote:
> Hi Amanda,
> 
> > On Jan 30, 2020, at 8:16 PM, Amanda Baber via RT <drafts-approval-
> > [e-mail]> wrote:
> >
> > Dear Authors/Chairs,
> >
> > Before we upload the new EBML registries, we have a question about
> > values that aren't mentioned in the document.
> >
> > Most one-, two-, three-, four-, and five-octet values have their
> > meaning specified in the IANA Considerations section: assigned,
> > available for assignment (described as "Unassigned" in the registry),
> > Reserved, or "Not valid for use as an Element ID." However, we don't
> > know how to describe these values in the registry:
> 
> Most of these values are "Not valid for use as an Element ID”. In
> https://www.ietf.org/id/draft-ietf-cellar-ebml-17.html#section-5
> <https://www.ietf.org/id/draft-ietf-cellar-ebml-17.html#section-5> is
> a rule for Element IDs that says "The VINT_DATA component of the
> Element ID MUST be encoded at the shortest valid length” but there are
> other reasons within these ranges so I’m noting the reason for each
> value.
> 
> > 0x4001-0x407E
> 
> The range 0x4001-0x407E is invalid as Element ID as they can be
> written more succinctly as 0x81-0xFE.
> 
> > 0x200001-0x203FFE
> 
> 0x200001-0x203FFE is invalid as Element ID as they can be written more
> succinctly as 0x81-0xFE and 0x40FF-0x7FFE.
> 
> > 0x10000001-0x101FFFFE
> 
> 0x10000001-0x101FFFFE is invalid as Element ID as they can be written
> more succinctly as 0x81-0xFE and 0x40FF-0x7FFE and 0x207FFF-0x3FFFFE.
> 
> > 0x0000000000-0x080FFFFFFE
> 
> The range of 0x0000000000-0x080FFFFFFE is more complex.
> - 0x0000000000 is invalid for other reasons as there is no VINT
> Marker. It’s not an Element ID at all.
> - 0x0000000001-0x7FFFFFFFF are invalid as the VINT_WIDTH indicates a
> width greater than the 5 byte width of the value range.
> - 0x0800000000 is invalid as the VINT_DATA of an Element ID can not be
> all zero
> - 0x0800000001-0x80FFFFFFE are not valid as they can be written more
> succinctly as 0x81-0xFE and 0x40FF-0x7FFE and 0x207FFF-0x3FFFFE and
> 0x103FFFFF-0x1FFFFFFE
> 
> > 0x0FFFFFFFFF-0xFFFFFFFFFF
> 
> The 0x0FFFFFFFFF-0xFFFFFFFFFF is easier but different :)
> - 0x0FFFFFFFFF is invalid since "The bits of the VINT_DATA component
> of the Element ID MUST NOT be all 0 values or all 1 values.” (section
> 5)
> - 0x1000000000-0xFFFFFFFFFF are invalid since the length of these
> values is 5 bytes, but the VINT_WIDTH is not equal to 4 null bits.
> 
> > How should we fill in the "Element Name" field for these values? I'm
> > attaching a PDF version of our first draft of the registry so that
> > you can see them in context.
> 
> 
> […]
> 
> I hope this helps. :)
> Kind Regards and thanks for your attention on this,
> 
> Dave Rice