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

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

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