From nobody Wed Feb 6 06:38:22 2019 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 886201200D7; Wed, 6 Feb 2019 06:38:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <154946389949.31111.9989731892518200541@ietfa.amsl.com> Date: Wed, 06 Feb 2019 06:38:19 -0800 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-ffv1-07.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 14:38:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Codec Encoding for LossLess Archiving and Realtime transmission WG of the IETF. Title : FFV1 Video Coding Format Version 0, 1, and 3 Authors : Michael Niedermayer Dave Rice Jerome Martinez Filename : draft-ietf-cellar-ffv1-07.txt Pages : 46 Date : 2019-02-06 Abstract: This document defines FFV1, a lossless intra-frame video encoding format. FFV1 is designed to efficiently compress video data in a variety of pixel formats. Compared to uncompressed video, FFV1 offers storage compression, frame fixity, and self-description, which makes FFV1 useful as a preservation or intermediate video format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cellar-ffv1-07 https://datatracker.ietf.org/doc/html/draft-ietf-cellar-ffv1-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ffv1-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 6 06:38:37 2019 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F028124BE5; Wed, 6 Feb 2019 06:38:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <154946389959.31128.10886139086327321305@ietfa.amsl.com> Date: Wed, 06 Feb 2019 06:38:19 -0800 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-ffv1-v4-04.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 14:38:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Codec Encoding for LossLess Archiving and Realtime transmission WG of the IETF. Title : FFV1 Video Coding Format Version 4 Authors : Michael Niedermayer Dave Rice Jerome Martinez Filename : draft-ietf-cellar-ffv1-v4-04.txt Pages : 47 Date : 2019-02-06 Abstract: This document defines FFV1, a lossless intra-frame video encoding format. FFV1 is designed to efficiently compress video data in a variety of pixel formats. Compared to uncompressed video, FFV1 offers storage compression, frame fixity, and self-description, which makes FFV1 useful as a preservation or intermediate video format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1-v4/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cellar-ffv1-v4-04 https://datatracker.ietf.org/doc/html/draft-ietf-cellar-ffv1-v4-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ffv1-v4-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 7 12:04:38 2019 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8F712F18C; Thu, 7 Feb 2019 12:04:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154956987624.5345.14422380318312920742@ietfa.amsl.com> Date: Thu, 07 Feb 2019 12:04:36 -0800 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2019-04-02 CHANGED X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 20:04:36 -0000 MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) Working Group will hold a virtual interim meeting on 2019-04-02 from 16:00 to 17:00 America/Toronto. Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=me21026faa14be85507cdef66b860014e mtg number: 313 505 170 From nobody Sat Feb 9 03:34:27 2019 Return-Path: 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 05FFC126F72 for ; Sat, 9 Feb 2019 03:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bunkus.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRs-CDxUd2OI for ; Sat, 9 Feb 2019 03:34:22 -0800 (PST) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3D7712D829 for ; Sat, 9 Feb 2019 03:34:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bunkus.org; s=mail2018100901; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=lvsmf/Ktwhfzfb9YvxhGd27C3ahxLZV3NLtI75bXwtc=; b=Dc4VwY1ahzyMDNevcfIcret9Oj+rX1nWLftm58hkzEDfITk6bVrwonhRsdMoGPuH0KYaXK231W+9l77pWNm4zcbHfPJgmJXVQmve8OgaS0Gs3TL0e3bNjj/KxLGGFWZlKIXhJTAz2/WZy/EAeOIkOr0YD98YWfCE6JAfgCCUhXk=; Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:47708) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1gsQth-0006L2-1F; Sat, 09 Feb 2019 12:34:15 +0100 Received: from sweet-chili.local (unknown [10.55.5.2]) by liselle.bunkus.org (Postfix) with ESMTPS id 8B246654001C; Sat, 9 Feb 2019 12:34:07 +0100 (CET) Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.local (Postfix) with ESMTP id 1D00D595C96B; Sat, 9 Feb 2019 12:34:07 +0100 (CET) X-CTCH-RefID: str=0001.0A0B0206.5C5EBAB7.0042, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 User-agent: mu4e 1.0; emacs 26.1 From: Moritz Bunkus To: help Questions , Cellar list Date: Sat, 09 Feb 2019 12:34:06 +0100 Message-ID: <87lg2ptcup.fsf@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Cellar] MKVToolNix v31.0.0 released X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2019 11:34:25 -0000 Hey, I've just released MKVToolNix v31.0.0 which fixes a couple of issues, especially drag & drop support in combination with Qt 5.12 and newer. Note that the addition of flushing cached data on closing files introduced in v30 has been reverted to do detrimental behavior; an additional command line option has been added to make mkvmerge flush its buffers for those who need it. Nothing has changed for package managers since v30.1.0. Here are the usual links: =E2=80=A6to the source code: https://mkvtoolnix.download/source.html =E2=80=A6to the binaries: https://mkvtoolnix.download/downloads.html The Windows and macOS binaries as well as the Linux AppImage are available already. The other Linux binaries are still being built and will be available of the course of the next couple of hours. Here are the NEWS since the previous release: ------------------------------------------------------------ # Version 31.0.0 "Dolores In A Shoestand" 2019-02-09 ## New features and enhancements * all programs: added a new option `--abort-on-warnings` that will cause the program to abort after it has emitted the first warning, similar to how it aborts after the first error. Implements #2493. * mkvmerge, mkvextract: when closing files that were opened for writing, cached data will not be flushed to storage automatically anymore. This reverts the workaround implemented for #2469. A new option was added to b= oth programs (`--flush-on-close`) that re-enables flushing for people who are affected by data loss such as described in #2469. The reason is that automatic flushing causes long delays in processing queues when the output by mkvmerge/mkvextract isn't the final product but just an intermediate result to be processed further. Implements #2480. * MKVToolNix GUI: multiplexer: the dialog previewing different character se= ts for text subtitles will now keep the position of the displayed text when switching between character sets. Implements #2489. ## Bug fixes * mkvmerge: AVI reader: using DV type 1 AVIs will now result in an unsuppor= ted file type being reported (as the underlying AVI library doesn't support them) instead of crashing mkvmerge. Fixes #2491. * mkvmerge: HEVC: the height of interlaced streams will now be set correctly to the height of the full frame instead of the height of a single interla= ced field. Fixes #2446. * mkvmerge: MP4 reader: edit lists consisting solely of elements that mkvme= rge doesn't support (such as dwells) are simply ignored. Before no data was r= ead for such tracks at all. Fixes #2487. * mkvmerge: text subtitles: entries with an explicit duration of 0ms will n= ow be handled correctly: the 0ms duration will be stored in Matroska instead= of the difference between the current and the following entry. Fixes #2490. * MKVToolNix GUI: multiplexer, chapter editor: fixed drag & drop handling w= ith Qt 5.12.0 and newer. Fixes #2472. * MKVToolNix GUI: multiplexer: the GUI did not clean up temporary files created when running `mkvmerge`. Fixes #2499. ## Build system changes * Qt 5.4.0 or newer has required (up from 5.3.0) since version 30.0.0; I ju= st forgot to include this entry. ------------------------------------------------------------ Have fun :) mosu From nobody Mon Feb 11 00:46:57 2019 Return-Path: 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 58825130E11; Mon, 11 Feb 2019 00:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=smyslov.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2G2lWVViJZo; Mon, 11 Feb 2019 00:46:48 -0800 (PST) Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92F69128AFB; Mon, 11 Feb 2019 00:46:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :Date:Subject:Cc:To:From:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=JtwQQzqP5qicuBL6htnBwqRcA2AMT/F/sK75hS1mdqc=; b=RikmaSCuN0ngLr82dV6wR8UWDP +d5g76DFNfK20/Whd7BQ3Yx7QdpLNQSIGCcH/3WXuZCrjHXkBxC9KTGUwKSAErsAoskEHbwanG/ff 0ra49aXq8G8DFSmYV/hJWa28yX1PeE43ECpBfMTJLrT4uNecoN6MXKJCwE0TFIfB4PS+ycaSQtu1W Z5KkglBJBEXHsoGHJbvrrt3uLtZXYsSwu6SNjGsnGG07lq46Ouu2op+10nBUI4VdVEA8alMrn6IkB xETpr7pmFNCu1RelcciyXnnOpeWQikqUtOxYVs7jAfqpgtWzY+wW2e1852ptzltGTuCqiMrPWUqaJ J0kJNp7A==; Received: from [82.138.51.4] (port=62884 helo=buildpc) by direct.host-care.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.91) (envelope-from ) id 1gt7Ek-0006KR-25; Mon, 11 Feb 2019 03:46:46 -0500 From: "Valery Smyslov" To: Cc: , , Date: Mon, 11 Feb 2019 11:46:43 +0300 Message-ID: <01b601d4c1e6$525c3340$f71499c0$@smyslov.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdTBKMjRCa04fHCsTzSnxP+tbMt+Jg== Content-Language: ru X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - direct.host-care.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smyslov.net X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: [Cellar] Secdir last call review of draft-ietf-cellar-ebml-09 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 08:46:49 -0000 Reviewer: Valery Smyslov Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The draft describes an Extensible Binary Meta Language (EBML) format as a generalized file format for any type of data. As such the EBML itself doesn't include any mechanisms providing security services, besides marginal integrity check via crc32, that is optional and limited in use. The EBML relies on external mechanisms that would provide security services. The Security Considerations section describes various issues related to security that the EBML implementations should consider even in the presence of external cryptographic protection. The list of issues seems to be quite exhaustive for the EBML. Comment not related to security: Section 2: BCP14 and RFC2119 are essentially the same document, I see no reason why they are referenced as different entities in a single sentence. From nobody Wed Feb 13 09:12:15 2019 Return-Path: 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 66F18129532 for ; Wed, 13 Feb 2019 09:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.653 X-Spam-Level: X-Spam-Status: No, score=-0.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZ_rN_1TVDI1 for ; Wed, 13 Feb 2019 09:12:11 -0800 (PST) Received: from mail-ed1-x543.google.com (mail-ed1-x543.google.com [IPv6:2a00:1450:4864:20::543]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF4F9128D52 for ; Wed, 13 Feb 2019 09:12:10 -0800 (PST) Received: by mail-ed1-x543.google.com with SMTP id f9so2573995eds.10 for ; Wed, 13 Feb 2019 09:12:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=to:from:subject:message-id:date:mime-version :content-transfer-encoding; bh=pUgEO6q7GtV25r35e7n9n4gHaba3k1JBFUN6aDAgYzI=; b=uZCwfTKduwhzCUfCSmyIuMVgp9ELRopYfZCwwYAf36YCRKLUE841ukWwMuC2rGRIBf PJsb9ahfg6xEbK4Q7L/2n8gBI7bZQo1qHwH598CLS348kIuwaCAU+uTEq9H9ZJ7QoAIl 3CMT77PhTVZY5sRKuRQEyVbvPAtweOAh6Nfgt4PPekpJlDSZh5wCkAfwnV0wYMlUKhPJ dcke0QhQleC659Pfoghz7MkN9QfQbmZLYeaAZRVl1CITu0ZCGE5Mw/Jb4GkvvFQ5CUtM 3jHCBv8MMXgZzhrTiBYYyqYkLQrEIMn7W4yO5mj2DRTaZb1xM8IsiUIbFAQFYpGiI30v c+Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:mime-version :content-transfer-encoding; bh=pUgEO6q7GtV25r35e7n9n4gHaba3k1JBFUN6aDAgYzI=; b=lVljq0jtO7fdfGSujcrQLiLzjHrVU/32P9IhivIBYZZccdceuk6o+EGkb0oB739gof zuklgkLHSaEJ+ZhEX4wiD8QLqMeSrr4q94VNYYmOcMNFiwNVWJ7Nvj8Fk7PkSXf1GPBt 2jkm5QVPrAc7plhgUEqnsTbwnoBhDxShvpH3CCjKjA3+DZaqXFQWFLgJqaQhJJTa+qRe TFivtdlzuptQ1o03dZy+nyP3jf49bm4bx35em7F3JxFWO5kSgGoW44lcYBthOw/K2uLQ TE4srRiW/Zij40+CMDAOXIJcxntU4Bu5w6ZNhjXyehQF/3EZRe5P+0mhtNoQqy4HBv+5 hkdw== X-Gm-Message-State: AHQUAuaSrwP8WeW9x2GzXHio6jEEkUt8eE2XyQUB7caVTORvyf7w6sh8 hNswpsgpsya/R640GcfJ6ffQqDuq X-Google-Smtp-Source: AHgI3IaxwtFt9tvoWCzM0FOKuir4jtBu4b4JJl69oZzVVjjR+qnnoksqt6Qigj0H90Lg+0pXVMY/Pg== X-Received: by 2002:a50:e797:: with SMTP id b23mr1160333edn.265.1550077928881; Wed, 13 Feb 2019 09:12:08 -0800 (PST) Received: from [127.0.0.1] ([195.189.96.147]) by smtp.googlemail.com with ESMTPSA id n60sm388089edc.90.2019.02.13.09.12.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Feb 2019 09:12:08 -0800 (PST) To: Codec Encoding for LossLess Archiving and Realtime transmission From: Andreas Rheinhardt Message-ID: <179177e3-86f8-1007-7af3-a261ae0be1e8@googlemail.com> Date: Wed, 13 Feb 2019 17:11:00 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Cellar] My review of the EBML-specifications X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 17:12:13 -0000 Hello, I know that I am late to the party and I am sorry for that, but better late than never. Those of you who follow the github repositories will already know of the issues I raised there; here is a summary for those who don't: 1. The EBML specs currently include a requirement that all VINT in the EBML Header may not exceed four bytes in length. This is a sensible requirement, but it unfortunately invalidates every Matroska and Webm file ever produced by libavformat/ffmpeg: The length of the EBML element is always coded on eight bytes. This PR is about this: https://github.com/Matroska-Org/ebml-specification/pull/219 2. Inspired by Matroska PR #278 (https://github.com/Matroska-Org/matroska-specification/pull/278) which intends to allow readers to infer the existence of mandatory elements with default values that exist in Matroska, but not in Webm I asked what happens when a new version of the same DocType has a new mandatory element with default value that is missing in an older version of the same EBML Schema that a file conforms to. MAY, SHOULD, MUST or MUST NOT the reader infer the existence of this element? See this issue: https://github.com/Matroska-Org/ebml-specification/issues/221 3. The current proposal for the EBML Element ID Registry does IMO not really include safeguards against allocating an element that is already in use. I.e. one could register a three byte Element ID that is already in use in Matroska (or any existing project), so that an EBML reader for Matroska would know two different elements with the same ID, one element only being permissible in the EBML Header and the other only permissible in the EBML Document. Not good. Here is my take on this: https://github.com/Matroska-Org/ebml-specification/issues/222 4. A few Matroska elements have complex default values. For example, the default value of BlockDuration is the DefaultDuration of the track. So evaluating the default value would mean that the EBML reader knows about the internals of the Block structure although said Block is supposed to be a binary blob for the EBML reader. See https://github.com/Matroska-Org/ebml-specification/issues/224 for more. 5. And then there are two little PR: https://github.com/Matroska-Org/ebml-specification/pull/220 and https://github.com/Matroska-Org/ebml-specification/pull/223. Greetings Andreas Rheinhardt From nobody Wed Feb 13 12:25:56 2019 Return-Path: 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 2278F128B01 for ; Wed, 13 Feb 2019 12:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plM4ICTJEhh8 for ; Wed, 13 Feb 2019 12:25:52 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AC65128766 for ; Wed, 13 Feb 2019 12:25:52 -0800 (PST) Received: from unescapeable.local ([47.186.39.7]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x1DKPoQu018668 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 13 Feb 2019 14:25:51 -0600 (CST) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1550089551; bh=BRbYBQUXgsDuJDuaFJZROKsElkk6qNeICnY053+3F64=; h=To:From:Subject:Date; b=bHRobt2UwzZRrvdmxqqLxqHHjP/J2Vk80uSIzvPwg47iSkJIGkXikhB7Sq2TAcNq5 P1kxE8Fu5h4v5QdWZyQ5i9ndvhCs9bJ0+XVIXILu4Z1+kxg6oCwodtAUrLWgBznM1O uk37bogrL8BWBUOUO3oBbtCEGHBOK3ED+lUFz84w= X-Authentication-Warning: raven.nostrum.com: Host [47.186.39.7] claimed to be unescapeable.local To: cellar@ietf.org From: Robert Sparks Message-ID: <7a2b7341-4074-3456-6697-7a22151aa5f5@nostrum.com> Date: Wed, 13 Feb 2019 14:25:50 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------F0021C8851CB7C040CF42DFC" Content-Language: en-US Archived-At: Subject: [Cellar] Early comment from an early review of draft-ietf-cellar-ebml-09 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 20:25:54 -0000 This is a multi-part message in MIME format. --------------F0021C8851CB7C040CF42DFC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I have received a genart early review assignment (disguised as a lc review assignment) for draft-ietf-cellar-ebml-09. I have started reading the draft - it will take some time to absorb it and provide a review. I wanted to get one editorial comment in early: the use of double-quotes to try to bound/emphasize names of things in this document is significantly damaging my ability to read it. They are unnecessary. Please just remove them. "VINT_MARKER" use one out of every eight bits of the total length of the "Variable Size Integer". Thus a "Variable Size Integer" of 1 octet length supplies 7 bits for "VINT_DATA", a 2 octet length supplies 14 bits for "VINT_DATA", and a 3 octet length supplies 21 bits for "VINT_DATA". is much harder to read than VINT_MARKER use one out of every eight bits of the total length of the Variable Size Integer. Thus a Variable Size Integer of 1 octet length supplies 7 bits for VINT_DATA, a 2 octet length supplies 14 bits for VINT_DATA, and a 3 octet length supplies 21 bits for VINT_DATA. In what I've read so far, I haven't found a place where removing the double-quotes would introduce any ambiguity. RjS ps. On a trivia/humor note - this draft is currently 2.73% double-quotes. The average for the entire RFC series is 0.26% double-quotes. --------------F0021C8851CB7C040CF42DFC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

I have received a genart early review assignment (disguised as a lc review assignment) for draft-ietf-cellar-ebml-09.

I have started reading the draft - it will take some time to absorb it and provide a review.

I wanted to get one editorial comment in early: the use of double-quotes to try to bound/emphasize names of things in this document is significantly damaging my ability to read it. They are unnecessary. Please just remove them.

   "VINT_MARKER" use one out of every eight bits of the total length of
   the "Variable Size Integer".  Thus a "Variable Size Integer" of 1
   octet length supplies 7 bits for "VINT_DATA", a 2 octet length
   supplies 14 bits for "VINT_DATA", and a 3 octet length supplies 21
   bits for "VINT_DATA".

is much harder to read than

   VINT_MARKER use one out of every eight bits of the total length of
   the Variable Size Integer.  Thus a Variable Size Integer of 1
   octet length supplies 7 bits for VINT_DATA, a 2 octet length
   supplies 14 bits for VINT_DATA, and a 3 octet length supplies 21
   bits for VINT_DATA.

In what I've read so far, I haven't found a place where removing the double-quotes would introduce any ambiguity.

RjS

ps. On a trivia/humor note - this draft is currently 2.73% double-quotes. The average for the entire RFC series is 0.26% double-quotes.

