IETF Logo Mail Archive

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

RFC Errata System <rfc-editor@rfc-editor.org> Sun, 30 October 2022 08:03 UTC

Return-Path: <wwwrun@rfcpa.amsl.com>
X-Original-To: cellar@ietfa.amsl.com
Delivered-To: cellar@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6DCC14F607 for <cellar@ietfa.amsl.com>; Sun, 30 Oct 2022 01:03:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.659
X-Spam-Level:
X-Spam-Status: No, score=-6.659 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgvfRrGWVnIr for <cellar@ietfa.amsl.com>; Sun, 30 Oct 2022 01:03:07 -0700 (PDT)
Received: from rfcpa.amsl.com (rfc-editor.org [50.223.129.200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 877A2C14F72C for <cellar@ietf.org>; Sun, 30 Oct 2022 01:03:07 -0700 (PDT)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id 5A18FF650; Sun, 30 Oct 2022 01:03:07 -0700 (PDT)
To: rfc-editor@rfc-editor.org
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: slhomme@matroska.org, slhomme@matroska.org, dave@dericed.com, moritz@bunkus.org, cellar@ietf.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20221030080307.5A18FF650@rfcpa.amsl.com>
Date: Sun, 30 Oct 2022 01:03:07 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/9Yb27E2GpbTetSvU5Qn_vjXeg04>
Subject: [Cellar] [Editorial Errata Reported] RFC8794 (7192)
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Codec Encoding for LossLess Archiving and Realtime transmission <cellar.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cellar>, <mailto:cellar-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cellar/>
List-Post: <mailto:cellar@ietf.org>
List-Help: <mailto:cellar-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cellar>, <mailto:cellar-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 30 Oct 2022 08:03:12 -0000

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 <slhomme@matroska.org>

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

v2.23.0 | Report a Bug | By Email