RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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

Report New Errata



Advanced Search