--------------F0021C8851CB7C040CF42DFC-- From nobody Wed Feb 13 13:15:21 2019 Return-Path: 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 86DC412F18C for ; Wed, 13 Feb 2019 13:15:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGHVusO66aVs for ; Wed, 13 Feb 2019 13:15:18 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E0D91200B3 for ; Wed, 13 Feb 2019 13:15:18 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 824343826A; Wed, 13 Feb 2019 16:12:07 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 078AF2FB7; Wed, 13 Feb 2019 16:15:16 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0629A55A; Wed, 13 Feb 2019 16:15:16 -0500 (EST) From: Michael Richardson To: Andreas Rheinhardt cc: Codec Encoding for LossLess Archiving and Realtime transmission In-Reply-To: <179177e3-86f8-1007-7af3-a261ae0be1e8@googlemail.com> References: <179177e3-86f8-1007-7af3-a261ae0be1e8@googlemail.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cellar] My review of the EBML-specifications X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 21:15:20 -0000 --=-=-= Content-Type: text/plain Thank you for these comments! Andreas Rheinhardt wrote: > 1. The EBML specs currently include a requirement that all VINT in the > EBML Header may not exceed four bytes in length. This is a sensible > requirement, but it unfortunately invalidates every Matroska and Webm > file ever produced by libavformat/ffmpeg: The length of the EBML > element is always coded on eight bytes. This PR is about this: > https://github.com/Matroska-Org/ebml-specification/pull/219 The EBML requirement on VINT size applies to the EBML Header itself, not to the contents of the Doc. It is not clear that it applies to users of EBML such as inside the Matroska component. > 3. The current proposal for the EBML Element ID Registry does IMO not > really include safeguards against allocating an element that is > already in use. I.e. one could register a three byte Element ID that > is already in use in Matroska (or any existing project), so that an > EBML reader for Matroska would know two different elements with the > same ID, one element only being permissible in the EBML Header and the > other only permissible in the EBML Document. Not good. Here is my take > on this: https://github.com/Matroska-Org/ebml-specification/issues/222 The IANA process is that Matroska gets it's own Element ID space, different from WebM, but never conflicting with the registry in the EBML header. So I am not sure I understand your scenario. Can you explain further? > 4. A few Matroska elements have complex default values. For example, > the default value of BlockDuration is the DefaultDuration of the I'm not sure that I understand how this is an EBML issue. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlxkiOMACgkQgItw+93Q 3WVjPgf/UiRuLmPZdKg+hOHT64xOZvzQtUihq0gK1tS30hGKGolip96tgZPXLTIE z/5B1t6p7uqxvgQPFuC927GTEYMCmg+euwyr7VZ6/WIk2x1eisaldd3R5VVTv164 rIKxpoG084+FlR5q8LAEmcd/uJuVTi8QpDZwUpZ97Bhrf3SGc+LyIukU66ptOiPt 3yXnv81+zBfaAun08+pzQnFg/uNdRgFtymTefKdI4hzamAG/VYFcEjKf922WRAFO FirLR/LpzYfV4Z+A2EmJFd9r5vgig6FSiQQSvzp2YiaOxbEcZzsYx2OlifHu7kYQ K9MTGzv0fQyJTsYiRoENexB0APij2w== =bxeC -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 13 16:59:46 2019 Return-Path: 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 1469313108F for ; Wed, 13 Feb 2019 16:59:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNHoDfYEUw-b for ; Wed, 13 Feb 2019 16:59:42 -0800 (PST) Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com [IPv6:2a00:1450:4864:20::541]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57E7D130E2B for ; Wed, 13 Feb 2019 16:59:42 -0800 (PST) Received: by mail-ed1-x541.google.com with SMTP id b20so3587371edw.11 for ; Wed, 13 Feb 2019 16:59:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=subject:to:references:from:message-id:date:mime-version:in-reply-to :content-transfer-encoding; bh=iuMGOFR6umPhbOJ2CrdWZ5dVRkqoWe+UDH0w/SJvfDc=; b=W96KDFxxmEE2EN/CaCoHN5JPena40JTTBG14V7+5BnGu5IbB5PVvxCM3HH1jK9JDW1 4yGkchx1zFRMtanMMIfzrgAcVGD1N2mBQsNK3SHBx6XB5g6/AqfFel8OT1M7RNNkscNO GkvTgl/aOSD84Gm4WNVROxlMdyR9coH0jT5vcry5uPxJH4MpeL67hZqoDB1C+CsWnJub p8xagt7iS5kwutccbvp9gcMi1olF34OizwkPqYKGrlarGPHVgXsnGTNqMBaLJOl13iA2 LNbOuUSc1IauW9K5z+T/jKeZIaKQKaaVj/Ok/akSIs2G22FCIwueNRm65CK1l3voy4xT v9zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :mime-version:in-reply-to:content-transfer-encoding; bh=iuMGOFR6umPhbOJ2CrdWZ5dVRkqoWe+UDH0w/SJvfDc=; b=ff+Km+0x4WltG0fE+ckTlxsv3GAgA5Jeo5r5FtlKc7eAakY7EAuIuRZyfvc5z4ehfj asok02IoKE271ri12SnnCHq9+UrPV93jBhDu5IJLET8Aa2kTbXxMOd4hxHUVGPvmn7Af +Qon0aWQECcgMOew+u4d8K1KB7jM0n5GAaFmsvfTtnFByzC2Ohre27z8/RDlAxcCye5W NFpyzwqQBvxFoLYHCZB0kolHsG+/udMDwlaj1hAv09apMwVLil7nUPek3Q1zG0lzcO6V 3N7MNGV4ADmUW4aicuH+DJTdpqOYgCXtJ/mAg9npUK/okKFrng7BnYylNS4Uou52sIV3 T4Lg== X-Gm-Message-State: AHQUAubPPCEFhOS6q5wtHtCWypdTVYG8syVkXcG+tU3DBMpCufDtpfg5 LkzxMB1SS2ItObP0rVUqSYk+Z0YV X-Google-Smtp-Source: AHgI3IY/uNRHSHPDMSg040hKFgbWGIkcJA817S0wzW2DtKk+IC/jTX4uQT/Oog/5hx6Al0ivIAz4sg== X-Received: by 2002:aa7:c446:: with SMTP id n6mr674465edr.235.1550105980507; Wed, 13 Feb 2019 16:59:40 -0800 (PST) Received: from [127.0.0.1] (exit3.tor-network.net. [31.220.0.225]) by smtp.googlemail.com with ESMTPSA id c5sm244574edm.36.2019.02.13.16.59.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Feb 2019 16:59:39 -0800 (PST) To: cellar@ietf.org References: <179177e3-86f8-1007-7af3-a261ae0be1e8@googlemail.com> <15787.1550092516@localhost> From: Andreas Rheinhardt Message-ID: <99c3da12-280b-cf0a-c71a-c004d98100a4@googlemail.com> Date: Thu, 14 Feb 2019 00:58:00 +0000 MIME-Version: 1.0 In-Reply-To: <15787.1550092516@localhost> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] My review of the EBML-specifications X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 00:59:45 -0000 Hello, Michael Richardson: > > Thank you for these comments! And thanks for your answer! > > Andreas Rheinhardt wrote: > > 1. The EBML specs currently include a requirement that all VINT in the > > EBML Header may not exceed four bytes in length. This is a sensible > > requirement, but it unfortunately invalidates every Matroska and Webm > > file ever produced by libavformat/ffmpeg: The length of the EBML > > element is always coded on eight bytes. This PR is about this: > > https://github.com/Matroska-Org/ebml-specification/pull/219 > > The EBML requirement on VINT size applies to the EBML Header itself, > not to the contents of the Doc. It is not clear that it applies to users of > EBML such as inside the Matroska component. a) You seem to read "every Matroska and Webm file ever produced by libavformat/ffmpeg" as "this affects only the Matroska component (i.e. the EBML Body) of said files". This is not so. libavformat encodes the size of the EBML Element (the element with ID 0x1A45DFA3 that is part of the EBML Header of the Matroska/Webm files produced by libavformat) on eight bytes. The current requirement invalidates such files. Given that the current requirement has been added years after such files were around, it has to be dropped. b) In my opinion the requirements on the VINT size are clear as they are. (It's just that they conflict with past and current practices.) If you believe that the requirements are unclear, then I would like to know what is unclear for you and why. > > > 3. The current proposal for the EBML Element ID Registry does IMO not > > really include safeguards against allocating an element that is > > already in use. I.e. one could register a three byte Element ID that > > is already in use in Matroska (or any existing project), so that an > > EBML reader for Matroska would know two different elements with the > > same ID, one element only being permissible in the EBML Header and the > > other only permissible in the EBML Document. Not good. Here is my take > > on this: https://github.com/Matroska-Org/ebml-specification/issues/222 > > The IANA process is that Matroska gets it's own Element ID space, > different from WebM, but never conflicting with the registry in the > EBML header. > > So I am not sure I understand your scenario. > Can you explain further? Let me summarise the current proposal as I understand it: i) An IANA registry for the EBML elements in the EBML Header is created. ii) The process for registering numbers. This includes a "First come first served" policy for certain ranges like Element IDs with a size of three octets. iii) An IANA Doctype Registry. You claim that the Matroska Element ID space will never conflict with the registry in the EBML Header. I fail to see the safeguards for this. After all, the IANA registry is only about the EBML Header elements, it does not contain the Element IDs used by any given EBML Schema. So how does the IANA know that an application for registration of an ID already in use by a project should be rejected? In order to do so, projects would not only need to register themselves on the Doctype registry, but they would also need to give information (that needs to be kept up-to-date) about their currently used Element IDs to the IANA registration authority. And I don't see any requirement for keeping such lists in the specification and also not a word about a requirement on part of the registration authority to check the lists of Element IDs when processing allocations. (I know that RFC 8126 requires compability with current usage, but as stated I fail to see how the current proposal would enable the IANA to actually check this.) And even if all these lists were existing and were kept-up-to-date at all times, there is still another problem: If usage of EBML becomes widespread with many projects being created, then IDs that are not in use by any project might become scarce (in particular for shorter IDs -- certainly for length 1 IDs and possibly for length 2 IDs), even when all projects only need a fraction of the IDs. My proposal for this is to reserve some IDs for use for future extensions to the EBML Header. No EBML Schema may invade these reserved IDs. Given how valuable IDs with length one are, no such ID should be reserved for this purpose. A few IDs with length two should be reserved as should some length three elements and more length four elements. Registering a shorter ID should of course be subject to stricter scrutinity than registering a longer ID. This proposal adversely affects the possibility of choosing an ID with a nice extra property (like a nice ASCII representation). The reserved ID ranges would of course need to be chosen in such a way as not to conflict with elements already in use by Webm and Matroska. > > > 4. A few Matroska elements have complex default values. For example, > > the default value of BlockDuration is the DefaultDuration of the > > I'm not sure that I understand how this is an EBML issue. The form that the default values can take is currently undefined. Defining (i.e. restricting) it is an EBML issue. Bringing Matroska's specification in line with what we define for EBML won't be an EBML issue, of course, but a Matroska one. It should be clear that evaluating something like the default value of Matroska's BlockDuration is impossible to do at the EBML layer (because then you need to know the internals of the Block structure). But something like "the default value is the value of another element (of the same type) that is a child of the same parent element" is possible (the other element needs to be mandatory for this to work or one uses a secondary default value in case the other element doesn't exist). Of course one can also restrict default values to known constants (constexpr). We need to decide where to draw the line. - Andreas Rheinhardt From nobody Wed Feb 13 17:12:48 2019 Return-Path: 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 C12311279E6 for ; Wed, 13 Feb 2019 17:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Om8G3ynkd4bn for ; Wed, 13 Feb 2019 17:12:44 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55519130DE3 for ; Wed, 13 Feb 2019 17:12:44 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 04E063826A; Wed, 13 Feb 2019 20:09:34 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id BBA3E2FB7; Wed, 13 Feb 2019 20:12:42 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BA5CD55A; Wed, 13 Feb 2019 20:12:42 -0500 (EST) From: Michael Richardson To: Andreas Rheinhardt cc: cellar@ietf.org In-Reply-To: <99c3da12-280b-cf0a-c71a-c004d98100a4@googlemail.com> References: <179177e3-86f8-1007-7af3-a261ae0be1e8@googlemail.com> <15787.1550092516@localhost> <99c3da12-280b-cf0a-c71a-c004d98100a4@googlemail.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cellar] My review of the EBML-specifications X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 01:12:47 -0000 --=-=-= Content-Type: text/plain Andreas Rheinhardt wrote: > Let me summarise the current proposal as I understand it: > i) An IANA registry for the EBML elements in the EBML Header is created. > ii) The process for registering numbers. This includes a "First come > first served" policy for certain ranges like Element IDs with a size > of three octets. > iii) An IANA Doctype Registry. iv) the Matroska document will create a new IANA Registry for Element IDs in use by Matroska v) The *Matroska document* will populate the EBML Element ID registry with a list of ElementIDs RESERVED. No *EBML* Element ID may be created with the same number. This is largely as a COURTESY, because in fact the two name spaces are intended to be distinct across header and contents, but it's better if there is no reuse. > And even if all these lists were existing and were kept-up-to-date at > all times, there is still another problem: If usage of EBML becomes > widespread with many projects being created, then IDs that are not in > use by any project might become scarce (in particular for shorter IDs > -- certainly for length 1 IDs and possibly for length 2 IDs), even > when all projects only need a fraction of the IDs. It's possible. > My proposal for this is to reserve some IDs for use for future > extensions to the EBML Header. No EBML Schema may invade these > reserved IDs. That's a reasonable proposal. > Given how valuable IDs with length one are, no such ID should be > reserved for this purpose. A few IDs with length two should be > reserved as should some length three elements and more length four > elements. Registering a shorter ID should of course be subject to > stricter scrutinity than registering a longer ID. We could set the IANA rules all IDs with length two to Specification Required. > This proposal adversely affects the possibility of choosing an ID with > a nice extra property (like a nice ASCII representation). Those are likely 4-byte elements, of which there are many. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlxkwIoACgkQgItw+93Q 3WV/Swf/QcBxZp3sT90rdaB98Dl8riPnY8aAJC/5qKVr883RQRkADZaAs1mlpEpt yHairDGikeFgXTD/qjKAmJLiJhHog/xkvJ5RzL1wJrGO0nooMms11fiUarNwFyHj //HQFF21NiaeJxyUmduD4E8BadOhDGUZ20PRCynsa9L8D+T3BfbRSeQY3kOpN+7V OKqe59mYIDWdUqNBuv1N55Dzt97rq1Uq4zhW5JunFxTLQzL3RKfT+MYKKXZWBiD+ RPeb+xVZYl2u/RKjxgrcZTUqMJLavSfrjgmsMJtz5GR+Nm/4a0LOAiTOZRMPy0h7 Tpp2MNYbVExeumKBqOPrSr4Gm1rNyA== =tNST -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Feb 17 00:03:54 2019 Return-Path: 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 A8ED3127AC2 for ; Sun, 17 Feb 2019 00:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmX6lr630IiW for ; Sun, 17 Feb 2019 00:03:51 -0800 (PST) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEE3A12008F for ; Sun, 17 Feb 2019 00:03:50 -0800 (PST) Received: by mail-pg1-x52d.google.com with SMTP id h11so4565307pgl.0 for ; Sun, 17 Feb 2019 00:03:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=v7biCuukjy/RQjo+eYrw81AvLaTlopyUMh/V3g2PhVU=; b=EKnaGD0DKOsJwG2j587xEs6dJfNOUyOk6ZNwUDLqM73CW4xUaTvPGgITYci+sWyemI oZXJe7wYsam11oP8DUy9VrIkQXOowrJDEsH9Hji1VZw2VjpwtALGJpwhPZbh/IGY4enW 5GkaE3urKgiv/QR5wDhvsulX9eeneHUuDG5pNaSUoW7qwtol2Q/FZpY/AX32tYpBDTcS UdIY07/cvSMIzdHJFgz8ckCIg98hAA/KcRK2K6u7uao2TccyeR7xRX/Wy9oqGNkVaOSJ Z9mI3XdcPMluo9YUIXxtQ5cec9aSbdLRLBp/EgQak4ZXSeoForyw/x0BGpQFqBVhteDv Ml0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=v7biCuukjy/RQjo+eYrw81AvLaTlopyUMh/V3g2PhVU=; b=YgugM8GV+9gUIhZ+Oc+uaaahtIi8aWCdUMPH1qQGc1D2Pk0Z6eBwVNzp+hKKU6nkpi dZMzp7PARtnUYUMuZXVhvc1QUI29EpX7fhaq3YgCmm9AVz97LsCyhaLecl1HhH5skaqM Bqh4medSDgMdeH3g2Rsk46dSyLCaQBzqbzRd+DZMBdOEOVTs1K4FZLDkX2zWU8Od7fiO 2JvM4jvxTUxvtnvOR6wPhEM3thQKmwJbnQP9UF/nIucOr/WV9RzpnZ/vhUuZoVBISM2b fpQa3httja9NGeX2JbUCkQTUMupvF61xEM5UNhBiesUgK+0wFUgovUqMT4dCaOfjeb2N RFMA== X-Gm-Message-State: AHQUAuZLKWxVePUrVZP2Ocd0LbUG/B9pgQ2JtKpMeM9d5999y+Cvh78J S8A3cM8eczJ7ziQCBMRSKVv30zeHdXc3uwE80DDEQg== X-Google-Smtp-Source: AHgI3IY4eb6QbezKetwL8AaABY104sg2nxECejfkVfwhc+AASQ1kna588+48FX8WJllT8/Z5xcZPXRzkETIxftQShR4= X-Received: by 2002:a63:ce0e:: with SMTP id y14mr13381243pgf.145.1550390630083; Sun, 17 Feb 2019 00:03:50 -0800 (PST) MIME-Version: 1.0 From: Steve Lhomme Date: Sun, 17 Feb 2019 09:03:40 +0100 Message-ID: To: hubblec4 , Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Cellar] Interactive Menu - VideoLAN Google Summer of Code X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2019 08:03:53 -0000 Hi everyone, As Videolan (which I'm part of) is preparing this year's Google Summer of Code projects, we added one regarding Matroska and interactive menus (think Netflix/Black Mirror Bandersnatch) https://wiki.videolan.org/SoC_2019/#Interactive_movie_support It involves adding things to the Matroska specification to handle active zones and actions, but not using the (complex) DVD chapter codec. And then adding support in VLC (which already has DVD and BluRay (and DVD in Matroska) support). If any of you know a student who qualifies to apply let her/him know. The technical discussions on Matroska will probably happen here. -- Steve Lhomme Matroska association Chairman From nobody Sun Feb 17 04:00:46 2019 Return-Path: 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 35FB21293B1 for ; Sun, 17 Feb 2019 04:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xq1bE7LSN7XK for ; Sun, 17 Feb 2019 04:00:42 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C700127AC2 for ; Sun, 17 Feb 2019 04:00:40 -0800 (PST) Received: from [192.168.2.109] ([93.243.145.124]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MV6PJ-1gXw9A09Dp-00YOT0; Sun, 17 Feb 2019 13:00:37 +0100 To: Steve Lhomme , Codec Encoding for LossLess Archiving and Realtime transmission References: From: hubblec4 Message-ID: Date: Sun, 17 Feb 2019 13:00:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:GNtmo1kPFkUZJVNpFMOERzd+G3wLK9g5Cu8N0gDO5avBiPv5Wut ixEiiZTPvFg94cKDlnBZqSMxfPCYaBwWr5HbYVepK+btYDILFAxWjUsB/fh9P/a0OGBs6Fj eEMxP8dIZZT+CXWgXKlXHoW+udk0Yj0NB0zfLbZUfbD4pOPyAFH37hs2i2b6s0TfmkIZ6Bt p8rMYH9ZAdSwgk41KAAqA== X-UI-Out-Filterresults: notjunk:1;V03:K0:jmv26gPFsAw=:x8U4uUYd2r5vum6VevhoKZ VoT/0n/WyMXrHsYn4bwm6q03bRgfekdLybPTCUqpCCN/VpA1iAYDuScNwJN5aF5ytMjpuA0k9 arqSUv/J3jEwEk8DaMHCQKn/BgMPB+AelNOkh9gCiDTA6DKIjLYn9wVkDIUtnIHbUbuQdgVkS oAC3Kp76xV0jyzX08Eup6eGeoTbswAq1flvTGfyOlE3i7xwMhewXTdRpX3AI3FEs4h60YS7Up PS3+wl6n47OWhmj5lH7rh+VjLzW2Sqhww5TYHv0YeZAt9qao8eW1ViA6wGjJbGXHl4nm3a2pr +3vW6UXz87msVPD4AZBSDvEe3ooyOg2PftwDjF33AD3uJgsbj15sONrI9Rl63FZw7oKSX7oGx KG2/fw9oZqsfAmkfR2cql2DDma1e6nJDFnpauPcdVknUwF+TmzwpO65P7+SToBfqbVi7jpCxt dJw0LEHATLC/3PoiZTJKGmVThKgZOhHbPwqKy27N3DWbwqWoPryRsCCqrZLM12nG6MF22e5ss L3zrKQnnoAQKlXeJYYqvTDZss1/9JE/5P5iaDW9zUxeCxCduBgzkhBFnKNNZtP5+MneQDgeCV oY6XsK3cNqtii8cHtWOZLl9ffT6qwx8Ilkx4rLI/Ku7Wb4GT3EfKTMHW9j/97GmpLo2ud0iI9 sZn2yla5FKdFL8igroQj4rt3pH7kvBvyyIq5Qs1Ft3iM4gQ7Ep77RW3kG7hoRB9domsxyWRd5 AqD6AB0GKAadCOMUjJDUk35WAZU3QfrdSGxrTNtK3/QPzuUmi3Ci0OWgAm88kbSBdXCE32auB QPninCPwbqSD0grlyFyR61pLnuLjkPH9XAkO4LzUGquB1f621Em/YIKkbh9nDmrK2pNInfXh/ MEiLLmPdcdJ8eO9bt9VQwTl/n12udt5DHv31zVprvkqukYYbGL03NHUwKczuaZfUBknluIbws HN74WpEDAGQ== Archived-At: Subject: Re: [Cellar] Interactive Menu - VideoLAN Google Summer of Code X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2019 12:00:44 -0000 Hi Steve Very interesting news. Am 17.02.2019 um 09:03 schrieb Steve Lhomme: > Hi everyone, > > As Videolan (which I'm part of) is preparing this year's Google Summer > of Code projects, we added one regarding Matroska and interactive > menus (think Netflix/Black Mirror Bandersnatch) > https://wiki.videolan.org/SoC_2019/#Interactive_movie_support > > It involves adding things to the Matroska specification to handle > active zones and actions, but not using the (complex) DVD chapter > codec. And then adding support in VLC (which already has DVD and > BluRay (and DVD in Matroska) support). > > If any of you know a student who qualifies to apply let her/him know. > > The technical discussions on Matroska will probably happen here. > > From nobody Sun Feb 17 06:05:06 2019 Return-Path: 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 3AE49129A85 for ; Sun, 17 Feb 2019 06:05:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGQpnRlAcbYo for ; Sun, 17 Feb 2019 06:05:02 -0800 (PST) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6486D128D0B for ; Sun, 17 Feb 2019 06:05:02 -0800 (PST) Received: by mail-pl1-x636.google.com with SMTP id 101so7403093pld.6 for ; Sun, 17 Feb 2019 06:05:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=n36j5kZJZ1AoFcZ7+/Plua/8nQlY+KzyRqjrot8QJpk=; b=pqMNergOAEkPHvZDoFaA1TZRKiYoiwUIKLsjS7wVlcdyUhU3VIELEuWCgUS3pza+mV 13K++V2CtI7YdVt6FGxw4xPzeRtlZe+PDE+cLS+NcTWl4Co1I2OJCaGcbpCzRLkBnXx+ Vr/sSSRvL5eBqlx+hkI/qq1U/H7AczfSY66tMkk9FmnBwefIgPokcBwazs25Jzbz+oDM pSK7o0XUFv+XaePU7yJ0GRq10gmdvExB0ztz5KtNZ5Be82zUfg6J2SDSA6uToZ99RVsN ffEJi0Sen0RY44JTTBM/E2eL9GSTbd1HcGvpOPX6hFi5LD4GyKwm3CUmh37GziqeUngR bSLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=n36j5kZJZ1AoFcZ7+/Plua/8nQlY+KzyRqjrot8QJpk=; b=kTzQ7SmpVo8ru0AeEsntZGXKkK73fqPfhFnq3zauUJ6IpJF18UOutgzRYxGDeVP1kH L7xxddyvyJcMrQLF3uPZlMroRvq1Yy1JXV5kJ4PZqJOS1ySp32VJaEaLhI2AQbyFdlsF lGg2mxhqmSFhQKYPv5DKcIq1DxyoZ+7vGOzDiFXX4DIXxAfstUd8HJ/O3dZIThuHi5jk J46fXx04NK7ZZt85ZX+CYHoPu4DRifzyzI8UNDZj2yjkUp/mcLi3GWld5gdLPgSsIJ2k z4ocHOTeooY8aVINUFsE7poO1WRWfXTkC5q1z7IhM5+LWXda0EcI+1kd7ne8HLFfdEjn IQrg== X-Gm-Message-State: AHQUAubyIrcPADjrVvdU7L9HaF57FZVvNuVPlihXZSbHC4OMcfArWcN3 Ibm3G9ukYHnwpFVnkHKYh7V/rLc1aeAMnrzVkiBnkzwBUZY= X-Google-Smtp-Source: AHgI3IZUL7nRewfbo0U9JzkBnmCwZdhEEqHVeFHYsnkhG0JXiNPqJo2azj2GiBivZiQa4znK6GHr2p7unELQw1HRH1Q= X-Received: by 2002:a17:902:2be8:: with SMTP id l95mr20410450plb.270.1550412301485; Sun, 17 Feb 2019 06:05:01 -0800 (PST) MIME-Version: 1.0 References: <7a2b7341-4074-3456-6697-7a22151aa5f5@nostrum.com> In-Reply-To: <7a2b7341-4074-3456-6697-7a22151aa5f5@nostrum.com> From: Steve Lhomme Date: Sun, 17 Feb 2019 15:04:52 +0100 Message-ID: To: Robert Sparks Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] Early comment from an early review of draft-ietf-cellar-ebml-09 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2019 14:05:04 -0000 Hello Robert, I agree with this. I think this is because we write the specs in Markdown and then translate to text/HTML. In Markdown we use `` around the names and it just changes the background. It seems when translated to text it's transformed into double quotes. I will investigate if there's a way to change this or either remove the `` altogether. Thanks a lot Le mer. 13 f=C3=A9vr. 2019 =C3=A0 21:25, Robert Sparks a =C3=A9crit : > > I have received a genart early review assignment (disguised as a lc revie= w assignment) for draft-ietf-cellar-ebml-09. > > I have started reading the draft - it will take some time to absorb it an= d provide a review. > > I wanted to get one editorial comment in early: the use of double-quotes = to try to bound/emphasize names of things in this document is significantly= damaging my ability to read it. They are unnecessary. Please just remove t= hem. > > "VINT_MARKER" use one out of every eight bits of the total length of > the "Variable Size Integer". Thus a "Variable Size Integer" of 1 > octet length supplies 7 bits for "VINT_DATA", a 2 octet length > supplies 14 bits for "VINT_DATA", and a 3 octet length supplies 21 > bits for "VINT_DATA". > > is much harder to read than > > VINT_MARKER use one out of every eight bits of the total length of > the Variable Size Integer. Thus a Variable Size Integer of 1 > octet length supplies 7 bits for VINT_DATA, a 2 octet length > supplies 14 bits for VINT_DATA, and a 3 octet length supplies 21 > bits for VINT_DATA. > > In what I've read so far, I haven't found a place where removing the doub= le-quotes would introduce any ambiguity. > > RjS > > ps. On a trivia/humor note - this draft is currently 2.73% double-quotes.= The average for the entire RFC series is 0.26% double-quotes. > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Sun Feb 17 07:47:39 2019 Return-Path: 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 E23E2129A85 for ; Sun, 17 Feb 2019 07:47:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Alo8jsqiHvN for ; Sun, 17 Feb 2019 07:47:36 -0800 (PST) Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C9BA129619 for ; Sun, 17 Feb 2019 07:47:35 -0800 (PST) Received: by mail-pf1-x442.google.com with SMTP id v21so4270172pfm.12 for ; Sun, 17 Feb 2019 07:47:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=GhfYbFO0CeC7iFJW2J4VsTCnDBdshizYRINRE9HkXPg=; b=ubEkpp1q1dK7RdUOi6oqTdOTyklkDevEAUFfQInkQXG4v5DTCPsX7+cnGBWXwmwKCH oMKKNBQRrDabavJ5vG/tA1/u1gcvkwdm3yN+vOUZ1+jpZif+kVEEksWB1sqKhuWjmcZo SYRyM3CQp2aYRfePow3lXx2miulljaBd+LW/tA5p175tFmk+DGJJhDpDmKqWwyowN+3e rJqsC6mt90mF+IDqbPEnKyNoO7bKat8EZlm1CUIqCUHRn/OLzuwR/cTuShnizZ2Jgd/C d47C/DJvlF2qi06UbUju3Y8iHJ5dLfkQjmDlOWNaR6VpgOHN1MqVBd/PsvukpNhBO4yT MGJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=GhfYbFO0CeC7iFJW2J4VsTCnDBdshizYRINRE9HkXPg=; b=ddBKtHpTXi6WHYKa2GXg85Whyq50yScrL4qwuhXUeje25HKPm6U4VOkmVTNirlHUn8 WTxEtvmIGMl8gyIMXs5z50rfTawfX6x4vkLwIJdt1qXjf0F6TcUg+owC+yIaXw7cHvMK +qvBy+8U/UwfjTA5b7p4A4BV9fo0EP9cgNjxWATquBVfhLeScN9AVBiW6UJqc4Kh13Xb 2wGeIKI/XPOZlh9eqBWJ49EbOg8Z+fSuZ03WvbK29+rkz6hoPuc7aeK8HEKOPh49aPuk w3YsGBEDEkd+2VO9DI/QKBz7WHhJBsAEL6UU+bjDN7SxZTo4D1oyI+Ms/KNAcX/hzCTF 2lhw== X-Gm-Message-State: AHQUAua49ywwnJeOcz51/QHPOl9u05GAKEWoQCyhjpJEMrUCkbQ+1O89 aywIjEC0Inn7oYC3XgSGc2dthaJprpTKODQMzzo6fRmZRus= X-Google-Smtp-Source: AHgI3IYUL6FMIezFWKCBXQzdHL8MOtuZ3Mg7M5cGxsCLpEwrLMz4m4EjcTDQNg56JIklDs5/Z9jW6rY9pEnw6WUn2Is= X-Received: by 2002:a63:5d5f:: with SMTP id o31mr14708582pgm.414.1550418455168; Sun, 17 Feb 2019 07:47:35 -0800 (PST) MIME-Version: 1.0 References: <179177e3-86f8-1007-7af3-a261ae0be1e8@googlemail.com> <15787.1550092516@localhost> <99c3da12-280b-cf0a-c71a-c004d98100a4@googlemail.com> <14709.1550106762@localhost> In-Reply-To: <14709.1550106762@localhost> From: Steve Lhomme Date: Sun, 17 Feb 2019 16:47:25 +0100 Message-ID: To: Michael Richardson Cc: Andreas Rheinhardt , Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] My review of the EBML-specifications X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2019 15:47:38 -0000 Le jeu. 14 f=C3=A9vr. 2019 =C3=A0 02:12, Michael Richardson a =C3=A9crit : > > > Andreas Rheinhardt = wrote: > > Let me summarise the current proposal as I understand it: > > i) An IANA registry for the EBML elements in the EBML Header is cre= ated. > > ii) The process for registering numbers. This includes a "First com= e > > first served" policy for certain ranges like Element IDs with a siz= e > > of three octets. > > iii) An IANA Doctype Registry. > > iv) the Matroska document will create a new IANA Registry for Element IDs > in use by Matroska > > v) The *Matroska document* will populate the EBML Element ID registry wit= h > a list of ElementIDs RESERVED. No *EBML* Element ID may be created > with the same number. > This is largely as a COURTESY, because in fact the two name spaces > are intended to be distinct across header and contents, but it's bette= r if > there is no reuse. I agree. They are different name spaces so even if the same element IDs are used in both it shouldn't matter to a reader. Given an ID needs a Path to be interpreted, you may even find the same ID in different places with different Pathes. (This is not described as such in the EBML IANA registries for IDs but it should probably be for Matroska) From nobody Sun Feb 17 08:58:54 2019 Return-Path: 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 D143E1295EC for ; Sun, 17 Feb 2019 08:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbG5BBeOjHHy for ; Sun, 17 Feb 2019 08:58:51 -0800 (PST) Received: from mail-pg1-x541.google.com (mail-pg1-x541.google.com [IPv6:2607:f8b0:4864:20::541]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4A2A1275F3 for ; Sun, 17 Feb 2019 08:58:51 -0800 (PST) Received: by mail-pg1-x541.google.com with SMTP id q206so7238544pgq.4 for ; Sun, 17 Feb 2019 08:58:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=jU6iiZ4+tciCbp+PdJcCs7GnpMbhIydO4TVio4enylM=; b=w6YO+X6RHSrpDqNSK35UbCvNToO0vMgNZV4MHaQrmlCLMVr6IQVlNLByscgeCYqpYQ 6nvbmOKu4YQBKS8T+ObgHR3PvxkgWOYxH5yC/1eRJqbS8TDfpLNfWpus+KYDeczwz0Xa BxblTF1D5/Yu+3kR+IX+XeOEbvk6osci9nwesZEW1f1OWLEh6EgCnuZm1iKKvJd90GTW zxpjTP5AYe4MWatZPxc5ARUFqVi/apiP3795DhIIDmV+bN7HNL/GLNhknrvcaUGFYbUj +ODshpCiF7+2lASLU89bl9EimIeWvJ8QiL2FMWqWkaZZ5ULm/fR2VpaJ3fnDDDBBrgh0 wdtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=jU6iiZ4+tciCbp+PdJcCs7GnpMbhIydO4TVio4enylM=; b=D3obDV/YT/NPauYV5gG0VF5iaTzOcpQnYLJ6myQPBLuORs4SCYG+o/ssosBUFXEKZ2 qetAoRD5YvN5f4lJ7oy9b0g15S0z25OV6LtRe4dTxaVWRnTjU4v/fEczJq0Awyo4djEq kmdy8gnv8hb7/GCAT9v6cKRfHiUErFtRD18xle04LvXRGclgFraop9XsjHjWP9p1eM94 3vNh34rtgknYUKlcXmcerNjmVrrcDJ6xU2FUqa/Pl5S4UqSlp6icuBuD8Zj6kxHWDTUA s1a7mlUA/b+fkCM/PbbFD2vmB/aWWcHG5D/b7YMpmh1uKihbZrUR0OndJ8nUOxAhGNyE F7OA== X-Gm-Message-State: AHQUAuYhorGXs50SkwrZWPmFJv0JMv+sg29NPTtTCgH4bcICmWUTKeqU JqmtOLPYOv/zq2CXk6AOlBp7QYNEnOeiJGbv2IJ8fpe7QBiXxw== X-Google-Smtp-Source: AHgI3IZIPBIU+u/GRk/qxwJd+xZPKmRSbA+taNIl7P/faObAR+cLi0DI6cGgk9/kwx5i68fbIttEQYdJM4IpMHzO+i0= X-Received: by 2002:a63:5207:: with SMTP id g7mr15045507pgb.253.1550422730878; Sun, 17 Feb 2019 08:58:50 -0800 (PST) MIME-Version: 1.0 References: <179177e3-86f8-1007-7af3-a261ae0be1e8@googlemail.com> In-Reply-To: <179177e3-86f8-1007-7af3-a261ae0be1e8@googlemail.com> From: Steve Lhomme Date: Sun, 17 Feb 2019 17:58:41 +0100 Message-ID: To: Andreas Rheinhardt Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] My review of the EBML-specifications X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2019 16:58:54 -0000 Le mer. 13 f=C3=A9vr. 2019 =C3=A0 18:12, Andreas Rheinhardt a =C3=A9crit : > > 4. A few Matroska elements have complex default values. For example, > the default value of BlockDuration is the DefaultDuration of the > track. So evaluating the default value would mean that the EBML reader > knows about the internals of the Block structure although said Block > is supposed to be a binary blob for the EBML reader. See > https://github.com/Matroska-Org/ebml-specification/issues/224 for more. > > 5. And then there are two little PR: > https://github.com/Matroska-Org/ebml-specification/pull/220 and > https://github.com/Matroska-Org/ebml-specification/pull/223. My reply on github: This is a real issue. Right now there is no restrictions on what can be put in the `default` attribute of each element (nor in `size`, `label`). That should be fixed. As for how to interpret the value we could define a syntax but that would take forever and block this document. I think it's a good thing that default values may be very complex things depending on the context (Matroska can't do without). We need to keep this possibility. For machine readable purposes it's important that the Schema says if an element has a default value or not even if the value is not interepreted. For example in `mkvalidator` it allows checking things are correct or missing, without having to know if the context is legit. I think escaping the `default` value when it's not a direct value could work. Another way would be to add an extra attribute for which the `default` value cannot be interpreted as such. In Matroska there is: * BlockDuration using `DefaultDuration` * DisplayWidth using `PixelWidth - PixelCropLeft - PixelCropRight` * DisplayHeight using `PixelHeight - PixelCropTop - PixelCropBottom` * OutputSamplingFrequency using `SamplingFrequency` --=20 Steve Lhomme Matroska association Chairman From nobody Sun Feb 17 12:36:25 2019 Return-Path: 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 9BDEA129619 for ; Sun, 17 Feb 2019 12:36:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiclO7tstygT for ; Sun, 17 Feb 2019 12:36:21 -0800 (PST) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AA89126C7E for ; Sun, 17 Feb 2019 12:36:21 -0800 (PST) Received: by mail-wr1-x431.google.com with SMTP id d17so1655069wre.10 for ; Sun, 17 Feb 2019 12:36:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Vo6e2LBzDHldKFkH9zeYtiZUBmqLptEsDtIaIW+4CQs=; b=kekkz/se0UQNtMRG8ZvWGdtuX+chhgNpJv54iMiF9dueusrR4dZkXJqQHw9ocC6QqU W8ualagM/wV8rmYKXk8fVzF4CVAf1UvfGc6cGJ2y4mYbuhtZAF16qMGWXrnHcQRHNqQ3 uysG24kJSlp2kjR6SQFe1+OP7YpGaooPoNdvYj86MktzvK7dPkdwsReimDRqQFja2LhL RM515Haq6d6c9siQVtRGap0E2MBeiUbsyY1Q/qdNPkop/xBegcl6FqiaAhqYWhhR0PoV N/QT6HaTZ9p1c6S895/bcrguXnRCZpg8meZYCTLs5L+DzY4lOZ04OOW0EgcVMHDbrCSC 3AzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Vo6e2LBzDHldKFkH9zeYtiZUBmqLptEsDtIaIW+4CQs=; b=RN5JIOzZ7MM3eOikib651BDnS3cDvW8tbRMCf2K1JZjkPohTZs79hI5e3r4H1QYXnb RKSdEq0Mb1eClyIGpykY+E4hkShWaWPNpoLGGvooh3z+TRa7W7qM1I78pXnI9wzTtN8s LEZdHreN2rrrkvI/tyR1X0tiDHws3HnCSEDVUVlmM7aIARFDyvhpuhE45vWD0YPttDk5 OMOBKly1d/V1IkmHWaADFN+Oo1DRlJFVb87PRyyksf8u2heQEHcaLJLY5PqmMPO5qyLv 687TU3Q5AuAstS3R2zL5DsTQv3fzA3rUnud35BzhAbVWehEhyntPZsQwo2OBGGvVTG8N tRaQ== X-Gm-Message-State: AHQUAuYUXbG+teFudu7ekEAWBpLqiOd1p8ZUO4C8s6uNe5VQNVPKj0aA B+zZFqY9dwCupXaki+wgHFodnrTK1XL8oQT/+m0= X-Google-Smtp-Source: AHgI3IZQkbXO2IrFh+PE/fnrDrCmzqpQxVQ1aocqfv195Sowdznl+INCJfpovugcf7IEQ1RrolOGuTvfEz+XxuI/VHE= X-Received: by 2002:adf:e706:: with SMTP id c6mr14394257wrm.278.1550435779045; Sun, 17 Feb 2019 12:36:19 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ashley Blewer Date: Sun, 17 Feb 2019 15:36:06 -0500 Message-ID: To: hubblec4 Cc: Steve Lhomme , Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="000000000000db6bdf05821cf5a5" Archived-At: Subject: Re: [Cellar] Interactive Menu - VideoLAN Google Summer of Code X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2019 20:36:24 -0000 --000000000000db6bdf05821cf5a5 Content-Type: text/plain; charset="UTF-8" Hey, that's really great news! Congratulations, and I hope you find a great candidate that picks this project to work on. :) On Sun, Feb 17, 2019 at 7:00 AM hubblec4 wrote: > Hi Steve > > Very interesting news. > > Am 17.02.2019 um 09:03 schrieb Steve Lhomme: > > Hi everyone, > > > > As Videolan (which I'm part of) is preparing this year's Google Summer > > of Code projects, we added one regarding Matroska and interactive > > menus (think Netflix/Black Mirror Bandersnatch) > > https://wiki.videolan.org/SoC_2019/#Interactive_movie_support > > > > It involves adding things to the Matroska specification to handle > > active zones and actions, but not using the (complex) DVD chapter > > codec. And then adding support in VLC (which already has DVD and > > BluRay (and DVD in Matroska) support). > > > > If any of you know a student who qualifies to apply let her/him know. > > > > The technical discussions on Matroska will probably happen here. > > > > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --000000000000db6bdf05821cf5a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey, that's really great news! Congratulations, and I = hope you find a great candidate that picks this project to work on. :)
<= /div>
O= n Sun, Feb 17, 2019 at 7:00 AM hubblec4 <hubblec4@gmx.ch> wrote:
Hi Steve

