[Cellar] [Errata Verified] RFC8794 (7189)

[RFC Errata System <[e-mail]>]

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