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

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

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