Very interesting news.

Am 17.02.2019 um 09:03 schrieb Steve Lhomme:
> Hi everyone,
>
> As Videolan (which I'm part of) is preparing this year's Googl= e Summer
> of Code projects, we added one regarding Matroska and interactive
> menus (think Netflix/Black Mirror Bandersnatch)
> https://wiki.videolan.org/SoC_2019= /#Interactive_movie_support
>
> It involves adding things to the Matroska specification to handle
> active zones and actions, but not using the (complex) DVD chapter
> codec. And then adding support in VLC (which already has DVD and
> BluRay (and DVD in Matroska) support).
>
> If any of you know a student who qualifies to apply let her/him know.<= br> >
> The technical discussions on Matroska will probably happen here.
>
>

_______________________________________________
Cellar mailing list
Cellar@ietf.org https://www.ietf.org/mailman/listinfo/cellar
--000000000000db6bdf05821cf5a5-- From nobody Mon Feb 18 01:42:51 2019 Return-Path: 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 A4ED9130EF1 for ; Mon, 18 Feb 2019 01:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OqWR7CpgtLK for ; Mon, 18 Feb 2019 01:42:48 -0800 (PST) Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C4BC130EEF for ; Mon, 18 Feb 2019 01:42:48 -0800 (PST) Received: by mail-lf1-x143.google.com with SMTP id t14so11795074lfk.7 for ; Mon, 18 Feb 2019 01:42:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-transfer-encoding; bh=9tnzM1YJ0yjevfvMoAVCqadU7uRMuOynhKooiiNdRYA=; b=S8j0pSxmNZX7KcTLVN1sSgJghaFiRJ2vkESWHJwHmcui7n2lPZJJZ9pEjjOm+eBlxn UAlElLXvA6w9jHwmJ5Kyn5rOuoj0kLe4jS4xuTUuyH8u03dwjkqkRQnyNs6elbFwKGJt 5YtBf3c5IAX6sJP2E6ptwu7Qwksj0/G3keOpXOZDuw48C4QPsLbqno+tEI2zPkTfuhZp j6GnSGh1TA9BV+/F9exboL8qJG79uycCiFWkq3+khFlPegvaH2TCmJiOSC6DrwtK3Bc1 /xG23FTQqc+7fhesRzS0lP63T16SB4DL4phAU8Ko4xDtemwcpyBdikMPtdCG0en3zI+J zsXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-transfer-encoding; bh=9tnzM1YJ0yjevfvMoAVCqadU7uRMuOynhKooiiNdRYA=; b=BHexQp+6g/piP3/SZFxocwgRRr1IvBfzHr6Pr7GXpAeWhi67g5my89gAOM6M3kXyO2 xzwwQlAicxRLGdHz2kYv4KkULncMZQI0OyER0k06WDImWXi+lRg60PAG9Ie0+FzgT8EU 3EzQhHZH+byy9DLOKjDJ180q+VdV9ik7FqUgn0/VIMrW4HB0k7QoXqhawPiGRvgZSqeD geypOvDEJhjnR/X8QJ2AjJ21xkhasJh4muwi7fLQU32odRehhNe8WfgQmDkwcsYBOTkU yqfe7cPTs8Pf0fbr7mfIQX/piN3c9TJkjgB/kval8MH5LAwSzl9QZxTRIkupqPWK8Py2 S/XA== X-Gm-Message-State: AHQUAuZPxx+1WVvlPNqGJYbLsNXlJF7ywW5SWBR3apWzAKnFXRPLOFdu FyJEnTZToiqzcb3h8AGHDFkjVVJo X-Google-Smtp-Source: AHgI3IYtUeB2O1o23nihqObDqXBdrZapImSeGYjUgrxQtj88LkXG0yLcu+By0iOqyFP8g919gW3A+Q== X-Received: by 2002:ac2:5624:: with SMTP id b4mr14110595lff.41.1550482965804; Mon, 18 Feb 2019 01:42:45 -0800 (PST) Received: from [127.0.0.1] (host-216-158-98-38.junet.se. [216.158.98.38]) by smtp.googlemail.com with ESMTPSA id x19sm2221269lfe.42.2019.02.18.01.42.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Feb 2019 01:42:45 -0800 (PST) To: Steve Lhomme Cc: Codec Encoding for LossLess Archiving and Realtime transmission References: <179177e3-86f8-1007-7af3-a261ae0be1e8@googlemail.com> From: Andreas Rheinhardt Message-ID: <2aa02af4-e36a-e964-e901-8e611d422fd5@googlemail.com> Date: Mon, 18 Feb 2019 09:41:00 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Cellar] My review of the EBML-specifications X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 09:42:51 -0000 Steve Lhomme: > Le mer. 13 févr. 2019 à 18:12, Andreas Rheinhardt > a écrit : >> >> 4. A few Matroska elements have complex default values. For example, >> the default value of BlockDuration is the DefaultDuration of the >> track. So evaluating the default value would mean that the EBML reader >> knows about the internals of the Block structure although said Block >> is supposed to be a binary blob for the EBML reader. See >> https://github.com/Matroska-Org/ebml-specification/issues/224 for more. >> >> 5. And then there are two little PR: >> https://github.com/Matroska-Org/ebml-specification/pull/220 and >> https://github.com/Matroska-Org/ebml-specification/pull/223. > > My reply on github: > > This is a real issue. Right now there is no restrictions on what can > be put in the `default` attribute of each element (nor in `size`, > `label`). That should be fixed I agree, but before we talk about how to store the default value we should clarify where to draw the line: It is clear that an EBML-only reader (that uses Matroska's EBML Schema) will never ever be able to evaluate the default value of BlockDuration as this requires parsing the Block structure (to get the TrackNumber) although a Block is a binary blob for an EBML reader. So this default element will have to be handled at a higher level (at the Matroska layer). If you want to have the information about the existence of a default value in EBML, then one would need to add a stub EBML value. But for the other values it would be possible in EBML as these are of the form "The default value is the value of a function whose return type is the same as the said element whose parameters are other elements that are siblings to the current element.". (Said other element would have to be mandatory for this to work.) As you said, defining this rigorously would block this document, so that's unfortunately not possible in version 1 of EBML. But the special case of "The default value is the value of another element (of the same type) that is a sibling to the current element" might be easily definable and quite useful. So where do we draw the line? Do we include or exclude the latter form of default value? - Andreas From nobody Mon Feb 18 03:33:17 2019 Return-Path: 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 3E89E130EF2 for ; Mon, 18 Feb 2019 03:33:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCStVaJMwwfq for ; Mon, 18 Feb 2019 03:33:14 -0800 (PST) Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79E99130EB0 for ; Mon, 18 Feb 2019 03:33:14 -0800 (PST) Received: by mail-wm1-x344.google.com with SMTP id q187so4681737wme.5 for ; Mon, 18 Feb 2019 03:33:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-transfer-encoding; bh=HwzJyoB4iEQX9dcbc6D3Y5T6z1ApuITb5FTR3goRTfw=; b=tCGBSMarBDe4+Iza1zEtywcacekWSE9ri5soR0AEuZbUHsN61yTAt1aWfxpPXgq8Cn 5FsStnQeyJ2/pRY7w1nRVeIiR3Lo8vA8wV9+FvxNJgKgTeB9RO0CYQUZWSdBxrRU6NhP acdzGlMvm8cs7gyGEvVC+ETupddWBPK7cD4YZEaVPddrWOVOEhiITQGkxFFXOoJhb2vK Eb4IrWHJLF8bGowLTT8Ryv0d7zVF5I5RBuETQSe0P7EpkLiYMBUd3ldnX/ACwAu5sCKz rLbj9/GHMxuUowJKaIJ7yACnGtSSS7hqRjXbq+Rzk+MZdUeLGGqCgOx9PzigQXUJLNyh dCbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-transfer-encoding; bh=HwzJyoB4iEQX9dcbc6D3Y5T6z1ApuITb5FTR3goRTfw=; b=JxZiGiENdPhNMQAhvrBISLnSBFb1QodyI3oeEVhXzFvvqjXBMhJ4QrHNE2P6ZNCweN APXSU4n/AxdkWTARO22TH4p0T3Ik47ovL19TF1nD20b4+al95qhrNCryYai3GzftyB8c GSfWpdKK4zu/lr4wvbdl3q45uG5iwwwp6vBaHDyGuOK5TZASuzlESOJ1ONmBqjF9jyIF tZ3Rkk7OH9F6bIy/G0N0gQz+9k+kSKEaTix/lO7YuQw/oQP87PAymSQ4r/Lssrr9DV+X qPj/g2y9hCnlRBuessLpOTYgqh1FB51XSulDSzZaLfBFnBInmL96lUT/fULv6Llb5HnB Zufg== X-Gm-Message-State: AHQUAuY7R0nYipW701rkHa3J4S2XvCXfiDmJfjoz+uc+pPtPh2IrAfwU a0uq3DWNHRkD36vgQRVqrhH/NiaH X-Google-Smtp-Source: AHgI3IYQL/7Xfdj2lYKoO2wK+FKAKtbH1Chc5edKXpqRgoHxb2giLWp+kUZEf47r87YmkhJSwfJsGw== X-Received: by 2002:a1c:a941:: with SMTP id s62mr15713361wme.16.1550489592706; Mon, 18 Feb 2019 03:33:12 -0800 (PST) Received: from [127.0.0.1] ([2001:41d0:601:1100::9eb]) by smtp.googlemail.com with ESMTPSA id f68sm12922194wmg.5.2019.02.18.03.33.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Feb 2019 03:33:11 -0800 (PST) To: Michael Richardson Cc: cellar@ietf.org References: <179177e3-86f8-1007-7af3-a261ae0be1e8@googlemail.com> <15787.1550092516@localhost> <99c3da12-280b-cf0a-c71a-c004d98100a4@googlemail.com> <14709.1550106762@localhost> From: Andreas Rheinhardt Message-ID: <275f68a9-a617-e685-159f-4f004232ca9d@googlemail.com> Date: Mon, 18 Feb 2019 11:32:00 +0000 MIME-Version: 1.0 In-Reply-To: <14709.1550106762@localhost> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] My review of the EBML-specifications X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 11:33:16 -0000 Michael Richardson: > > Andreas Rheinhardt wrote: > > Let me summarise the current proposal as I understand it: > > i) An IANA registry for the EBML elements in the EBML Header is created. > > ii) The process for registering numbers. This includes a "First come > > first served" policy for certain ranges like Element IDs with a size > > of three octets. > > iii) An IANA Doctype Registry. > > iv) the Matroska document will create a new IANA Registry for Element IDs > in use by Matroska > > v) The *Matroska document* will populate the EBML Element ID registry with > a list of ElementIDs RESERVED. No *EBML* Element ID may be created > with the same number. > This is largely as a COURTESY, because in fact the two name spaces > are intended to be distinct across header and contents, but it's better if > there is no reuse. > I didn't think of this as a courtesy. After all, if these are distinct namespaces with the potential for overlapping, then resynchronisation might be affected (in case of errors). In order to prevent this, the ID of the `EBML` element (`0x1A45DFA3`) should not be allowed to be reused by any EBML Schema. And I think it should be explicitly stated that these are different namespaces. I read the document and thought (ok, I already believed that before I read the document, but nevertheless) that it is not allowed to reuse header EBML IDs for the EBML Body. My rationale was that the EBML's own EBML Schema is part of any other EBML Schema (either explicitly or implicitly). If this is not so, then we might need to clarify the following statement: "An EBML Schema MAY constrain the use of EBML Header Elements (see EBML Header Elements) by adding or constraining that Element's range attribute. For example, an EBML Schema MAY constrain the EBMLMaxSizeLength to a maximum value of 8 or MAY constrain the EBMLVersion to only support a value of 1. If an EBML Schema adopts the EBML Header Element as-is, then it is not required to document that Element within the EBML Schema. If an EBML Schema constrains the range of an EBML Header Element, then that Element MUST be documented within an node of the EBML Schema." So some Header Elements are documented in an EBML Schema. According to the wording of `Element ID` ("used to uniquely identify a defined EBML Element within a specific EBML Schema") this means that the documented EBML Header IDs MUST NOT be reused for the EBML Body. But I don't think it makes sense to base the decision whether an ID may be reused or not on whether the Header Element with said ID is constrained or not. > > And even if all these lists were existing and were kept-up-to-date at > > all times, there is still another problem: If usage of EBML becomes > > widespread with many projects being created, then IDs that are not in > > use by any project might become scarce (in particular for shorter IDs > > -- certainly for length 1 IDs and possibly for length 2 IDs), even > > when all projects only need a fraction of the IDs. > > It's possible. Actually not. If the namespaces are distint, then the above scenario can't happen. > > > My proposal for this is to reserve some IDs for use for future > > extensions to the EBML Header. No EBML Schema may invade these > > reserved IDs. > > That's a reasonable proposal. > > > Given how valuable IDs with length one are, no such ID should be > > reserved for this purpose. A few IDs with length two should be > > reserved as should some length three elements and more length four > > elements. Registering a shorter ID should of course be subject to > > stricter scrutinity than registering a longer ID. > > We could set the IANA rules all IDs with length two to Specification Required. > That won't be required if the namespaces are distinct. - Andreas From nobody Wed Feb 20 12:02:04 2019 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 165A5128B14; Wed, 20 Feb 2019 12:02:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks To: Cc: cellar@ietf.org, ietf@ietf.org, draft-ietf-cellar-ebml.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155069292202.31303.6397142165718454854@ietfa.amsl.com> Date: Wed, 20 Feb 2019 12:02:02 -0800 Archived-At: Subject: [Cellar] Genart last call review of draft-ietf-cellar-ebml-09 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 20:02:02 -0000 Reviewer: Robert Sparks Review result: Not Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-cellar-ebml-09 Reviewer: Robert Sparks Review Date: 2019-02-20 IETF LC End Date: None IESG Telechat date: Not scheduled for a telechat Summary: Not ready for publication as a Proposed Standard Note that this is really an early review - IETF LC has not yet been issued for this draft. Issues: It's not clear that this group is chartered to produce a general purpose binary equivalent to XML. Instead, it appears to be chartered to document FFV1 and Matroska. EBML as it is currently used for those things needs to be documented, but rather than try to make it into a format that other things besides the work of this group appears out of scope. If I'm correct, then this document shouldn't need to create an IANA registry - it need only document what the group needs (and if the group needs more later, it can update this document). The abstract and introduction would need to be adjusted to scope the purpose of the format to supporting the work of this group. My review assumes a scope of "documenting these existing formats" rather than providing a general purpose markup language. If I'm wrong and this group is chartered to produce an alternative for other protocols to use, this needs review from people who are more expert in that kind of representational design than me. The document is very hard to absorb given its current structure. It requires multi-pass reading to figure out. While I like the idea of leaping directly into security considerations, the draft really needs an introduction that lays out the high-level structural concepts more linearly. A diagram of the inherent tree structure would help reinforce the definitions. Showing the defined types (13.1.5.9) in that diagram would be useful. A shorter introduction to VINT (not the details of its structure, but why you have such a construct in the first place) would also help. Also consider examples showing the end of Unknown-Sized elements is determined (The description in the first partial paragraph at the top of page 12 is complicated). It would also help to introduce the idea of null terminated strings here to smooth the forward reference from section 8.4 to section 9. CRC-32 elements aren't defined until towards the end of the document, but non-trivial things are done with them throughout. Having those introduced, at least conceptually, much earlier would be good. The third paragraph of the Security Considerations section (including the bullets) appears to say its ok to treat the following invalid things as valid. If that's the case, why are they invalid in the first place? I think for some of them, perhaps text has drifted and they are no longer invalid, but just to be avoided when it is reasonable to do so? For those that really are invalid, some text should be added describing _why_ they are ok to accept. In 5.4 you claim the Size column in the first table refers to the size of the "VINT_DATA" in bits. The values there are not how many bits of VINT_DATA you have. If that's what you really want to show, the values should be 7, 14, etc. rather that 2^7, 2^14. If you mean for the column to show how large an integer can be represented by a VINT with this octet length, the values need to be 2^7-1, 2^14-1, etc. It would be helpful to reduce the width of the first columns so that the last value in the Representation column does not wrap. The last sentence of the 2nd paragraph of section 7 does not parse. Please simplify it. There is odd notation at the end of page 12. What does 2^(2_7) mean? At section 8, the second sentence scans very badly. Consider breaking it into two or more sentences so that there is no ambiguity around the concept being defined. As written, its too easy to misunderstand that the element type defines a concept that describes definition. At section 11, you say that EBML Documents MUST NOT contain any data that is not part of an EBML Element, but I think other sections allow that to happen in data rewrite situations? Why is the unique and persistent requirement SHOULD and not MUST at the top of page 20? At the definition of name (13.1.5.1), please talk about why this particular set of characters were chosen. Please expand on "the risk of false positives" in 13.1.5.3. The risk here is not obvious from the current text. At 13.1.5.6.1 (a section nesting 5 deep is a document structure warning sign by itself), in the first bullet I suggest you say "are of the type of the element" instead of "are integers or floats". What you have now lets me put an integer on one side and a float on the other. The range representations in 13.1.5.6.1 don't allow representing 0<=x<1, 0 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 26DDB130F83 for ; Wed, 20 Feb 2019 18:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.88 X-Spam-Level: X-Spam-Status: No, score=-0.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3dIMCrX5Tl9 for ; Wed, 20 Feb 2019 18:16:07 -0800 (PST) Received: from smtp.mozilla.org (smtp1.mdc1.mozilla.com [63.245.208.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 473F11275F3 for ; Wed, 20 Feb 2019 18:16:07 -0800 (PST) Received: from localhost (localhost4.localdomain [127.0.0.1]) by smtp1.mail.mdc1.mozilla.com (Postfix) with ESMTP id 203749A05B for ; Thu, 21 Feb 2019 02:16:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (smtp1.mail.mdc1.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x_UXmgVmm9R6 for ; Thu, 21 Feb 2019 02:16:06 +0000 (UTC) Received: from [10.252.25.170] (unknown [63.245.221.198]) (Authenticated sender: tterriberry@mozilla.com) by smtp1.mail.mdc1.mozilla.com (Postfix) with ESMTPSA id F00DC9A052 for ; Thu, 21 Feb 2019 02:16:05 +0000 (UTC) Cc: cellar@ietf.org References: <179177e3-86f8-1007-7af3-a261ae0be1e8@googlemail.com> <15787.1550092516@localhost> <99c3da12-280b-cf0a-c71a-c004d98100a4@googlemail.com> <14709.1550106762@localhost> <275f68a9-a617-e685-159f-4f004232ca9d@googlemail.com> From: "Timothy B. Terriberry" Message-ID: <1f0128a8-ed35-dd30-fbc1-4f7fb2e90f54@xiph.org> Date: Wed, 20 Feb 2019 18:16:05 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 SeaMonkey/2.49.7.0 MIME-Version: 1.0 In-Reply-To: <275f68a9-a617-e685-159f-4f004232ca9d@googlemail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] My review of the EBML-specifications X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 02:16:10 -0000 Andreas Rheinhardt wrote: > And I think it should be explicitly stated that these are different > namespaces. I read the document and thought (ok, I already believed To be fair, the current document does explicitly state this in 15.1, "This IANA Registry only applies to Elements contained at least in the EBML Header, thus including Global Elements." (minor nit: "at least" is a bit awkward, "that can be contained in the EBML Header" might be clearer). > that before I read the document, but nevertheless) that it is not > allowed to reuse header EBML IDs for the EBML Body. My rationale was > that the EBML's own EBML Schema is part of any other EBML Schema > (either explicitly or implicitly). If this is not so, then we might > need to clarify the following statement: > > "An EBML Schema MAY constrain the use of EBML Header Elements (see > EBML Header Elements) by adding or constraining that Element's range > attribute. For example, an EBML Schema MAY constrain the > EBMLMaxSizeLength to a maximum value of 8 or MAY constrain the > EBMLVersion to only support a value of 1. If an EBML Schema adopts the > EBML Header Element as-is, then it is not required to document that > Element within the EBML Schema. If an EBML Schema constrains the range > of an EBML Header Element, then that Element MUST be documented within > an node of the EBML Schema." Your rationale here is logical and I agree this could use clarification. The text I quoted above relies on an implied equivalence between Element ID namespaces and IANA registries, but that isn't explicitly stated anywhere, and the text you quote seems to contradict this. Having two separate IANA registries for the same namespace seems like it would be problematic, but I suppose that is the issue you are raising. >> We could set the IANA rules all IDs with length two to Specification Required. >> > That won't be required if the namespaces are distinct. But isn't that (that length-two IDs are Specification Required) what the document currently says? (this question is for Michael) From nobody Wed Feb 20 20:13:00 2019 Return-Path: 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 9294B129532; Wed, 20 Feb 2019 20:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBRx6Bn35bVd; Wed, 20 Feb 2019 20:12:56 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E001129441; Wed, 20 Feb 2019 20:12:56 -0800 (PST) Received: from unescapeable.local ([47.186.39.7]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x1L4CsVm085836 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 20 Feb 2019 22:12:54 -0600 (CST) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1550722375; bh=aADA5IjkzDe+kNUs6ELLln3i5FdcP6tVKPxpvTw+kM8=; h=Subject:From:To:Cc:References:Date:In-Reply-To; b=UVtppei17YPDbvHeI35kQryorBvGUBYUbQa9q4+bY3nZxgx/q7TKlyC4mpbmdf1Gn RU5wRXVjL2/VLEztCIqOOT42gPkXNPHB/BzetKyK147T9IZXquILKNp8Uy5h2mkykF bJu80UuSsRL4LAxyCgUNuLu8k/iCH+Xp4yv4pcm4= X-Authentication-Warning: raven.nostrum.com: Host [47.186.39.7] claimed to be unescapeable.local From: Robert Sparks To: gen-art@ietf.org Cc: cellar@ietf.org, ietf@ietf.org, draft-ietf-cellar-ebml.all@ietf.org References: <155069292202.31303.6397142165718454854@ietfa.amsl.com> Message-ID: <1331770b-df2d-0c9f-45c7-db36db34fc00@nostrum.com> Date: Wed, 20 Feb 2019 22:12:52 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <155069292202.31303.6397142165718454854@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Cellar] IEEE 754 reference (was Re: [Gen-art] Genart last call review of draft-ietf-cellar-ebml-09) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 04:12:59 -0000 Also, the reference to IEEE 754 should probably point to the 2008 version instead of the 1985 version (unless you've got a specific reason to use the older one?) RjS On 2/20/19 2:02 PM, Robert Sparks wrote: > Reviewer: Robert Sparks > Review result: Not Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-cellar-ebml-09 > Reviewer: Robert Sparks > Review Date: 2019-02-20 > IETF LC End Date: None > IESG Telechat date: Not scheduled for a telechat > > Summary: Not ready for publication as a Proposed Standard > > Note that this is really an early review - IETF LC has not yet been issued for > this draft. > > Issues: > > It's not clear that this group is chartered to produce a general purpose > binary equivalent to XML. Instead, it appears to be chartered to document FFV1 > and Matroska. EBML as it is currently used for those things needs to be > documented, but rather than try to make it into a format that other things > besides the work of this group appears out of scope. If I'm correct, then this > document shouldn't need to create an IANA registry - it need only document > what the group needs (and if the group needs more later, it can update this > document). The abstract and introduction would need to be adjusted to scope > the purpose of the format to supporting the work of this group. My review > assumes a scope of "documenting these existing formats" rather than providing a > general purpose markup language. If I'm wrong and this group is chartered to > produce an alternative for other protocols to use, this needs review from > people who are more expert in that kind of representational design than me. > > The document is very hard to absorb given its current structure. It requires > multi-pass reading to figure out. While I like the idea of leaping directly > into security considerations, the draft really needs an introduction that lays > out the high-level structural concepts more linearly. A diagram of the > inherent tree structure would help reinforce the definitions. Showing the > defined types (13.1.5.9) in that diagram would be useful. A shorter > introduction to VINT (not the details of its structure, but why you have such > a construct in the first place) would also help. Also consider examples > showing the end of Unknown-Sized elements is determined (The description in > the first partial paragraph at the top of page 12 is complicated). It would > also help to introduce the idea of null terminated strings here to smooth the > forward reference from section 8.4 to section 9. CRC-32 elements aren't > defined until towards the end of the document, but non-trivial things are done > with them throughout. Having those introduced, at least conceptually, much > earlier would be good. > > The third paragraph of the Security Considerations section (including the > bullets) appears to say its ok to treat the following invalid things as valid. > If that's the case, why are they invalid in the first place? I think for some > of them, perhaps text has drifted and they are no longer invalid, but just > to be avoided when it is reasonable to do so? For those that really are invalid, > some text should be added describing _why_ they are ok to accept. > > In 5.4 you claim the Size column in the first table refers to the size of the > "VINT_DATA" in bits. The values there are not how many bits of VINT_DATA you > have. If that's what you really want to show, the values should be 7, 14, etc. > rather that 2^7, 2^14. If you mean for the column to show how large an integer > can be represented by a VINT with this octet length, the values need to be > 2^7-1, 2^14-1, etc. It would be helpful to reduce the width of the first > columns so that the last value in the Representation column does not wrap. > > The last sentence of the 2nd paragraph of section 7 does not parse. Please > simplify it. > > There is odd notation at the end of page 12. What does 2^(2_7) mean? > > At section 8, the second sentence scans very badly. Consider breaking it into > two or more sentences so that there is no ambiguity around the concept being > defined. As written, its too easy to misunderstand that the element type > defines a concept that describes definition. > > At section 11, you say that EBML Documents MUST NOT contain any data that is > not part of an EBML Element, but I think other sections allow that to happen > in data rewrite situations? > > Why is the unique and persistent requirement SHOULD and not MUST at the top > of page 20? > > At the definition of name (13.1.5.1), please talk about why this particular set > of characters were chosen. > > Please expand on "the risk of false positives" in 13.1.5.3. The risk here is not > obvious from the current text. > > At 13.1.5.6.1 (a section nesting 5 deep is a document structure warning sign > by itself), in the first bullet I suggest you say "are of the type of the > element" instead of "are integers or floats". What you have now lets me put an > integer on one side and a float on the other. > > The range representations in 13.1.5.6.1 don't allow representing 0<=x<1, 0 or any other range with one or more open ends. Why isn't that problematic? > > The element descriptions in section 13 have range values that don't conform to > the range represnations in 13.1.5.6.1. See 13.2.5 for example (where the range > is "not 0"). > > The last sentence of section 13.1.12 looks like a security problem. Why would > you ever use _any_ elements containing a CRC-32 element that's bad? Some > discussion near the top of the document about what these CRC-32 elements are > supposed to accomplish seems necessary. More needs to be said about the similar > security issues at section 14. > > At 13.2.9, what does "read upper values" mean? > > Nits: > > The definition of Master Element is not a definition - it describes one > propery Master Elements have. AFAICT, the concept isn't concisely defined > anywhere in the document. > > The definition of Void Element doesn't need to say "damaged data". It > coule be perfectly good data that you are overwriting. > > I suggest removing the word "official" from the Element Name definition. > > The concept of an Identically Recurring Element is not clear throughout > the document. Some section should give a complete definition, and the > places that call out whether exceptions (such as where the security > considerations discusses Identically Recurring Elements with invalid > CRC-32 elements) are still Identically Recurring Elements or not. > What happens if the values in the invalid CRC-32 elements are different > from each other? > > At section 8.7, second paragraph, first sentence. The sentence is long, and > "equals to" looks like a problem spot for non-native-English readers. Perhaps > "set to the same value as"? > > Micronits: > > Page 9: s/four octet./four octets./ > > Expanding the numbers in section 8.1 and 8.2 isn't really helpful. It would > be better to just say 2^64-1. > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Sun Feb 24 01:07:12 2019 Return-Path: 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 7908612D4E6 for ; Sun, 24 Feb 2019 01:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpqA7TCev58e for ; Sun, 24 Feb 2019 01:07:09 -0800 (PST) Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39B341200B3 for ; Sun, 24 Feb 2019 01:07:09 -0800 (PST) Received: by mail-wm1-x343.google.com with SMTP id y15so5435012wma.0 for ; Sun, 24 Feb 2019 01:07:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=nisiW39lEHOYvL3xySYj+9Mfhyc7fn4p7pAyM7atKRs=; b=UT8oOA2+iAasp88WYTNFII0BIzZxbxIvmDqdo0uR2VhHai/FX4T91bh+x+BvJWtVMt AK3hXH964PirT2hOGifTOLDo6Zo/WbxvCDEegqI0qGBlTyeD0Kobh+vmvi8ZA11EQF4R 1R2YffZMWtLQeSE4W2xKEqvjvmISUkBXURsmfgBPO0sRT7gbZFAVwdyDfU0pp46mJHie heUBHbwHyafHiwpPUgdm6wzb7h4znWL4a90vpZEVCI2sAHji2cSuy87zYDtF9heEGweY KoXhC8f9NeHmXjOxHQOjjfsXTHRnKI1jiMyUNaPFDNc9FbIgo9OIs8/rjHX/CKj8gjF4 tPNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=nisiW39lEHOYvL3xySYj+9Mfhyc7fn4p7pAyM7atKRs=; b=FvDRDoeasj/bz7BDkKWV2b230Zg46OU8gtaK9ZB6SxXmukn+XFbIT5RJEgKus295f7 d+sXsoXI8TSydy82kat/OoHHdce+ovrPrL3spSfFXoYMXIfLFsdVs7XPXAY2HIbGnblE 9SiQje/gZWTVZBIxV7vF0rqdmazHUXgbHcpwslgTkS2lb7v6f1eRlJ7k8/+pKeC1636g C8a51rDN+DGDm1cRhc+RmRd/s6p3tKI0jVLjsvBqO5yU/7wT6Ew1n/lzepyhCUGDQ3CK d2aifD0bXcKopRITzbXIrW2C3PDpBCGT6rkmHBNw5enKM9wXzKV5hEomG2cMnwSJK5M8 vuoQ== X-Gm-Message-State: AHQUAuZ9qkfdm+UoeRXMhkqiPE6xDJDijhrqxglR6HTQnFT46a9eENzi gIersLzcflb5iHDV/+/akGOpjvZthU7rhA== X-Google-Smtp-Source: AHgI3IZVn55DwJL2ueJ1EKkNB/QrBI8bg1k6vhj0/bD6bDqFBSnomazkqjTgbutose6RM8GZsMzSUw== X-Received: by 2002:a1c:458:: with SMTP id 85mr6808974wme.97.1550999226574; Sun, 24 Feb 2019 01:07:06 -0800 (PST) Received: from [10.0.0.199] (51.213.7.109.rev.sfr.net. [109.7.213.51]) by smtp.googlemail.com with ESMTPSA id f13sm4936611wmh.41.2019.02.24.01.07.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Feb 2019 01:07:04 -0800 (PST) References: <179177e3-86f8-1007-7af3-a261ae0be1e8@googlemail.com> <2aa02af4-e36a-e964-e901-8e611d422fd5@googlemail.com> To: Codec Encoding for LossLess Archiving and Realtime transmission From: Steve Lhomme Message-ID: <5C725EB9.8070003@matroska.org> Date: Sun, 24 Feb 2019 10:07:05 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <2aa02af4-e36a-e964-e901-8e611d422fd5@googlemail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] My review of the EBML-specifications X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2019 09:07:11 -0000 On 18/02/2019 10:41, Andreas Rheinhardt wrote: > Steve Lhomme: >> Le mer. 13 f=C3=A9vr. 2019 =C3=A0 18:12, Andreas Rheinhardt >> a =C3=A9crit : >>> >>> 4. A few Matroska elements have complex default values. For example, >>> the default value of BlockDuration is the DefaultDuration of the >>> track. So evaluating the default value would mean that the EBML reade= r >>> knows about the internals of the Block structure although said Block >>> is supposed to be a binary blob for the EBML reader. See >>> https://github.com/Matroska-Org/ebml-specification/issues/224 for mor= e. >>> >>> 5. And then there are two little PR: >>> https://github.com/Matroska-Org/ebml-specification/pull/220 and >>> https://github.com/Matroska-Org/ebml-specification/pull/223. >> >> My reply on github: >> >> This is a real issue. Right now there is no restrictions on what can >> be put in the `default` attribute of each element (nor in `size`, >> `label`). That should be fixed > I agree, but before we talk about how to store the default value we > should clarify where to draw the line: It is clear that an EBML-only > reader (that uses Matroska's EBML Schema) will never ever be able to > evaluate the default value of BlockDuration as this requires parsing > the Block structure (to get the TrackNumber) although a Block is a > binary blob for an EBML reader. So this default element will have to > be handled at a higher level (at the Matroska layer). If you want to > have the information about the existence of a default value in EBML, > then one would need to add a stub EBML value. > > But for the other values it would be possible in EBML as these are of > the form "The default value is the value of a function whose return > type is the same as the said element whose parameters are other > elements that are siblings to the current element.". (Said other > element would have to be mandatory for this to work.) As you said, > defining this rigorously would block this document, so that's > unfortunately not possible in version 1 of EBML. But the special case > of "The default value is the value of another element (of the same > type) that is a sibling to the current element" might be easily > definable and quite useful. So where do we draw the line? Do we > include or exclude the latter form of default value? It does seem reasonable to add this one case. But on second thought it's = not that easy either. It may be the value of another field but is it in=20 the same parent, in another parent, if so which one and how to target it = properly ? I think it opens a can of worms that should not be opened for = now. From nobody Sun Feb 24 16:19:46 2019 Return-Path: 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 CBFAC12EB11 for ; Sun, 24 Feb 2019 16:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEh2-X5ibR-f for ; Sun, 24 Feb 2019 16:19:41 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14F2512867A for ; Sun, 24 Feb 2019 16:19:41 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 20EEB380BE for ; Sun, 24 Feb 2019 19:19:37 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 8B36DE45; Sun, 24 Feb 2019 19:19:37 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 89CCBB5A for ; Sun, 24 Feb 2019 19:19:37 -0500 (EST) From: Michael Richardson to: cellar@ietf.org In-Reply-To: <2827.1548632874@localhost> References: <2827.1548632874@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Cellar] DRAFT AGENDA 2019-02-26 20:00 UTC virtual interim meeting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 00:19:44 -0000 CELLAR -- DRAFT AGENDA for Virtual Interim Meeting Feburary 26, 2019 20:00 UTC DRAFT MINUTES FROM 2019-02-26 below INFO: https://datatracker.ietf.org/meeting/interim-2019-cellar-02/session/cell= ar https://datatracker.ietf.org/doc/agenda-interim-2019-cellar-02-sessa/ WEB CONFERENCE: https://appear.in/cellar-interim THERE IS NO TELEPHONE DIALIN You can try this at any time. These notes at: https://github.com/cellar-wg/chair-notes Proposed Agenda: 1. Note Well. 2a. Accept draft minutes from December meeting 2b. Accept draft minutes from January meeting 3. Logistics for Meeting. 2a) Etherpad for notes https://etherpad.tools.ietf.org/p/notes-cellar-virtual?useMonospaceF= ont=3Dtrue 2b) APPEAR.IN for video and screen sharing. https://appear.in/cellar-interim (as agreed last meeting) 2c) Roll call 4. WG status update - EBML is waiting on AD to proceed 5. EBML IANA concerns raised with Matroska. 6. Steve LHome on Matroska document changes since last meeting. 7. WG plans for advancing documents. =3D=3D=3D=3D=3D=3D minutes from December. CELLAR -- Agenda for Virtual Interim Meeting August 28, 2018 20:00 UTC INFO: https://datatracker.ietf.org/meeting/interim-2018-cellar-04/session= /cellar WEBEX: Meeting number: 313 505 170 Meeting password: dq64cWsm Meeting link: https://ietf.webex.com/ietf/j.php?MTID=3Dme21026faa14be85507cdef66b= 860014e Host key: 763872 Audio connection: 1-650-479-3208 Call-in toll number (US/Canada) Attendees: * Michael Richardson * J=C3=A9r=C3=B4me Martinez * Martin Below * Dave Rice (as call-in user) * Tim Terriberry * Steve Lhomme * Missing: Regrets: * Moritz Bunkus * Reto Kromer * Michael Niedermayer Agenda: 1. Note Well. https://www.ietf.org/about/note-well/ Proposed Agenda: 1. Note Well. 2. Accept draft minutes from September meeting https://datatracker.ietf.org/meeting/interim-2018-cellar-05/materials/minu= tes-interim-2018-cellar-05-201809252000 taken as written. 3. Logistics for Meeting. 2a) Etherpad for notes https://etherpad.tools.ietf.org/p/notes-cellar-virtual04?useMonospac= eFont=3Dtrue 2b) Roll call c) March meeting in March 26. 20:00 UTC. Preference to meetecho... webr= tc based. 21:00 UTC. 4. WG status update - EBML is now in IESG publication queue. Thx to Steven Villereal for the= shepherd writeup. Shepherd writeup: https://datatracker.ietf.org/doc/draft-ietf-cellar-ebm= l/shepherdwriteup/ - work on Matroska and FFV1 issues!! Preview of xml2rfc v3 for FFV1 is at https://htmlpreview.github.io/?http= s://gist.githubusercontent.com/dericed/5ce9c949eeec9042a4ac5e2b222f1cc0/raw= /b315b8d3f5c4b06ecf656fc1fb7e9ad9bd6fd88c/draft-ietf-cellar-ffv1-06.html. - confirm list of dates for meetings: 2019-01-29 2019-02-26 2019-03-26 5. https://github.com/FFmpeg/FFV1/issues (without a version): - new v0,1,3 was posted in September, are there still issues with v1? - Jerome still has to work to do on 0,1,3 version. - https://github.com/FFmpeg/FFV1/pull/100 new feature for v3. Could be= an extension done later on? - https://github.com/FFmpeg/FFV1/pull/111 CRITICAL PATH. Jerome. - hoping to get into WGLC by mid-January. 6. https://github.com/Matroska-Org/matroska-specification/issues - what new issues? - 29 issues open. - draft-ietf-cellar-tags-00 - draft-ietf-cellar-codec-00 - draft-ietf-cellar-matroska-01 (165 pages. Maybe it could be broken u= p further) 7. Any other Business. https://appear.in/cellar-interim We have Tim, Steve, MCR, Jerome, Marti= n,... Dave missing. =3D=3D=3D=3D=3D=3D minutes from January CELLAR -- DRAFT AGENDA for Virtual Interim Meeting January 29, 2019 20:00 UTC DRAFT MINUTES FROM 2018-12-18 meeting will be posted as soon as I find them and/or etherpad is fixed. INFO: https://datatracker.ietf.org/meeting/interim-2019-cellar-01/session/ce= llar https://datatracker.ietf.org/doc/agenda-interim-2019-cellar-01-sessa/ WEB CONFERENCE: https://appear.in/cellar-interim THERE IS NO TELEPHONE DIALIN You can try this at any time. Probably best to turn off camera. Set your name in the upper right. Attendees: * Michael Richardson * J=C3=A9r=C3=B4me Martinez * Dave Rice * Andrew Weaver * Michael Niedermayer * Reto Kromer * Steve Lhomme * Proposed Agenda: 1. Note Well. 2. Accept draft minutes from December meeting https://datatracker.ietf.org/doc/minutes-interim-2018-cellar-08-2018121815= 00/ 3. Logistics for Meeting. 2a) Etherpad for notes https://etherpad.tools.ietf.org/p/notes-cellar-virtual?useMonospaceF= ont=3Dtrue 2b) APPEAR.IN for video and screen sharing. https://appear.in/cellar-interim (as agreed last meeting) 2c) Roll call 4. WG status update - EBML is now in IESG publication queue. - work on Matroska and FFV1 issues!! - confirm list of dates for meetings: 2019-01-29 2019-02-26 2019-04-02 *NEW DATE* No objections. (Steve & Jerome) 5. Dave Rice on updates to EBML to address AD comments. - EBML draft is now updated to version 09 as of the 24th - There's already many updates in github since 09, since version 10 will b= e very soon - I'd say that about 90% of the AD review is resolved, with a few more eit= her to do or in the pull request section to be finalized - Yep typing away 6. Steve LHomme on Matroska document changes since last meeting. - split webm and divX out of this document - not extensions in the ebml sense. - we use fields in matroska which are not valid EBML, so we need to define= them in the Matroska document. - need a way to process the extra profiles - 7. WG plans for advancing documents. - ffv1 version 0,1,3 ---> WGLC? - Michael finished the missing pieces, so now we are ready for more revie= w. - All remaining issues are for version 4. - No relationship to Matroska document. - Peter B may have offered in the past. Peter Bubestinger * FLAC needs some work to turn it into an IETF-style specification. * Matroska is the new focus. From nobody Sun Feb 24 23:12:02 2019 Return-Path: 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 6C453130EDD for ; Sun, 24 Feb 2019 23:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEfK_2jC_R1g for ; Sun, 24 Feb 2019 23:11:58 -0800 (PST) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4C96130EDB for ; Sun, 24 Feb 2019 23:11:57 -0800 (PST) Received: from smtp6.infomaniak.ch (smtp6.infomaniak.ch [83.166.132.19]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x1P7Bsj9031658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 25 Feb 2019 08:11:54 +0100 Received: from Castor ([46.140.0.175]) (authenticated bits=0) by smtp6.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x1P7BqMT056497 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 25 Feb 2019 08:11:54 +0100 Date: Mon, 25 Feb 2019 08:11:54 +0100 From: Reto Kromer To: cellar@ietf.org X-Priority: 3 In-Reply-To: <19999.1551053977@localhost> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4.3 (480) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Cellar] DRAFT AGENDA 2019-02-26 20:00 UTC virtual interim meeting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 07:12:00 -0000 Michael Richardson wrote: >CELLAR -- DRAFT AGENDA for Virtual Interim Meeting >Feburary 26, 2019 20:00 UTC I am afraid, I will be travelling and cannot attend this meeting. Sorry for that! Best regards, Reto From nobody Tue Feb 26 03:48:14 2019 Return-Path: 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 8CD85130ECD for ; Tue, 26 Feb 2019 03:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZBAYIjCUDP4 for ; Tue, 26 Feb 2019 03:48:10 -0800 (PST) Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB5B8126C01 for ; Tue, 26 Feb 2019 03:48:09 -0800 (PST) Received: by mail-wr1-x444.google.com with SMTP id f14so13623152wrg.1 for ; Tue, 26 Feb 2019 03:48:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=qZKc29NMFtGXC/QQOUTkTAtHSsfE8QkQQsS9BUH5fvo=; b=UJF9fhL2HF/W2Rjl3FIM2wpZz0+t8NhLCoPgzgblpYXbgS2sDa462U8qyTUHPWOuEg 7Q+Hl7s7GPXejD2+K7u0PDoSBQdjBnhpIw0pQj+Tb9K8A2bKLZG/lc1zBP5UObn2nhTr hVI+0h4yFhaJb12XskRyR3hLHZMZ1JGnVX0dl5TS/aZjzEq7E50jTL1lOEP49PZUk0US vLi3oPPKGqcNTxUXwVyET10Xzc/Kwz3+lnQMZCq85HHzOvpJLeI5wjrPEOVuwDyw/8zh ZFF925LaW+kHfmgc4lI367Ck0MgRyUxFH/eXLeRJEdETZkd9d/3x2IpBmM6vibgyee5j l92Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=qZKc29NMFtGXC/QQOUTkTAtHSsfE8QkQQsS9BUH5fvo=; b=Pwn9L9MUvM47kIyQx7MNkv4NHYB9+Mr4jlg12bUZuIglNRAPm8yIHWHUjPAey5OkcM E7YNLbD/Gygc+z5TpyaDueILLu+eX3k5nj+Czt4g7TafG705BO3G+cAlp+5L/iFxUf/r 9m1CE7/oHO413lCfFmkvaXe0TX5juRwuBXIAUHZ6u8rM0s0m1Sg8HokgKNo8VMwHW8xN L0ihyA1fwRQHjUDoZyzIrKUPlwlvvpTVnobJOSEzbv1k/eoxIn5QvwWaDMsT6wzZxYZj CXODQn7HmXSzxOztEPL13uQ2p8u7EquoK7Ij3Ugfw2xiZ09MGdKX7JTxBO70Z0MzCflp Pk2g== X-Gm-Message-State: AHQUAubQpfuhgGaQbOGbDGxIHfixxzhRfjjj9DRejT3nFQH8xxKAhoSg g0FuS7IxPYGnesQI5nvT4ajyJzgH7f8TRg== X-Google-Smtp-Source: AHgI3IY6H8zppK2MLeqbntMyOtGx0rXKIUQyzj1WqUZgQTDdRFaJYhcxauc54YlWi41DJfQG6ecLnQ== X-Received: by 2002:adf:a749:: with SMTP id e9mr15436384wrd.210.1551181687569; Tue, 26 Feb 2019 03:48:07 -0800 (PST) Received: from [192.168.3.18] (229.74.9.109.rev.sfr.net. [109.9.74.229]) by smtp.gmail.com with ESMTPSA id x17sm19070660wrd.95.2019.02.26.03.48.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Feb 2019 03:48:06 -0800 (PST) From: Steve Lhomme To: cellar@ietf.org References: <179177e3-86f8-1007-7af3-a261ae0be1e8@googlemail.com> <15787.1550092516@localhost> <99c3da12-280b-cf0a-c71a-c004d98100a4@googlemail.com> <14709.1550106762@localhost> <275f68a9-a617-e685-159f-4f004232ca9d@googlemail.com> Message-ID: <3c906300-1dcd-8567-e960-542a4e6b9a16@matroska.org> Date: Tue, 26 Feb 2019 12:48:08 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <275f68a9-a617-e685-159f-4f004232ca9d@googlemail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] My review of the EBML-specifications X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 11:48:13 -0000 On 18/02/2019 12:32, Andreas Rheinhardt wrote: > Michael Richardson: >> >> Andreas Rheinhardt wrote: >> > Let me summarise the current proposal as I understand it: >> > i) An IANA registry for the EBML elements in the EBML Header is created. >> > ii) The process for registering numbers. This includes a "First come >> > first served" policy for certain ranges like Element IDs with a size >> > of three octets. >> > iii) An IANA Doctype Registry. >> >> iv) the Matroska document will create a new IANA Registry for Element IDs >> in use by Matroska >> >> v) The *Matroska document* will populate the EBML Element ID registry with >> a list of ElementIDs RESERVED. No *EBML* Element ID may be created >> with the same number. >> This is largely as a COURTESY, because in fact the two name spaces >> are intended to be distinct across header and contents, but it's better if >> there is no reuse. >> > I didn't think of this as a courtesy. After all, if these are distinct > namespaces with the potential for overlapping, then resynchronisation > might be affected (in case of errors). In order to prevent this, the > ID of the `EBML` element (`0x1A45DFA3`) should not be allowed to be > reused by any EBML Schema. The resynchronization is indeed a good case for avoiding reuse. I'm less sure about the sub element IDs of the EBML header. On one hand there's not many so it's not a big restriction on the main EBML-based format. On the other hand the number might grow in the future and collide with EBML-based formats that used the same IDs. IMO it still goes down to the namespace. The ID makes sense at one level and none at any other level. So reusing the ID should not be an issue. This is by design. The same ID in different places could be used and this is fine. So IMO we should add a note that the 0x1A45DFA3 cannot be used anywhere in the EBML-based format, as well as the EBML global elements. > And I think it should be explicitly stated that these are different > namespaces. I read the document and thought (ok, I already believed > that before I read the document, but nevertheless) that it is not > allowed to reuse header EBML IDs for the EBML Body. My rationale was > that the EBML's own EBML Schema is part of any other EBML Schema > (either explicitly or implicitly). If this is not so, then we might > need to clarify the following statement: I think it's OK to say the EBML Header Schema is included in the EBML Document. That's also a reason why the EBML 0x1A45DFA3 ID is unique, because there cannot be another at the same level with the same ID. > "An EBML Schema MAY constrain the use of EBML Header Elements (see > EBML Header Elements) by adding or constraining that Element's range > attribute. For example, an EBML Schema MAY constrain the > EBMLMaxSizeLength to a maximum value of 8 or MAY constrain the > EBMLVersion to only support a value of 1. If an EBML Schema adopts the > EBML Header Element as-is, then it is not required to document that > Element within the EBML Schema. If an EBML Schema constrains the range > of an EBML Header Element, then that Element MUST be documented within > an node of the EBML Schema." Sounds good. > So some Header Elements are documented in an EBML Schema. According to > the wording of `Element ID` ("used to uniquely identify a defined EBML > Element within a specific EBML Schema") this means that the documented > EBML Header IDs MUST NOT be reused for the EBML Body. But I don't > think it makes sense to base the decision whether an ID may be reused > or not on whether the Header Element with said ID is constrained or not. IMO it's only for elements in the same path, so it can only happen for the 0x1A45DFA3 one. >> > And even if all these lists were existing and were kept-up-to-date at >> > all times, there is still another problem: If usage of EBML becomes >> > widespread with many projects being created, then IDs that are not in >> > use by any project might become scarce (in particular for shorter IDs >> > -- certainly for length 1 IDs and possibly for length 2 IDs), even >> > when all projects only need a fraction of the IDs. >> >> It's possible. > Actually not. If the namespaces are distint, then the above scenario > can't happen. >> >> > My proposal for this is to reserve some IDs for use for future >> > extensions to the EBML Header. No EBML Schema may invade these >> > reserved IDs. >> >> That's a reasonable proposal. >> >> > Given how valuable IDs with length one are, no such ID should be >> > reserved for this purpose. A few IDs with length two should be >> > reserved as should some length three elements and more length four >> > elements. Registering a shorter ID should of course be subject to >> > stricter scrutinity than registering a longer ID. >> >> We could set the IANA rules all IDs with length two to Specification Required. >> > That won't be required if the namespaces are distinct. > > - Andreas > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > From nobody Tue Feb 26 06:26:27 2019 Return-Path: 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 7EDFD130E5D for ; Tue, 26 Feb 2019 06:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKLryGx0lJCK for ; Tue, 26 Feb 2019 06:26:24 -0800 (PST) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51F41128CE4 for ; Tue, 26 Feb 2019 06:26:23 -0800 (PST) Received: from [IPv6:2001:4bca:201:6825:58d7:590f:9d18:2] ([2001:4bca:116c:e625:58d7:590f:9d18:2]) (AUTH: PLAIN bubestinger@schokokeks.org, TLS: TLSv1.2, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA id 0000000000000084.000000005C754C8A.00003CB7; Tue, 26 Feb 2019 15:26:18 +0100 To: Codec Encoding for LossLess Archiving and Realtime transmission From: "Peter B." Message-ID: <6acec64a-f31f-9de6-8909-0f5e492d6beb@das-werkstatt.com> Date: Tue, 26 Feb 2019 15:26:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Cellar] My review of the FFV1 specification X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 14:26:26 -0000 Hi everyone :) I've read over the current version of the FFV1 specification: https://github.com/FFmpeg/FFV1 It seems complete and quite well to read/understand :D (Especially, considering it's a video codec spec) I don't see anything missing, nor any points that would require discussion. The only "issues" I've encountered were some typos and possible readability improvements. The document is actually very clean and well written. For clarification and auditability, I've created issues on Github:   * pseudo-code: inconsistent syntax?     https://github.com/FFmpeg/FFV1/issues/147   * "version \<= 3": Why the backslash?     https://github.com/FFmpeg/FFV1/issues/149   * Typo: Slice Header in Slice Footer?     https://github.com/FFmpeg/FFV1/issues/150 For all the raised issues, as well as some other very minor wording/typos/spacing, I've created a pull-request: https://github.com/FFmpeg/FFV1/pull/148 Nice greetings, Peter B. From nobody Tue Feb 26 09:29:57 2019 Return-Path: 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 BF930130E5D for ; Tue, 26 Feb 2019 09:29:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDowtaB1H6Ql for ; Tue, 26 Feb 2019 09:29:54 -0800 (PST) Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EACD12D4F2 for ; Tue, 26 Feb 2019 09:29:54 -0800 (PST) Received: by mail-wr1-x441.google.com with SMTP id i12so14912530wrw.0 for ; Tue, 26 Feb 2019 09:29:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=31Lxie7UtygxjxK0vLxwMsXyuX8YoSiGTuxkcck/MwU=; b=heW7HDUqW8ODFcy/HAuBp3O2VJ3axuD+pbq5v/kLXUOqnDCrWy8XkX3dIjHWSE2NSt n755bODk5hGk2gyM1caDbvGtN1yamPShsYg9uPaXoQprNQO6A3jEDaaCzVEm4eAUBVLM TMPgW9oTo47n14MBELNvFEvjFiGB25Q1q0eeKRoarAA3wiWkqDA+KnpagLa9SDf/BpHy 8mAnjUbztPMKEwvfCRNb7RB6UpTinO7HyZ71fckPZunynLEwl1h2jS4vr9UjdaaiRt4j y54sdlso9cdJL5ga3aLvUdHGNb1E1lmzMWU5ZaDbou/FTVEhGLedcN88+ldUpIJ+QDQA xY0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=31Lxie7UtygxjxK0vLxwMsXyuX8YoSiGTuxkcck/MwU=; b=fJr3fPtJ6pwfX/Q2xdE20R8P5lvMzQTAEgYVxfA5EY25ZVwqSNd055HepXD891qYGs 1/Rin1Gy1MJksSS1sLZPW0dfNNhkDvqjCYQYeeTkpoJlUPkl0LTyV91aqYYAa9neCrNJ F71CeldbXVjEGPFZdRVa4OrIiJtGreZDOdSyIyydRMKVRDkYoBNHbCdy7BaZGgKHEXwb iqRs9tY6E6o41oAuXb/zS+xIH/TUwKsBc0Xy05ALboYJq6jg8TFT00rjHkzhd5+MCZZW akG1nOVt1WLgY6DuIm6PbM+otFpMZppX2whlbBSoOrFgStwQgWdkDGbdy7JIXu2Poh6N ukBg== X-Gm-Message-State: AHQUAuZeDQ6VYJJq8rCgceIOshqkYovY2jErWJKoq6Ll+EK6gSwco73R Pd7mB8k7IcEgKhtiaXmeV1dPEDHF+fy1xA== X-Google-Smtp-Source: AHgI3IYfu5w4weMbBNQpprDJqGQ8InE5i4+ueC4hbQ3iwQ80wJfo3VH1A/RXpDoDdtO1hhwn41adYw== X-Received: by 2002:adf:c3c5:: with SMTP id d5mr16689552wrg.308.1551202192308; Tue, 26 Feb 2019 09:29:52 -0800 (PST) Received: from [192.168.3.18] (229.74.9.109.rev.sfr.net. [109.9.74.229]) by smtp.gmail.com with ESMTPSA id l5sm27215wmi.24.2019.02.26.09.29.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Feb 2019 09:29:51 -0800 (PST) To: cellar@ietf.org References: <179177e3-86f8-1007-7af3-a261ae0be1e8@googlemail.com> <15787.1550092516@localhost> <99c3da12-280b-cf0a-c71a-c004d98100a4@googlemail.com> <14709.1550106762@localhost> <275f68a9-a617-e685-159f-4f004232ca9d@googlemail.com> <1f0128a8-ed35-dd30-fbc1-4f7fb2e90f54@xiph.org> From: Steve Lhomme Message-ID: <4b89599e-d428-88b3-5b9c-b2dba500eb61@matroska.org> Date: Tue, 26 Feb 2019 18:29:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <1f0128a8-ed35-dd30-fbc1-4f7fb2e90f54@xiph.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Cellar] My review of the EBML-specifications X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 17:29:57 -0000 On 21/02/2019 03:16, Timothy B. Terriberry wrote: > Andreas Rheinhardt wrote: >> And I think it should be explicitly stated that these are different >> namespaces. I read the document and thought (ok, I already believed > > To be fair, the current document does explicitly state this in 15.1, > "This IANA Registry only applies to Elements contained at least in the > EBML Header, thus including Global Elements." (minor nit: "at least" > is a bit awkward, "that can be contained in the EBML Header" might be > clearer). I created a Pull Request to fix this oddity https://github.com/Matroska-Org/ebml-specification/pull/232 > >> that before I read the document, but nevertheless) that it is not >> allowed to reuse header EBML IDs for the EBML Body. My rationale was >> that the EBML's own EBML Schema is part of any other EBML Schema >> (either explicitly or implicitly). If this is not so, then we might >> need to clarify the following statement: >> >> "An EBML Schema MAY constrain the use of EBML Header Elements (see >> EBML Header Elements) by adding or constraining that Element's range >> attribute. For example, an EBML Schema MAY constrain the >> EBMLMaxSizeLength to a maximum value of 8 or MAY constrain the >> EBMLVersion to only support a value of 1. If an EBML Schema adopts the >> EBML Header Element as-is, then it is not required to document that >> Element within the EBML Schema. If an EBML Schema constrains the range >> of an EBML Header Element, then that Element MUST be documented within >> an node of the EBML Schema." > > Your rationale here is logical and I agree this could use > clarification. The text I quoted above relies on an implied > equivalence between Element ID namespaces and IANA registries, but > that isn't explicitly stated anywhere, and the text you quote seems to > contradict this. Having two separate IANA registries for the same > namespace seems like it would be problematic, but I suppose that is > the issue you are raising. > >>> We could set the IANA rules all IDs with length two to Specification >>> Required. >>> >> That won't be required if the namespaces are distinct. > > But isn't that (that length-two IDs are Specification Required) what > the document currently says? (this question is for Michael) > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Tue Feb 26 10:04:31 2019 Return-Path: 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 86A76130EC1 for ; Tue, 26 Feb 2019 10:04:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CciGBND0DBtt for ; Tue, 26 Feb 2019 10:04:25 -0800 (PST) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11384130ED1 for ; Tue, 26 Feb 2019 10:04:25 -0800 (PST) Received: by mail-wr1-x433.google.com with SMTP id g12so2926474wrm.5 for ; Tue, 26 Feb 2019 10:04:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=neFyhklWSTarUFpybrWBhHk5GseUu7ME3LYFzV3afEk=; b=eDFkU4APLC4aD/EhnmcP7tHmkHqdXI/FhIpxHf3aWupz5QuZfus0BUFAW+n+KdSgN9 D8xFsHbiIERjpzHXltg+Kr5hCubxjTbpfBO6LVyN2SboaovXQpzJBpU+zma6Oh23saH5 iI5OtqaTSxPTnA2g+f/1HKF7YzTvo+KPCgq/By0JnxkIq/FlMtWTVKhh6vTdeFo4DJqU 6c5Thhk6BbUF7B45IdUdWMZ5OM9RHFVKj3njPfjy2xxRgX4d+YGbDhTWhi5lmksRj7xV L8pjjMzNZavCRmKT8TQtDJKKcCiKVZiA50BDD2N04OVwPcPiYXoCrE/Cs4/HodCXvy82 2ccQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=neFyhklWSTarUFpybrWBhHk5GseUu7ME3LYFzV3afEk=; b=Q/dFRrfwN6n9vLh6+F4ygay0sJpfTVQzsWqBFedBKGhtzi7t674XtaJoUPC+aDepGp TvE98d7RfwyvU0KLjcUZyj2HWMdyOooF6vbpHGg8qFI4CMOKHvHMzngWVW6x/Vo1edJL 78uXtNozSfWF6odZxqPpiQXZrTLkEzzer9Epdm47IGeyZ8PBVJYqxZRHaVmS7aR6zW7B EwSQpQhCat81+Owbvy0QgDETCNirRwtys2tEpPzzcXbpagmNEaVvKhi7HVB4XGJvADlg arf9CbhgDZqIDMTWGrN/Ff/GLtobbWh2G+TryLIRiDacQE7Rk3a7935JgUsTh05g7nhN z2CQ== X-Gm-Message-State: AHQUAuaq3gi8IQTcGDJUEm/pzx2Go/R62qg2hoh19fFJ/cdH/1PEexv+ 4IL4REM4vccFLL+Qn9eoTAkDT5suIj0HLA== X-Google-Smtp-Source: AHgI3IaY7Ec9qrVW1xm3kbnfwFingcb89eFXYEHHIQn1hz+0CT7aMZLwYw3+pR+pXRDkAxmHvCbEQQ== X-Received: by 2002:adf:e50e:: with SMTP id j14mr17416667wrm.262.1551204263072; Tue, 26 Feb 2019 10:04:23 -0800 (PST) Received: from [192.168.3.18] (229.74.9.109.rev.sfr.net. [109.9.74.229]) by smtp.gmail.com with ESMTPSA id s5sm14436818wra.77.2019.02.26.10.04.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Feb 2019 10:04:21 -0800 (PST) To: cellar@ietf.org References: <155069292202.31303.6397142165718454854@ietfa.amsl.com> From: Steve Lhomme Message-ID: <6e48cc1a-f819-8e26-bac0-0926c743fd3c@matroska.org> Date: Tue, 26 Feb 2019 19:04:21 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <155069292202.31303.6397142165718454854@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Cellar] Genart last call review of draft-ietf-cellar-ebml-09 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 18:04:29 -0000 Hello Robert, First of all, thanks for your review :) On 20/02/2019 21:02, Robert Sparks wrote: > Reviewer: Robert Sparks > Review result: Not Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-cellar-ebml-09 > Reviewer: Robert Sparks > Review Date: 2019-02-20 > IETF LC End Date: None > IESG Telechat date: Not scheduled for a telechat > > Summary: Not ready for publication as a Proposed Standard > > Note that this is really an early review - IETF LC has not yet been issued for > this draft. > > Issues: > > It's not clear that this group is chartered to produce a general purpose > binary equivalent to XML. Instead, it appears to be chartered to document FFV1 > and Matroska. EBML as it is currently used for those things needs to be > documented, but rather than try to make it into a format that other things > besides the work of this group appears out of scope. If I'm correct, then this > document shouldn't need to create an IANA registry - it need only document > what the group needs (and if the group needs more later, it can update this > document). The abstract and introduction would need to be adjusted to scope > the purpose of the format to supporting the work of this group. My review > assumes a scope of "documenting these existing formats" rather than providing a > general purpose markup language. If I'm wrong and this group is chartered to > produce an alternative for other protocols to use, this needs review from > people who are more expert in that kind of representational design than me. It is indeed not our main goal to make EBML a very generic format. But we need to make it flexible enough so that extending Matroska has a set of rules on how to do it and/or what is not allowed. To do that the EBML format and the Schema that goes with it needs to be flexible, even allowing profiles (WebM) or extensions (DivX ones) to be possible. Also one could say that EBML is half of Matroska, given Matroska is *just* a semantic that uses this binary format. Everything that is defined in EBML doesn't need to be defined again in Matroska, only the semantic of each element and how they interact with each other. All the extensibility that has been put in EBML was that Matroska is flexible enough. The data recovery/safety/etc also goes in the EBML part. But again they are designed for Matroska. > > The document is very hard to absorb given its current structure. It requires > multi-pass reading to figure out. While I like the idea of leaping directly > into security considerations, the draft really needs an introduction that lays > out the high-level structural concepts more linearly. A diagram of the > inherent tree structure would help reinforce the definitions. Showing the > defined types (13.1.5.9) in that diagram would be useful. A shorter > introduction to VINT (not the details of its structure, but why you have such > a construct in the first place) would also help. Also consider examples Yes, adding more examples would definitely make things easier to understand (as the possible range of IDs as currently discussed). > showing the end of Unknown-Sized elements is determined (The description in > the first partial paragraph at the top of page 12 is complicated). It would > also help to introduce the idea of null terminated strings here to smooth the > forward reference from section 8.4 to section 9. CRC-32 elements aren't > defined until towards the end of the document, but non-trivial things are done > with them throughout. Having those introduced, at least conceptually, much > earlier would be good. OK (agreed) > > The third paragraph of the Security Considerations section (including the > bullets) appears to say its ok to treat the following invalid things as valid. > If that's the case, why are they invalid in the first place? I think for some > of them, perhaps text has drifted and they are no longer invalid, but just > to be avoided when it is reasonable to do so? For those that really are invalid, > some text should be added describing _why_ they are ok to accept. OK, we need to review that in depth. > In 5.4 you claim the Size column in the first table refers to the size of the > "VINT_DATA" in bits. The values there are not how many bits of VINT_DATA you > have. If that's what you really want to show, the values should be 7, 14, etc. > rather that 2^7, 2^14. If you mean for the column to show how large an integer > can be represented by a VINT with this octet length, the values need to be > 2^7-1, 2^14-1, etc. It would be helpful to reduce the width of the first > columns so that the last value in the Representation column does not wrap. This is being fixed by showing the range of values possible. It's much more readable IMO. > The last sentence of the 2nd paragraph of section 7 does not parse. Please > simplify it. OK > > There is odd notation at the end of page 12. What does 2^(2_7) mean? That was a formatting bug that has been fixed. > > At section 8, the second sentence scans very badly. Consider breaking it into > two or more sentences so that there is no ambiguity around the concept being > defined. As written, its too easy to misunderstand that the element type > defines a concept that describes definition. OK > At section 11, you say that EBML Documents MUST NOT contain any data that is > not part of an EBML Element, but I think other sections allow that to happen > in data rewrite situations? When voiding data you can still keep the EBML structure intact. Only when there's an off-by-one during voiding you might end up with bytes that are incorrect. > > Why is the unique and persistent requirement SHOULD and not MUST at the top > of page 20? Not sure what you're referring to. > At the definition of name (13.1.5.1), please talk about why this particular set > of characters were chosen. > > Please expand on "the risk of false positives" in 13.1.5.3. The risk here is not > obvious from the current text. > > At 13.1.5.6.1 (a section nesting 5 deep is a document structure warning sign > by itself), in the first bullet I suggest you say "are of the type of the > element" instead of "are integers or floats". What you have now lets me put an > integer on one side and a float on the other. OK > > The range representations in 13.1.5.6.1 don't allow representing 0<=x<1, 0 or any other range with one or more open ends. Why isn't that problematic? No idea. We need to look at that. > The element descriptions in section 13 have range values that don't conform to > the range represnations in 13.1.5.6.1. See 13.2.5 for example (where the range > is "not 0"). This is being worked on. > The last sentence of section 13.1.12 looks like a security problem. Why would > you ever use _any_ elements containing a CRC-32 element that's bad? Some > discussion near the top of the document about what these CRC-32 elements are > supposed to accomplish seems necessary. More needs to be said about the similar > security issues at section 14. The CRC-32 can be used to recover a bit in some cases. But given the nature of EBML it's often OK to parse the content even if you know there's going to be an error inside. In pratice most players never care and parse the data (rather than not playing big chuncks of video). For storage/archiving it's good to know where errors are. > > At 13.2.9, what does "read upper values" mean? > > Nits: > > The definition of Master Element is not a definition - it describes one > propery Master Elements have. AFAICT, the concept isn't concisely defined > anywhere in the document. Good point. > > The definition of Void Element doesn't need to say "damaged data". It > coule be perfectly good data that you are overwriting. Correct > I suggest removing the word "official" from the Element Name definition. OK > > The concept of an Identically Recurring Element is not clear throughout > the document. Some section should give a complete definition, and the > places that call out whether exceptions (such as where the security > considerations discusses Identically Recurring Elements with invalid > CRC-32 elements) are still Identically Recurring Elements or not. > What happens if the values in the invalid CRC-32 elements are different > from each other? > > At section 8.7, second paragraph, first sentence. The sentence is long, and > "equals to" looks like a problem spot for non-native-English readers. Perhaps > "set to the same value as"? > > Micronits: > > Page 9: s/four octet./four octets./ > > Expanding the numbers in section 8.1 and 8.2 isn't really helpful. It would > be better to just say 2^64-1. OK I guess we still have a lot on our plate ;) From nobody Tue Feb 26 10:13:06 2019 Return-Path: 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 1F6A8124408 for ; Tue, 26 Feb 2019 10:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 966EgNrs4RH8 for ; Tue, 26 Feb 2019 10:13:01 -0800 (PST) Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7855D1277CC for ; Tue, 26 Feb 2019 10:13:01 -0800 (PST) Received: from [146.96.19.240] (port=8607 helo=[10.10.201.48]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gyhDt-000evS-7y; Tue, 26 Feb 2019 13:13:00 -0500 From: Dave Rice Message-Id: <45FD90C2-B2B6-4439-B304-9CAF410113C3@dericed.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0C5F8731-9FB3-42F9-B011-9E18507AAD84" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 26 Feb 2019 13:12:56 -0500 In-Reply-To: <6e48cc1a-f819-8e26-bac0-0926c743fd3c@matroska.org> Cc: cellar@ietf.org To: Steve Lhomme References: <155069292202.31303.6397142165718454854@ietfa.amsl.com> <6e48cc1a-f819-8e26-bac0-0926c743fd3c@matroska.org> X-Mailer: Apple Mail (2.3445.102.3) X-OutGoing-Spam-Status: No, score=-2.4 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] Genart last call review of draft-ietf-cellar-ebml-09 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 18:13:04 -0000 --Apple-Mail=_0C5F8731-9FB3-42F9-B011-9E18507AAD84 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 26, 2019, at 1:04 PM, Steve Lhomme = wrote: >=20 > Hello Robert, >=20 > First of all, thanks for your review :) >=20 > On 20/02/2019 21:02, Robert Sparks wrote: >> Reviewer: Robert Sparks >> Review result: Not Ready >>=20 >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please treat these comments just >> like any other last call comments. >>=20 >> For more information, please see the FAQ at >>=20 >> . >>=20 >> Document: draft-ietf-cellar-ebml-09 >> Reviewer: Robert Sparks >> Review Date: 2019-02-20 >> IETF LC End Date: None >> IESG Telechat date: Not scheduled for a telechat >>=20 >> Summary: Not ready for publication as a Proposed Standard >>=20 >> Note that this is really an early review - IETF LC has not yet been = issued for >> this draft. >>=20 >> Issues: >>=20 >> It's not clear that this group is chartered to produce a general = purpose >> binary equivalent to XML. Instead, it appears to be chartered to = document FFV1 >> and Matroska. EBML as it is currently used for those things needs to = be >> documented, but rather than try to make it into a format that other = things >> besides the work of this group appears out of scope. If I'm correct, = then this >> document shouldn't need to create an IANA registry - it need only = document >> what the group needs (and if the group needs more later, it can = update this >> document). The abstract and introduction would need to be adjusted to = scope >> the purpose of the format to supporting the work of this group. My = review >> assumes a scope of "documenting these existing formats" rather than = providing a >> general purpose markup language. If I'm wrong and this group is = chartered to >> produce an alternative for other protocols to use, this needs review = from >> people who are more expert in that kind of representational design = than me. >=20 > It is indeed not our main goal to make EBML a very generic format. But = we need to make it flexible enough so that extending Matroska has a set = of rules on how to do it and/or what is not allowed. To do that the EBML = format and the Schema that goes with it needs to be flexible, even = allowing profiles (WebM) or extensions (DivX ones) to be possible. >=20 > Also one could say that EBML is half of Matroska, given Matroska is = *just* a semantic that uses this binary format. Everything that is = defined in EBML doesn't need to be defined again in Matroska, only the = semantic of each element and how they interact with each other. All the = extensibility that has been put in EBML was that Matroska is flexible = enough. >=20 > The data recovery/safety/etc also goes in the EBML part. But again = they are designed for Matroska. >=20 >>=20 >> The document is very hard to absorb given its current structure. It = requires >> multi-pass reading to figure out. While I like the idea of leaping = directly >> into security considerations, the draft really needs an introduction = that lays >> out the high-level structural concepts more linearly. A diagram of = the >> inherent tree structure would help reinforce the definitions. Showing = the >> defined types (13.1.5.9) in that diagram would be useful. A shorter >> introduction to VINT (not the details of its structure, but why you = have such >> a construct in the first place) would also help. Also consider = examples >=20 > Yes, adding more examples would definitely make things easier to = understand (as the possible range of IDs as currently discussed). >=20 >> showing the end of Unknown-Sized elements is determined (The = description in >> the first partial paragraph at the top of page 12 is complicated). It = would >> also help to introduce the idea of null terminated strings here to = smooth the >> forward reference from section 8.4 to section 9. CRC-32 elements = aren't >> defined until towards the end of the document, but non-trivial things = are done >> with them throughout. Having those introduced, at least conceptually, = much >> earlier would be good. >=20 > OK (agreed) >=20 >>=20 >> The third paragraph of the Security Considerations section (including = the >> bullets) appears to say its ok to treat the following invalid things = as valid. >> If that's the case, why are they invalid in the first place? I think = for some >> of them, perhaps text has drifted and they are no longer invalid, but = just >> to be avoided when it is reasonable to do so? For those that really = are invalid, >> some text should be added describing _why_ they are ok to accept. >=20 > OK, we need to review that in depth. >=20 >> In 5.4 you claim the Size column in the first table refers to the = size of the >> "VINT_DATA" in bits. The values there are not how many bits of = VINT_DATA you >> have. If that's what you really want to show, the values should be 7, = 14, etc. >> rather that 2^7, 2^14. If you mean for the column to show how large = an integer >> can be represented by a VINT with this octet length, the values need = to be >> 2^7-1, 2^14-1, etc. It would be helpful to reduce the width of the = first >> columns so that the last value in the Representation column does not = wrap. >=20 > This is being fixed by showing the range of values possible. It's much = more readable IMO. >=20 >> The last sentence of the 2nd paragraph of section 7 does not parse. = Please >> simplify it. >=20 > OK >=20 >>=20 >> There is odd notation at the end of page 12. What does 2^(2_7) mean? >=20 > That was a formatting bug that has been fixed. >=20 >>=20 >> At section 8, the second sentence scans very badly. Consider breaking = it into >> two or more sentences so that there is no ambiguity around the = concept being >> defined. As written, its too easy to misunderstand that the element = type >> defines a concept that describes definition. >=20 > OK >=20 >> At section 11, you say that EBML Documents MUST NOT contain any data = that is >> not part of an EBML Element, but I think other sections allow that to = happen >> in data rewrite situations? >=20 > When voiding data you can still keep the EBML structure intact. Only = when there's an off-by-one during voiding you might end up with bytes = that are incorrect. >>=20 >> Why is the unique and persistent requirement SHOULD and not MUST at = the top >> of page 20? >=20 > Not sure what you're referring to. This refers to "The "DocType" value for an "EBML Document Type=E2=80=9D = SHOULD be unique and persistent.=E2=80=9D The page count here reflects = https://tools.ietf.org/html/draft-ietf-cellar-ebml-09 = . >> At the definition of name (13.1.5.1), please talk about why this = particular set >> of characters were chosen. >>=20 >> Please expand on "the risk of false positives" in 13.1.5.3. The risk = here is not >> obvious from the current text. >>=20 >> At 13.1.5.6.1 (a section nesting 5 deep is a document structure = warning sign >> by itself), in the first bullet I suggest you say "are of the type of = the >> element" instead of "are integers or floats". What you have now lets = me put an >> integer on one side and a float on the other. > OK >=20 >>=20 >> The range representations in 13.1.5.6.1 don't allow representing = 0<=3Dx<1, 0> or any other range with one or more open ends. Why isn't that = problematic? >=20 > No idea. We need to look at that. Currently we have x-y which is described to mean 0<=3Dx<=3D1, but this = doesn=E2=80=99t account for non-inclusive less than or greater than. >> The element descriptions in section 13 have range values that don't = conform to >> the range represnations in 13.1.5.6.1. See 13.2.5 for example (where = the range >> is "not 0"). >=20 > This is being worked on. >=20 >> The last sentence of section 13.1.12 looks like a security problem. = Why would >> you ever use _any_ elements containing a CRC-32 element that's bad? = Some >> discussion near the top of the document about what these CRC-32 = elements are >> supposed to accomplish seems necessary. More needs to be said about = the similar >> security issues at section 14. >=20 > The CRC-32 can be used to recover a bit in some cases. But given the = nature of EBML it's often OK to parse the content even if you know = there's going to be an error inside. In pratice most players never care = and parse the data (rather than not playing big chuncks of video). For = storage/archiving it's good to know where errors are. >>=20 >> At 13.2.9, what does "read upper values" mean? >>=20 >> Nits: >>=20 >> The definition of Master Element is not a definition - it describes = one >> propery Master Elements have. AFAICT, the concept isn't concisely = defined >> anywhere in the document. >=20 > Good point. >=20 >>=20 >> The definition of Void Element doesn't need to say "damaged data". It >> coule be perfectly good data that you are overwriting. >=20 > Correct >=20 >> I suggest removing the word "official" from the Element Name = definition. >=20 > OK >=20 >>=20 >> The concept of an Identically Recurring Element is not clear = throughout >> the document. Some section should give a complete definition, and the >> places that call out whether exceptions (such as where the security >> considerations discusses Identically Recurring Elements with invalid >> CRC-32 elements) are still Identically Recurring Elements or not. >> What happens if the values in the invalid CRC-32 elements are = different >> from each other? >>=20 >> At section 8.7, second paragraph, first sentence. The sentence is = long, and >> "equals to" looks like a problem spot for non-native-English readers. = Perhaps >> "set to the same value as"? >>=20 >> Micronits: >>=20 >> Page 9: s/four octet./four octets./ >>=20 >> Expanding the numbers in section 8.1 and 8.2 isn't really helpful. It = would >> be better to just say 2^64-1. >=20 > OK >=20 > I guess we still have a lot on our plate ;) >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar = --Apple-Mail=_0C5F8731-9FB3-42F9-B011-9E18507AAD84 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Feb 26, 2019, at 1:04 PM, Steve Lhomme <slhomme@matroska.org> wrote:

