Re: [Cellar] [Editorial Errata Reported] RFC8794 (7192)

[Chris Smiley <[e-mail]>]

Greetings ADs,

We are unable to verify this erratum that the submitter marked as editorial.  
Please note that we have changed the “Type” of the following errata 
report to “Technical”.  As Stream Approver, please review and set the 
Status and Type accordingly (see the definitions at 
https://www.rfc-editor.org/errata-definitions/).

You may review the report at: 
https://www.rfc-editor.org/errata/eid7192

Please see https://www.rfc-editor.org/how-to-verify/ for further 
information on how to verify errata reports.

Further information on errata can be found at: 
https://www.rfc-editor.org/errata.php.

Thank you.

RFC Editor/cs


> On Oct 30, 2022, at 1:03 AM, RFC Errata System <[e-mail]> wrote:
> 
> The following errata report has been submitted for RFC8794,
> "Extensible Binary Meta Language".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7192
> 
> --------------------------------------
> Type: Editorial
> Reported by: Steve Lhomme <[e-mail]>
> 
> Section: 7.6.
> 
> Original Text
> -------------
>   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.
> 
> 
> Corrected Text
> --------------
>   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
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> 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
>