Re: [Cellar] [IANA #1276199] [Errata Verified] RFC8794 (7189)

[Dave Rice <[e-mail]>]

Hi Amanda,
I’m supporting Steve’s answer. Thank you. 
Dave

> On Jul 29, 2023, at 7:52 AM, Steve Lhomme <[e-mail]> wrote:
> 
> Hello Amanda,
> 
> I wasn’t sure a reply was required, but the changes are correct.
> 
> Thanks a lot!
> 
>> On 29 Jul 2023, at 02:48, Amanda Baber via RT <[e-mail]> wrote:
>> 
>> Hi Steve, Dave,
>> 
>> Resending this confirmation request.
>> 
>> thanks,
>> Amanda
>> 
>>> On Fri Jul 14 01:51:46 2023, amanda.baber wrote:
>>> Hi Steve, Dave, Moritz,
>>> 
>>> We've updated the EBML Element IDs registry to list this errata report
>>> as an additional reference for the registry itself, as the RFC
>>> Required range has been changed from values 0x81-0xFE to 0x80-0xFE.
>>> Can one of you confirm that the following changes have also been
>>> completed correctly?
>>> 
>>> OLD:
>>> 
>>> 0x80    Reserved        [RFC8794]
>>> 0x81-0xBE       Unassigned
>>> 
>>> NEW:
>>> 
>>> 0x80-0xBE       Unassigned
>>> 
>>> OLD:
>>> 
>>> 0x0000-0x3FFF   Not valid for use as an Element ID      [RFC8794]
>>> 0x4000  Reserved        [RFC8794]
>>> 0x4001-0x407E   Not valid for use as an Element ID      [RFC8794]
>>> 
>>> NEW:
>>> 
>>> 0x0000-0x407E   Not valid for use as an Element ID      [RFC8794][RFC
>>> Errata 7189]
>>> 
>>> OLD:
>>> 
>>> 0x000000-0x1FFFFF       Not valid for use as an Element ID
>>> [RFC8794]
>>>      0x200000        Reserved        [RFC8794]
>>> 0x200001-0x203FFE       Not valid for use as an Element ID
>>> [RFC8794]
>>> 
>>> NEW:
>>> 
>>> 0x000000-0x203FFE       Not valid for use as an Element ID
>>> [RFC8794][RFC Errata 7189]
>>> 
>>> OLD:
>>> 
>>> 0x00000000-0x0FFFFFFF   Not valid for use as an Element ID
>>> [RFC8794]
>>>      0x10000000      Reserved        [RFC8794]
>>> 0x10000001-0x101FFFFE   Not valid for use as an Element ID
>>> [RFC8794]
>>> 
>>> NEW:
>>> 
>>> 0x00000000-0x101FFFFE   Not valid for use as an Element ID
>>> [RFC8794][RFC Errata 7189]
>>> 
>>> Please see
>>> https://www.iana.org/assignments/ebml
>>> 
>>> Best regards,
>>> 
>>> Amanda Baber
>>> IANA Operations Manager
>>> 
>>> On Mon Jul 10 00:35:37 2023, [e-mail] wrote:
>>>> The following errata report has been verified for RFC8794,
>>>> "Extensible Binary Meta Language".
>>>> 
>>>> --------------------------------------
>>>> You may review the report below and at:
>>>> https://www.rfc-editor.org/errata/eid7189
>>>> 
>>>> --------------------------------------
>>>> Status: Verified
>>>> Type: Technical
>>>> 
>>>> Reported by: Steve Lhomme <[e-mail]>
>>>> Date Reported: 2022-10-30
>>>> Verified by: Murray Kucherawy (IESG)
>>>> 
>>>> Section: 17.1.
>>>> 
>>>> Original Text
>>>> -------------
>>>> One-octet Element IDs MUST be between 0x81 and 0xFE.  These items are
>>>> valuable because they are short, and they need to be used for
>>>> commonly repeated elements.  Element IDs are to be allocated within
>>>> this range according to the "RFC Required" policy [RFC8126].
>>>> 
>>>> The following one-octet Element IDs are RESERVED: 0xFF and 0x80.
>>>> 
>>>> Values in the one-octet range of 0x00 to 0x7F are not valid for use
>>>> as an Element ID.
>>>> 
>>>> Two-octet Element IDs MUST be between 0x407F and 0x7FFE.  Element IDs
>>>> are to be allocated within this range according to the "Specification
>>>> Required" policy [RFC8126].
>>>> 
>>>> The following two-octet Element IDs are RESERVED: 0x7FFF and 0x4000.
>>>> 
>>>> Values in the two-octet ranges of 0x0000 to 0x3FFF and 0x8000 to
>>>> 0xFFFF are not valid for use as an Element ID.
>>>> 
>>>> Three-octet Element IDs MUST be between 0x203FFF and 0x3FFFFE.
>>>> Element IDs are to be allocated within this range according to the
>>>> "First Come First Served" policy [RFC8126].
>>>> 
>>>> The following three-octet Element IDs are RESERVED: 0x3FFFFF and
>>>> 0x200000.
>>>> 
>>>> Values in the three-octet ranges of 0x000000 to 0x1FFFFF and 0x400000
>>>> to 0xFFFFFF are not valid for use as an Element ID.
>>>> 
>>>> Four-octet Element IDs MUST be between 0x101FFFFF and 0x1FFFFFFE.
>>>> Four-octet Element IDs are somewhat special in that they are useful
>>>> for resynchronizing to major structures in the event of data
>>>> corruption or loss.  As such, four-octet Element IDs are split into
>>>> two categories.  Four-octet Element IDs whose lower three octets (as
>>>> encoded) would make printable 7-bit ASCII values (0x20 to 0x7E,
>>>> inclusive) MUST be allocated by the "Specification Required" policy.
>>>> Sequential allocation of values is not required: specifications
>>>> SHOULD include a specific request and are encouraged to do early
>>>> allocations.
>>>> 
>>>> To be clear about the above category: four-octet Element IDs always
>>>> start with hex 0x10 to 0x1F, and that octet may be chosen so that the
>>>> entire VINT has some desirable property, such as a specific CRC.  The
>>>> other three octets, when ALL having values between 0x20 (32, ASCII
>>>> Space) and 0x7E (126, ASCII "~"), fall into this category.
>>>> 
>>>> Other four-octet Element IDs may be allocated by the "First Come
>>>> First Served" policy.
>>>> 
>>>> The following four-octet Element IDs are RESERVED: 0x1FFFFFFF and
>>>> 0x10000000.
>>>> 
>>>> Values in the four-octet ranges of 0x00000000 to 0x0FFFFFFF and
>>>> 0x20000000 to 0xFFFFFFFF are not valid for use as an Element ID.
>>>> 
>>>> 
>>>> 
>>>> Corrected Text
>>>> --------------
>>>> One-octet Element IDs MUST be between 0x80 and 0xFE.  These items are
>>>> valuable because they are short, and they need to be used for
>>>> commonly repeated elements.  Element IDs are to be allocated within
>>>> this range according to the "RFC Required" policy [RFC8126].
>>>> 
>>>> The following one-octet Element ID is RESERVED: 0xFF.
>>>> 
>>>> Values in the one-octet range of 0x00 to 0x7F are not valid for use
>>>> as an Element ID.
>>>> 
>>>> Two-octet Element IDs MUST be between 0x407F and 0x7FFE.  Element IDs
>>>> are to be allocated within this range according to the "Specification
>>>> Required" policy [RFC8126].
>>>> 
>>>> The following two-octet Element ID is RESERVED: 0x7FFF.
>>>> 
>>>> Values in the two-octet ranges of 0x0000 to 0x4000 and 0x8000 to
>>>> 0xFFFF are not valid for use as an Element ID.
>>>> 
>>>> Three-octet Element IDs MUST be between 0x203FFF and 0x3FFFFE.
>>>> Element IDs are to be allocated within this range according to the
>>>> "First Come First Served" policy [RFC8126].
>>>> 
>>>> The following three-octet Element ID is RESERVED: 0x3FFFFF.
>>>> 
>>>> Values in the three-octet ranges of 0x000000 to 0x200000 and 0x400000
>>>> to 0xFFFFFF are not valid for use as an Element ID.
>>>> 
>>>> Four-octet Element IDs MUST be between 0x101FFFFF and 0x1FFFFFFE.
>>>> Four-octet Element IDs are somewhat special in that they are useful
>>>> for resynchronizing to major structures in the event of data
>>>> corruption or loss.  As such, four-octet Element IDs are split into
>>>> two categories.  Four-octet Element IDs whose lower three octets (as
>>>> encoded) would make printable 7-bit ASCII values (0x20 to 0x7E,
>>>> inclusive) MUST be allocated by the "Specification Required" policy.
>>>> Sequential allocation of values is not required: specifications
>>>> SHOULD include a specific request and are encouraged to do early
>>>> allocations.
>>>> 
>>>> To be clear about the above category: four-octet Element IDs always
>>>> start with hex 0x10 to 0x1F, and that octet may be chosen so that the
>>>> entire VINT has some desirable property, such as a specific CRC.  The
>>>> other three octets, when ALL having values between 0x20 (32, ASCII
>>>> Space) and 0x7E (126, ASCII "~"), fall into this category.
>>>> 
>>>> Other four-octet Element IDs may be allocated by the "First Come
>>>> First Served" policy.
>>>> 
>>>> The following four-octet Element ID is RESERVED: 0x1FFFFFFF.
>>>> 
>>>> Values in the four-octet ranges of 0x00000000 to 0x10000000 and
>>>> 0x20000000 to 0xFFFFFFFF are not valid for use as an Element ID.
>>>> 
>>>> 
>>>> Notes
>>>> -----
>>>> Allow 0x80 EBML ID (and similar) since it's used in Matroska.
>>>> 
>>>> This changes the rules for the IANA registry.
>>>> 
>>>> See https://github.com/ietf-wg-cellar/ebml-specification/pull/408
>>>> 
>>>> --------------------------------------
>>>> RFC8794 (draft-ietf-cellar-ebml-17)
>>>> --------------------------------------
>>>> Title               : Extensible Binary Meta Language
>>>> Publication Date    : July 2020
>>>> Author(s)           : S. Lhomme, D. Rice, M. Bunkus
>>>> Category            : PROPOSED STANDARD
>>>> Source              : Codec Encoding for LossLess Archiving and
>>>> Realtime transmission
>>>> Area                : Applications and Real-Time
>>>> Stream              : IETF
>>>> Verifying Party     : IESG
>> 
>