Hello Robert,

First of all, thanks for your = review :)

On 20/02/2019 = 21:02, Robert Sparks wrote:
Reviewer: Robert Sparks
Review result: Not Ready

I am = the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being = processed
by the IESG for the IETF Chair.  Please = treat these comments just
like any other last call = comments.

For more information, please see = the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-cellar-ebml-09
Reviewer: Robert Sparks
Review Date: = 2019-02-20
IETF LC End Date: None
IESG = Telechat date: Not scheduled for a telechat

Summary: Not ready for publication as a Proposed Standard

Note that this is really an early review - = IETF LC has not yet been issued for
this draft.

Issues:

It's not = clear that this group is chartered to produce a general purpose
binary equivalent to XML. Instead, it appears to be chartered = to document FFV1
and Matroska. EBML as it is currently = used for those things needs to be
documented, but rather = than try to make it into a format that other things
besides = the work of this group appears out of scope. If I'm correct, then = this
document shouldn't need to create an IANA registry - = it need only document
what the group needs (and if the = group needs more later, it can update this
document). The = abstract and introduction would need to be adjusted to scope
the purpose of the format to supporting the work of this = group. My review
assumes a scope of "documenting these = existing formats" rather than providing a
general purpose = markup language. If I'm wrong and this group is chartered to
produce an alternative for other protocols to use, this needs = review from
people who are more expert in that kind of = representational design than me.

