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

[Steve Lhomme <[e-mail]>]

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
>