RFC Errata
Found 9 records.
Status: Verified (1)
RFC 8794, "Extensible Binary Meta Language", July 2020
Note: This RFC has been updated by RFC 9559
Source of RFC: cellar (art)
Errata ID: 7189
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Steve Lhomme
Date Reported: 2022-10-30
Verifier Name: Murray Kucherawy
Date Verified: 2023-07-10
Section 17.1. says:
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.
It should say:
One-octet Element IDs MUST be allocated in the range 0x80 - 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 - 0x7F are not valid for use as Element IDs. Two-octet Element IDs MUST be allocated in the range 0x407F - 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 0x0100 - 0x407E and 0x8000 - 0xFFFF are not valid for use as Element IDs. Three-octet Element IDs MUST be allocated in the range 0x203FFF - 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 0x010000 - 0x203FFE and 0x400000 - 0xFFFFFF are not valid for use as Element IDs. Four-octet Element IDs MUST be allocated in the range 0x101FFFFF - 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 0x01000000 - 0x101FFFFE and 0x20000000 - 0xFFFFFFFF are not valid for use as Element IDs.
Notes:
This erratum corrects values in this text.
Status: Reported (7)
RFC 8794, "Extensible Binary Meta Language", July 2020
Note: This RFC has been updated by RFC 9559
Source of RFC: cellar (art)
Errata ID: 7185
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Steve Lhomme
Date Reported: 2022-10-30
Section 11.1.16 says:
<xs:attribute name="maxOccurs" default="1"> <xs:simpleType> <xs:restriction base="xs:integer"> <xs:minInclusive value="0"/> </xs:restriction> </xs:simpleType> </xs:attribute>
It should say:
<xs:attribute name="maxOccurs" default="unbounded"> <xs:simpleType> <xs:union> <xs:simpleType> <xs:restriction base="xs:integer"> <xs:minInclusive value="0"/> </xs:restriction> </xs:simpleType> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="unbounded"/> </xs:restriction> </xs:simpleType> </xs:union> </xs:simpleType> </xs:attribute>
Notes:
maxOccurs doesn't have a defined default value and has no upper bound.
See https://github.com/ietf-wg-cellar/ebml-specification/issues/395
Errata ID: 7187
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Steve Lhomme
Date Reported: 2022-10-30
Section 15.1. says:
Non-mandatory EBML Elements can be added in a new EBMLDocTypeVersion. Since they are not mandatory, they won't be found in older versions of the EBMLDocTypeVersion, just as they might not be found in newer versions. This causes no compatibility issue.
It should say:
Non-mandatory EBML Elements can be added in a new DocTypeVersion. Since they are not mandatory, they won't be found in older versions of the DocTypeVersion, just as they might not be found in newer versions. This causes no compatibility issue.
Notes:
Use DocTypeVersion in the text rather than EBMLDocTypeVersion for more consistency.
See https://github.com/ietf-wg-cellar/ebml-specification/pull/405
Errata ID: 7190
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Steve Lhomme
Date Reported: 2022-10-30
Section 11.1.6.2. says:
EBMLAtomName = ALPHA / DIGIT 0*EBMLNameChar
It should say:
EBMLAtomName = (ALPHA / DIGIT) 0*EBMLNameChar
Notes:
Fix grouping in the EBMLAtomName
See https://github.com/ietf-wg-cellar/ebml-specification/pull/418
Errata ID: 7192
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Steve Lhomme
Date Reported: 2022-10-30
Section 7.6. says:
The Date Element stores an integer in the same format as the Signed Integer Element that expresses a point in time referenced in nanoseconds from the precise beginning of the third millennium of the Gregorian Calendar in Coordinated Universal Time (also known as 2001-01-01T00:00:00.000000000 UTC). This provides a possible expression of time from 1708-09-11T00:12:44.854775808 UTC to 2293-04-11T11:47:16.854775807 UTC.
It should say:
The Date Element stores an integer in the same format as the Signed Integer Element that expresses a point in time referenced in nanoseconds from the precise beginning of the third millennium of the Gregorian Calendar in Coordinated Universal Time (also known as 2001-01-01T00:00:00.000000000 UTC). This provides a possible expression of time from September 1708 to April 2293. The integer stored represents the number of nanoseconds between the date to express and 2001-01-01T00:00:00.000000000 UTC, not counting leap seconds. That is 86,400,000,000,000 nanoseconds for each day. Conversions from other date systems should ensure leap seconds are not counted in EBML values. The 2001-01-01T00:00:00.000000000 UTC date also corresponds to 978307200 seconds in Unix time [POSIX].
Notes:
Add some notice about leap seconds not being counted as in POSIX. Remove bogus nanosecond values.
See https://github.com/ietf-wg-cellar/ebml-specification/pull/415
Errata ID: 7186
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Steve Lhomme
Date Reported: 2022-10-30
Section 10.2. says:
The version of the EBML Body is found in EBMLDocTypeVersion. A parser for the particular DocType format can read the EBML Document if it can read either the EBMLDocTypeVersion version of that format or a version equal or higher than the one found in EBMLDocTypeReadVersion.
It should say:
The version of the EBML Body is found in DocTypeVersion. A parser for the particular DocType format can read the EBML Document if it can read either the DocTypeVersion version of that format or a version equal or higher than the one found in DocTypeReadVersion.
Notes:
Use DocTypeVersion in the text rather than EBMLDocTypeVersion for more consistency.
See https://github.com/ietf-wg-cellar/ebml-specification/pull/405
Errata ID: 7188
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Steve Lhomme
Date Reported: 2022-10-30
Section 15.2. says:
EBML Elements MAY be marked as deprecated in a new EBMLDocTypeVersion using the "maxver" attribute of the EBML Schema. If such an Element is found in an EBML Document with a newer version of the EBMLDocTypeVersion, it SHOULD be discarded.
It should say:
EBML Elements MAY be marked as deprecated in a new DocTypeVersion using the "maxver" attribute of the EBML Schema. If such an Element is found in an EBML Document with a newer version of the DocTypeVersion, it SHOULD be discarded.
Notes:
Use DocTypeVersion in the text rather than EBMLDocTypeVersion for more consistency.
See https://github.com/ietf-wg-cellar/ebml-specification/pull/405
Errata ID: 7193
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Steve Lhomme
Date Reported: 2022-10-30
Section 19. says:
[Matroska] Lhomme, S., Bunkus, M., and D. Rice, "Matroska Media Container Format Specifications", Work in Progress, Internet-Draft, draft-ietf-cellar-matroska-05, 17 April 2020, <https://tools.ietf.org/html/draft-ietf-cellar- matroska-05>.
It should say:
[Matroska] Lhomme, S., Bunkus, M., and D. Rice, "Matroska Media Container Format Specifications", Work in Progress, Internet-Draft, draft-ietf-cellar-matroska-05, 17 April 2020, <https://tools.ietf.org/html/draft-ietf-cellar- matroska-05>. [POSIX] IEEE and The Open Group, "Portable Operating System Interface (POSIX(R)) Base Specifications, Issue 7", DOI 10.1109/IEEESTD.2018.8277153, 31 January 2018, <https://standards.ieee.org/standard/1003_1-2017.html>.
Notes:
Added a reference to POSIX for the new nanosecond explanation.
See https://github.com/ietf-wg-cellar/ebml-specification/pull/415
Status: Held for Document Update (1)
RFC 8794, "Extensible Binary Meta Language", July 2020
Note: This RFC has been updated by RFC 9559
Source of RFC: cellar (art)
Errata ID: 7191
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Steve Lhomme
Date Reported: 2022-10-30
Held for Document Update by: Murray Kucherawy
Date Held: 2024-02-29
Section 5. says:
+=========================+================+=================+ | Element ID Octet Length | Range of Valid | Number of Valid | | | Element IDs | Element IDs | +=========================+================+=================+ | 1 | 0x81 - 0xFE | 126 | +-------------------------+----------------+-----------------+
It should say:
+=========================+================+=================+ | Element ID Octet Length | Range of Valid | Number of Valid | | | Element IDs | Element IDs | +=========================+================+=================+ | 1 | 0x80 - 0xFE | 127 | +-------------------------+----------------+-----------------+
Notes:
0x80 is allowed in Matroska so in EBML as well.
See https://github.com/ietf-wg-cellar/ebml-specification/pull/414