It is indeed not our main goal = to make EBML a very generic format. But we need to make it flexible = enough so that extending Matroska has a set of rules on how to do it = and/or what is not allowed. To do that the EBML format and the Schema = that goes with it needs to be flexible, even allowing profiles (WebM) or = extensions (DivX ones) to be possible.

Also one could say that EBML is half of Matroska, given = Matroska is *just* a semantic that uses this binary format. Everything = that is defined in EBML doesn't need to be defined again in Matroska, = only the semantic of each element and how they interact with each other. = All the extensibility that has been put in EBML was that Matroska is = flexible enough.

The data recovery/safety/etc also goes in the EBML part. But = again they are designed for Matroska.


The document is very = hard to absorb given its current structure. It requires
multi-pass reading to figure out. While I like the idea of = leaping directly
into security considerations, the draft = really needs an introduction that lays
out the high-level = structural concepts more linearly. A diagram of the
inherent= tree structure would help reinforce the definitions. Showing the
defined types (13.1.5.9) in that diagram would be useful. A = shorter
introduction to VINT (not the details of its = structure, but why you have such
a construct in the first = place) would also help. Also consider examples

Yes, adding more examples would definitely make things easier = to understand (as the possible range of IDs as currently = discussed).

showing= the end of Unknown-Sized elements is determined (The description in
the first partial paragraph at the top of page 12 is = complicated). It would
also help to introduce the idea of = null terminated strings here to smooth the
forward = reference from section 8.4 to section 9. CRC-32 elements aren't
defined until towards the end of the document, but = non-trivial things are done
with them throughout. Having = those introduced, at least conceptually, much
earlier = would be good.

OK (agreed)


The third paragraph of = the Security Considerations section (including the
bullets) = appears to say its ok to treat the following invalid things as valid.
If that's the case, why are they invalid in the first place? = I think for some
of them, perhaps text has drifted and = they are no longer invalid, but just
to be avoided when it = is reasonable to do so? For those that really are invalid,
some text should be added describing _why_ they are ok to = accept.

OK, we need to review that in depth.

In = 5.4 you claim the Size column in the first table refers to the size of = the
"VINT_DATA" in bits. The values there are not how many = bits of VINT_DATA you
have. If that's what you really want = to show, the values should be 7, 14, etc.
rather that 2^7, = 2^14. If you mean for the column to show how large an integer
can be represented by a VINT with this octet length, the = values need to be
2^7-1, 2^14-1, etc. It would be helpful = to reduce the width of the first
columns so that the last = value in the Representation column does not wrap.

This is being fixed by showing the range of values possible. = It's much more readable IMO.

The last sentence of the 2nd = paragraph of section 7 does not parse. Please
simplify = it.

OK


There is odd notation at the end of page 12. What does = 2^(2_7) mean?

That was a formatting bug that has been fixed.


At section 8, the second sentence scans very badly. Consider = breaking it into
two or more sentences so that there is no = ambiguity around the concept being
defined. As written, = its too easy to misunderstand that the element type
defines = a concept that describes definition.

OK

At section 11, you say that EBML = Documents MUST NOT contain any data that is
not part of an = EBML Element, but I think other sections allow that to happen
in data rewrite situations?

When voiding data you can still = keep the EBML structure intact. Only when there's an off-by-one during = voiding you might end up with bytes that are incorrect.

Why is the unique and persistent requirement SHOULD and not = MUST at the top
of page 20?

Not sure what you're referring = to.

This = refers to "The "DocType" value for an "EBML Document Type=E2=80=9D = SHOULD be unique and persistent.=E2=80=9D
The page count here = reflects https://tools.ietf.org/html/draft-ietf-cellar-ebml-09.
At = the definition of name (13.1.5.1), please talk about why this particular = set
of characters were chosen.

Please expand on "the risk of false positives" in 13.1.5.3. = The risk here is not
obvious from the current text.

At 13.1.5.6.1 (a section nesting 5 deep is a = document structure warning sign
by itself), in the first = bullet I suggest you say "are of the type of the
element" = instead of "are integers or floats". What you have now lets me put an
integer on one side and a float on the other.
OK


The range representations in 13.1.5.6.1 don't allow = representing 0<=3Dx<1, 0<x<1,
or any other = range with one or more open ends. Why isn't that problematic?

No idea. We need to look at that.

Currently = we have x-y which is described to mean 0<=3Dx<=3D1, but this = doesn=E2=80=99t account for non-inclusive less than or greater = than.

The = element descriptions in section 13 have range values that don't conform = to
the range represnations in 13.1.5.6.1. See 13.2.5 for = example (where the range
is "not 0").

This is being worked on.

The last sentence of section 13.1.12 = looks like a security problem. Why would
you ever use = _any_ elements containing a CRC-32 element that's bad? Some
discussion near the top of the document about what these = CRC-32 elements are
supposed to accomplish seems = necessary. More needs to be said about the similar
security = issues at section 14.

The CRC-32 can be used to recover a bit in some cases. But = given the nature of EBML it's often OK to parse the content even if you = know there's going to be an error inside. In pratice most players never = care and parse the data (rather than not playing big chuncks of video). = For storage/archiving it's good to know where errors are.

At 13.2.9, what does "read upper values" mean?

Nits:

The = definition of Master Element is not a definition - it describes one
propery Master Elements have. AFAICT, the concept isn't = concisely defined
anywhere in the document.

Good point.


The definition of Void = Element doesn't need to say "damaged data". It
coule be = perfectly good data that you are overwriting.

Correct

I suggest removing the word = "official" from the Element Name definition.

OK


The concept of an Identically Recurring Element is not clear = throughout
the document. Some section should give a = complete definition, and the
places that call out whether = exceptions (such as where the security
considerations = discusses Identically Recurring Elements with invalid
CRC-32= elements) are still Identically Recurring Elements or not.
What happens if the values in the invalid CRC-32 elements are = different
from each other?

At = section 8.7, second paragraph, first sentence. The sentence is long, = and
"equals to" looks like a problem spot for = non-native-English readers. Perhaps
"set to the same value = as"?

Micronits:

Page 9: s/four octet./four octets./

Expanding the numbers in section 8.1 and 8.2 isn't really = helpful. It would
be better to just say 2^64-1.

OK

I guess we = still have a lot on our plate ;)

_______________________________________________
Cellar mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar

= --Apple-Mail=_0C5F8731-9FB3-42F9-B011-9E18507AAD84-- From nobody Tue Feb 26 10:52:30 2019 Return-Path: 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 DB2821277CC for ; Tue, 26 Feb 2019 10:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwhWSdFOUG5T for ; Tue, 26 Feb 2019 10:52:25 -0800 (PST) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50A9312958B for ; Tue, 26 Feb 2019 10:52:25 -0800 (PST) Received: by mail-wr1-x429.google.com with SMTP id o17so15170795wrw.3 for ; Tue, 26 Feb 2019 10:52:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=aiNxGsKqndIRDrPy0Jgl6S7YilAOBG2CQtqb1o9cI3k=; b=DBowKH0rWWgwdDO2oc4gXMBTsvNMW5bhc/osmf+k9MNysOKSJrGR8Ii3BPWnmpFGLk nt+I7f3DGogaA0XyxokteDCPtC13+I68X0f9UIWVoq+y9//l23z7O+O7ot+45WImq46b xCu+GVenm0PQqaGBosrtU0QoDGIu3qgnzSRJ35esBlB5c4PwXMPH7u0JCH5efKuv6N35 IS+EeGobaHbWmccb3898UvDbkY8aF3gP+4hWbFCEKPsFYDoZESrQK67tf/d+f/8eQ5L+ sfnrCreKxaII5cy//HX74BzvqHW8LUpmEPQGqyxpc1yIBoClOpyb/GjJugAWc8KH/VHd XzXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=aiNxGsKqndIRDrPy0Jgl6S7YilAOBG2CQtqb1o9cI3k=; b=ct3WG4ezY2Oe1itax4PfaHyTt5U/fk3CMQTKt9ebao7lnL4f5l62R2MdMB8SamjlXR 2408xRYIWNGAXwQjOis5LJXkaIbfaMEZDkp4DDkJAHFRPFe80+SqGGgjINnguJDonexn qMMCG3O0N+jPw8jQB42htb29EPcwRcTFCytQjvYBuT4UUonrNxEifZRjHcX8FdL0LCJC NIs5V+hkwd0Ebf7Mpp0ufdrovjeGSnFToqGi8lc5i/19j2VBWCmfplEw3uDCNqBGChDu C2DgYS8X1MQfjP6DrKYKrg8EzVyFWMzCB375VfsOLnIimuX1eh2QXRPTvw4WBjDxOh1d 5hDg== X-Gm-Message-State: AHQUAuakYdw7iqNsqUr2Fb95XoHSQhDcLuNMgvVKiNK1Ov4vUt9uFzGU csw0/DdmcvjJN2kim+E7b2LRTrWKlnxcrg== X-Google-Smtp-Source: AHgI3IbNSCGL2WeOdDtUnlp3utGavzKet5IYf4zhAize8MnQ4/2DR2ImsLcBv8gDtwns3pwjK/sWmA== X-Received: by 2002:adf:cd02:: with SMTP id w2mr13154141wrm.30.1551207143177; Tue, 26 Feb 2019 10:52:23 -0800 (PST) Received: from [192.168.3.18] (229.74.9.109.rev.sfr.net. [109.9.74.229]) by smtp.gmail.com with ESMTPSA id n14sm15450553wrx.24.2019.02.26.10.52.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Feb 2019 10:52:22 -0800 (PST) To: cellar@ietf.org References: <155069292202.31303.6397142165718454854@ietfa.amsl.com> <1331770b-df2d-0c9f-45c7-db36db34fc00@nostrum.com> From: Steve Lhomme Message-ID: Date: Tue, 26 Feb 2019 19:52:21 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <1331770b-df2d-0c9f-45c7-db36db34fc00@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Cellar] IEEE 754 reference (was Re: [Gen-art] Genart last call review of draft-ietf-cellar-ebml-09) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 18:52:29 -0000 I tried changing that but the xml2rfc tool doesn't seem to know about this version and doesn't produce a valid link (actually it just fails to build anything). The entry to produce the correct link is missing in here https://xml2rfc.tools.ietf.org/public/rfc/bibxml2/ On 21/02/2019 05:12, Robert Sparks wrote: > Also, the reference to IEEE 754 should probably point to the 2008 > version instead of the 1985 version (unless you've got a specific > reason to use the older one?) > > RjS > > On 2/20/19 2:02 PM, Robert Sparks wrote: >> Reviewer: Robert Sparks >> Review result: Not Ready >> >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair.  Please treat these comments just >> like any other last call comments. >> >> For more information, please see the FAQ at >> >> . >> >> Document: draft-ietf-cellar-ebml-09 >> Reviewer: Robert Sparks >> Review Date: 2019-02-20 >> IETF LC End Date: None >> IESG Telechat date: Not scheduled for a telechat >> >> Summary: Not ready for publication as a Proposed Standard >> >> Note that this is really an early review - IETF LC has not yet been >> issued for >> this draft. >> >> Issues: >> >> It's not clear that this group is chartered to produce a general purpose >> binary equivalent to XML. Instead, it appears to be chartered to >> document FFV1 >> and Matroska. EBML as it is currently used for those things needs to be >> documented, but rather than try to make it into a format that other >> things >> besides the work of this group appears out of scope. If I'm correct, >> then this >> document shouldn't need to create an IANA registry - it need only >> document >> what the group needs (and if the group needs more later, it can >> update this >> document). The abstract and introduction would need to be adjusted to >> scope >> the purpose of the format to supporting the work of this group. My >> review >> assumes a scope of "documenting these existing formats" rather than >> providing a >> general purpose markup language. If I'm wrong and this group is >> chartered to >> produce an alternative for other protocols to use, this needs review >> from >> people who are more expert in that kind of representational design >> than me. >> >> The document is very hard to absorb given its current structure. It >> requires >> multi-pass reading to figure out. While I like the idea of leaping >> directly >> into security considerations, the draft really needs an introduction >> that lays >> out the high-level structural concepts more linearly. A diagram of the >> inherent tree structure would help reinforce the definitions. Showing >> the >> defined types (13.1.5.9) in that diagram would be useful. A shorter >> introduction to VINT (not the details of its structure, but why you >> have such >> a construct in the first place) would also help. Also consider examples >> showing the end of Unknown-Sized elements is determined (The >> description in >> the first partial paragraph at the top of page 12 is complicated). It >> would >> also help to introduce the idea of null terminated strings here to >> smooth the >> forward reference from section 8.4 to section 9. CRC-32 elements aren't >> defined until towards the end of the document, but non-trivial things >> are done >> with them throughout. Having those introduced, at least conceptually, >> much >> earlier would be good. >> >> The third paragraph of the Security Considerations section (including >> the >> bullets) appears to say its ok to treat the following invalid things >> as valid. >> If that's the case, why are they invalid in the first place? I think >> for some >> of them, perhaps text has drifted and they are no longer invalid, but >> just >> to be avoided when it is reasonable to do so? For those that really >> are invalid, >> some text should be added describing _why_ they are ok to accept. >> >> In 5.4 you claim the Size column in the first table refers to the >> size of the >> "VINT_DATA" in bits. The values there are not how many bits of >> VINT_DATA you >> have. If that's what you really want to show, the values should be 7, >> 14, etc. >> rather that 2^7, 2^14. If you mean for the column to show how large >> an integer >> can be represented by a VINT with this octet length, the values need >> to be >> 2^7-1, 2^14-1, etc. It would be helpful to reduce the width of the first >> columns so that the last value in the Representation column does not >> wrap. >> >> The last sentence of the 2nd paragraph of section 7 does not parse. >> Please >> simplify it. >> >> There is odd notation at the end of page 12. What does 2^(2_7) mean? >> >> At section 8, the second sentence scans very badly. Consider breaking >> it into >> two or more sentences so that there is no ambiguity around the >> concept being >> defined. As written, its too easy to misunderstand that the element type >> defines a concept that describes definition. >> >> At section 11, you say that EBML Documents MUST NOT contain any data >> that is >> not part of an EBML Element, but I think other sections allow that to >> happen >> in data rewrite situations? >> >> Why is the unique and persistent requirement SHOULD and not MUST at >> the top >> of page 20? >> >> At the definition of name (13.1.5.1), please talk about why this >> particular set >> of characters were chosen. >> >> Please expand on "the risk of false positives" in 13.1.5.3. The risk >> here is not >> obvious from the current text. >> >> At 13.1.5.6.1 (a section nesting 5 deep is a document structure >> warning sign >> by itself), in the first bullet I suggest you say "are of the type of >> the >> element" instead of "are integers or floats". What you have now lets >> me put an >> integer on one side and a float on the other. >> >> The range representations in 13.1.5.6.1 don't allow representing >> 0<=x<1, 0> or any other range with one or more open ends. Why isn't that >> problematic? >> >> The element descriptions in section 13 have range values that don't >> conform to >> the range represnations in 13.1.5.6.1. See 13.2.5 for example (where >> the range >> is "not 0"). >> >> The last sentence of section 13.1.12 looks like a security problem. >> Why would >> you ever use _any_ elements containing a CRC-32 element that's bad? Some >> discussion near the top of the document about what these CRC-32 >> elements are >> supposed to accomplish seems necessary. More needs to be said about >> the similar >> security issues at section 14. >> >> At 13.2.9, what does "read upper values" mean? >> >> Nits: >> >> The definition of Master Element is not a definition - it describes one >> propery Master Elements have. AFAICT, the concept isn't concisely >> defined >> anywhere in the document. >> >> The definition of Void Element doesn't need to say "damaged data". It >> coule be perfectly good data that you are overwriting. >> >> I suggest removing the word "official" from the Element Name definition. >> >> The concept of an Identically Recurring Element is not clear throughout >> the document. Some section should give a complete definition, and the >> places that call out whether exceptions (such as where the security >> considerations discusses Identically Recurring Elements with invalid >> CRC-32 elements) are still Identically Recurring Elements or not. >> What happens if the values in the invalid CRC-32 elements are different >> from each other? >> >> At section 8.7, second paragraph, first sentence. The sentence is >> long, and >> "equals to" looks like a problem spot for non-native-English readers. >> Perhaps >> "set to the same value as"? >> >> Micronits: >> >> Page 9: s/four octet./four octets./ >> >> Expanding the numbers in section 8.1 and 8.2 isn't really helpful. It >> would >> be better to just say 2^64-1. >> >> >> _______________________________________________ >> Gen-art mailing list >> Gen-art@ietf.org >> https://www.ietf.org/mailman/listinfo/gen-art > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Tue Feb 26 11:56:48 2019 Return-Path: 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 C1DAA129B88 for ; Tue, 26 Feb 2019 11:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzFdefNuRFmL for ; Tue, 26 Feb 2019 11:56:46 -0800 (PST) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C03A7128AFB for ; Tue, 26 Feb 2019 11:56:45 -0800 (PST) Received: by mail-wr1-x42b.google.com with SMTP id w2so15325342wrt.11 for ; Tue, 26 Feb 2019 11:56:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=88ylAZ+3jgkxILNWGmBqNPWRpihlEB51LrX+ie1lq6Q=; b=MDHoWQ68hBP9TjZBDyxB9gNr1zgGz+DU9G6V2R6rnVzeWJwoaXTl1hJ8miDJJl4Ede erQEuo9uEt3u1gBw/hfexI2tyPr9UDEioEio/IGcm6JtrQhyeOI00fBEcdx9uclDslbF KWVu45SaV2NUdO/NvdhEC8UB9BB2WgP800J6own/9HiQTQ0wa+f5JAQMYDQTqpsGgcQN PVbETvTOoreJ+n+91pGsmgIWssN29gTyI0PlopUg5jn9DR0/Hg9ItMFQceuL4u62eYeC sqioSzw/dsKHe9LQadybtGjQLO9y/lWsuWSM9ZSktIr9dI8Wzqlt29z4/ipXUxmEdSej 27QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=88ylAZ+3jgkxILNWGmBqNPWRpihlEB51LrX+ie1lq6Q=; b=B+qmXO8J75zHDt/wIYdfVgkKgaeT6iaMOeLh3q3yj6kKPICHktUYE1GTwA8WfkVCv7 LCxhh1RoBwMMpx3MSOqhU3qfs5zNTNS/nOfGg4YRqkTiKsz26NJeALBpEqpCF889w574 W4zMaR+t2DAtpgZTd6/0K+juUzGdDhIBbCs3H6yVd9S+341R/3NLYVVWk25qjOUyG//J 9LeoAkHRUv8tmANyT5EVhUC/QzobtQnFTB3ahiIScomnh76gQrW2gZJ7WkVALVLuHVNK 7z4odM8yPNh6f5N3/CaEj25ZCHkskRKB7+h3o9TNp4akTjSWMBmhNy3kupT4W1pyu+p0 iMbA== X-Gm-Message-State: AHQUAuYG8H/9AZ3YNzI0y8/f87GFm4oL3QrHR+9nv6RGABmyEIlDe15i BV/F7IjQ6ADGR02+2fGexVR5IgrrsB04PA== X-Google-Smtp-Source: AHgI3IZw/S8Ale9meu1CfHUQ6MuC+ZLuwKXX6PeYEKuTTr7kXMxojmYsOvDlkUrL8EGSgf80mybTSQ== X-Received: by 2002:adf:fc49:: with SMTP id e9mr18904461wrs.2.1551211003780; Tue, 26 Feb 2019 11:56:43 -0800 (PST) Received: from [192.168.3.18] (229.74.9.109.rev.sfr.net. [109.9.74.229]) by smtp.gmail.com with ESMTPSA id o12sm32439045wre.0.2019.02.26.11.56.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Feb 2019 11:56:41 -0800 (PST) From: Steve Lhomme To: cellar@ietf.org References: <155069292202.31303.6397142165718454854@ietfa.amsl.com> <6e48cc1a-f819-8e26-bac0-0926c743fd3c@matroska.org> Message-ID: <9f495208-9ff0-31b1-d295-75eda6bf78c9@matroska.org> Date: Tue, 26 Feb 2019 20:56:41 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <6e48cc1a-f819-8e26-bac0-0926c743fd3c@matroska.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Cellar] Genart last call review of draft-ietf-cellar-ebml-09 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 19:56:48 -0000 On 26/02/2019 19:04, Steve Lhomme wrote: > The third paragraph of the Security Considerations section (including the > bullets) appears to say its ok to treat the following invalid things > as valid. > If that's the case, why are they invalid in the first place? I think > for some > of them, perhaps text has drifted and they are no longer invalid, but > just > to be avoided when it is reasonable to do so? For those that really > are invalid, > some text should be added describing _why_ they are ok to accept. The following are considered usable even if not strictly valid: - Invalid "Element IDs" that are longer than the limit stated in the "EBMLMaxIDLength Element" of the "EBML Header". - Invalid "Element IDs" that are not encoded in the shortest-possible way. - Invalid "Element Data Size" values that are longer than the limit stated in the "EBMLMaxSizeLength Element" of the "EBML Header". These are not really invalid, just that they don't match what the EBML header says. They might be perfectly usable despite that. - Invalid "Element IDs" comprised of reserved values. This is more problematic. But the reserved values mean they could be used one day, so you may not choke on them. Either way it's fine to be strict or not. - Usage of "0x00" octets in "EBML Elements" with a string type. If found at the end of the string this is a waste of space. It may also be shortened strings in the middle. This may be explained better. All these seem to just allow a parser to be very strict or very forgivable. But it's all usable data. From nobody Tue Feb 26 12:35:42 2019 Return-Path: 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 4973F128CF2 for ; Tue, 26 Feb 2019 12:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2aS5DLtlycg for ; Tue, 26 Feb 2019 12:35:38 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E0621288BD for ; Tue, 26 Feb 2019 12:35:38 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 6500D3826A for ; Tue, 26 Feb 2019 15:35:33 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 8D411BB7; Tue, 26 Feb 2019 15:35:36 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8BD5EB90 for ; Tue, 26 Feb 2019 15:35:36 -0500 (EST) From: Michael Richardson To: cellar@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Cellar] minutes and agenda items X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 20:35:41 -0000 --=-=-= Content-Type: text/plain As noted in the agenda, I have started pushing my notes to: https://github.com/cellar-wg/chair-notes pull requests most appreciated for edits of minutes. otherwise, you can find minutes at: https://datatracker.ietf.org/wg/cellar/meetings/ I have uploaded today's DRAFT minutes there, even though they have not been approved, because otherwise they won't get included into the IETF104 proceedings, and the upload function is disabled at the end of each IETF meeting. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlx1oxgACgkQgItw+93Q 3WWJhQgAsBiHwKwMBZfIaTPyKMwgikb7vRsCqtA9bP3tx6bMFzGQuTS5fAM7ej8V eEI4ilw5lS5sKROF2Frc+cbEOaSL2r+O0480iSrHzKifRqURLAKT2XPLATXis5pw tgroagwxTUya9LX/FS3nLkFFZ2ZG2QJJSuTMfF/x1dq0A1oNGeEjPwYAprJIxoO4 51FbGjo8RkelOWGYBKg/D1F44BdOdca7L/EopdJiYak9gxkBXdjVvmk1L2mqbTyN ReJpRliLTTjPyY+hBVvS5/6ZXqgJbciOKPRAMZRSS0rP+yXG43aMcxi5tt4qu0cb gxCVqZPs1XdGTi4RrD+TvdVbHRffOw== =X40z -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 27 04:59:51 2019 Return-Path: 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 2A793128D52 for ; Wed, 27 Feb 2019 04:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A_BNx-ElmIgF for ; Wed, 27 Feb 2019 04:59:48 -0800 (PST) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB838130EBE for ; Wed, 27 Feb 2019 04:59:47 -0800 (PST) Received: by mail-wr1-x42f.google.com with SMTP id w6so14594325wrs.4 for ; Wed, 27 Feb 2019 04:59:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=gHrdZ7CFrY9RNofM91j5LeGZnvJrhZQpJabECVOD0XU=; b=X+Tbmv/qrq8pxGxL2aHsSReOqDfPFn8V3DPG4rLAZHABz8zYFKg33/99WavM53Krnc 0znUr54vs7IR9KlLlEK/0gwosEAQFb5oIPMH6KwupoRsIi+9N5kqoLBhlQsI77IcOsEK eQpvqdMgzQ2fDejPd/FxWTbrFNBFxSyEXi7+aRJ3DzLaGNu9JC8T8lginJ6buTY7rpti u86Vhif994TP2tW4Xs0s2QmtgziG0PMYwGGXnGJDFnrC4kDcA1A/d8Bqtj1THde/97e7 7MAN2Cg1N5cdO5bB8/LFA5wWu7nY7b7DhPfLUkuLWtWQvHO7JggmnEkUXES5wFL1dAf8 1qlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=gHrdZ7CFrY9RNofM91j5LeGZnvJrhZQpJabECVOD0XU=; b=SKYDDTDyf5KS4Mh+rqS5svB5jGwJEL1z02pj+zLnp0YtsYT8JBS2bc07sw7B1PchLj FoftC01nW3B1nHuQ1C5oYumtCUY+y4TEIkhXKmRSn/mzz9Ovsv7G5h1yEh47V2tHSo0D bHwUdo6nWnXlC9JVi290T4ImoBkv3tYJEnmVI80PAqbFD0HKVhMf4lXeA+hb3wvg1Bz3 tO6dyFSTO/OgyWAGGllLCNxaMgGmUoafB9r0Ahyw/DNevAYN7kC7djeJSs/VuUAKRBPR wU2EbwNCxv5eAkZZo1qsjW8hgej48bXqzq4dokjJEwsLfrsN0kg8TO5ASTyAS3xcqXJj 6Row== X-Gm-Message-State: APjAAAWVBpujRbkjO2oh3noxZl5USp4wpLV1OOC5BO2vEBKxZa4OE89c ZS8nYplszulbLa10lduYJTfsbS2dIDaSoA== X-Google-Smtp-Source: APXvYqx0Q2wEE+PBi+48SK/mgoezPMRE6s4UTET88c25xUfoxhojRAJmgKTscQIkSQ0TCRD0yRQQNQ== X-Received: by 2002:adf:f690:: with SMTP id v16mr2379852wrp.139.1551272385742; Wed, 27 Feb 2019 04:59:45 -0800 (PST) Received: from [192.168.3.18] (229.74.9.109.rev.sfr.net. [109.9.74.229]) by smtp.gmail.com with ESMTPSA id e7sm19023643wrw.35.2019.02.27.04.59.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Feb 2019 04:59:44 -0800 (PST) To: Dave Rice Cc: cellar@ietf.org References: <155069292202.31303.6397142165718454854@ietfa.amsl.com> <6e48cc1a-f819-8e26-bac0-0926c743fd3c@matroska.org> <45FD90C2-B2B6-4439-B304-9CAF410113C3@dericed.com> From: Steve Lhomme Message-ID: Date: Wed, 27 Feb 2019 13:59:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <45FD90C2-B2B6-4439-B304-9CAF410113C3@dericed.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Cellar] Genart last call review of draft-ietf-cellar-ebml-09 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 12:59:50 -0000 On 26/02/2019 19:12, Dave Rice wrote: > > >> On Feb 26, 2019, at 1:04 PM, Steve Lhomme > > wrote: > > This refers to "The "DocType" value for an "EBML Document Type” SHOULD > be unique and persistent.” > The page count here reflects > https://tools.ietf.org/html/draft-ietf-cellar-ebml-09. > OK, this was already changed into a MUST in the pending version From nobody Wed Feb 27 07:46:11 2019 Return-Path: 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 26EBD131007 for ; Wed, 27 Feb 2019 07:46:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Prme1fVKFhNR for ; Wed, 27 Feb 2019 07:46:00 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2AB9131071 for ; Wed, 27 Feb 2019 07:46:00 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 03C7C380BE; Wed, 27 Feb 2019 10:45:54 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 547A285; Wed, 27 Feb 2019 10:45:58 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 518F05F; Wed, 27 Feb 2019 10:45:58 -0500 (EST) From: Michael Richardson To: Steve Lhomme cc: cellar@ietf.org In-Reply-To: <3c906300-1dcd-8567-e960-542a4e6b9a16@matroska.org> References: <179177e3-86f8-1007-7af3-a261ae0be1e8@googlemail.com> <15787.1550092516@localhost> <99c3da12-280b-cf0a-c71a-c004d98100a4@googlemail.com> <14709.1550106762@localhost> <275f68a9-a617-e685-159f-4f004232ca9d@googlemail.com> <3c906300-1dcd-8567-e960-542a4e6b9a16@matroska.org> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Feb 2019 10:45:58 -0500 Message-ID: <25763.1551282358@localhost> Archived-At: Subject: Re: [Cellar] My review of the EBML-specifications X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 15:46:10 -0000 Steve Lhomme wrote: >> I didn't think of this as a courtesy. After all, if these are disti= nct >> namespaces with the potential for overlapping, then resynchronisati= on >> might be affected (in case of errors). In order to prevent this, th= e >> ID of the `EBML` element (`0x1A45DFA3`) should not be allowed to be >> reused by any EBML Schema. > The resynchronization is indeed a good case for avoiding reuse. I'm = less sure > about the sub element IDs of the EBML header. On one hand there's no= t many so > it's not a big restriction on the main EBML-based format. On the oth= er hand > the number might grow in the future and collide with EBML-based form= ats that > used the same IDs. Should the resynchronization goals be stated somewhere? > IMO it still goes down to the namespace. The ID makes sense at one l= evel and > none at any other level. So reusing the ID should not be an issue. T= his is by > design. The same ID in different places could be used and this is fi= ne. > So IMO we should add a note that the 0x1A45DFA3 cannot be used anywh= ere in > the EBML-based format, as well as the EBML global elements. Exactly. -- ] Never tell me the odds! | ipv6 mesh networ= ks [ ] Michael Richardson, Sandelman Software Works | IoT architect= [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ From nobody Wed Feb 27 14:26:18 2019 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1BE131175; Wed, 27 Feb 2019 14:26:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Michael Richardson To: X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Cc: mcr+ietf@sandelman.ca, Michael Richardson , iesg-secretary@ietf.org, cellar@ietf.org, cellar-chairs@ietf.org Message-ID: <155130637631.14077.7924169710109097319.idtracker@ietfa.amsl.com> Date: Wed, 27 Feb 2019 14:26:16 -0800 Archived-At: Subject: [Cellar] Publication has been requested for draft-ietf-cellar-ffv1-07 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 22:26:16 -0000 Michael Richardson has requested publication of draft-ietf-cellar-ffv1-07 as Informational on behalf of the CELLAR working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/