From nobody Sun Dec 1 13:14:33 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 030CC120113 for ; Sun, 1 Dec 2019 13:14:32 -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_HELO_NONE=0.001, 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 XMy5teiFMXVu for ; Sun, 1 Dec 2019 13:14:30 -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 5450B120110 for ; Sun, 1 Dec 2019 13:14:30 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6A5873897B for ; Sun, 1 Dec 2019 16:10:56 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6E8AB726 for ; Sun, 1 Dec 2019 16:14:29 -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] DRAFT AGENDA for VIRTUAL INTERIM MEETING 2019-12-10 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, 01 Dec 2019 21:14:32 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable {additions and changes welcome} CELLAR -- DRAFT AGENDA for Virtual Interim Meeting December 10, 2019 19:00 UTC 21:00 Amsterdam 15:00 NYC 12:00 San Francisco INFO: https://datatracker.ietf.org/meeting/interim-2019-cellar-10/session/cell= ar https://datatracker.ietf.org/doc/agenda-interim-2019-cellar-10-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 1. Note Well. 2. Accept draft minutes from September 24 meeting (attached below) 3. Logistics for Meeting. 2a) Etherpad for notes https://etherpad.ietf.org/p/notes-cellar-virtual?useMonospaceFont=3D= true 2b) APPEAR.IN is not called "whereby.com" https://whereby.com/cellar-interimw 2c) Roll call 4. Establish meeting schedule for 2020! 5. WG status update * EBML -- version 13 was posted 2019-10-22, on IESG telechat for 2019-12= -05 * FFV1 -- version 10 was posted 2019-10-23, waiting for AD writeup. 6. Work on Matroska issues. 7. Any other business. NEXT meeting is TBD. =3D=3D=3D=3D CELLAR -- DRAFT AGENDA for Virtual Interim Meeting October 22, 2019 19:00 UTC 21:00 Amsterdam 15:00 NYC 12:00 San Francisco Present: 1. Michael Richardson 1. Martin Below 1. J=C3=A9r=C3=B4me Martinez 1. Steve Lhomme 1. Dave Rice INFO: https://datatracker.ietf.org/meeting/interim-2019-cellar-09/session/cell= ar https://datatracker.ietf.org/doc/agenda-interim-2019-cellar-09-sessa/ WEB CONFERENCE: https://whereby.com/cellar-interim THERE IS NO TELEPHONE DIALIN (You can try this at any time.) These notes at: https://github.com/cellar-wg/chair-notes 1. Note Well. https://www.ietf.org/about/note-well/ 2. Accept draft minutes from September 24 meeting (attached below) 3. Logistics for Meeting. 2a) Etherpad for notes https://etherpad.ietf.org/p/notes-cellar-virtual?useMonospaceFont=3D= true 2b) APPEAR.IN is now called "whereby.com" https://whereby.com/cellar-interim 2c) Roll call 4. WG status update * EBML -- version 13 was posted 2019-10-22, waiting for AD. * FFV1 -- version 10 was posted 2019-10-10, waiting for AD. 5. Interest in using gerrithub.io? For non-CLI uses, github has limitations lacking a web-based rebase process. http://gerrithub.io/ 6. Work on Matroska issues. ** now that EBML has provided the side-data container, we can start addin= g side-data types to Matroska. ** Google (WEBM) has created some new blocks (for HDR information) in the= container, and we need to make sure we do not collide. https://github.= com/cellar-wg/matroska-specification/issues/345 *** can we get them to coordinate better? *** now it is finished, but we need to try again. We could say that valu= es up to 10 are reserved. EBML issue: implementation note default? publish a new version? mcr: says go ahead with new version as you wish. FFV1: still waiting, but there are some issues raised by new decoder for v3= . And we should clarify the text. 7. Any other business. NEXT meeting is 2019-12-03 moved to 2019-12-10. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl3kLTUACgkQgItw+93Q 3WXpOAf+M63wKis+i1LBN87RrGywywDH4rPE5lk8/wBWorcsj2CpBr79DUfIpEOE LFpAxVAUVpkiYSi+ZywlmqpFwAKJ8lJKu5B/anRZAHKsnDBkKeWAnkWXjam9VNNZ BgYEkRx862k22ob9UZlaqla9ncsTLRL9eAcuuWdDpVYGDHVnNCB8N3iqy57H0gga Z/VOq3lPXRfYWi6E50MS80qf/V3Acucj0epUlQZSfbCAm7TfWksBA0Jgbd2fm8WR TViUcvyasl5tmseNxXFHi0d9gG4zL+5n7KWZzncpgBkA2pfd6nLifzd27TSv2yUb ahCeH6G3tWTZIq46f3PwJcRDUrf9pg== =b9nW -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Dec 1 13:46:58 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 D00DD12008F; Sun, 1 Dec 2019 13:46:55 -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.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <157523681575.22116.14691297918166516760@ietfa.amsl.com> Date: Sun, 01 Dec 2019 13:46:55 -0800 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-ebml-14.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: Sun, 01 Dec 2019 21:46:56 -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 : Extensible Binary Meta Language Authors : Steve Lhomme Dave Rice Moritz Bunkus Filename : draft-ietf-cellar-ebml-14.txt Pages : 57 Date : 2019-12-01 Abstract: This document defines the Extensible Binary Meta Language (EBML) format as a generalized file format for any type of data in a hierarchical form. EBML is designed as a binary equivalent to XML and uses a storage-efficient approach to build nested Elements with identifiers, lengths, and values. Similar to how an XML Schema defines the structure and semantics of an XML Document, this document defines how EBML Schemas are created to convey the semantics of an EBML Document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cellar-ebml-14 https://datatracker.ietf.org/doc/html/draft-ietf-cellar-ebml-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ebml-14 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 Sun Dec 1 13:53:52 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 6B4471200B9 for ; Sun, 1 Dec 2019 13:53:51 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 EKfWHjX0MWlJ for ; Sun, 1 Dec 2019 13:53:49 -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 AA45A12008F for ; Sun, 1 Dec 2019 13:53:49 -0800 (PST) Received: from cpe-104-162-94-162.nyc.res.rr.com ([104.162.94.162]:41289 helo=[10.0.1.6]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1ibX9z-001WjX-JF; Sun, 01 Dec 2019 16:53:48 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Dave Rice In-Reply-To: <14450.1575234869@localhost> Date: Sun, 1 Dec 2019 16:53:40 -0500 Cc: cellar@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <14450.1575234869@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3601.0.10) 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] DRAFT AGENDA for VIRTUAL INTERIM MEETING 2019-12-10 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, 01 Dec 2019 21:53:51 -0000 > On Dec 1, 2019, at 4:14 PM, Michael Richardson = wrote: >=20 >=20 > {additions and changes welcome} >=20 > CELLAR -- DRAFT AGENDA for Virtual Interim Meeting > December 10, 2019 19:00 UTC > 21:00 Amsterdam > 15:00 NYC > 12:00 San Francisco >=20 > INFO: > = https://datatracker.ietf.org/meeting/interim-2019-cellar-10/session/cellar= > = https://datatracker.ietf.org/doc/agenda-interim-2019-cellar-10-sessa/ >=20 > 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 >=20 > 1. Note Well. > 2. Accept draft minutes from September 24 meeting (attached below) >=20 > 3. Logistics for Meeting. > 2a) Etherpad for notes > = https://etherpad.ietf.org/p/notes-cellar-virtual?useMonospaceFont=3Dtrue >=20 > 2b) APPEAR.IN is not called "whereby.com" > https://whereby.com/cellar-interimw >=20 > 2c) Roll call >=20 > 4. Establish meeting schedule for 2020! >=20 > 5. WG status update > * EBML -- version 13 was posted 2019-10-22, on IESG telechat for = 2019-12-05 There was a lot of recent updates based on the feedback, so I just = posted version 14. > * FFV1 -- version 10 was posted 2019-10-23, waiting for AD writeup. Version 11 was posted on 2019-10-23. > 6. Work on Matroska issues. >=20 > 7. Any other business. >=20 > NEXT meeting is TBD. >=20 > =3D=3D=3D=3D > CELLAR -- DRAFT AGENDA for Virtual Interim Meeting > October 22, 2019 19:00 UTC > 21:00 Amsterdam > 15:00 NYC > 12:00 San Francisco >=20 > Present: > 1. Michael Richardson > 1. Martin Below > 1. J=C3=A9r=C3=B4me Martinez > 1. Steve Lhomme > 1. Dave Rice >=20 >=20 >=20 > INFO: > = https://datatracker.ietf.org/meeting/interim-2019-cellar-09/session/cellar= > = https://datatracker.ietf.org/doc/agenda-interim-2019-cellar-09-sessa/ >=20 > WEB CONFERENCE: > https://whereby.com/cellar-interim > THERE IS NO TELEPHONE DIALIN (You can try this at any time.) > These notes at: https://github.com/cellar-wg/chair-notes >=20 > 1. Note Well. https://www.ietf.org/about/note-well/ > 2. Accept draft minutes from September 24 meeting (attached below) >=20 > 3. Logistics for Meeting. > 2a) Etherpad for notes > = https://etherpad.ietf.org/p/notes-cellar-virtual?useMonospaceFont=3Dtrue >=20 > 2b) APPEAR.IN is now called "whereby.com" > https://whereby.com/cellar-interim >=20 > 2c) Roll call >=20 > 4. WG status update > * EBML -- version 13 was posted 2019-10-22, waiting for AD. > * FFV1 -- version 10 was posted 2019-10-10, waiting for AD. >=20 > 5. Interest in using gerrithub.io? > For non-CLI uses, github has limitations lacking a web-based rebase > process. http://gerrithub.io/ >=20 > 6. Work on Matroska issues. > ** now that EBML has provided the side-data container, we can start = adding side-data types to Matroska. > ** Google (WEBM) has created some new blocks (for HDR information) in = the container, and we need to make sure we do not collide. = https://github.com/cellar-wg/matroska-specification/issues/345 > *** can we get them to coordinate better? > *** now it is finished, but we need to try again. We = could say that values up to 10 are reserved. >=20 > EBML issue: implementation note default? publish a new version? > mcr: says go ahead with new version as you wish. >=20 > FFV1: still waiting, but there are some issues raised by new decoder = for v3.. And we should clarify the text. >=20 >=20 > 7. Any other business. >=20 > NEXT meeting is 2019-12-03 moved to 2019-12-10. >=20 >=20 >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Mon Dec 2 00:17: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 E67CD120227 for ; Mon, 2 Dec 2019 00:17:13 -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, SPF_HELO_NONE=0.001, 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 sT-MiBiJjOrM for ; Mon, 2 Dec 2019 00:17:11 -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 E18F4120154 for ; Mon, 2 Dec 2019 00:17:10 -0800 (PST) Received: from smtp-2-0001.mail.infomaniak.ch (smtp-2-0001.mail.infomaniak.ch [10.5.36.108]) by smtp-sh2.infomaniak.ch (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id xB28H6C5017825 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 2 Dec 2019 09:17:07 +0100 Received: from Castor (unknown [IPV6:2a02:120b:2c7d:1f10:c500:9e44:d444:b9a0]) by smtp-2-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 2E1E1102C4919 for ; Mon, 2 Dec 2019 09:17:05 +0100 (CET) Date: Mon, 2 Dec 2019 09:17:06 +0100 From: Reto Kromer To: cellar@ietf.org X-Priority: 3 In-Reply-To: <14450.1575234869@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 for VIRTUAL INTERIM MEETING 2019-12-10 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, 02 Dec 2019 08:17:14 -0000 Michael Richardson wrote: >CELLAR -- DRAFT AGENDA for Virtual Interim Meeting >December 10, 2019 19:00 UTC I am afraid, I cannot make it, because I will be teaching all week in Hyderabad (where the meeting would start at 00:30 next day). Best regards, Reto From nobody Mon Dec 2 11:39:01 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 8B63D12003E for ; Mon, 2 Dec 2019 11:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 x2sfGN0CuZRH for ; Mon, 2 Dec 2019 11:38:58 -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 7859C120018 for ; Mon, 2 Dec 2019 11:38:57 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CCC343818F for ; Mon, 2 Dec 2019 14:35:22 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 39B6FA3B for ; Mon, 2 Dec 2019 14:38:57 -0500 (EST) From: Michael Richardson To: cellar@ietf.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 Archived-At: Subject: [Cellar] New Non-WG Mailing List: V3 -- audio/video across the Internet 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, 02 Dec 2019 19:39:00 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain My reading of the email below was that it was about codecs. Visiting the list description I see: Discution of V3 BOF for replacements for SIPv2, SDPv2, and RTPv2 To see the collection of prior postings to the list, visit the V3 Archives. which has only a single email it in yet. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline; filename=1902 Content-Description: forwarded message Return-Path: Received: from tuna.sandelman.ca [2607:f0b0:f:3::184] by localhost with IMAP (fetchmail-6.3.26) for (single-drop); Mon, 02 Dec 2019 14:34:50 -0500 (EST) Received: from tuna.sandelman.ca ([unix socket]) by tuna (Cyrus git2.4.17+0-Debian-2.4.17+nocaldav-0+deb8u2) with LMTPA; Mon, 02 Dec 2019 12:50:38 -0500 X-Sieve: CMU Sieve 2.4 Received: from delivery.mtaroutes.com (delivery.mtaroutes.com [185.201.17.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tuna.sandelman.ca (Postfix) with ESMTPS id E6D1B3818F for ; Mon, 2 Dec 2019 12:50:37 -0500 (EST) Received: from mail.ietf.org ([4.31.198.44]) by mx171.antispamcloud.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1ibpth-000l3V-6d for mcr+ietf@sandelman.ca; Mon, 02 Dec 2019 18:54:10 +0100 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 501961208A0 for ; Mon, 2 Dec 2019 09:54:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1575309244; bh=l6h8W4meNTn0S6mJhpf04oPEjvlzxRFRX8dJfipExgI=; h=From:To:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To:Cc; b=nhmFpm8wWNkTjNBByq5EZD018o/LmB773TEoM9QkanzZh/jUR41hgwucQL66Wckwo s8991juCyn1qjCQR6QYJlquGjFlpBZcWw2gQKKJNhhwswq4hR/eqlkQviIunkuveMH BfVCb6IWy0aCPa9vapd4BitrnNDyZd9QkWX0HFQY= X-Mailbox-Line: From ietf-announce-bounces@ietf.org Mon Dec 2 09:54:03 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF1612003E; Mon, 2 Dec 2019 09:54:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1575309242; bh=l6h8W4meNTn0S6mJhpf04oPEjvlzxRFRX8dJfipExgI=; h=From:To:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To:Cc; b=NV5GRg+FLit12Q3iqhf1cqdJVYLpDRa1m6dm93ORKVAeHpU8SKjEyqAqFZwzfWEJJ hEMZ99398HEGlflEDxzTby7PtrNE4beY2Az1sK1AILcOYMcqVMEE00awYXN3dJzru9 grhnz0JT/YjaurVweh21zem8SsdF1tyosbngx2OY= X-Original-To: ietf-announce@ietf.org Delivered-To: ietf-announce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F271120837; Mon, 2 Dec 2019 09:54:00 -0800 (PST) MIME-Version: 1.0 From: IETF Secretariat To: "IETF Announcement List" Subject: New Non-WG Mailing List: V3 X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157530924012.24871.12141122580424152664.idtracker@ietfa.amsl.com> Date: Mon, 02 Dec 2019 09:54:00 -0800 Archived-At: X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF announcement list. No discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: ietf@ietf.org Cc: v3@ietf.org, fluffy@iii.ca Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: ietf-announce-bounces@ietf.org Sender: "IETF-Announce" Received-SPF: pass (mx171.antispamcloud.com: domain of ietf.org designates 4.31.198.44 as permitted sender) client-ip=4.31.198.44; envelope-from=ietf-announce-bounces@ietf.org; helo=mail.ietf.org; X-SPF-Result: mx171.antispamcloud.com: domain of ietf.org designates 4.31.198.44 as permitted sender Authentication-Results: mx171.antispamcloud.com; dmarc=pass header.from=ietf.org Authentication-Results: antispamcloud.com; spf=pass smtp.mailfrom=ietf-announce-bounces@ietf.org; dkim=pass header.i=ietf.org X-Filter-Label: newsletter X-MailAssure-Class: whitelisted X-MailAssure-Evidence: sender X-Recommended-Action: accept X-Filter-ID: 8G1aH+8yearZuN6N5+X5bm6KuAmzEgFjeXz34jnHp0xMKXLqkQRFsIWTaj/0nSwX5MV8hRbMho2V e1Mmu7RLVwAQLhgWwSpelbM1Gt6jiFvrawWHjRgLzTACMPbBicVwZ9tl/JMgsC25j3FhIU18xZmw FhPC0NTZdyPZKMGNvfXMavUEmd0T8PjEY56Bn13JYDkRJGhexbCS7kIGacfIZzi3I0faKQYntkUZ 4A6tCuWdwYWSGRd/abGpRRivDf8eGCkEdUdkIBJinsC26gHIrI5uU9eNF2tiurGvWHqIygcCXdU5 E7066WxYloA+V/RpVgW9/bktU41htiJ8fk7NkBHKS9Ji6W0hFr7WM+1kQbceuhqvZCw5r2XUpCAP BqjwUZRk3ghRI9iuuTttsBd8SSBhDMa5EN14Lo5y9kkYIa0DPRUo6VT3lv+C0/swD9N0RAwX31WV Y5lWjWxuGSRuxVXsVM1mX0XgIxBNY9fVWqOJl9eE+x4UQmQoNBFMk6oG3ZvBSOdcZaQYlKee2Vxu tyhNi/UdPBoU1Z/Cqs2aHu0Ia/9gbANbtDrZMN7BmTC4WeE1etlLVBNMEaUkTMbMapFVgpT1b21u ZVckGp0ccObqvcLZCDNz7FE5l8aegTfr3uyz5tPieumwXNu3Cz7ynnOBBTH+lAe0QDHnXL1mlq9L XFOWIkCzigWbLTQzeUgPodBczlYc8yVfyy40LjeEPzx+L0TS1hVTJa5UEcfzKWDqGQyz6/bS74aG jOU6a/gVR8qt/xOQuX5d39ZxYyGINwrXMlPWGQoFcCL2WkA+UkS2iwxkynhsEdbzajrBtdvFGqrn dpVi9HVIfI7c9T9wPosEMysPur9wmiDBurOy6iS4KOSI2Vvfs9/+9mymysgQzTnE2QOLFmTK7djF HwOqKqSAftb2UNU8lYnX1sAlrhp3dsUPl7uuWZECTxDoGLxKZHCDOOUUWpeU2f8dSuSp6Gy1Qwrh ot22XAKXvzo9z90Za1iemThGZviXQaj7awOEeigamSwCMYjofYdJwKAJXYeAVixICv3LfS4AvSbd st//asDO0V6SUvEY03codo+QSZJ4KV0fnw5TLxQHMSWVaA== X-Report-Abuse-To: spam@quarantine10.antispamcloud.com QSBuZXcgSUVURiBub24td29ya2luZyBncm91cCBlbWFpbCBsaXN0IGhhcyBiZWVuIGNyZWF0ZWQu CgpMaXN0IGFkZHJlc3M6wqB2M0BpZXRmLm9yZwpBcmNoaXZlOsKgaHR0cHM6Ly9tYWlsYXJjaGl2 ZS5pZXRmLm9yZy9hcmNoL2Jyb3dzZS92My8KVG8gc3Vic2NyaWJlOsKgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92MwoKUHVycG9zZToKVGhpcyBlbWFpbCBsaXN0IGlzIHdv cmtpbmcgdG93YXJkcyBhIEJPRiBvbiBhIG5ldyBwcm90b2NvbCBmb3IgYXVkaW8KdmlkZW8gYXBw bGljYXRpb25zIG92ZXIgdGhlIGludGVybmV0LsKgwqDCoMKgCgpUaGlzIGxpc3QgYmVsb25ncyB0 byBJRVRGIGFyZWE6IEFSVAoKRm9yIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24sIHBsZWFzZSBjb250 YWN0IHRoZSBsaXN0IGFkbWluaXN0cmF0b3JzLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KSUVURi1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QKSUVURi1Bbm5v dW5jZUBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lldGYt YW5ub3VuY2UK --=-=-= Content-Type: text/plain -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl3laFAACgkQgItw+93Q 3WWMvgf+M/ajv9Hx37zqkYpRbPkgVFsou8MC2TmNKREt1aQXX18NzwIzQXpYJa30 x8c7lXXJvuDzWzE6LHy/0To/ujQuajDXmfEczePYLnvl7qc4HtYeZMpDCxmhhcbB VfWbbmyJzqH71hA3z+na+S00JDTLYo9k97buUT2OlocbSuLPJsyUyVW/Ad4jh/AE bB7m1qLTqRcmZ75BmmxMPU0q9E0uSj1vV0ZpcHx1kLLILiju5iR+g34VCQBnU+SY +ZFzCx+VcyF1ClB21NL6Yiwkxv3P3BteCUp29JpzNPsQs9AVDZggPYJJB0Ml8QYj wFRZyO2W0U+REATVZ4UdrzEbpZf6qA== =WVrt -----END PGP SIGNATURE----- --==-=-=-- From nobody Tue Dec 3 10:54:08 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 DBE7512000F; Tue, 3 Dec 2019 10:54:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-cellar-ebml@ietf.org, Steven Villereal , cellar-chairs@ietf.org, villereal@gmail.com, cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <157539924789.24871.7033050331898895759.idtracker@ietfa.amsl.com> Date: Tue, 03 Dec 2019 10:54:07 -0800 Archived-At: Subject: [Cellar] Roman Danyliw's No Objection on draft-ietf-cellar-ebml-14: (with COMMENT) 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: Tue, 03 Dec 2019 18:54:08 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-cellar-ebml-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1. Please add a reference to Matroska instead of an inline URL Section 1. Please add a reference for WebM Section 2 and Table 4 of Section 5. These sections define EBML Class. However, it isn’t used else where in the document. What is it supposed to be used for? Section 4.4. Recommend replacing “This table” text to be the name of specific table in question (i.e., Table 1, Table 2) Section 6.2. Per “Unknown-Sized Element MUST NOT be used or defined unnecessarily; however if the Element Data Size is not known before the Element Data is written, such as in some cases of data streaming, then Unknown- Sized Elements MAY be used.”, should this text be read as “the Unknown- Sized Elements MUST only be used if the Element Data Size is not known before the Element Data is written”. I’m having trouble understanding how to handle normative language for a qualitative statement of “unnecessarily” Section 11.1.5.1. Double checking on the grammar of the name attribute – it is permitted to start with a “-“ or a “.”? Section 11.1.5.3. Are there any uniqueness properties for an id attribute? Drawing a parallel from XML, I would have thought that each EBML element would have unique ID per doctype (say like an xml:id) Section 11.1.7.2. documentation@purpose has a number of possible enumerated values, however, none are defined in the text (they are only listed) From nobody Fri Dec 6 08:05:44 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 29F311200D7; Fri, 6 Dec 2019 08:05:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks via Datatracker To: Cc: last-call@ietf.org, cellar@ietf.org, draft-ietf-cellar-ebml.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Sparks Message-ID: <157564834306.20915.14892581266236819776@ietfa.amsl.com> Date: Fri, 06 Dec 2019 08:05:43 -0800 Archived-At: Subject: [Cellar] Genart telechat review of draft-ietf-cellar-ebml-14 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: Fri, 06 Dec 2019 16:05:43 -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 wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-cellar-ebml-14 Reviewer: Robert Sparks Review Date: 2019-12-06 IETF LC End Date: 2019-11-07 IESG Telechat date: 2019-12-19 This is just a copy of my LC review of -13 (to which I received no response): Summary: Not ready for publication as a Proposed Standard I had previously reviewed version -09 of this document. Thanks for addressing many of the issues I had raised at that time. My re-review has focused mainly on the diff between -09 and -13. It was surprisingly hard to make useful diffs between these versions, but it was possible to do so by separating out some reordered sections and comparing them separately. I still find this document difficult to comprehend. While not all of the issues I raised were addressed, I don't feel strongly enough about them to repeat them. However, there is one major issue still outstanding that is something the AD should handle. (Attention Alexey) : 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. From nobody Fri Dec 6 10:53: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 B05C912006D for ; Fri, 6 Dec 2019 10:53:04 -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, SPF_HELO_NONE=0.001, 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 uZvv7UdLA4LK for ; Fri, 6 Dec 2019 10:53:02 -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 4FDCE12004A for ; Fri, 6 Dec 2019 10:53:02 -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=xjb7gJO7VVS//cBccJvBh0U8jI41DJaxKMJgfjdqVj8=; b=RRqerCR2nRAg67wsvB+XOFiZ0NuwySDwLNtadFTXLEHW4WLCcxXJyJIlODLcGUnmA1ClZmbuA2+n/Wi68Vo/rZCacEbVD5Puiam2C1Uof8RwvZ2U4E3ios0/AKKLE71iCVWancmVNyeW4Vqo1usZxXyXX6XkXtkM4rM4wUnp+zM=; Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:42944) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1idIig-0004o0-1g for cellar@ietf.org; Fri, 06 Dec 2019 19:52:52 +0100 Received: from sweet-chili.int.bunkus.org (unknown [10.55.5.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by liselle.bunkus.org (Postfix) with ESMTPS id 3B652654000A; Fri, 6 Dec 2019 19:52:50 +0100 (CET) Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.int.bunkus.org (Postfix) with ESMTP id 84FB81973416; Fri, 6 Dec 2019 19:52:49 +0100 (CET) X-CTCH-RefID: str=0001.0A09020E.5DEAA384.000C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 User-agent: mu4e 1.2.0; emacs 26.3 From: Moritz Bunkus To: help Questions , Cellar list Date: Fri, 06 Dec 2019 19:52:49 +0100 Message-ID: <874kyd9tha.fsf@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Cellar] MKVToolNix v41.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: Fri, 06 Dec 2019 18:53:05 -0000 Hey, here's one last release before the end of the year, and it's a bit bigger than the previous ones. Have a look at the news below for details. Nothing's changed for package maintainers. 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 41.0.0 "Smarra" 2019-12-06 ## New features and enhancements * mkvmerge: Matroska reader: Vorbis tracks: stream comments (aka Vorbis comments) will be converted to Matroska attachments (for cover arts) and Matroska track tags (for other comments). Additionally the stream comments will be removed from Vorbis headers. * mkvmerge: MP4 reader: added support for reading Opus audio from MP4 files. Part of the implementation of #2673. * mkvmerge: MP4 reader: added support for reading VP9 video from MP4 files. Part of the implementation of #2673. * mkvmerge: Ogg reader: Vorbis, Opus & VP8 streams: stream comments (aka Vorbis comments) will be converted to Matroska attachments (for cover art= s) and Matroska track tags (for other comments). Additionally the stream comments will be removed from Vorbis headers. * mkvmerge: WAV reader: added support for reading RF64 files. * MKVToolNix GUI: multiplexer: the list of predefined track names is now sp= lit up into three lists, one for each track type (audio, video & subtitles). Part of the implementation of #2654. * MKVToolNix GUI: multiplexer: when trying to add thumbnails for a Blu-ray = the GUI will determine the thumbnail's pixel size from the thumbnail files if the XML file doesn't contain that information. This works for JPEG and PNG files. Implements #2674. * MKVToolNix GUI: general: line edits & combo boxes will now have a "clear text" button appear whenever they're not empty. Part of the implementation of #2654. * MKVToolNix GUI: update check: the dialog showing the latest news & version information states explicitly where the links take the user (the MKVToolN= ix `NEWS.md` file and YouTube respectively). ## Bug fixes * mkvmerge: Matroska reader: mkvmerge did not copy the codec's private data when reading WavPack from Matroska files. Fixes #2685. * mkvmerge: MPLS handling: re-added caching when using MPLS playlists as in= put files. Fixes #2666. * mkvmerge: MPEG TS reader: when reading an MPLS playlist, the calculation = of the minimum timestamp to use for shifting all output timestamps to zero w= as wrong. It was wrongfully considering timestamps from packets it would not copy due to the MPLS's timestamp restrictions. This could lead to the fir= st timestamps in the output file being quite large, e.g. more than a couple = of minutes, causing sync problems when multiplexing together with other files. Fixes #2670. * MKVToolNix GUI: multiplexer: the automatic switch between aspect ratio & display width/height wasn't reflected in the configuration generated for `mkvmerge`. The user had to change between the two settings manually. Fix= es #2660. * MKVToolNix GUI: multiplexer: the progress dialog shown when scanning a Blu-ray wasn't closed properly in certain situations. Fixes #2678. * MKVToolNix GUI: general: the configured font was not applied to a lot of controls (e.g. the file & track lists or the menu entries) on application startup. Instead the user had to open & close the preferences in order for the font to be applied to all controls. Fixes #2671. ------------------------------------------------------------ Have fun :) Kind regards, mosu From nobody Fri Dec 6 11:04:18 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 960E5120059 for ; Fri, 6 Dec 2019 11:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_HELO_NONE=0.001, 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 2LWWm3mjXVu6 for ; Fri, 6 Dec 2019 11:04:16 -0800 (PST) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 37FAA12004A for ; Fri, 6 Dec 2019 11:04:16 -0800 (PST) Received: by mail-qk1-x72c.google.com with SMTP id k6so7387037qki.5 for ; Fri, 06 Dec 2019 11:04:16 -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=KtKT99E4NVBV4NsybYltu0vzEjr+4gM9IZgwsJsQF20=; b=PWWF7fiC+/D/ruFq2sfI9zCNu3u/Mrq7v82+A1uCCeWaxtVu4MDuajWauu7wtNvsWT Ho43iI8KsSELWfMMqixFAB48342Bw/VrwwAdGuqlt/I9udAExHpFJLiUkIGJK3qGl8RA KAnNU7vokt9ZDLsyImIpO273zNNUatHhNlGHCixTBX0IsMB6OIo26Akhrn6v1AaPfWEk O2VzSPM96bO5NkMqWB0IlWUiK/G0eCU5n3e41spmTQ3TJbfFWfh/425DLRNIYw18Gw9n I/iMYCYWUxmByZBMwIetQ1HusX0ZKVCUvA5zBNrD91Zt3NYlcKNXAWg2qJtXQ8mrICJE rY6Q== 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=KtKT99E4NVBV4NsybYltu0vzEjr+4gM9IZgwsJsQF20=; b=gFSOH5YFG3VSCo1VJ/6xxZApHJ1wKcX08DORG9wC9kP8rC3rAGaXFI7b1SJwmgLni4 No0WZUKZpag0hU4OCOhR8KYcppaNzJb8oY1tmEgbyvyP25IogI/MbytCoaykHVNb0EjF K6mWtgB2enL9L6DckdW2O0g8AAh5hyJObEtoZR7WKLkyQlEm97P62LhWg+HBYUQilmiC nIZG87eRQktvihVvClaqEXcKRdi9AgvFQP2iND8noWCfuyVt8Ka9xSuIH/Lip0SbXwo5 LBBwVrljFgYdwK+zp9ctbs8ZDpTmX3+hrp8V73t2XhR5h6M77/cQntXDLN7G+QY5+dGS cj9A== X-Gm-Message-State: APjAAAW368fHUixBBfztjkk05DtMmyhpCxe+u+xx5Kd6fV//vW5kmrNf 9/L8zQG+pbIrvmYqOEePgj4+iM/Qrvvv2NbMYI5UwFi+dg== X-Google-Smtp-Source: APXvYqyIoe3qmklD3hhOA6wgN4m2KPYqksLDnB1zsJmb5NuWcok7Jv1STTNaDyzdwqXj5TW/aOpNEHZm+KTMYJLZvS4= X-Received: by 2002:a05:620a:101b:: with SMTP id z27mr14563715qkj.241.1575659054004; Fri, 06 Dec 2019 11:04:14 -0800 (PST) MIME-Version: 1.0 References: <874kyd9tha.fsf@bunkus.org> In-Reply-To: <874kyd9tha.fsf@bunkus.org> From: Kieran O Leary Date: Fri, 6 Dec 2019 20:04:02 +0100 Message-ID: To: Moritz Bunkus Cc: help Questions , Cellar list Content-Type: multipart/alternative; boundary="000000000000337c3805990db65d" Archived-At: Subject: Re: [Cellar] MKVToolNix v41.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: Fri, 06 Dec 2019 19:04:18 -0000 --000000000000337c3805990db65d Content-Type: text/plain; charset="UTF-8" Awesome! Also happy birthday Matroska! --000000000000337c3805990db65d Content-Type: text/html; charset="UTF-8"
Awesome! Also happy birthday Matroska!
--000000000000337c3805990db65d-- From nobody Tue Dec 10 11:10:47 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 7C2B5120A3B for ; Tue, 10 Dec 2019 11:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 AGZnDtvosdb1 for ; Tue, 10 Dec 2019 11:10: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 4CF6112096D for ; Tue, 10 Dec 2019 11:10:40 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 873043897D for ; Tue, 10 Dec 2019 14:06:53 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id EC9453F for ; Tue, 10 Dec 2019 14:10:39 -0500 (EST) From: Michael Richardson to: cellar@ietf.org In-Reply-To: <14450.1575234869@localhost> References: <14450.1575234869@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] REMINDER TODAY: Re: DRAFT AGENDA for VIRTUAL INTERIM MEETING 2019-12-10 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, 10 Dec 2019 19:10:47 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Just to remind. Michael Richardson wrote: > {additions and changes welcome} > CELLAR -- DRAFT AGENDA for Virtual Interim Meeting > December 10, 2019 19:00 UTC > 21:00 Amsterdam > 15:00 NYC > 12:00 San Francisco > INFO: > https://datatracker.ietf.org/meeting/interim-2019-cellar-10/session/c= ellar > https://datatracker.ietf.org/doc/agenda-interim-2019-cellar-10-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 > 1. Note Well. > 2. Accept draft minutes from September 24 meeting (attached below) > 3. Logistics for Meeting. > 2a) Etherpad for notes > https://etherpad.ietf.org/p/notes-cellar-virtual?useMonospaceFont=3Dt= rue > 2b) APPEAR.IN is not called "whereby.com" > https://whereby.com/cellar-interimw > 2c) Roll call > 4. Establish meeting schedule for 2020! > 5. WG status update > * EBML -- version 13 was posted 2019-10-22, on IESG telechat for 2019= -12-05 > * FFV1 -- version 10 was posted 2019-10-23, waiting for AD writeup. > 6. Work on Matroska issues. > 7. Any other business. > NEXT meeting is TBD. > =3D=3D=3D=3D > CELLAR -- DRAFT AGENDA for Virtual Interim Meeting > October 22, 2019 19:00 UTC > 21:00 Amsterdam > 15:00 NYC > 12:00 San Francisco > Present: > 1. Michael Richardson > 1. Martin Below > 1. J=C3=A9r=C3=B4me Martinez > 1. Steve Lhomme > 1. Dave Rice > INFO: > https://datatracker.ietf.org/meeting/interim-2019-cellar-09/session/c= ellar > https://datatracker.ietf.org/doc/agenda-interim-2019-cellar-09-sessa/ > WEB CONFERENCE: > https://whereby.com/cellar-interim > THERE IS NO TELEPHONE DIALIN (You can try this at any time.) > These notes at: https://github.com/cellar-wg/chair-notes > 1. Note Well. https://www.ietf.org/about/note-well/ > 2. Accept draft minutes from September 24 meeting (attached below) > 3. Logistics for Meeting. > 2a) Etherpad for notes > https://etherpad.ietf.org/p/notes-cellar-virtual?useMonospaceFont=3Dt= rue > 2b) APPEAR.IN is now called "whereby.com" > https://whereby.com/cellar-interim > 2c) Roll call > 4. WG status update > * EBML -- version 13 was posted 2019-10-22, waiting for AD. > * FFV1 -- version 10 was posted 2019-10-10, waiting for AD. > 5. Interest in using gerrithub.io? > For non-CLI uses, github has limitations lacking a web-based rebase > process. http://gerrithub.io/ > 6. Work on Matroska issues. > ** now that EBML has provided the side-data container, we can start a= dding side-data types to Matroska. > ** Google (WEBM) has created some new blocks (for HDR information) in= the container, and we need to make sure we do not collide. https://git= hub.com/cellar-wg/matroska-specification/issues/345 > *** can we get them to coordinate better? > *** now it is finished, but we need to try again. We could say that = values up to 10 are reserved. > EBML issue: implementation note default? publish a new version? > mcr: says go ahead with new version as you wish. > FFV1: still waiting, but there are some issues raised by new decoder = for v3. And we should clarify the text. > 7. Any other business. > NEXT meeting is 2019-12-03 moved to 2019-12-10. > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl3v7a8ACgkQgItw+93Q 3WV2QAf9EqSrR/cWICypyGYO/XipTqwgNMAaO5+F3yz/pRXZFUwARGKsSAmS6ZfD YSKX0z1YeasXwz2VCFMq+2T5U5dNRq8iGoR5CxuMHmPZPXaPkgpwlEfp9nVZ2eE3 SyNL4/dYWzXs8azQV9Dt8vWTxU1Yx5rP7QwM37epJRQmBg4wW9MGyLuXiP/hxCpu 8y3rb7vL4oLC0aE7X14TVnA/7NKfj/HMM/yiUHsQOutZW2wCBQktERKPFVJMrBqn MeX4rW90Dqi6uJMGxIeJJm4U47Ohn8jQ3A/HZCSjOp6lh9I5t4+gdeBDja0Eoht5 ynX0BYumytbsAR+LPhFPaaqqimOzyw== =6okB -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Dec 10 11:53: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 D2842120AB3 for ; Tue, 10 Dec 2019 11:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] 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 7g6M2LKexDkH for ; Tue, 10 Dec 2019 11:53:44 -0800 (PST) Received: from mail-pl1-x641.google.com (mail-pl1-x641.google.com [IPv6:2607:f8b0:4864:20::641]) (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 AAD6C120AB5 for ; Tue, 10 Dec 2019 11:53:44 -0800 (PST) Received: by mail-pl1-x641.google.com with SMTP id c23so284499plz.4 for ; Tue, 10 Dec 2019 11:53:44 -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=XODZngefAuDknlZ4hVg4vgTeRxzWr3me//ZCmk4aMEQ=; b=nZRvPUx4p47qwv+ttwPEaDksCsKih3t7Seaj+U0pinpS1B2e3Zj17i2SftAnlO5VTy D5EF9f083T01tqOwh8srB0n0ka55QNg2cu5E3lS76sFSklUA72ZXnORSB2Nd144FhG+T zRRoloja05OQn2ObgsFj4yKyJh3YQcMfjZ+bTazaWN3a6uyXwJzOv7RKKyXA3z60qlXI LewT5TND9Wdbql3dOTHzI6ClkTXtj1ceTgHT3H1yxo9gXMsT+TGi39lFIOdmg7YAeMFo FKhEnPXutEQ5H75qe4NupSVjik1knGSE7wE07/eQQyoOpn+Wy42/9WNoP59oIFimPA/r OOXg== 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=XODZngefAuDknlZ4hVg4vgTeRxzWr3me//ZCmk4aMEQ=; b=hF+jBPRe640+DFl7nalHa32Bz/q6LKf1q7sr9/dUEScn1rYnai4bTmOuIF7lX3fPOK aYwABZRYrZPUh/uLecqLaEDG1fxLOIgfR8wmdhPIHL14hyKogR+Hq9dljAjMAlVMVLAB wUtTDbL+bju5oq1zwbPG7asmBJCnDR9/wT1raB983Sn9cGHD5j5P0g9ey+81YzKzy0K1 9xv6k6GFP46OjDiFk6aHi1mbVkD2B576UUWtRIPaac5a4/sGTzUr0h7s3Wnd7fkiLsi3 zQ/315BTz1+IdF/D+4ytROarNaFPbuLO5Te20WAWxsNagRdD6Kt+ro52+WJknDkw11dG bh/Q== X-Gm-Message-State: APjAAAWHaYAgO7siC5NEpMpqf/Uyvl3aiJ6gnbIPzPcP543FT2rsbjDX G2qJjA00P40dh5ZGNP5KejfNFJ6KX9dKsDH1oB1uytbX2vR1cA== X-Google-Smtp-Source: APXvYqyfqJ2H6fmqeSKuyQHG+rT/V7yVAhpEwv1mf3ifdIrq6JaLfnRbdjCZdA1eLSFcpSRLERdXWqPN1Ol9Vp6x4Os= X-Received: by 2002:a17:902:9b8b:: with SMTP id y11mr21577863plp.35.1576007624161; Tue, 10 Dec 2019 11:53:44 -0800 (PST) MIME-Version: 1.0 References: <157539924789.24871.7033050331898895759.idtracker@ietfa.amsl.com> In-Reply-To: <157539924789.24871.7033050331898895759.idtracker@ietfa.amsl.com> From: Steve Lhomme Date: Tue, 10 Dec 2019 20:53:32 +0100 Message-ID: To: Roman Danyliw Cc: The IESG , villereal@gmail.com, draft-ietf-cellar-ebml@ietf.org, cellar-chairs@ietf.org, 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] Roman Danyliw's No Objection on draft-ietf-cellar-ebml-14: (with COMMENT) 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, 10 Dec 2019 19:53:47 -0000 Hello Roman, Thanks for taking the time to read and comment the document. Here are my replies to your remarks. Le mar. 3 d=C3=A9c. 2019 =C3=A0 19:54, Roman Danyliw via Datatracker a =C3=A9crit : > > Roman Danyliw has entered the following ballot position for > draft-ietf-cellar-ebml-14: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 1. Please add a reference to Matroska instead of an inline URL OK > Section 1. Please add a reference for WebM OK > Section 2 and Table 4 of Section 5. These sections define EBML Class. > However, it isn=E2=80=99t used else where in the document. What is it su= pposed to be > used for? It was used later in the document for Class A to Class D. But we don't use that terminology anymore. Dave Rice has been replaced in a new Pull Request: https://github.com/cellar-wg/ebml-specification/pull/306 > Section 4.4. Recommend replacing =E2=80=9CThis table=E2=80=9D text to be= the name of specific > table in question (i.e., Table 1, Table 2) OK > Section 6.2. Per =E2=80=9CUnknown-Sized Element MUST NOT be used or defi= ned > unnecessarily; however if the Element Data Size is not known before the E= lement > Data is written, such as in some cases of data streaming, then Unknown- S= ized > Elements MAY be used.=E2=80=9D, should this text be read as =E2=80=9Cthe = Unknown- Sized > Elements MUST only be used if the Element Data Size is not known before t= he > Element Data is written=E2=80=9D. Yes, your suggestion has been integrated. > I=E2=80=99m having trouble understanding how to handle > normative language for a qualitative statement of =E2=80=9Cunnecessarily= =E2=80=9D > > Section 11.1.5.1. Double checking on the grammar of the name attribute = =E2=80=93 it is > permitted to start with a =E2=80=9C-=E2=80=9C or a =E2=80=9C.=E2=80=9D? No. The text has been updated accordingly. > Section 11.1.5.3. Are there any uniqueness properties for an id attribut= e? > Drawing a parallel from XML, I would have thought that each EBML element= would > have unique ID per doctype (say like an xml:id) No, the same id can be used by multiple element. Only the Path must be unique. Although it's not explicitly mentioned. > Section 11.1.7.2. documentation@purpose has a number of possible enumera= ted > values, however, none are defined in the text (they are only listed) A table has been added to define the various values in detail. > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Tue Dec 10 11:55:41 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 59CE6120A5C for ; Tue, 10 Dec 2019 11:55:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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 pyJUpcMEQ7YD for ; Tue, 10 Dec 2019 11:55:38 -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 9914D120AAA for ; Tue, 10 Dec 2019 11:55:38 -0800 (PST) Received: from [10.0.0.11] (212095006050.public.telering.at [::ffff:212.95.6.50]) (AUTH: PLAIN bubestinger@schokokeks.org, ) by zucker.schokokeks.org with ESMTPSA id 000000000000006A.000000005DEFF838.00000A8F; Tue, 10 Dec 2019 20:55:36 +0100 To: cellar@ietf.org References: <14450.1575234869@localhost> <27291.1576005039@localhost> From: "Peter B." Message-ID: <12ac084b-f31c-331b-d501-92aa2dc3494c@das-werkstatt.com> Date: Tue, 10 Dec 2019 20:55:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <27291.1576005039@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Cellar] REMINDER TODAY: Re: DRAFT AGENDA for VIRTUAL INTERIM MEETING 2019-12-10 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, 10 Dec 2019 19:55:40 -0000 Short question about web conference URL for this meeting: On 10/12/2019 20:10, Michael Richardson wrote: > > 2b) APPEAR.IN is not called "whereby.com" > >https://whereby.com/cellar-interimw You wrote "appear.in is *not* called whereby.com", but "appear.in/cellar-interim" returns a "404 not found", but "whereby.com/cellar-interim" seems to work. Which one is the correct URL? Thank you very much, Peter B. From nobody Tue Dec 10 12:02:16 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 EB1D2120A6B for ; Tue, 10 Dec 2019 12:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=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 gLcXegBV83ao for ; Tue, 10 Dec 2019 12:02:12 -0800 (PST) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 79D87120A67 for ; Tue, 10 Dec 2019 12:02:12 -0800 (PST) Received: by mail-pg1-x52e.google.com with SMTP id l24so9398671pgk.2 for ; Tue, 10 Dec 2019 12:02:12 -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=L/fL+eAxmFH07IEaigZ4xGRwH1jdBGq47PB9RlFiiAI=; b=eSb/x/InDb8kcwSh8wCusKPwCpVFBwSppaQ1UuSG/+JIcISYvZMfmqlW58NvOHNfxc p8VZmea2NStoMrNzcZB76SozqT99+edDsEUlSipUlfvrhdWVM3gJ2vcgf+oreN/hhAaE IyiDnPf6ldEnyuIzJEtX65dpa/A8528QfU3Ngl6W8IQk1WeC6suXngU6/TPE3uZsz2++ 2kSYpQBmcEUFfpREzhyZhgpUoG/wK3ijtw6TZPpF3QZXtvuJKHDQsOg8kO+V7jO8kYuy hxkvo2WdcsTD9B/uLE8TMAUx1LmNK1li6gnDZNnoFmZcDp+K/wsB9MaXe2ILEzcbJhgZ NDdg== 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=L/fL+eAxmFH07IEaigZ4xGRwH1jdBGq47PB9RlFiiAI=; b=UxYiJxI879R+Ue95bBCf5Gs1qugZkzDQyNkmOog5/kr5b2FCPIrGuILGLtCsuDgTO/ faJxTE5MsQXEWxUI59JU/lj17XyoGwvKWtlmf5Bc6E0dLT1DCOsvyaU/OS/hz3C+o4ac nXQN9B41QOEnyor8Xo8/243q5kcLrH3Cd1oecbboxDMA3YmGBG7PnjkkdAi5o8eoV6wF HcfJRqxZwZsFRL4WP3AwhvXKfUJV/CLGrutF+OGl8xBlVR51ypRah5pJ6+4xfPki5kAP 0gRaCBRf4Judggka9esX/l99MIBUByxObKN3wLERxkoD9xt+mvOMlon9S490u131L1Na oRWA== X-Gm-Message-State: APjAAAWY9p5HEfny8u2qXDR8bkDcSxwBL/ptht8Qctr78cQh5nWeBm6J uo8WrAVfp7znxkOxY0MkRrqtyVetbfW/qmsxee5nEQ== X-Google-Smtp-Source: APXvYqzvivCBAQYKfH0Teal19hjQCOtYU5apx6Our0Kqmg8sPfprrk1lv3a75Abww4AcapDOYcv0uV6YAwr3X++oNlw= X-Received: by 2002:aa7:9313:: with SMTP id 19mr35684300pfj.160.1576008131870; Tue, 10 Dec 2019 12:02:11 -0800 (PST) MIME-Version: 1.0 References: <14450.1575234869@localhost> <27291.1576005039@localhost> <12ac084b-f31c-331b-d501-92aa2dc3494c@das-werkstatt.com> In-Reply-To: <12ac084b-f31c-331b-d501-92aa2dc3494c@das-werkstatt.com> From: Steve Lhomme Date: Tue, 10 Dec 2019 21:02:00 +0100 Message-ID: To: "Peter B." 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] REMINDER TODAY: Re: DRAFT AGENDA for VIRTUAL INTERIM MEETING 2019-12-10 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, 10 Dec 2019 20:02:14 -0000 Indeed, I had to create a group and then I'm alone. It looks quite different from the previous times. Michael, any help ? Le mar. 10 d=C3=A9c. 2019 =C3=A0 20:55, Peter B. a = =C3=A9crit : > > Short question about web conference URL for this meeting: > > On 10/12/2019 20:10, Michael Richardson wrote: > > > 2b) APPEAR.IN is not called "whereby.com" > > >https://whereby.com/cellar-interimw > > You wrote "appear.in is *not* called whereby.com", but > "appear.in/cellar-interim" returns a "404 not found", but > "whereby.com/cellar-interim" seems to work. > > Which one is the correct URL? > > > Thank you very much, > Peter B. > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Tue Dec 10 12:05: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 1E300120A47 for ; Tue, 10 Dec 2019 12:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=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 Eqcfzm5rKqcA for ; Tue, 10 Dec 2019 12:05:45 -0800 (PST) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 6CFBC12008C for ; Tue, 10 Dec 2019 12:05:45 -0800 (PST) Received: by mail-pg1-x534.google.com with SMTP id a33so9187550pgm.5 for ; Tue, 10 Dec 2019 12:05:45 -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=orHepbUBcmOkDbRCqmh/RCCQV1tLqL2Z+FBII+gYPTY=; b=P3sOhGuMDuKC1BCDfspw2aWrGbe6EG3dEajVurD72whWrwa29qW5MCNAtMMRer59xy 74gpcR2VzUv4U2J+SeYYlBoFZRBaR/ZksetZW9uzLAe8TRfuPyiMEuFE1KoEyvkMhorR HpPVCGt/fDoeuDiPmNocqAVPwT2rKRUClsjf8tfKR7/++TRCitiUxm+xiVS0cZGJFZcr BvyD9wb6byUehTHfkRPuUoHHe3V2NkQkWwKeTnidfNA64H86/eyAU/ZKlL9kDlxGJAm0 Q3jJiXQUNLv00JTA5Y/JlpDohhWvTd6kwx8Wf6RqFSXzQpgZtLG28aOJguuTJ1YCAfAk eBrA== 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=orHepbUBcmOkDbRCqmh/RCCQV1tLqL2Z+FBII+gYPTY=; b=DtJAMC7Vq3YFy/FGR17gY/3DN+K/bglwd7KlVZRGWxUfbRaVzz/Xg3f9KM71lSiYGQ UQrqH6UrMIV2DE8BXzgSTdJXzW80hBAIPX2rPdMsfauIvZcjwMBTFGCiY7VV/UECwUoN VDb2MtuCoVtvKgM7mGAZ5hXWRziUxwUVjYNEcikAsbUr9VOcLJBT8DzEvDatWBV1DWK3 5lWiRJOCTzPjm5J6HGz54G4k9STBDQGnhyI0NXW7xemZK6FbxLufGoOcc0CfKvthA7hO +vk6vhGp+5Y3fYnj2Am6qYtzNLZJTrzd7dr7HASrvPnUr9QMky+gOWoAne2Ra7aM4MOq O1Yg== X-Gm-Message-State: APjAAAXZzu95OdWwl5KgmMgPzGdDtOkHmRfFC2n5c4PIRqSOZujGt/1P jcx8ALDutdWgr/ZGix7X+xoGiSe6NCMO6cEnpXKk/h0tcIr3Qw== X-Google-Smtp-Source: APXvYqwi3CofPNlUciWgXSeEYaS+W+17WZEFAmueQrBzpRkHw0dXWDIFT9wmaBzSd7HLFYzp74b0VmZPKUofbh96LBM= X-Received: by 2002:a63:213:: with SMTP id 19mr7512446pgc.160.1576008345002; Tue, 10 Dec 2019 12:05:45 -0800 (PST) MIME-Version: 1.0 References: <14450.1575234869@localhost> <27291.1576005039@localhost> <12ac084b-f31c-331b-d501-92aa2dc3494c@das-werkstatt.com> In-Reply-To: From: Steve Lhomme Date: Tue, 10 Dec 2019 21:05:33 +0100 Message-ID: To: "Peter B." 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] REMINDER TODAY: Re: DRAFT AGENDA for VIRTUAL INTERIM MEETING 2019-12-10 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, 10 Dec 2019 20:05:47 -0000 https://whereby.com/cellar-interim is the one Le mar. 10 d=C3=A9c. 2019 =C3=A0 21:02, Steve Lhomme = a =C3=A9crit : > > Indeed, I had to create a group and then I'm alone. It looks quite > different from the previous times. > > Michael, any help ? > > Le mar. 10 d=C3=A9c. 2019 =C3=A0 20:55, Peter B. a= =C3=A9crit : > > > > Short question about web conference URL for this meeting: > > > > On 10/12/2019 20:10, Michael Richardson wrote: > > > > 2b) APPEAR.IN is not called "whereby.com" > > > >https://whereby.com/cellar-interimw > > > > You wrote "appear.in is *not* called whereby.com", but > > "appear.in/cellar-interim" returns a "404 not found", but > > "whereby.com/cellar-interim" seems to work. > > > > Which one is the correct URL? > > > > > > Thank you very much, > > Peter B. > > > > _______________________________________________ > > Cellar mailing list > > Cellar@ietf.org > > https://www.ietf.org/mailman/listinfo/cellar > > > > -- > Steve Lhomme > Matroska association Chairman --=20 Steve Lhomme Matroska association Chairman From nobody Tue Dec 10 13:03:13 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 1046C12011D; Tue, 10 Dec 2019 13:03:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: mcr+ietf@sandelman.ca, cellar@ietf.org, cellar-chairs@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157601179102.9927.15769073477976571582.idtracker@ietfa.amsl.com> Date: Tue, 10 Dec 2019 13:03:11 -0800 Archived-At: Subject: [Cellar] cellar - New Interim Meeting Request 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: Tue, 10 Dec 2019 21:03:11 -0000 A new interim meeting request has just been submitted by Michael Richardson. This request requires approval by the Area Director of the Applications and Real-Time Area The meeting can be approved here: https://datatracker.ietf.org/meeting/interim/request/interim-2020-cellar-10 --------------------------------------------------------- Working Group Name: Codec Encoding for LossLess Archiving and Realtime transmission Area Name: Applications and Real-Time Area Session Requester: Michael Richardson City: Amsterdam Country: NL Session 1: Date: 2020-09-22 Start Time: 09:00 Europe/Amsterdam Duration: 01:00 Remote Participation Information: Remote participation information will be obtained at the time of approval Agenda Note: --------------------------------------------------------- From nobody Tue Dec 10 13:17:34 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 256D3120121 for ; Tue, 10 Dec 2019 13:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 yEMaOLxUfGro for ; Tue, 10 Dec 2019 13:17:30 -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 652F0120019 for ; Tue, 10 Dec 2019 13:17:30 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 1FD583897F for ; Tue, 10 Dec 2019 16:13:43 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A6B013F for ; Tue, 10 Dec 2019 16:17:29 -0500 (EST) From: Michael Richardson to: cellar@ietf.org In-Reply-To: <27291.1576005039@localhost> References: <14450.1575234869@localhost> <27291.1576005039@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 2019-12-10 minutes and upcoming CELLAR virtual interim meetings 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, 10 Dec 2019 21:17:33 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Future meetings will probably be: 2020-01-21. 2020-02-25 2020-03-31 (IETF week is 20-27, I goofed during the call) 2020-04-28 2020-05-26 2020-06-23 skip July (IETF week is july 25-31 in Madrid) 2020-08-28 2020-09-22 possibly in-person with NoTimeToWait - 2020 in AMS. 2020-10-27 2020-12-01 Here are the draft minutes from today. CELLAR -- DRAFT AGENDA for Virtual Interim Meeting December 10, 2019 19:00 UTC 21:00 Amsterdam 15:00 NYC 12:00 San Francisco REGRETS: 1) Reto Kromer PRESENT: 1) Michael Richardson 2) Benjamin Turkus 3) Dave Rice 4) Martin Below 5) Michael Niedermayer 6) Peter Bubestinger 7) Steve Lhomme 8) Jerome Martinez 9) Dante Bromkovsky INFO: https://datatracker.ietf.org/meeting/interim-2019-cellar-10/session/cell= ar https://datatracker.ietf.org/doc/agenda-interim-2019-cellar-10-sessa/ WEB CONFERENCE: https://whereby.com/cellar-interim THERE IS NO TELEPHONE DIALIN (You can try this at any time.) These notes at: https://github.com/cellar-wg/chair-notes 1. Note Well. https://www.ietf.org/about/note-well/ 2. Accept draft minutes from October 22 meeting (attached below) no objections or changes noted. 3. Logistics for Meeting. 2a) Etherpad for notes https://etherpad.ietf.org/p/notes-cellar-virtual?useMonospaceFont=3D= true 2b) APPEAR.IN is not called "whereby.com" https://whereby.com/cellar-interim 2c) Roll call 4. Establish meeting schedule for 2020! Fourth tuesday of the month. Starting January 28, 2020. No meeting in July. September meeting might be 22nd, at conference "No Time to Wait". (web= page for the last one: https://mediaarea.net/NoTimeToWait4 , in Amsterdam = 2020 September) November meeting moved to Tuesday, December 1. 5. WG status update * EBML -- version 14 was posted 2019-12-02, on IESG telechat for 2019-12= -05 --- deferred as document was too long for some IESG membes t= o get a handle on * FFV1 -- version 11 was posted 2019-10-23, waiting for AD writeup. Dave Rice reports that changes that occured today was as a result of a revi= ew; some figures and tables are now cross-referenced more clearly. The same was done to ffv1. Some help is needed to get appropriate captions= on the tables. Robert Sparks asks that new versions not be updated until there are replies= and instructions. ACTION: MCR to followup with Robert Sparks on IANA issue. -> EBML is a "general purpose audio/video container" Steve to fix #304. 6. Work on Matroska issues. Split the main Matroska document to take the Chapters in another document? Only elements required for proper playback should be in the main document. Document 166 pages today. Chapters is 6 pages, section 11. --- but the section is not finished. Core document 9.3.4 "Tracks" is pages 45->106. MCR: hears support for splitting the chapter off, but asks if there is real= ly that much savings. Steve: we could make the document smaller by grouping things that have only= one parent or one child, with some better transformation of the formatting. The chapters section is not finished, and there are lot of incomplete secti= ons which will make the section significantly larger, and so splitting it off into another= document may still be justified. It makes no sense to work on it now, but make the split off now. Steve will give it a try and see what the savings is, and if we have a lot = references that break, but does not think that this is the case. Dave Rice is hesistant, not sure he sees enough of an advantage. Tags and Meta-data are developed asynchronously, but the chapters are not g= oing to evolve in place. This issue will be deferred. Peter B: ffv1 support in davinci / black-magic. Would rather do this after the doc= ument is published. What is status? did Derek's feedback about the implementation in GO make it back into the = document. DR: Yes, this went back into the document about three months ago. This re= sulted in a few issues being created, and the review was very helpful. Noting that there are three decoders: ffmpeg, Derek-GO, and Jerome's decoder 7. Any other business. 7.1 Side Data Format for MKV Benjamin: side data format for MKV! Dave Rice: it is merged into Matroska, can add side data to frames. Three competing things how to encode time code into the file. Related disc= ussion at https://mailarchive.ietf.org/arch/browse/cellar/?q=3Dmatroska%20a= nd%20side%20data%20vs%20timecode. 1) use side data. A debated proposal is at https://github.com/cellar-wg/ma= troska-specification/pull/348. (needsd to mentioned in main document) A sam= ple of matroska with side data timecode is at https://github.com/Matroska-O= rg/matroska-test-files/pull/5. 2) meta-data tag or segment info(needs to be in main document) 3) seperate track (codec-like document) NEXT meeting is 2020-01-22, =3D=3D=3D=3D CELLAR -- DRAFT AGENDA for Virtual Interim Meeting October 22, 2019 19:00 UTC 21:00 Amsterdam 15:00 NYC 12:00 San Francisco Present: 1. Michael Richardson 1. Martin Below 1. J=C3=A9r=C3=B4me Martinez 1. Steve Lhomme 1. Dave Rice INFO: https://datatracker.ietf.org/meeting/interim-2019-cellar-09/session/cell= ar https://datatracker.ietf.org/doc/agenda-interim-2019-cellar-09-sessa/ WEB CONFERENCE: https://whereby.com/cellar-interim THERE IS NO TELEPHONE DIALIN (You can try this at any time.) These notes at: https://github.com/cellar-wg/chair-notes 1. Note Well. https://www.ietf.org/about/note-well/ 2. Accept draft minutes from September 24 meeting (attached below) 3. Logistics for Meeting. 2a) Etherpad for notes https://etherpad.ietf.org/p/notes-cellar-virtual?useMonospaceFont=3D= true 2b) APPEAR.IN is now called "whereby.com" https://whereby.com/cellar-interim 2c) Roll call 4. WG status update * EBML -- version 13 was posted 2019-10-22, waiting for AD. * FFV1 -- version 10 was posted 2019-10-10, waiting for AD. 5. Interest in using gerrithub.io? For non-CLI uses, github has limitations lacking a web-based rebase process. http://gerrithub.io/ 6. Work on Matroska issues. ** now that EBML has provided the side-data container, we can start addin= g side-data types to Matroska. ** Google (WEBM) has created some new blocks (for HDR information) in the= container, and we need to make sure we do not collide. https://github.= com/cellar-wg/matroska-specification/issues/345 *** can we get them to coordinate better? *** now it is finished, but we need to try again. We could= say that values up to 10 are reserved. EBML issue: implementation note default? publish a new version? mcr: says go ahead with new version as you wish. FFV1: still waiting, but there are some issues raised by new decoder for v3= . And we should clarify the text. 7. Any other business. NEXT meeting is 2019-12-03 moved to 2019-12-10. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl3wC2kACgkQgItw+93Q 3WWwowf+MNqHrvQNV4GUQc5ikX635akVyjlMRKRPidOIaUmLg313tGNYwU5BVLwi T1+xhhf230fMX3TcW2FMFDnmJCiNoS1I/e9vyO9H0VuqQMZj6DoG0spnpS3gUMUC gEEvi/d/NHBjIiAr1KUfOeFkNt1qu8lqqHYyd07/VGolmZSjkFGKJOHrxjUAuhts XR1qOeyiKvusGMowHxK+4rbiBT6CdwLrrZJ3ielnPQ1igex0ztIpA4L91oXTk8wI Td2lmgseuCgwAOUqd8vPQ61bhTedQalNrHhfvfGMqyjlwWmwVth7OI5Q049D8qXP lvpeJewk/LSz5y+1XsG/CEz1UFdKKw== =vDWE -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Dec 10 13:27:27 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 5E532120019; Tue, 10 Dec 2019 13:27:21 -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.113.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157601324121.9922.8507984771250820545@ietfa.amsl.com> Date: Tue, 10 Dec 2019 13:27:21 -0800 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2020-01-21 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: Tue, 10 Dec 2019 21:27:21 -0000 The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) Working Group will hold a virtual interim meeting on 2020-01-21 from 21:00 to 22:00 Europe/Amsterdam. Agenda: to be uploaded Information about remote participation: https://whereby.com/cellar-interim From nobody Tue Dec 10 13:27: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 E476A120869; Tue, 10 Dec 2019 13:27:32 -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.113.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157601325289.9918.9984230696511723846@ietfa.amsl.com> Date: Tue, 10 Dec 2019 13:27:32 -0800 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2020-02-25 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: Tue, 10 Dec 2019 21:27:35 -0000 The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) Working Group will hold a virtual interim meeting on 2020-02-25 from 21:00 to 22:00 Europe/Amsterdam. Agenda: to be uploaded Information about remote participation: https://whereby.com/cellar-interim From nobody Tue Dec 10 13:27:51 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 3A6451209A2; Tue, 10 Dec 2019 13:27:41 -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.113.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157601326119.9994.2020948536628433649@ietfa.amsl.com> Date: Tue, 10 Dec 2019 13:27:41 -0800 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2020-03-31 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: Tue, 10 Dec 2019 21:27:44 -0000 The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) Working Group will hold a virtual interim meeting on 2020-03-31 from 21:00 to 22:00 Europe/Amsterdam. Agenda: to be uploaded Information about remote participation: https://whereby.com/cellar-interim From nobody Tue Dec 10 13:27:55 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 970A9120B29; Tue, 10 Dec 2019 13:27:48 -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.113.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157601326855.9939.3678744655044541090@ietfa.amsl.com> Date: Tue, 10 Dec 2019 13:27:48 -0800 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2020-04-28 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: Tue, 10 Dec 2019 21:27:51 -0000 The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) Working Group will hold a virtual interim meeting on 2020-04-28 from 21:00 to 22:00 Europe/Amsterdam. Agenda: to be uploaded Information about remote participation: https://whereby.com/cellar-interim From nobody Tue Dec 10 13:28: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 7F9CA120B95; Tue, 10 Dec 2019 13:27:58 -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.113.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157601327847.9877.17665853498695486758@ietfa.amsl.com> Date: Tue, 10 Dec 2019 13:27:58 -0800 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2020-05-26 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: Tue, 10 Dec 2019 21:28:01 -0000 The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) Working Group will hold a virtual interim meeting on 2020-05-26 from 21:00 to 22:00 Europe/Amsterdam. Agenda: to be uploaded Information about remote participation: https://whereby.com/cellar-interim From nobody Tue Dec 10 13:28:13 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 6706E120B50; Tue, 10 Dec 2019 13:28:06 -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.113.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157601328638.9909.1078602713734542537@ietfa.amsl.com> Date: Tue, 10 Dec 2019 13:28:06 -0800 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2020-06-23 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: Tue, 10 Dec 2019 21:28:09 -0000 The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) Working Group will hold a virtual interim meeting on 2020-06-23 from 21:00 to 22:00 Europe/Amsterdam. Agenda: to be uploaded Information about remote participation: https://whereby.com/cellar-interim From nobody Tue Dec 10 13:28:32 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 4E41E12081A; Tue, 10 Dec 2019 13:28:23 -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.113.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157601330321.9863.8427453526082082668@ietfa.amsl.com> Date: Tue, 10 Dec 2019 13:28:23 -0800 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2020-08-25 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: Tue, 10 Dec 2019 21:28:26 -0000 The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) Working Group will hold a virtual interim meeting on 2020-08-25 from 21:00 to 22:00 Europe/Amsterdam. Agenda: to be uploaded Information about remote participation: https://whereby.com/cellar-interim From nobody Tue Dec 10 13:28:39 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 3867E120C4A; Tue, 10 Dec 2019 13:28:30 -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.113.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157601331020.9998.614192285504688267@ietfa.amsl.com> Date: Tue, 10 Dec 2019 13:28:30 -0800 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2020-10-27 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: Tue, 10 Dec 2019 21:28:33 -0000 The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) Working Group will hold a virtual interim meeting on 2020-10-27 from 21:00 to 22:00 Europe/Amsterdam. Agenda: to be uploaded Information about remote participation: https://whereby.com/cellar-interim From nobody Tue Dec 10 13:28:48 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 5A44F120B47; Tue, 10 Dec 2019 13:28:39 -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.113.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157601331935.9873.13390792783812100475@ietfa.amsl.com> Date: Tue, 10 Dec 2019 13:28:39 -0800 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2020-12-01 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: Tue, 10 Dec 2019 21:28:42 -0000 The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) Working Group will hold a virtual interim meeting on 2020-12-01 from 21:00 to 22:00 Europe/Amsterdam. Agenda: to be uploaded Information about remote participation: https://whereby.com/cellar-interim From nobody Tue Dec 10 15:14:45 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 0AA8A1201EF for ; Tue, 10 Dec 2019 15:14:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 2FcaDKCnUS0l for ; Tue, 10 Dec 2019 15:14:42 -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 D61EC120059 for ; Tue, 10 Dec 2019 15:14:41 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 920C038981; Tue, 10 Dec 2019 17:16:30 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7D2CC7A2; Tue, 10 Dec 2019 17:13:28 -0500 (EST) From: Michael Richardson To: "Peter B." cc: cellar@ietf.org In-Reply-To: <12ac084b-f31c-331b-d501-92aa2dc3494c@das-werkstatt.com> References: <14450.1575234869@localhost> <27291.1576005039@localhost> <12ac084b-f31c-331b-d501-92aa2dc3494c@das-werkstatt.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 Date: Tue, 10 Dec 2019 17:13:28 -0500 Message-ID: <10361.1576016008@localhost> Archived-At: Subject: Re: [Cellar] REMINDER TODAY: Re: DRAFT AGENDA for VIRTUAL INTERIM MEETING 2019-12-10 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, 10 Dec 2019 23:14:44 -0000 Peter B. wrote: > Short question about web conference URL for this meeting: > On 10/12/2019 20:10, Michael Richardson wrote: >> > 2b) APPEAR.IN is not called "whereby.com" >> >https://whereby.com/cellar-interimw "now" called. > You wrote "appear.in is *not* called whereby.com", but > "appear.in/cellar-interim" returns a "404 not found", but > "whereby.com/cellar-interim" seems to work. They stopped the transition system. Sorry for the confusion. -- ] 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 [ From nobody Fri Dec 13 06:14:03 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 8146212009E; Fri, 13 Dec 2019 06:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 RbcQLcHe6EtR; Fri, 13 Dec 2019 06:13:54 -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 EBC79120851; Fri, 13 Dec 2019 06:13:53 -0800 (PST) Received: from [146.96.19.240] (port=55309 helo=[10.10.201.20]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iflhT-000wim-QT; Fri, 13 Dec 2019 09:13:52 -0500 From: Dave Rice Message-Id: <89710487-BA01-4ECB-99AD-D3730014E8A1@dericed.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_98A31C74-3076-4AFD-913A-6363AED51955" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Fri, 13 Dec 2019 09:13:45 -0500 In-Reply-To: Cc: Roman Danyliw , draft-ietf-cellar-ebml@ietf.org, Steven Villereal , The IESG , cellar-chairs@ietf.org, Codec Encoding for LossLess Archiving and Realtime transmission To: Steve Lhomme References: <157539924789.24871.7033050331898895759.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.8) X-OutGoing-Spam-Status: No, score=-2.9 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] Roman Danyliw's No Objection on draft-ietf-cellar-ebml-14: (with COMMENT) 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: Fri, 13 Dec 2019 14:13:56 -0000 --Apple-Mail=_98A31C74-3076-4AFD-913A-6363AED51955 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 10, 2019, at 2:53 PM, Steve Lhomme = wrote: >=20 > Hello Roman, >=20 > Thanks for taking the time to read and comment the document. Here are > my replies to your remarks. >=20 > Le mar. 3 d=C3=A9c. 2019 =C3=A0 19:54, Roman Danyliw via Datatracker > > a =C3=A9crit : >>=20 >> Roman Danyliw has entered the following ballot position for >> draft-ietf-cellar-ebml-14: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Section 1. Please add a reference to Matroska instead of an inline = URL >=20 > OK >=20 >> Section 1. Please add a reference for WebM >=20 > OK >=20 >> Section 2 and Table 4 of Section 5. These sections define EBML = Class. >> However, it isn=E2=80=99t used else where in the document. What is = it supposed to be >> used for? >=20 > It was used later in the document for Class A to Class D. But we don't > use that terminology anymore. Dave Rice has been replaced in a new > Pull Request: > https://github.com/cellar-wg/ebml-specification/pull/306 = This has been reviewed and merged. >> Section 4.4. Recommend replacing =E2=80=9CThis table=E2=80=9D text = to be the name of specific >> table in question (i.e., Table 1, Table 2) >=20 > OK >=20 >> Section 6.2. Per =E2=80=9CUnknown-Sized Element MUST NOT be used or = defined >> unnecessarily; however if the Element Data Size is not known before = the Element >> Data is written, such as in some cases of data streaming, then = Unknown- Sized >> Elements MAY be used.=E2=80=9D, should this text be read as =E2=80=9Cth= e Unknown- Sized >> Elements MUST only be used if the Element Data Size is not known = before the >> Element Data is written=E2=80=9D. >=20 > Yes, your suggestion has been integrated. >=20 >> I=E2=80=99m having trouble understanding how to handle >> normative language for a qualitative statement of =E2=80=9Cunnecessaril= y=E2=80=9D >>=20 >> Section 11.1.5.1. Double checking on the grammar of the name = attribute =E2=80=93 it is >> permitted to start with a =E2=80=9C-=E2=80=9C or a =E2=80=9C.=E2=80=9D?= >=20 > No. The text has been updated accordingly. >=20 >> Section 11.1.5.3. Are there any uniqueness properties for an id = attribute? >> Drawing a parallel from XML, I would have thought that each EBML = element would >> have unique ID per doctype (say like an xml:id) >=20 > No, the same id can be used by multiple element. Only the Path must be > unique. Although it's not explicitly mentioned. This mention is added in = https://github.com/cellar-wg/ebml-specification/pull/310/files = . I think all comments here have been addressed. Thanks so much for your = review, Roman. >> Section 11.1.7.2. documentation@purpose has a number of possible = enumerated >> values, however, none are defined in the text (they are only listed) >=20 > A table has been added to define the various values in detail. >=20 >>=20 >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar = >=20 >=20 >=20 > --=20 > Steve Lhomme > Matroska association Chairman >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar = --Apple-Mail=_98A31C74-3076-4AFD-913A-6363AED51955 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Dec 10, 2019, at 2:53 PM, Steve Lhomme <slhomme@matroska.org> wrote:

Hello Roman,

Thanks for taking the time to = read and comment the document. Here are
my replies to your remarks.

Le mar. 3 d=C3=A9c. 2019 =C3=A0 19:54, Roman Danyliw via = Datatracker
<noreply@ietf.org> a =C3=A9crit :

Roman Danyliw has entered the following ballot position = for
draft-ietf-cellar-ebml-14: No Objection

When responding, please keep the subject line = intact and reply to all
email addresses included in the To = and CC lines. (Feel free to cut this
introductory = paragraph, however.)


Please = refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/


---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

Section 1.  Please add a = reference to Matroska instead of an inline URL

OK

Section= 1.  Please add a reference for WebM

OK

Section 2 and Table 4 of Section 5. =  These sections define EBML Class.
However, it = isn=E2=80=99t used else where in the document.  What is it supposed = to be
used for?

It was used later in the = document for Class A to Class D. But we don't
use that terminology anymore. = Dave Rice has been replaced in a new
Pull Request:
https://github.com/cellar-wg/ebml-specification/pull/306

This has = been reviewed and merged.

Section= 4.4.  Recommend replacing =E2=80=9CThis table=E2=80=9D text to be = the name of specific
table in question (i.e., Table 1, = Table 2)

OK

Section= 6.2.  Per =E2=80=9CUnknown-Sized Element MUST NOT be used or = defined
unnecessarily; however if the Element Data Size is = not known before the Element
Data is written, such as in = some cases of data streaming, then Unknown- Sized
Elements = MAY be used.=E2=80=9D, should this text be read as =E2=80=9Cthe Unknown- = Sized
Elements MUST only be used if the Element Data Size = is not known before the
Element Data is written=E2=80=9D.

Yes, your suggestion has been integrated.

I=E2=80= =99m having trouble understanding how to handle
normative = language for a qualitative statement of =E2=80=9Cunnecessarily=E2=80=9D
Section 11.1.5.1.  Double checking on = the grammar of the name attribute =E2=80=93 it is
permitted = to start with a =E2=80=9C-=E2=80=9C or a =E2=80=9C.=E2=80=9D?

No. The text has been updated accordingly.

Section= 11.1.5.3.  Are there any uniqueness properties for an id = attribute?
Drawing a parallel from XML,  I would have = thought that each EBML element would
have unique ID per = doctype (say like an xml:id)

No, the same id can be used by = multiple element. Only the Path must be
unique. Although it's not explicitly mentioned.



Section= 11.1.7.2.  documentation@purpose has a number of possible = enumerated
values, however, none are defined in the text = (they are only listed)

A table has been added to define = the various values in detail.


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



-- Steve Lhomme
Matroska association = Chairman

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

= --Apple-Mail=_98A31C74-3076-4AFD-913A-6363AED51955-- From nobody Fri Dec 13 10:20: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 1EC9412010C; Fri, 13 Dec 2019 10:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=cert.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 Ki6TRfTPjcVw; Fri, 13 Dec 2019 10:20:22 -0800 (PST) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 F4162120013; Fri, 13 Dec 2019 10:20:21 -0800 (PST) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id xBDIJW3T015264; Fri, 13 Dec 2019 13:19:32 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu xBDIJW3T015264 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1576261173; bh=PLxE6ljZM6LVqauzHgKD9BeNrWb0NQqeUZ+OK+Ue0EY=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=qW5ZGQ+lAvXo9VelUuAHcpaLHJnf61TuZusax3N0Cq/QCQhvbM/wrFRv4zYQPUrZK GvaVYKhJ77K9iq29MvDR7mAoKu80snb9hLiOdw+SbAxM5bnNA6Zl8bFVCJDQ7AgJko z69pjvD7mJ/ppUei44vrl3j9IVdQdqMTujeL4XKU= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id xBDIJUiW009852; Fri, 13 Dec 2019 13:19:30 -0500 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0468.000; Fri, 13 Dec 2019 13:19:30 -0500 From: Roman Danyliw To: Dave Rice , Steve Lhomme CC: Steven Villereal , "cellar-chairs@ietf.org" , "draft-ietf-cellar-ebml@ietf.org" , The IESG , "Codec Encoding for LossLess Archiving and Realtime transmission" Thread-Topic: [Cellar] Roman Danyliw's No Objection on draft-ietf-cellar-ebml-14: (with COMMENT) Thread-Index: AQHVqgsRgWvC+2koyUe0cqP2NLMjhae0JrsAgARYD4D///BKIA== Date: Fri, 13 Dec 2019 18:19:29 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01E70DF027@marchand> References: <157539924789.24871.7033050331898895759.idtracker@ietfa.amsl.com> <89710487-BA01-4ECB-99AD-D3730014E8A1@dericed.com> In-Reply-To: <89710487-BA01-4ECB-99AD-D3730014E8A1@dericed.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC01E70DF027marchand_" MIME-Version: 1.0 Archived-At: Subject: Re: [Cellar] Roman Danyliw's No Objection on draft-ietf-cellar-ebml-14: (with COMMENT) 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: Fri, 13 Dec 2019 18:20:25 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC01E70DF027marchand_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3RldmUhDQoNClRoYW5rcyBmb3IgbWFraW5nIHRoZXNlIGNoYW5nZXMgYW5kIGV4cGxhaW5p bmcgdGhlIGlkIGF0dHJpYnV0ZS4gIFRoZXkgYWRkcmVzcyBteSBDT01NRU5Ucy4NCg0KUmVnYXJk cywNClJvbWFuDQoNCkZyb206IGllc2cgPGllc2ctYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxm IE9mIERhdmUgUmljZQ0KU2VudDogRnJpZGF5LCBEZWNlbWJlciAxMywgMjAxOSA5OjE0IEFNDQpU bzogU3RldmUgTGhvbW1lIDxzbGhvbW1lQG1hdHJvc2thLm9yZz4NCkNjOiBSb21hbiBEYW55bGl3 IDxyZGRAY2VydC5vcmc+OyBTdGV2ZW4gVmlsbGVyZWFsIDx2aWxsZXJlYWxAZ21haWwuY29tPjsg Y2VsbGFyLWNoYWlyc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1jZWxsYXItZWJtbEBpZXRmLm9yZzsg VGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+OyBDb2RlYyBFbmNvZGluZyBmb3IgTG9zc0xlc3MgQXJj aGl2aW5nIGFuZCBSZWFsdGltZSB0cmFuc21pc3Npb24gPGNlbGxhckBpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbQ2VsbGFyXSBSb21hbiBEYW55bGl3J3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWll dGYtY2VsbGFyLWVibWwtMTQ6ICh3aXRoIENPTU1FTlQpDQoNCg0KT24gRGVjIDEwLCAyMDE5LCBh dCAyOjUzIFBNLCBTdGV2ZSBMaG9tbWUgPHNsaG9tbWVAbWF0cm9za2Eub3JnPG1haWx0bzpzbGhv bW1lQG1hdHJvc2thLm9yZz4+IHdyb3RlOg0KDQpIZWxsbyBSb21hbiwNCg0KVGhhbmtzIGZvciB0 YWtpbmcgdGhlIHRpbWUgdG8gcmVhZCBhbmQgY29tbWVudCB0aGUgZG9jdW1lbnQuIEhlcmUgYXJl DQpteSByZXBsaWVzIHRvIHlvdXIgcmVtYXJrcy4NCg0KTGUgbWFyLiAzIGTDqWMuIDIwMTkgw6Ag MTk6NTQsIFJvbWFuIERhbnlsaXcgdmlhIERhdGF0cmFja2VyDQo8bm9yZXBseUBpZXRmLm9yZzxt YWlsdG86bm9yZXBseUBpZXRmLm9yZz4+IGEgw6ljcml0IDoNCg0KDQpSb21hbiBEYW55bGl3IGhh cyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KZHJhZnQtaWV0Zi1j ZWxsYXItZWJtbC0xNDogTm8gT2JqZWN0aW9uDQoNCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtl ZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KZW1haWwgYWRkcmVz c2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRo aXMNCmludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNClBsZWFzZSByZWZlciB0 byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0 bWwNCmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBw b3NpdGlvbnMuDQoNCg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3Np dGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1jZWxsYXItZWJtbC8NCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNPTU1FTlQ6 DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQoNClNlY3Rpb24gMS4gIFBsZWFzZSBhZGQgYSByZWZlcmVuY2UgdG8g TWF0cm9za2EgaW5zdGVhZCBvZiBhbiBpbmxpbmUgVVJMDQoNCk9LDQoNCg0KU2VjdGlvbiAxLiAg UGxlYXNlIGFkZCBhIHJlZmVyZW5jZSBmb3IgV2ViTQ0KDQpPSw0KDQoNClNlY3Rpb24gMiBhbmQg VGFibGUgNCBvZiBTZWN0aW9uIDUuICBUaGVzZSBzZWN0aW9ucyBkZWZpbmUgRUJNTCBDbGFzcy4N Ckhvd2V2ZXIsIGl0IGlzbuKAmXQgdXNlZCBlbHNlIHdoZXJlIGluIHRoZSBkb2N1bWVudC4gIFdo YXQgaXMgaXQgc3VwcG9zZWQgdG8gYmUNCnVzZWQgZm9yPw0KDQpJdCB3YXMgdXNlZCBsYXRlciBp biB0aGUgZG9jdW1lbnQgZm9yIENsYXNzIEEgdG8gQ2xhc3MgRC4gQnV0IHdlIGRvbid0DQp1c2Ug dGhhdCB0ZXJtaW5vbG9neSBhbnltb3JlLiBEYXZlIFJpY2UgaGFzIGJlZW4gcmVwbGFjZWQgaW4g YSBuZXcNClB1bGwgUmVxdWVzdDoNCmh0dHBzOi8vZ2l0aHViLmNvbS9jZWxsYXItd2cvZWJtbC1z cGVjaWZpY2F0aW9uL3B1bGwvMzA2DQoNClRoaXMgaGFzIGJlZW4gcmV2aWV3ZWQgYW5kIG1lcmdl ZC4NCg0KDQpTZWN0aW9uIDQuNC4gIFJlY29tbWVuZCByZXBsYWNpbmcg4oCcVGhpcyB0YWJsZeKA nSB0ZXh0IHRvIGJlIHRoZSBuYW1lIG9mIHNwZWNpZmljDQp0YWJsZSBpbiBxdWVzdGlvbiAoaS5l LiwgVGFibGUgMSwgVGFibGUgMikNCg0KT0sNCg0KDQpTZWN0aW9uIDYuMi4gIFBlciDigJxVbmtu b3duLVNpemVkIEVsZW1lbnQgTVVTVCBOT1QgYmUgdXNlZCBvciBkZWZpbmVkDQp1bm5lY2Vzc2Fy aWx5OyBob3dldmVyIGlmIHRoZSBFbGVtZW50IERhdGEgU2l6ZSBpcyBub3Qga25vd24gYmVmb3Jl IHRoZSBFbGVtZW50DQpEYXRhIGlzIHdyaXR0ZW4sIHN1Y2ggYXMgaW4gc29tZSBjYXNlcyBvZiBk YXRhIHN0cmVhbWluZywgdGhlbiBVbmtub3duLSBTaXplZA0KRWxlbWVudHMgTUFZIGJlIHVzZWQu 4oCdLCBzaG91bGQgdGhpcyB0ZXh0IGJlIHJlYWQgYXMg4oCcdGhlIFVua25vd24tIFNpemVkDQpF bGVtZW50cyBNVVNUIG9ubHkgYmUgdXNlZCBpZiB0aGUgRWxlbWVudCBEYXRhIFNpemUgaXMgbm90 IGtub3duIGJlZm9yZSB0aGUNCkVsZW1lbnQgRGF0YSBpcyB3cml0dGVu4oCdLg0KDQpZZXMsIHlv dXIgc3VnZ2VzdGlvbiBoYXMgYmVlbiBpbnRlZ3JhdGVkLg0KDQoNCknigJltIGhhdmluZyB0cm91 YmxlIHVuZGVyc3RhbmRpbmcgaG93IHRvIGhhbmRsZQ0Kbm9ybWF0aXZlIGxhbmd1YWdlIGZvciBh IHF1YWxpdGF0aXZlIHN0YXRlbWVudCBvZiDigJx1bm5lY2Vzc2FyaWx54oCdDQoNClNlY3Rpb24g MTEuMS41LjEuICBEb3VibGUgY2hlY2tpbmcgb24gdGhlIGdyYW1tYXIgb2YgdGhlIG5hbWUgYXR0 cmlidXRlIOKAkyBpdCBpcw0KcGVybWl0dGVkIHRvIHN0YXJ0IHdpdGggYSDigJwt4oCcIG9yIGEg 4oCcLuKAnT8NCg0KTm8uIFRoZSB0ZXh0IGhhcyBiZWVuIHVwZGF0ZWQgYWNjb3JkaW5nbHkuDQoN Cg0KU2VjdGlvbiAxMS4xLjUuMy4gIEFyZSB0aGVyZSBhbnkgdW5pcXVlbmVzcyBwcm9wZXJ0aWVz IGZvciBhbiBpZCBhdHRyaWJ1dGU/DQpEcmF3aW5nIGEgcGFyYWxsZWwgZnJvbSBYTUwsICBJIHdv dWxkIGhhdmUgdGhvdWdodCB0aGF0IGVhY2ggRUJNTCBlbGVtZW50IHdvdWxkDQpoYXZlIHVuaXF1 ZSBJRCBwZXIgZG9jdHlwZSAoc2F5IGxpa2UgYW4geG1sOmlkKQ0KDQpObywgdGhlIHNhbWUgaWQg Y2FuIGJlIHVzZWQgYnkgbXVsdGlwbGUgZWxlbWVudC4gT25seSB0aGUgUGF0aCBtdXN0IGJlDQp1 bmlxdWUuIEFsdGhvdWdoIGl0J3Mgbm90IGV4cGxpY2l0bHkgbWVudGlvbmVkLg0KDQpUaGlzIG1l bnRpb24gaXMgYWRkZWQgaW4gaHR0cHM6Ly9naXRodWIuY29tL2NlbGxhci13Zy9lYm1sLXNwZWNp ZmljYXRpb24vcHVsbC8zMTAvZmlsZXMuDQoNCkkgdGhpbmsgYWxsIGNvbW1lbnRzIGhlcmUgaGF2 ZSBiZWVuIGFkZHJlc3NlZC4gVGhhbmtzIHNvIG11Y2ggZm9yIHlvdXIgcmV2aWV3LCBSb21hbi4N Cg0KU2VjdGlvbiAxMS4xLjcuMi4gIGRvY3VtZW50YXRpb25AcHVycG9zZSBoYXMgYSBudW1iZXIg b2YgcG9zc2libGUgZW51bWVyYXRlZA0KdmFsdWVzLCBob3dldmVyLCBub25lIGFyZSBkZWZpbmVk IGluIHRoZSB0ZXh0ICh0aGV5IGFyZSBvbmx5IGxpc3RlZCkNCg0KQSB0YWJsZSBoYXMgYmVlbiBh ZGRlZCB0byBkZWZpbmUgdGhlIHZhcmlvdXMgdmFsdWVzIGluIGRldGFpbC4NCg0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpDZWxsYXIgbWFpbGlu ZyBsaXN0DQpDZWxsYXJAaWV0Zi5vcmc8bWFpbHRvOkNlbGxhckBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2VsbGFyDQoNCg0KDQotLQ0KU3RldmUgTGhv bW1lDQpNYXRyb3NrYSBhc3NvY2lhdGlvbiBDaGFpcm1hbg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQ2VsbGFyIG1haWxpbmcgbGlzdA0KQ2VsbGFy QGlldGYub3JnPG1haWx0bzpDZWxsYXJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2NlbGxhcg0KDQo= --_000_359EC4B99E040048A7131E0F4E113AFC01E70DF027marchand_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25v cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uYXBw bGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFj ZTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5IaSBTdGV2ZSE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGZvciBt YWtpbmcgdGhlc2UgY2hhbmdlcyBhbmQgZXhwbGFpbmluZyB0aGUgaWQgYXR0cmlidXRlLiZuYnNw OyBUaGV5IGFkZHJlc3MgbXkgQ09NTUVOVHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2Fy ZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Sb21hbjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBpZXNnICZsdDtpZXNnLWJvdW5jZXNAaWV0Zi5v cmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZiA8L2I+DQpEYXZlIFJpY2U8YnI+DQo8Yj5TZW50OjwvYj4g RnJpZGF5LCBEZWNlbWJlciAxMywgMjAxOSA5OjE0IEFNPGJyPg0KPGI+VG86PC9iPiBTdGV2ZSBM aG9tbWUgJmx0O3NsaG9tbWVAbWF0cm9za2Eub3JnJmd0Ozxicj4NCjxiPkNjOjwvYj4gUm9tYW4g RGFueWxpdyAmbHQ7cmRkQGNlcnQub3JnJmd0OzsgU3RldmVuIFZpbGxlcmVhbCAmbHQ7dmlsbGVy ZWFsQGdtYWlsLmNvbSZndDs7IGNlbGxhci1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtY2Vs bGFyLWVibWxAaWV0Zi5vcmc7IFRoZSBJRVNHICZsdDtpZXNnQGlldGYub3JnJmd0OzsgQ29kZWMg RW5jb2RpbmcgZm9yIExvc3NMZXNzIEFyY2hpdmluZyBhbmQgUmVhbHRpbWUgdHJhbnNtaXNzaW9u ICZsdDtjZWxsYXJAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQ2VsbGFy XSBSb21hbiBEYW55bGl3J3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtY2VsbGFyLWVibWwt MTQ6ICh3aXRoIENPTU1FTlQpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBEZWMgMTAsIDIwMTksIGF0IDI6NTMgUE0sIFN0ZXZlIExob21tZSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnNsaG9tbWVAbWF0cm9za2Eub3JnIj5zbGhvbW1lQG1hdHJvc2thLm9yZzwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj5IZWxsbyBSb21hbiw8YnI+DQo8YnI+DQpUaGFua3MgZm9yIHRha2luZyB0aGUg dGltZSB0byByZWFkIGFuZCBjb21tZW50IHRoZSBkb2N1bWVudC4gSGVyZSBhcmU8YnI+DQpteSBy ZXBsaWVzIHRvIHlvdXIgcmVtYXJrcy48YnI+DQo8YnI+DQpMZSBtYXIuIDMgZMOpYy4gMjAxOSDD oCAxOTo1NCwgUm9tYW4gRGFueWxpdyB2aWEgRGF0YXRyYWNrZXI8YnI+DQombHQ7PC9zcGFuPjxh IGhyZWY9Im1haWx0bzpub3JlcGx5QGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5ub3JlcGx5 QGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IGEgw6ljcml0IDo8YnIg c3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDt0ZXh0LWFsaWduOnN0YXJ0Oy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNw YWNpbmc6MHB4Ij4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KUm9tYW4gRGFueWxpdyBoYXMgZW50ZXJl ZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3I8YnI+DQpkcmFmdC1pZXRmLWNlbGxh ci1lYm1sLTE0OiBObyBPYmplY3Rpb248YnI+DQo8YnI+DQpXaGVuIHJlc3BvbmRpbmcsIHBsZWFz ZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGw8YnI+DQplbWFp bCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0 byBjdXQgdGhpczxicj4NCmludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKTxicj4NCjxi cj4NCjxicj4NClBsZWFzZSByZWZlciB0byA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9p ZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwiPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sPC9hPjxicj4NCmZvciBtb3Jl IGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuPGJy Pg0KPGJyPg0KPGJyPg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3Np dGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY2VsbGFyLWVibWwvIj5odHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNlbGxhci1lYm1sLzwvYT48YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KQ09NTUVOVDo8YnI+DQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PGJyPg0KPGJyPg0KU2VjdGlvbiAxLiAmbmJzcDtQbGVhc2UgYWRkIGEgcmVmZXJlbmNlIHRvIE1h dHJvc2thIGluc3RlYWQgb2YgYW4gaW5saW5lIFVSTDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv YmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4N Ck9LPGJyPg0KPGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7dGV4dC1hbGlnbjpzdGFydDstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlNlY3Rpb24gMS4gJm5ic3A7 UGxlYXNlIGFkZCBhIHJlZmVyZW5jZSBmb3IgV2ViTTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv YmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4N Ck9LPGJyPg0KPGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7dGV4dC1hbGlnbjpzdGFydDstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlNlY3Rpb24gMiBhbmQgVGFi bGUgNCBvZiBTZWN0aW9uIDUuICZuYnNwO1RoZXNlIHNlY3Rpb25zIGRlZmluZSBFQk1MIENsYXNz Ljxicj4NCkhvd2V2ZXIsIGl0IGlzbuKAmXQgdXNlZCBlbHNlIHdoZXJlIGluIHRoZSBkb2N1bWVu dC4gJm5ic3A7V2hhdCBpcyBpdCBzdXBwb3NlZCB0byBiZTxicj4NCnVzZWQgZm9yPzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPjxicj4NCkl0IHdhcyB1c2VkIGxhdGVyIGluIHRoZSBkb2N1bWVudCBmb3Ig Q2xhc3MgQSB0byBDbGFzcyBELiBCdXQgd2UgZG9uJ3Q8YnI+DQp1c2UgdGhhdCB0ZXJtaW5vbG9n eSBhbnltb3JlLiBEYXZlIFJpY2UgaGFzIGJlZW4gcmVwbGFjZWQgaW4gYSBuZXc8YnI+DQpQdWxs IFJlcXVlc3Q6PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9jZWxsYXIt d2cvZWJtbC1zcGVjaWZpY2F0aW9uL3B1bGwvMzA2Ij5odHRwczovL2dpdGh1Yi5jb20vY2VsbGFy LXdnL2VibWwtc3BlY2lmaWNhdGlvbi9wdWxsLzMwNjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBoYXMg YmVlbiByZXZpZXdlZCBhbmQgbWVyZ2VkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQ7Zm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13 ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7d29yZC1zcGFjaW5nOjBweCI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5TZWN0aW9uIDQuNC4gJm5ic3A7UmVjb21tZW5kIHJlcGxhY2luZyDigJxU aGlzIHRhYmxl4oCdIHRleHQgdG8gYmUgdGhlIG5hbWUgb2Ygc3BlY2lmaWM8YnI+DQp0YWJsZSBp biBxdWVzdGlvbiAoaS5lLiwgVGFibGUgMSwgVGFibGUgMik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48 YnI+DQpPSzxicj4NCjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7LXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5TZWN0aW9uIDYuMi4g Jm5ic3A7UGVyIOKAnFVua25vd24tU2l6ZWQgRWxlbWVudCBNVVNUIE5PVCBiZSB1c2VkIG9yIGRl ZmluZWQ8YnI+DQp1bm5lY2Vzc2FyaWx5OyBob3dldmVyIGlmIHRoZSBFbGVtZW50IERhdGEgU2l6 ZSBpcyBub3Qga25vd24gYmVmb3JlIHRoZSBFbGVtZW50PGJyPg0KRGF0YSBpcyB3cml0dGVuLCBz dWNoIGFzIGluIHNvbWUgY2FzZXMgb2YgZGF0YSBzdHJlYW1pbmcsIHRoZW4gVW5rbm93bi0gU2l6 ZWQ8YnI+DQpFbGVtZW50cyBNQVkgYmUgdXNlZC7igJ0sIHNob3VsZCB0aGlzIHRleHQgYmUgcmVh ZCBhcyDigJx0aGUgVW5rbm93bi0gU2l6ZWQ8YnI+DQpFbGVtZW50cyBNVVNUIG9ubHkgYmUgdXNl ZCBpZiB0aGUgRWxlbWVudCBEYXRhIFNpemUgaXMgbm90IGtub3duIGJlZm9yZSB0aGU8YnI+DQpF bGVtZW50IERhdGEgaXMgd3JpdHRlbuKAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQpZZXMs IHlvdXIgc3VnZ2VzdGlvbiBoYXMgYmVlbiBpbnRlZ3JhdGVkLjxicj4NCjxiciBzdHlsZT0iY2Fy ZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO3RleHQtYWxp Z246c3RhcnQ7LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgi Pg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5J4oCZbSBoYXZpbmcgdHJvdWJsZSB1bmRlcnN0YW5kaW5nIGhvdyB0 byBoYW5kbGU8YnI+DQpub3JtYXRpdmUgbGFuZ3VhZ2UgZm9yIGEgcXVhbGl0YXRpdmUgc3RhdGVt ZW50IG9mIOKAnHVubmVjZXNzYXJpbHnigJ08YnI+DQo8YnI+DQpTZWN0aW9uIDExLjEuNS4xLiAm bmJzcDtEb3VibGUgY2hlY2tpbmcgb24gdGhlIGdyYW1tYXIgb2YgdGhlIG5hbWUgYXR0cmlidXRl IOKAkyBpdCBpczxicj4NCnBlcm1pdHRlZCB0byBzdGFydCB3aXRoIGEg4oCcLeKAnCBvciBhIOKA nC7igJ0/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KTm8uIFRoZSB0ZXh0IGhhcyBiZWVuIHVw ZGF0ZWQgYWNjb3JkaW5nbHkuPGJyPg0KPGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAs IDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7dGV4dC1hbGlnbjpzdGFydDstd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8YnI+DQo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlNl Y3Rpb24gMTEuMS41LjMuICZuYnNwO0FyZSB0aGVyZSBhbnkgdW5pcXVlbmVzcyBwcm9wZXJ0aWVz IGZvciBhbiBpZCBhdHRyaWJ1dGU/PGJyPg0KRHJhd2luZyBhIHBhcmFsbGVsIGZyb20gWE1MLCAm bmJzcDtJIHdvdWxkIGhhdmUgdGhvdWdodCB0aGF0IGVhY2ggRUJNTCBlbGVtZW50IHdvdWxkPGJy Pg0KaGF2ZSB1bmlxdWUgSUQgcGVyIGRvY3R5cGUgKHNheSBsaWtlIGFuIHhtbDppZCk8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj48YnI+DQpObywgdGhlIHNhbWUgaWQgY2FuIGJlIHVzZWQgYnkgbXVsdGlw bGUgZWxlbWVudC4gT25seSB0aGUgUGF0aCBtdXN0IGJlPGJyPg0KdW5pcXVlLiBBbHRob3VnaCBp dCdzIG5vdCBleHBsaWNpdGx5IG1lbnRpb25lZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgbWVu dGlvbiBpcyBhZGRlZCBpbiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9jZWxsYXIt d2cvZWJtbC1zcGVjaWZpY2F0aW9uL3B1bGwvMzEwL2ZpbGVzIj5odHRwczovL2dpdGh1Yi5jb20v Y2VsbGFyLXdnL2VibWwtc3BlY2lmaWNhdGlvbi9wdWxsLzMxMC9maWxlczwvYT4uPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgYWxs IGNvbW1lbnRzIGhlcmUgaGF2ZSBiZWVuIGFkZHJlc3NlZC4gVGhhbmtzIHNvIG11Y2ggZm9yIHlv dXIgcmV2aWV3LCBSb21hbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0O2ZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93 czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+U2VjdGlvbiAxMS4xLjcuMi4gJm5ic3A7ZG9jdW1lbnRhdGlvbkBwdXJw b3NlIGhhcyBhIG51bWJlciBvZiBwb3NzaWJsZSBlbnVtZXJhdGVkPGJyPg0KdmFsdWVzLCBob3dl dmVyLCBub25lIGFyZSBkZWZpbmVkIGluIHRoZSB0ZXh0ICh0aGV5IGFyZSBvbmx5IGxpc3RlZCk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQpBIHRhYmxlIGhhcyBiZWVuIGFkZGVkIHRvIGRlZmlu ZSB0aGUgdmFyaW91cyB2YWx1ZXMgaW4gZGV0YWlsLjxicj4NCjxiciBzdHlsZT0iY2FyZXQtY29s b3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO3RleHQtYWxpZ246c3Rh cnQ7LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPGJy Pg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCkNlbGxhciBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86Q2Vs bGFyQGlldGYub3JnIj5DZWxsYXJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZWxsYXIiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vY2VsbGFyPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjxi cj4NCjxicj4NCi0tPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxicj4NClN0ZXZlIExob21tZTxicj4NCk1hdHJvc2thIGFzc29jaWF0aW9uIENoYWlybWFu PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpDZWxsYXIgbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpD ZWxsYXJAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkNlbGxhckBpZXRmLm9yZzwvc3Bhbj48 L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vY2VsbGFyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NlbGxhcjwvc3Bhbj48L2E+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_359EC4B99E040048A7131E0F4E113AFC01E70DF027marchand_-- From nobody Sun Dec 15 01:12:33 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 93EAA120099 for ; Sun, 15 Dec 2019 01:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=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 mv6AHcX_XcWP for ; Sun, 15 Dec 2019 01:12:29 -0800 (PST) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 9CF3F120089 for ; Sun, 15 Dec 2019 01:12:29 -0800 (PST) Received: by mail-pf1-x434.google.com with SMTP id x184so3951508pfb.3 for ; Sun, 15 Dec 2019 01:12:29 -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=5NxsDK7yOU4KKHgUGtQsO4SL0XQUj46RHMf5YzQG5xo=; b=H46WMxTo+VoQ52dikzxi5Bi+R4e/dqjDHnOjRRooFIMAz3f5O9BvM525NbYp4AbuHB YjfiNDjE5LB5UfoimqMBzsfs7kq8raXFD9p7448qyOOhxy0cLICjcBWVxaIrclXZNSuu cnCHSbBYDyZt9IwV2LRxuQAhaz/76BFFROrv8keadgZJLI36ZTnqBgY+UsjSsFgiofGv +PDlI4IPdcre7JbqZJ2FbamrfoDWnbJFmux457N5zYbQU8NCbtM/ahfUgTvJMUIp1u/8 H1cg57r7UjLZzr2FvWKZbPXMLU02T/TuNCFslBprCfBI20jNLeQv+isfa+pYONqBjJHg OO5Q== 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=5NxsDK7yOU4KKHgUGtQsO4SL0XQUj46RHMf5YzQG5xo=; b=Ao05HLyj4CUmYNgr1FNTPSHIwW+AzL3oY2VhRB+RHwMpuUAWmD2T9hakAMsPWwXkwR tnObirvH6leJ4aTL2FcxV9I1Bh9vSqDHEXWydzWabd9OifXFNjDc5ThjpFU12D2dO1r1 ml7eUl/x4B7fPNaAimjWNYB1JiIttTnoO1w2I/G/z7yY9jEUF0xeVbx8JaNWp3zG5XIv MFz+ThXMWtOmtcRDrIActbU09GZLHzaqkA6nBtzQ+OHJZdgxbb09pO2IkEwixMzyJUzT 65P9h5zdub+Zw74J5BEfdmBfcu8ET4TgmpMXzdRB1T4C33HosjanGme5GV7acQJeOAn6 huww== X-Gm-Message-State: APjAAAVH2Cr1SJ3QhtEgpaeQqbD2/Zmy3G8gOCJbI+3skkR5yBEwLqJg /kknIjY78++zxn3Strh/lLGZup50sVfw881HT02L/qQB8M0= X-Google-Smtp-Source: APXvYqw08CscOjghnoM3WteSo6RrRDDQ2hNTe8VTPGLCEVFbJajHbWdB73gXMwD92TJQP1owDtnCuA7gd5Kib74Iz2M= X-Received: by 2002:aa7:9315:: with SMTP id 21mr9951261pfj.187.1576401149017; Sun, 15 Dec 2019 01:12:29 -0800 (PST) MIME-Version: 1.0 References: <14450.1575234869@localhost> <27291.1576005039@localhost> <8420.1576012649@localhost> In-Reply-To: <8420.1576012649@localhost> From: Steve Lhomme Date: Sun, 15 Dec 2019 10:12:17 +0100 Message-ID: To: Michael Richardson 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] DRAFT 2019-12-10 minutes and upcoming CELLAR virtual interim meetings 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, 15 Dec 2019 09:12:31 -0000 Hi, The 2020-08-28 is a Friday, is this correct? Le mar. 10 d=C3=A9c. 2019 =C3=A0 22:17, Michael Richardson a =C3=A9crit : > > > Future meetings will probably be: > > 2020-01-21. > 2020-02-25 > 2020-03-31 (IETF week is 20-27, I goofed during the call) > 2020-04-28 > 2020-05-26 > 2020-06-23 > skip July (IETF week is july 25-31 in Madrid) > 2020-08-28 > 2020-09-22 possibly in-person with NoTimeToWait - 2020 in AMS. > 2020-10-27 > 2020-12-01 > > > Here are the draft minutes from today. > > CELLAR -- DRAFT AGENDA for Virtual Interim Meeting > December 10, 2019 19:00 UTC > 21:00 Amsterdam > 15:00 NYC > 12:00 San Francisco > > REGRETS: > 1) Reto Kromer > > PRESENT: > 1) Michael Richardson > 2) Benjamin Turkus > 3) Dave Rice > 4) Martin Below > 5) Michael Niedermayer > 6) Peter Bubestinger > 7) Steve Lhomme > 8) Jerome Martinez > 9) Dante Bromkovsky > > > INFO: > https://datatracker.ietf.org/meeting/interim-2019-cellar-10/session/ce= llar > https://datatracker.ietf.org/doc/agenda-interim-2019-cellar-10-sessa/ > > WEB CONFERENCE: > https://whereby.com/cellar-interim > THERE IS NO TELEPHONE DIALIN (You can try this at any time.) > These notes at: https://github.com/cellar-wg/chair-notes > > 1. Note Well. https://www.ietf.org/about/note-well/ > 2. Accept draft minutes from October 22 meeting (attached below) > no objections or changes noted. > > 3. Logistics for Meeting. > 2a) Etherpad for notes > https://etherpad.ietf.org/p/notes-cellar-virtual?useMonospaceFont= =3Dtrue > > 2b) APPEAR.IN is not called "whereby.com" > https://whereby.com/cellar-interim > > 2c) Roll call > > 4. Establish meeting schedule for 2020! > Fourth tuesday of the month. Starting January 28, 2020. > No meeting in July. > September meeting might be 22nd, at conference "No Time to Wait". (w= eb page for the last one: https://mediaarea.net/NoTimeToWait4 , in Amsterda= m 2020 September) > November meeting moved to Tuesday, December 1. > > 5. WG status update > * EBML -- version 14 was posted 2019-12-02, on IESG telechat for 2019-= 12-05 > --- deferred as document was too long for some IESG membes= to get a handle on > * FFV1 -- version 11 was posted 2019-10-23, waiting for AD writeup. > > Dave Rice reports that changes that occured today was as a result of a re= view; some figures and tables are now cross-referenced more clearly. > The same was done to ffv1. Some help is needed to get appropriate captio= ns on the tables. > Robert Sparks asks that new versions not be updated until there are repli= es and instructions. > ACTION: MCR to followup with Robert Sparks on IANA issue. > -> EBML is a "general purpose audio/video container" Steve to fix #304= . > > 6. Work on Matroska issues. > > Split the main Matroska document to take the Chapters in another document= ? > Only elements required for proper playback should be in the main document= . > Document 166 pages today. > Chapters is 6 pages, section 11. --- but the section is not finished. > Core document 9.3.4 "Tracks" is pages 45->106. > > MCR: hears support for splitting the chapter off, but asks if there is re= ally that much savings. > Steve: we could make the document smaller by grouping things that have on= ly one parent or one child, with some better transformation of the formatti= ng. > > > The chapters section is not finished, and there are lot of incomplete sec= tions which will > make the section significantly larger, and so splitting it off into anoth= er document may still be justified. > It makes no sense to work on it now, but make the split off now. > Steve will give it a try and see what the savings is, and if we have a lo= t references that break, but does not think that this is the case. > Dave Rice is hesistant, not sure he sees enough of an advantage. > Tags and Meta-data are developed asynchronously, but the chapters are not= going to evolve in place. > This issue will be deferred. > > Peter B: > ffv1 support in davinci / black-magic. Would rather do this afte= r the document is published. What is status? > did Derek's feedback about the implementation in GO make it back = into the document. > DR: Yes, this went back into the document about three months ago.= This resulted in a few issues being created, and the review was very help= ful. > > Noting that there are three decoders: ffmpeg, Derek-GO, and Jerome's deco= der > > 7. Any other business. > > 7.1 Side Data Format for MKV > Benjamin: side data format for MKV! > Dave Rice: it is merged into Matroska, can add side data to frame= s. > Three competing things how to encode time code into the file. Rel= ated discussion at https://mailarchive.ietf.org/arch/browse/cellar/?q=3Dmat= roska%20and%20side%20data%20vs%20timecode. > 1) use side data. A debated proposal is at https://github.com/cel= lar-wg/matroska-specification/pull/348. (needsd to mentioned in main docume= nt) A sample of matroska with side data timecode is at https://github.com/M= atroska-Org/matroska-test-files/pull/5. > 2) meta-data tag or segment info(needs to be in main document) > 3) seperate track (codec-like document) > > > > > NEXT meeting is 2020-01-22, > > =3D=3D=3D=3D > CELLAR -- DRAFT AGENDA for Virtual Interim Meeting > October 22, 2019 19:00 UTC > 21:00 Amsterdam > 15:00 NYC > 12:00 San Francisco > > Present: > 1. Michael Richardson > 1. Martin Below > 1. J=C3=A9r=C3=B4me Martinez > 1. Steve Lhomme > 1. Dave Rice > > > > INFO: > https://datatracker.ietf.org/meeting/interim-2019-cellar-09/session/ce= llar > https://datatracker.ietf.org/doc/agenda-interim-2019-cellar-09-sessa/ > > WEB CONFERENCE: > https://whereby.com/cellar-interim > THERE IS NO TELEPHONE DIALIN (You can try this at any time.) > These notes at: https://github.com/cellar-wg/chair-notes > > 1. Note Well. https://www.ietf.org/about/note-well/ > 2. Accept draft minutes from September 24 meeting (attached below) > > 3. Logistics for Meeting. > 2a) Etherpad for notes > https://etherpad.ietf.org/p/notes-cellar-virtual?useMonospaceFont= =3Dtrue > > 2b) APPEAR.IN is now called "whereby.com" > https://whereby.com/cellar-interim > > 2c) Roll call > > 4. WG status update > * EBML -- version 13 was posted 2019-10-22, waiting for AD. > * FFV1 -- version 10 was posted 2019-10-10, waiting for AD. > > 5. Interest in using gerrithub.io? > For non-CLI uses, github has limitations lacking a web-based rebase > process. http://gerrithub.io/ > > 6. Work on Matroska issues. > ** now that EBML has provided the side-data container, we can start add= ing side-data types to Matroska. > ** Google (WEBM) has created some new blocks (for HDR information) in t= he container, and we need to make sure we do not collide. https://githu= b.com/cellar-wg/matroska-specification/issues/345 > *** can we get them to coordinate better? > *** now it is finished, but we need to try again. We cou= ld say that values up to 10 are reserved. > > EBML issue: implementation note default? publish a new version? > mcr: says go ahead with new version as you wish. > > FFV1: still waiting, but there are some issues raised by new decoder for = v3.. And we should clarify the text. > > > 7. Any other business. > > NEXT meeting is 2019-12-03 moved to 2019-12-10. > > > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- > > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Mon Dec 16 06:02:01 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 A0295120835 for ; Mon, 16 Dec 2019 06:01:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157650491965.21483.4287269740346552570.idtracker@ietfa.amsl.com> Date: Mon, 16 Dec 2019 06:01:59 -0800 From: IETF Secretariat Archived-At: Subject: [Cellar] Milestones changed for cellar WG 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: Mon, 16 Dec 2019 14:02:00 -0000 Changed milestone "Adopt matroska specifications as WG documents", set state to active from review, accepting new milestone, resolved as "Done". URL: https://datatracker.ietf.org/wg/cellar/about/ From nobody Mon Dec 16 06:35:50 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 5C43A12007C; Mon, 16 Dec 2019 06:35:48 -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.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <157650694829.21524.18212311323270569528@ietfa.amsl.com> Date: Mon, 16 Dec 2019 06:35:48 -0800 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-ebml-15.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: Mon, 16 Dec 2019 14:35:48 -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 : Extensible Binary Meta Language Authors : Steve Lhomme Dave Rice Moritz Bunkus Filename : draft-ietf-cellar-ebml-15.txt Pages : 58 Date : 2019-12-16 Abstract: This document defines the Extensible Binary Meta Language (EBML) format as a generalized file format for any type of data in a hierarchical form. EBML is designed as a binary equivalent to XML and uses a storage-efficient approach to build nested Elements with identifiers, lengths, and values. Similar to how an XML Schema defines the structure and semantics of an XML Document, this document defines how EBML Schemas are created to convey the semantics of an EBML Document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cellar-ebml-15 https://datatracker.ietf.org/doc/html/draft-ietf-cellar-ebml-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ebml-15 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 Mon Dec 16 21:28:44 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 8884A1200C7; Mon, 16 Dec 2019 21:28:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach via Datatracker To: "The IESG" Cc: draft-ietf-cellar-ebml@ietf.org, Steven Villereal , cellar-chairs@ietf.org, villereal@gmail.com, cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Roach Message-ID: <157656052355.24550.17056837047628625307.idtracker@ietfa.amsl.com> Date: Mon, 16 Dec 2019 21:28:43 -0800 Archived-At: Subject: [Cellar] Adam Roach's Discuss on draft-ietf-cellar-ebml-15: (with DISCUSS and COMMENT) 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: Tue, 17 Dec 2019 05:28:44 -0000 Adam Roach has entered the following ballot position for draft-ietf-cellar-ebml-15: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks to the authors and the participants of the CELLAR working group for the work that has gone into documenting the EBML format. I have a handful of comments that I believe need to be addressed prior to publication, and a handful of suggestions for improvement. --------------------------------------------------------------------------- Abstract: I see that the Introduction has been revised to address Ben Campbell's AD review comment regarding the document positioning itself as a general-purpose data format rather than being scoped to its use in Matroska. The Abstract still claims the much broader scope -- please update it to match the reduced scope in the Introduction. --------------------------------------------------------------------------- §7.3: > A Float Element stores a floating-point number as defined in > [IEEE.754.1985]. This is not sufficiently precise to interoperate, as IEEE-754 defines multiple floating-point representations at each bit length. To differentiate from, e.g., decimal representation and arithmetic format (neither of which are probably what you want), please specify the use of "binary interchange format" (unless some other format is intended). --------------------------------------------------------------------------- §14.1.3: > For String Elements and UTF-8 Elements the length of Element Data MAY > be reduced by adding Null Octets ... > Note that this method is NOT RECOMMENDED. These two normative statements conflict with each other: when using RFC 2119 language, MAY is a very different level than "NOT RECOMMENDED" (which is equivalent to "SHOULD NOT"). Please pick one, and eliminate the other. --------------------------------------------------------------------------- §17.1: > The VINT Data value of one-octet Element IDs MUST be between 0x01 and > 0x7E. These items are valuable because they are short, and need to > be used for commonly repeated elements. Values from 1 to 126 are to > be allocated according to the "RFC Required" policy [RFC8126]. This, combined with the values that are being registered, is extremely confusing, and I don't know how IANA is supposed to understand what's going on without reading and understanding the VINT bit encoding scheme (which is way too much to ask of them). This is because of the document-wide practice of speaking of IDs in their VINT-encoded values (e.g., 0xBF) instead of their data values (e.g., 63 or 0x3F), including in the initial registry in this section. Please either revise the prose to speak in terms of VINT-encoded values (e.g., "MUST be between 0x81 and 0xFE"), or revise the registration tables to indicate the VINT data values (e.g., "0x3F" for CRC-32). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- §5: > Table 3: Examples of valid and invalid VINTs This label is a bit confusing, as all the shown VINTs are valid; they're just not valid for use as Element IDs. --------------------------------------------------------------------------- §6.3: > +--------------+----------------------+ > | Octet Length | Possible Value Range | > +==============+======================+ > | 1 | 0 to 2^(7-2) | > +--------------+----------------------+ > | 2 | 0 to 2^(14-2) | > +--------------+----------------------+ > | 3 | 0 to 2^(21-2) | > +--------------+----------------------+ > | 4 | 0 to 2^(28-2) | > +--------------+----------------------+ > | 5 | 0 to 2^(35-2) | > +--------------+----------------------+ > | 6 | 0 to 2^(42-2) | > +--------------+----------------------+ > | 7 | 0 to 2^(49-2) | > +--------------+----------------------+ > | 8 | 0 to 2^(56-2) | > +--------------+----------------------+ I think the value ranges here are indicated incorrectly. If I understand the encoding scheme correctly, the range for one octet is 0 through 126, which is "0 to (2^7)-2" rather than "0 to 2^(7-2)" (which means 0 through 32). The other lengths have identical errors. --------------------------------------------------------------------------- §8: > An EBML Document is comprised of only two components, an EBML Header Please change to either of the following: An EBML Document is composed of only two components... An EBML Document comprises only two components... --------------------------------------------------------------------------- §11.1.5.2: > A path with a EBMLGlobalParent defines a > Section 11.3. This doesn't parse. I think you mean: A path with a EBMLGlobalParent defines a Global Element; see Section 11.3. --------------------------------------------------------------------------- § 11.1.5.12: > A boolean to express if an EBML Element is defined as an Identically > Recurring Element or not. As the term "Identically Recurring Element" has not been defined prior to this section, A forward reference to 11.1.16 would be very useful here. From nobody Tue Dec 17 07:27: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 F39A4120867; Tue, 17 Dec 2019 07:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 90Ws0aJFMElr; Tue, 17 Dec 2019 07:27:17 -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 2439E12012C; Tue, 17 Dec 2019 07:27:17 -0800 (PST) Received: from [146.96.19.240] (port=54137 helo=[10.10.201.20]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1ihEkh-002bT6-4b; Tue, 17 Dec 2019 10:27:16 -0500 From: Dave Rice Message-Id: <2D4A95A1-B570-47C7-B040-923EF3F24C9C@dericed.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_59ACD132-E5FA-4043-B57A-88E72D68B988" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Tue, 17 Dec 2019 10:27:09 -0500 In-Reply-To: <157656052355.24550.17056837047628625307.idtracker@ietfa.amsl.com> Cc: The IESG , draft-ietf-cellar-ebml@ietf.org, Steven Villereal , cellar-chairs@ietf.org, cellar@ietf.org To: Adam Roach References: <157656052355.24550.17056837047628625307.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.8) X-OutGoing-Spam-Status: No, score=-2.9 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] Adam Roach's Discuss on draft-ietf-cellar-ebml-15: (with DISCUSS and COMMENT) 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, 17 Dec 2019 15:27:19 -0000 --Apple-Mail=_59ACD132-E5FA-4043-B57A-88E72D68B988 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Adam, Comments are in-line below. tl;dr Most comments are responded to within = https://github.com/cellar-wg/ebml-specification/pull/313 = and there=E2=80= =99s a call for feedback of others in regards to your comment on =C2=A717.= 1. > On Dec 17, 2019, at 12:28 AM, Adam Roach via Datatracker = wrote: >=20 > Adam Roach has entered the following ballot position for > draft-ietf-cellar-ebml-15: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Thanks to the authors and the participants of the CELLAR working group = for > the work that has gone into documenting the EBML format. I have a = handful > of comments that I believe need to be addressed prior to publication, = and > a handful of suggestions for improvement. >=20 > = --------------------------------------------------------------------------= - >=20 > Abstract: >=20 > I see that the Introduction has been revised to address Ben Campbell's = AD > review comment regarding the document positioning itself as a = general-purpose > data format rather than being scoped to its use in Matroska. The = Abstract > still claims the much broader scope -- please update it to match the = reduced > scope in the Introduction. >=20 > = --------------------------------------------------------------------------= - >=20 > =C2=A77.3: >=20 >> A Float Element stores a floating-point number as defined in >> [IEEE.754.1985]. >=20 > This is not sufficiently precise to interoperate, as IEEE-754 defines = multiple > floating-point representations at each bit length. To differentiate = from, > e.g., decimal representation and arithmetic format (neither of which = are > probably what you want), please specify the use of "binary interchange > format" (unless some other format is intended). I started a pull request at with proposed changes referenced below. Here I changed the sentence to: > A Float Element stores a floating-point number in binary interchange = format as defined in [@!IEEE.754.1985]. > = --------------------------------------------------------------------------= - >=20 > =C2=A714.1.3: >=20 >> For String Elements and UTF-8 Elements the length of Element Data MAY >> be reduced by adding Null Octets > ... >> Note that this method is NOT RECOMMENDED. >=20 > These two normative statements conflict with each other: when using = RFC 2119 > language, MAY is a very different level than "NOT RECOMMENDED" (which = is > equivalent to "SHOULD NOT"). Please pick one, and eliminate the other. I believe that =E2=80=9CNOT RECOMMENDED=E2=80=9D is preferred here, so = changed the =E2=80=9CMAY=E2=80=9D to =E2=80=9Ccould=E2=80=9D. > = --------------------------------------------------------------------------= - >=20 > =C2=A717.1: >=20 >> The VINT Data value of one-octet Element IDs MUST be between 0x01 and >> 0x7E. These items are valuable because they are short, and need to >> be used for commonly repeated elements. Values from 1 to 126 are to >> be allocated according to the "RFC Required" policy [RFC8126]. >=20 > This, combined with the values that are being registered, is extremely > confusing, and I don't know how IANA is supposed to understand what's = going on > without reading and understanding the VINT bit encoding scheme (which = is way > too much to ask of them). This is because of the document-wide = practice > of speaking of IDs in their VINT-encoded values (e.g., 0xBF) instead = of their > data values (e.g., 63 or 0x3F), including in the initial registry in = this section. >=20 > Please either revise the prose to speak in terms of VINT-encoded = values > (e.g., "MUST be between 0x81 and 0xFE"), or revise the registration > tables to indicate the VINT data values (e.g., "0x3F" for CRC-32). I understand the request and the reason for it and am interested in = assessing rough consensus amongst the other authors before making this = change. These elements have been long-associated with these particular = vint expressions of the Element IDs, so I have some concerns that a = global change of Element ID reference from VINT to the Element Data of = that VINT would confuse readers. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > =C2=A75: >=20 >> Table 3: Examples of valid and invalid VINTs >=20 > This label is a bit confusing, as all the shown VINTs are valid; > they're just not valid for use as Element IDs. Good catch. Changed to: > Table 3: Examples of valid and invalid Element IDs > = --------------------------------------------------------------------------= - >=20 > =C2=A76.3: >=20 >> +--------------+----------------------+ >> | Octet Length | Possible Value Range | >> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >> | 1 | 0 to 2^(7-2) | >> +--------------+----------------------+ >> | 2 | 0 to 2^(14-2) | >> +--------------+----------------------+ >> | 3 | 0 to 2^(21-2) | >> +--------------+----------------------+ >> | 4 | 0 to 2^(28-2) | >> +--------------+----------------------+ >> | 5 | 0 to 2^(35-2) | >> +--------------+----------------------+ >> | 6 | 0 to 2^(42-2) | >> +--------------+----------------------+ >> | 7 | 0 to 2^(49-2) | >> +--------------+----------------------+ >> | 8 | 0 to 2^(56-2) | >> +--------------+----------------------+ >=20 > I think the value ranges here are indicated incorrectly. If I = understand the > encoding scheme correctly, the range for one octet is 0 through 126, > which is "0 to (2^7)-2" rather than "0 to 2^(7-2)" (which means 0 = through 32). >=20 > The other lengths have identical errors. In our markdown these are listed in `2^7-2` format and the translation = to RFC adds in the parenthesis. Surrounding the minus sign with spaces = appears to fix the issue and the resulting RFC text shows: 0 to 2^7 - 2 > = --------------------------------------------------------------------------= - >=20 >=20 > =C2=A78: >=20 >> An EBML Document is comprised of only two components, an EBML Header >=20 > Please change to either of the following: >=20 > An EBML Document is composed of only two components... >=20 > An EBML Document comprises only two components=E2=80=A6 I chose the first suggestion. > = --------------------------------------------------------------------------= - >=20 > =C2=A711.1.5.2: >=20 >> A path with a EBMLGlobalParent defines a >> Section 11.3. >=20 > This doesn't parse. I think you mean: >=20 > A path with a EBMLGlobalParent defines a Global Element; see Section = 11.3. Yes exactly. In the prior version of xml2rfc, the section = cross-reference could be labelled, but we switched to rewriting these = cross-references to be simply the section name, but missed that fix for = this one. Thanks for catching it. > = --------------------------------------------------------------------------= - >=20 > =C2=A7 11.1.5.12: >=20 >> A boolean to express if an EBML Element is defined as an Identically >> Recurring Element or not. >=20 > As the term "Identically Recurring Element" has not been defined prior = to this > section, A forward reference to 11.1.16 would be very useful here. Added. Thanks so much, Dave Rice --Apple-Mail=_59ACD132-E5FA-4043-B57A-88E72D68B988 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Adam,
Comments are in-line below.
tl;dr = Most comments are responded to within https://github.com/cellar-wg/ebml-specification/pull/313&nb= sp;and there=E2=80=99s a call for feedback of others in regards to your = comment on =C2=A717.1.

On Dec 17, 2019, at 12:28 AM, Adam Roach via = Datatracker <noreply@ietf.org> wrote:

Adam = Roach has entered the following ballot position for
draft-ietf-cellar-ebml-15: Discuss

When responding, please keep the subject line intact and = reply to all
email addresses included in the To and CC = lines. (Feel free to cut this
introductory paragraph, = however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/


---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

Thanks to the authors and the = participants of the CELLAR working group for
the work that = has gone into documenting the EBML format. I have a handful
of comments that I believe need to be addressed prior to = publication, and
a handful of suggestions for = improvement.

---------------------------------------------------------------= ------------

Abstract:

I see that the Introduction has been revised to address Ben = Campbell's AD
review comment regarding the document = positioning itself as a general-purpose
data format rather = than being scoped to its use in Matroska. The Abstract
still= claims the much broader scope -- please update it to match the = reduced
scope in the Introduction.

---------------------------------------------------------------= ------------

=C2=A77.3:

A Float Element stores = a floating-point number as defined in
[IEEE.754.1985].

This is not sufficiently precise = to interoperate, as IEEE-754 defines multiple
floating-point= representations at each bit length. To differentiate from,
e.g., decimal representation and arithmetic format (neither = of which are
probably what you want), please specify the = use of "binary interchange
format" (unless some other = format is intended).

I started a pull request at with proposed changes = referenced below.
Here I changed the sentence = to:

> A Float Element stores a = floating-point number in binary interchange format as defined = in [@!IEEE.754.1985].

---------------------------------------------------------------= ------------

=C2=A714.1.3:

For String Elements and = UTF-8 Elements the length of Element Data MAY
be reduced = by adding Null Octets
...
Note that this method = is NOT RECOMMENDED.

These two = normative statements conflict with each other: when using RFC 2119
language, MAY is a very different level than "NOT = RECOMMENDED" (which is
equivalent to "SHOULD NOT"). Please = pick one, and eliminate the other.

I = believe that =E2=80=9CNOT RECOMMENDED=E2=80=9D is preferred here, so = changed the =E2=80=9CMAY=E2=80=9D to =E2=80=9Ccould=E2=80=9D.

---------------------------------------------------------------= ------------

=C2=A717.1:

The VINT Data value of = one-octet Element IDs MUST be between 0x01 and
0x7E. =  These items are valuable because they are short, and need to
be used for commonly repeated elements.  Values from 1 = to 126 are to
be allocated according to the "RFC = Required" policy [RFC8126].

This, combined with the values that are being registered, is = extremely
confusing, and I don't know how IANA is supposed = to understand what's going on
without reading and = understanding the VINT bit encoding scheme (which is way
too= much to ask of them). This is because of the document-wide practice
of speaking of IDs in their VINT-encoded values (e.g., 0xBF) = instead of their
data values (e.g., 63 or 0x3F), including = in the initial registry in this section.

Please either revise the prose to speak in terms of = VINT-encoded values
(e.g., "MUST be between 0x81 and = 0xFE"), or revise the registration
tables to indicate the = VINT data values (e.g., "0x3F" for CRC-32).

I = understand the request and the reason for it and am interested in = assessing rough consensus amongst the other authors before making this = change. These elements have been long-associated with these particular = vint expressions of the Element IDs, so I have some concerns that a = global change of Element ID reference from VINT to the Element Data of = that VINT would confuse readers.

---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

=C2=A75:

=             Ta= ble 3: Examples of valid and invalid VINTs

This label is a bit confusing, as all the shown VINTs are = valid;
they're just not valid for use as Element IDs.

Good = catch. Changed to:
> Table 3: Examples of valid and invalid = Element IDs

---------------------------------------------------------------= ------------

=C2=A76.3:

=             &n= bsp;  +--------------+----------------------+
=             &n= bsp;  | Octet Length | Possible Value Range |
=             &n= bsp;  +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
=             &n= bsp;  | 1 =            | 0 to = 2^(7-2)         |
=             &n= bsp;  +--------------+----------------------+
=             &n= bsp;  | 2 =            | 0 to = 2^(14-2)        |
=             &n= bsp;  +--------------+----------------------+
=             &n= bsp;  | 3 =            | 0 to = 2^(21-2)        |
=             &n= bsp;  +--------------+----------------------+
=             &n= bsp;  | 4 =            | 0 to = 2^(28-2)        |
=             &n= bsp;  +--------------+----------------------+
=             &n= bsp;  | 5 =            | 0 to = 2^(35-2)        |
=             &n= bsp;  +--------------+----------------------+
=             &n= bsp;  | 6 =            | 0 to = 2^(42-2)        |
=             &n= bsp;  +--------------+----------------------+
=             &n= bsp;  | 7 =            | 0 to = 2^(49-2)        |
=             &n= bsp;  +--------------+----------------------+
=             &n= bsp;  | 8 =            | 0 to = 2^(56-2)        |
=             &n= bsp;  +--------------+----------------------+

I think the value ranges here are = indicated incorrectly. If I understand the
encoding scheme = correctly, the range for one octet is 0 through 126,
which = is "0 to (2^7)-2" rather than "0 to 2^(7-2)" (which means 0 through = 32).

The other lengths have identical = errors.

In our markdown these are listed in `2^7-2` format = and the translation to RFC adds in the parenthesis. Surrounding the = minus sign with spaces appears to fix the issue and the resulting RFC = text shows:

 0 to 2^7 - = 2

---------------------------------------------------------------= ------------


=C2=A78:

An EBML = Document is comprised of only two components, an EBML Header

Please change to either of the = following:

  An EBML Document is = composed of only two components...

=   An EBML Document comprises only two = components=E2=80=A6

I chose the first suggestion.

---------------------------------------------------------------= ------------

=C2=A711.1.5.2:

A path = with a EBMLGlobalParent defines a
Section 11.3.

This doesn't parse. I think you = mean:

 A path with a EBMLGlobalParent = defines a Global Element; see Section 11.3.

Yes = exactly. In the prior version of xml2rfc, the section cross-reference = could be labelled, but we switched to rewriting these cross-references = to be simply the section name, but missed that fix for this one. Thanks = for catching it.

---------------------------------------------------------------= ------------

=C2=A7 11.1.5.12:

A = boolean to express if an EBML Element is defined as an Identically
Recurring Element or not.

As the term "Identically Recurring Element" has not been = defined prior to this
section, A forward reference to = 11.1.16 would be very useful here.

Added.

Thanks so much,
Dave Rice

= --Apple-Mail=_59ACD132-E5FA-4043-B57A-88E72D68B988-- From nobody Tue Dec 17 09:51:07 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 0B4D012085F for ; Tue, 17 Dec 2019 09:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 hb_qccyvzQJa for ; Tue, 17 Dec 2019 09:51:04 -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 111BA12085E for ; Tue, 17 Dec 2019 09:51:04 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0C4EF3897F; Tue, 17 Dec 2019 12:51:00 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id EC47151E; Tue, 17 Dec 2019 12:51:02 -0500 (EST) From: Michael Richardson To: Steve Lhomme cc: Codec Encoding for LossLess Archiving and Realtime transmission In-Reply-To: References: <14450.1575234869@localhost> <27291.1576005039@localhost> <8420.1576012649@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 Date: Tue, 17 Dec 2019 12:51:02 -0500 Message-ID: <26585.1576605062@localhost> Archived-At: Subject: Re: [Cellar] DRAFT 2019-12-10 minutes and upcoming CELLAR virtual interim meetings 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, 17 Dec 2019 17:51:06 -0000 Steve Lhomme wrote: > The 2020-08-28 is a Friday, is this correct? no. It should be 2020-08-25. -- ] 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 [ From nobody Tue Dec 17 09:55: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 94A89120C3E for ; Tue, 17 Dec 2019 09:55:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 4wr0jEG79Vmm for ; Tue, 17 Dec 2019 09:55: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 2C9FD120D38 for ; Tue, 17 Dec 2019 09:55:39 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7867E3897F; Tue, 17 Dec 2019 12:55:35 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6353A51E; Tue, 17 Dec 2019 12:55:38 -0500 (EST) From: Michael Richardson To: Steve Lhomme cc: Codec Encoding for LossLess Archiving and Realtime transmission In-Reply-To: References: <14450.1575234869@localhost> <27291.1576005039@localhost> <8420.1576012649@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 Date: Tue, 17 Dec 2019 12:55:38 -0500 Message-ID: <27483.1576605338@localhost> Archived-At: Subject: Re: [Cellar] DRAFT 2019-12-10 minutes and upcoming CELLAR virtual interim meetings 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, 17 Dec 2019 17:55:44 -0000 I appear to have gotten the date correct in the meeting page at: https://datatracker.ietf.org/wg/cellar/meetings/ You can get a calendar feed from: https://datatracker.ietf.org/meeting/upcoming.ics?filters=cellar -- ] 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 [ From nobody Tue Dec 17 11:01:13 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 43D28120894 for ; Tue, 17 Dec 2019 11:01:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157660927127.26466.5705663278177378510.idtracker@ietfa.amsl.com> Date: Tue, 17 Dec 2019 11:01:11 -0800 From: IETF Secretariat Archived-At: Subject: [Cellar] Milestones changed for cellar WG 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: Tue, 17 Dec 2019 19:01:11 -0000 Changed milestone "Submit specification for EBML to IESG (Standards Track)", set due date to June 2019 from August 2018, resolved as "Done", added draft-ietf-cellar-ebml to milestone. Changed milestone "Submit informational specification for FFV1 video codec versions 0, 1 and 3 to IESG for publication", set due date to September 2019 from October 2018, resolved as "Done", added draft-ietf-cellar-ffv1 to milestone. Changed milestone "Submit informational specification for Matroska container format versions 1, 2 and 3 to IESG for publication", set due date to June 2020 from April 2019. Changed milestone "Submit specification for FFV1 video codec version 4 to IESG (Standards Track)", set due date to September 2020 from December 2018, added draft-ietf-cellar-ffv1-v4 to milestone. Changed milestone "Submit specification for FLAC audio codec to IESG (Standards Track)", set due date to April 2021 from April 2019, added draft-ietf-cellar-flac to milestone. URL: https://datatracker.ietf.org/wg/cellar/about/ From nobody Tue Dec 17 11:11:19 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 745BF1208A4; Tue, 17 Dec 2019 11:11:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-cellar-ebml@ietf.org, Steven Villereal , cellar-chairs@ietf.org, villereal@gmail.com, cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <157660987147.26437.3406623415377049016.idtracker@ietfa.amsl.com> Date: Tue, 17 Dec 2019 11:11:11 -0800 Archived-At: Subject: [Cellar] Alissa Cooper's No Objection on draft-ietf-cellar-ebml-15: (with COMMENT) 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: Tue, 17 Dec 2019 19:11:11 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-cellar-ebml-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Adam's DISCUSS point about the abstract. I'm not clear on why the IANA registry names are prefixed with "CELLAR." Are there more general EBML Element ID and DocType registries envisioned? If not, I would suggest dropping the "CELLAR." For future documents I would expect the authors to respond to the Gen-ART reviewer's comments via email after fixes have been applied to address the issues raised in the review. From nobody Tue Dec 17 11:57: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 0E055120883; Tue, 17 Dec 2019 11:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.28 X-Spam-Level: X-Spam-Status: No, score=-1.28 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.4, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" 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 2EYbPm44C-ZC; Tue, 17 Dec 2019 11:57:00 -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 C0803120077; Tue, 17 Dec 2019 11:57:00 -0800 (PST) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id xBHJu8tX017992 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 17 Dec 2019 13:56:10 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1576612571; bh=97LFby15o1UMhRWqM02RiT73X4AnBEEVg6JBIZLzdFE=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=N4USaSiqqwh+IE8lZ8igHtShPTE1daGGcZKy3nTmZXtVVwqlskomjiWr7HVeVcCzG uEy4IQ7XQa02Q9CmsSsKreFO7IQ39uT+Y6ljUg1vhfQny0LdrkgfdFyk0zI2uPWT3K 09NVvCqX9AaaPS0l268S/mJRVci8VBXdrEw7YA1w= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Dave Rice Cc: Steven Villereal , draft-ietf-cellar-ebml@ietf.org, The IESG , cellar-chairs@ietf.org, cellar@ietf.org References: <157656052355.24550.17056837047628625307.idtracker@ietfa.amsl.com> <2D4A95A1-B570-47C7-B040-923EF3F24C9C@dericed.com> From: Adam Roach Message-ID: <69d0eb8f-f790-293c-0cd9-deadc915254f@nostrum.com> Date: Tue, 17 Dec 2019 13:56:02 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <2D4A95A1-B570-47C7-B040-923EF3F24C9C@dericed.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Cellar] Adam Roach's Discuss on draft-ietf-cellar-ebml-15: (with DISCUSS and COMMENT) 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, 17 Dec 2019 19:57:03 -0000 Dave -- Thanks for the quick response! The issues that the PR addresses look good to me. Two comments inline below. On 12/17/19 9:27 AM, Dave Rice wrote: > >> >> Abstract: >> >> I see that the Introduction has been revised to address Ben Campbell's AD >> review comment regarding the document positioning itself as a >> general-purpose >> data format rather than being scoped to its use in Matroska. The Abstract >> still claims the much broader scope -- please update it to match the >> reduced >> scope in the Introduction. >> I didn't see a response to this discuss point. See also the GENART review, which raises this issue in some detail. >> >> §17.1: >> >>> The VINT Data value of one-octet Element IDs MUST be between 0x01 and >>> 0x7E.  These items are valuable because they are short, and need to >>> be used for commonly repeated elements.  Values from 1 to 126 are to >>> be allocated according to the "RFC Required" policy [RFC8126]. >> >> This, combined with the values that are being registered, is extremely >> confusing, and I don't know how IANA is supposed to understand what's >> going on >> without reading and understanding the VINT bit encoding scheme (which >> is way >> too much to ask of them). This is because of the document-wide practice >> of speaking of IDs in their VINT-encoded values (e.g., 0xBF) instead >> of their >> data values (e.g., 63 or 0x3F), including in the initial registry in >> this section. >> >> Please either revise the prose to speak in terms of VINT-encoded values >> (e.g., "MUST be between 0x81 and 0xFE"), or revise the registration >> tables to indicate the VINT data values (e.g., "0x3F" for CRC-32). > > I understand the request and the reason for it and am interested in > assessing rough consensus amongst the other authors before making this > change. These elements have been long-associated with these particular > vint expressions of the Element IDs, so I have some concerns that a > global change of Element ID reference from VINT to the Element Data of > that VINT would confuse readers. Given that information, I imagine that the better path would be revising the IANA instructions to operate on VINTs ("MUST be between 0x81 and 0xFE") instead of VINT element data. This should be very straightforward, as the encoding of VINTs results in contiguous ranges that should be easy for IANA to deal with. /a From nobody Tue Dec 17 13:16: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 4C54512086A; Tue, 17 Dec 2019 13:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 9egb3z5lee_D; Tue, 17 Dec 2019 13:16:07 -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 A52C3120077; Tue, 17 Dec 2019 13:16:07 -0800 (PST) Received: from [146.96.19.240] (port=20097 helo=[10.10.201.20]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1ihKCI-002lA8-7P; Tue, 17 Dec 2019 16:16:07 -0500 From: Dave Rice Message-Id: <4A5AD779-2C48-460B-A34C-672D98F39C98@dericed.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_062788C0-12C7-4AD1-935C-D83DD6B043BE" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Tue, 17 Dec 2019 16:16:00 -0500 In-Reply-To: <69d0eb8f-f790-293c-0cd9-deadc915254f@nostrum.com> Cc: Steven Villereal , draft-ietf-cellar-ebml@ietf.org, The IESG , cellar-chairs@ietf.org, cellar@ietf.org To: Adam Roach References: <157656052355.24550.17056837047628625307.idtracker@ietfa.amsl.com> <2D4A95A1-B570-47C7-B040-923EF3F24C9C@dericed.com> <69d0eb8f-f790-293c-0cd9-deadc915254f@nostrum.com> X-Mailer: Apple Mail (2.3445.104.8) X-OutGoing-Spam-Status: No, score=-2.9 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] Adam Roach's Discuss on draft-ietf-cellar-ebml-15: (with DISCUSS and COMMENT) 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, 17 Dec 2019 21:16:09 -0000 --Apple-Mail=_062788C0-12C7-4AD1-935C-D83DD6B043BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 17, 2019, at 2:56 PM, Adam Roach wrote: >=20 > Dave -- >=20 > Thanks for the quick response! The issues that the PR addresses look = good to me. Two comments inline below. >=20 > On 12/17/19 9:27 AM, Dave Rice wrote: >>=20 >>>=20 >>> Abstract: >>>=20 >>> I see that the Introduction has been revised to address Ben = Campbell's AD >>> review comment regarding the document positioning itself as a = general-purpose >>> data format rather than being scoped to its use in Matroska. The = Abstract >>> still claims the much broader scope -- please update it to match the = reduced >>> scope in the Introduction. >>>=20 >=20 > I didn't see a response to this discuss point. See also the GENART = review, which raises this issue in some detail. IIUC, this issue is discussed in = https://github.com/cellar-wg/ebml-specification/pull/311/files = . >>> =C2=A717.1: >>>=20 >>>> The VINT Data value of one-octet Element IDs MUST be between 0x01 = and >>>> 0x7E. These items are valuable because they are short, and need to >>>> be used for commonly repeated elements. Values from 1 to 126 are = to >>>> be allocated according to the "RFC Required" policy [RFC8126]. >>>=20 >>> This, combined with the values that are being registered, is = extremely >>> confusing, and I don't know how IANA is supposed to understand = what's going on >>> without reading and understanding the VINT bit encoding scheme = (which is way >>> too much to ask of them). This is because of the document-wide = practice >>> of speaking of IDs in their VINT-encoded values (e.g., 0xBF) instead = of their >>> data values (e.g., 63 or 0x3F), including in the initial registry in = this section. >>>=20 >>> Please either revise the prose to speak in terms of VINT-encoded = values >>> (e.g., "MUST be between 0x81 and 0xFE"), or revise the registration >>> tables to indicate the VINT data values (e.g., "0x3F" for CRC-32). >>=20 >> I understand the request and the reason for it and am interested in = assessing rough consensus amongst the other authors before making this = change. These elements have been long-associated with these particular = vint expressions of the Element IDs, so I have some concerns that a = global change of Element ID reference from VINT to the Element Data of = that VINT would confuse readers. >=20 > Given that information, I imagine that the better path would be = revising the IANA instructions to operate on VINTs ("MUST be between = 0x81 and 0xFE") instead of VINT element data. This should be very = straightforward, as the encoding of VINTs results in contiguous ranges = that should be easy for IANA to deal with. Thanks. I=E2=80=99ve updated the section to use the VINT value rather = than the decimal of the Element Data of that VINT. The commit is at = https://github.com/cellar-wg/ebml-specification/pull/313/commits/948291dfd= defa02f857c83a7155519b980d9b2f6 = . Dave Rice= --Apple-Mail=_062788C0-12C7-4AD1-935C-D83DD6B043BE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Dec 17, 2019, at 2:56 PM, Adam Roach <adam@nostrum.com> = wrote:

Dave --

Thanks for the quick = response! The issues that the PR addresses look good to me. Two comments = inline below.

On 12/17/19 9:27 AM, Dave = Rice wrote:


Abstract:

I see that the = Introduction has been revised to address Ben Campbell's AD
review comment regarding the document positioning itself as a = general-purpose
data format rather than being scoped to = its use in Matroska. The Abstract
still claims the much = broader scope -- please update it to match the reduced
scope= in the Introduction.


I didn't see a = response to this discuss point. See also the GENART review, which raises = this issue in some detail.

=C2=A717.1:

The VINT = Data value of one-octet Element IDs MUST be between 0x01 and
0x7E.  These items are valuable because they are short, = and need to
be used for commonly repeated elements. =  Values from 1 to 126 are to
be allocated according = to the "RFC Required" policy [RFC8126].

This, combined with the values that are being registered, is = extremely
confusing, and I don't know how IANA is supposed = to understand what's going on
without reading and = understanding the VINT bit encoding scheme (which is way
too= much to ask of them). This is because of the document-wide practice
of speaking of IDs in their VINT-encoded values (e.g., 0xBF) = instead of their
data values (e.g., 63 or 0x3F), including = in the initial registry in this section.

Please either revise the prose to speak in terms of = VINT-encoded values
(e.g., "MUST be between 0x81 and = 0xFE"), or revise the registration
tables to indicate the = VINT data values (e.g., "0x3F" for CRC-32).
I understand the request and the reason for it and am = interested in assessing rough consensus amongst the other authors before = making this change. These elements have been long-associated with these = particular vint expressions of the Element IDs, so I have some concerns = that a global change of Element ID reference from VINT to the Element = Data of that VINT would confuse readers.

Given that information, I imagine that the better path would = be revising the IANA instructions to operate on VINTs ("MUST be between = 0x81 and 0xFE") instead of VINT element data. This should be very = straightforward, as the encoding of VINTs results in contiguous ranges = that should be easy for IANA to deal with.

Thanks. I=E2=80=99ve updated the section to use the VINT = value rather than the decimal of the Element Data of that VINT. The = commit is at https://github.com/cellar-wg/ebml-specification/pull/313/commit= s/948291dfddefa02f857c83a7155519b980d9b2f6.

Dave Rice
= --Apple-Mail=_062788C0-12C7-4AD1-935C-D83DD6B043BE-- From nobody Tue Dec 17 13:38: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 D89EA120091; Tue, 17 Dec 2019 13:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.4, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" 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 5MzYa4wo02AP; Tue, 17 Dec 2019 13:38:49 -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 5BB06120077; Tue, 17 Dec 2019 13:38:49 -0800 (PST) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id xBHLbs3G036869 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 17 Dec 2019 15:37:56 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1576618678; bh=Xt/xP2qKi3rEyFPWcEAwPo95JQvqMvzj78xYD8F27fo=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=R4cg00seJ/aLzU8r2+6rC2RzWtRdil9J2ToK+w2fPvUqejWgqN4flU4A1iwxcjTmx 1azBbMSi596hR2Ji07OtE6xRl7Lt5aWA2bByv9CY8lKc8leIv2nHc3K0/mSrceJ6Ln dBomUTR4bHFMf+N/R7lugAJ8prG3GJQvovlH3rJc= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Dave Rice Cc: Steven Villereal , draft-ietf-cellar-ebml@ietf.org, The IESG , cellar-chairs@ietf.org, cellar@ietf.org References: <157656052355.24550.17056837047628625307.idtracker@ietfa.amsl.com> <2D4A95A1-B570-47C7-B040-923EF3F24C9C@dericed.com> <69d0eb8f-f790-293c-0cd9-deadc915254f@nostrum.com> <4A5AD779-2C48-460B-A34C-672D98F39C98@dericed.com> From: Adam Roach Message-ID: <09ddd4eb-ee6e-7eb3-dd56-f58946116103@nostrum.com> Date: Tue, 17 Dec 2019 15:37:49 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <4A5AD779-2C48-460B-A34C-672D98F39C98@dericed.com> Content-Type: multipart/alternative; boundary="------------71A84C638BD2B26E686E2C9C" Content-Language: en-US Archived-At: Subject: Re: [Cellar] Adam Roach's Discuss on draft-ietf-cellar-ebml-15: (with DISCUSS and COMMENT) 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, 17 Dec 2019 21:38:51 -0000 This is a multi-part message in MIME format. --------------71A84C638BD2B26E686E2C9C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks for your responses. Modulo the comment I left in github [1], these two PRs (combined with the other PR you cited in an earlier message) address the concerns I had. I'll clear my DISCUSS when a new version with these PRs incorporated is put in the i-d repository. Thanks! /a ____ [1] https://github.com/cellar-wg/ebml-specification/pull/313/commits/948291dfddefa02f857c83a7155519b980d9b2f6#r359039422 On 12/17/19 3:16 PM, Dave Rice wrote: > > >> On Dec 17, 2019, at 2:56 PM, Adam Roach > > wrote: >> >> Dave -- >> >> Thanks for the quick response! The issues that the PR addresses look >> good to me. Two comments inline below. >> >> On 12/17/19 9:27 AM, Dave Rice wrote: >>> >>>> >>>> Abstract: >>>> >>>> I see that the Introduction has been revised to address Ben >>>> Campbell's AD >>>> review comment regarding the document positioning itself as a >>>> general-purpose >>>> data format rather than being scoped to its use in Matroska. The >>>> Abstract >>>> still claims the much broader scope -- please update it to match >>>> the reduced >>>> scope in the Introduction. >>>> >> >> I didn't see a response to this discuss point. See also the GENART >> review, which raises this issue in some detail. > > IIUC, this issue is discussed in > https://github.com/cellar-wg/ebml-specification/pull/311/files. > >>>> §17.1: >>>> >>>>> The VINT Data value of one-octet Element IDs MUST be between 0x01 and >>>>> 0x7E.  These items are valuable because they are short, and need to >>>>> be used for commonly repeated elements.  Values from 1 to 126 are to >>>>> be allocated according to the "RFC Required" policy [RFC8126]. >>>> >>>> This, combined with the values that are being registered, is extremely >>>> confusing, and I don't know how IANA is supposed to understand >>>> what's going on >>>> without reading and understanding the VINT bit encoding scheme >>>> (which is way >>>> too much to ask of them). This is because of the document-wide practice >>>> of speaking of IDs in their VINT-encoded values (e.g., 0xBF) >>>> instead of their >>>> data values (e.g., 63 or 0x3F), including in the initial registry >>>> in this section. >>>> >>>> Please either revise the prose to speak in terms of VINT-encoded values >>>> (e.g., "MUST be between 0x81 and 0xFE"), or revise the registration >>>> tables to indicate the VINT data values (e.g., "0x3F" for CRC-32). >>> >>> I understand the request and the reason for it and am interested in >>> assessing rough consensus amongst the other authors before making >>> this change. These elements have been long-associated with these >>> particular vint expressions of the Element IDs, so I have some >>> concerns that a global change of Element ID reference from VINT to >>> the Element Data of that VINT would confuse readers. >> >> Given that information, I imagine that the better path would be >> revising the IANA instructions to operate on VINTs ("MUST be between >> 0x81 and 0xFE") instead of VINT element data. This should be very >> straightforward, as the encoding of VINTs results in contiguous >> ranges that should be easy for IANA to deal with. > > Thanks. I’ve updated the section to use the VINT value rather than the > decimal of the Element Data of that VINT. The commit is at > https://github.com/cellar-wg/ebml-specification/pull/313/commits/948291dfddefa02f857c83a7155519b980d9b2f6. > > Dave Rice --------------71A84C638BD2B26E686E2C9C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Thanks for your responses. Modulo the comment I left in github [1], these two PRs (combined with the other PR you cited in an earlier message) address the concerns I had. I'll clear my DISCUSS when a new version with these PRs incorporated is put in the i-d repository.

Thanks!

/a


____
[1] https://github.com/cellar-wg/ebml-specification/pull/313/commits/948291dfddefa02f857c83a7155519b980d9b2f6#r359039422

On 12/17/19 3:16 PM, Dave Rice wrote:


On Dec 17, 2019, at 2:56 PM, Adam Roach <adam@nostrum.com> wrote:

Dave --

Thanks for the quick response! The issues that the PR addresses look good to me. Two comments inline below.

On 12/17/19 9:27 AM, Dave Rice wrote:


Abstract:

I see that the Introduction has been revised to address Ben Campbell's AD
review comment regarding the document positioning itself as a general-purpose
data format rather than being scoped to its use in Matroska. The Abstract
still claims the much broader scope -- please update it to match the reduced
scope in the Introduction.


I didn't see a response to this discuss point. See also the GENART review, which raises this issue in some detail.


§17.1:

The VINT Data value of one-octet Element IDs MUST be between 0x01 and
0x7E.  These items are valuable because they are short, and need to
be used for commonly repeated elements.  Values from 1 to 126 are to
be allocated according to the "RFC Required" policy [RFC8126].

This, combined with the values that are being registered, is extremely
confusing, and I don't know how IANA is supposed to understand what's going on
without reading and understanding the VINT bit encoding scheme (which is way
too much to ask of them). This is because of the document-wide practice
of speaking of IDs in their VINT-encoded values (e.g., 0xBF) instead of their
data values (e.g., 63 or 0x3F), including in the initial registry in this section.

Please either revise the prose to speak in terms of VINT-encoded values
(e.g., "MUST be between 0x81 and 0xFE"), or revise the registration
tables to indicate the VINT data values (e.g., "0x3F" for CRC-32).

I understand the request and the reason for it and am interested in assessing rough consensus amongst the other authors before making this change. These elements have been long-associated with these particular vint expressions of the Element IDs, so I have some concerns that a global change of Element ID reference from VINT to the Element Data of that VINT would confuse readers.

Given that information, I imagine that the better path would be revising the IANA instructions to operate on VINTs ("MUST be between 0x81 and 0xFE") instead of VINT element data. This should be very straightforward, as the encoding of VINTs results in contiguous ranges that should be easy for IANA to deal with.

Thanks. I’ve updated the section to use the VINT value rather than the decimal of the Element Data of that VINT. The commit is at https://github.com/cellar-wg/ebml-specification/pull/313/commits/948291dfddefa02f857c83a7155519b980d9b2f6.

Dave Rice


--------------71A84C638BD2B26E686E2C9C-- From nobody Tue Dec 17 18:17: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 7A269120096; Tue, 17 Dec 2019 18:17:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 hTP3pa9F2bzy; Tue, 17 Dec 2019 18:17:45 -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 26913120091; Tue, 17 Dec 2019 18:17:45 -0800 (PST) Received: from cpe-104-162-94-162.nyc.res.rr.com ([104.162.94.162]:36639 helo=[10.0.1.6]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1ihOuB-001svq-6y; Tue, 17 Dec 2019 21:17:44 -0500 From: Dave Rice Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_AD256537-FE02-4A16-81BB-152C9D4158F3" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Tue, 17 Dec 2019 21:17:31 -0500 In-Reply-To: <09ddd4eb-ee6e-7eb3-dd56-f58946116103@nostrum.com> Cc: draft-ietf-cellar-ebml@ietf.org, Steven Villereal , The IESG , cellar-chairs@ietf.org, Codec Encoding for LossLess Archiving and Realtime transmission To: Adam Roach References: <157656052355.24550.17056837047628625307.idtracker@ietfa.amsl.com> <2D4A95A1-B570-47C7-B040-923EF3F24C9C@dericed.com> <69d0eb8f-f790-293c-0cd9-deadc915254f@nostrum.com> <4A5AD779-2C48-460B-A34C-672D98F39C98@dericed.com> <09ddd4eb-ee6e-7eb3-dd56-f58946116103@nostrum.com> X-Mailer: Apple Mail (2.3601.0.10) X-OutGoing-Spam-Status: No, score=-2.6 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] Adam Roach's Discuss on draft-ietf-cellar-ebml-15: (with DISCUSS and COMMENT) 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, 18 Dec 2019 02:17:46 -0000 --Apple-Mail=_AD256537-FE02-4A16-81BB-152C9D4158F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Adam, > On Dec 17, 2019, at 4:37 PM, Adam Roach wrote: >=20 > Thanks for your responses. Modulo the comment I left in github [1], = these two PRs (combined with the other PR you cited in an earlier = message) address the concerns I had. I'll clear my DISCUSS when a new = version with these PRs incorporated is put in the i-d repository. Thanks, this comment addresses your github comment and references the = other reserved one-octet Element ID value: = https://github.com/cellar-wg/ebml-specification/pull/313/commits/689cbdb68= 82bc409628774cfa2854ee981d3ce87 = . Also, to be clear what hex ranges are not valid for use as Element IDs, = I restated these ranges specifically within this section at = https://github.com/cellar-wg/ebml-specification/pull/313/commits/06d1960f9= 208e58f56972870b72f2c95fe1d8fe3 = . Dave > Thanks! >=20 > /a >=20 >=20 > ____ > [1] = https://github.com/cellar-wg/ebml-specification/pull/313/commits/948291dfd= defa02f857c83a7155519b980d9b2f6#r359039422 = >=20 > On 12/17/19 3:16 PM, Dave Rice wrote: >>=20 >>=20 >>> On Dec 17, 2019, at 2:56 PM, Adam Roach > wrote: >>>=20 >>> Dave -- >>>=20 >>> Thanks for the quick response! The issues that the PR addresses look = good to me. Two comments inline below. >>>=20 >>> On 12/17/19 9:27 AM, Dave Rice wrote: >>>>=20 >>>>>=20 >>>>> Abstract: >>>>>=20 >>>>> I see that the Introduction has been revised to address Ben = Campbell's AD >>>>> review comment regarding the document positioning itself as a = general-purpose >>>>> data format rather than being scoped to its use in Matroska. The = Abstract >>>>> still claims the much broader scope -- please update it to match = the reduced >>>>> scope in the Introduction. >>>>>=20 >>>=20 >>> I didn't see a response to this discuss point. See also the GENART = review, which raises this issue in some detail. >>=20 >> IIUC, this issue is discussed in = https://github.com/cellar-wg/ebml-specification/pull/311/files = . >>=20 >>>>> =C2=A717.1: >>>>>=20 >>>>>> The VINT Data value of one-octet Element IDs MUST be between 0x01 = and >>>>>> 0x7E. These items are valuable because they are short, and need = to >>>>>> be used for commonly repeated elements. Values from 1 to 126 are = to >>>>>> be allocated according to the "RFC Required" policy [RFC8126]. >>>>>=20 >>>>> This, combined with the values that are being registered, is = extremely >>>>> confusing, and I don't know how IANA is supposed to understand = what's going on >>>>> without reading and understanding the VINT bit encoding scheme = (which is way >>>>> too much to ask of them). This is because of the document-wide = practice >>>>> of speaking of IDs in their VINT-encoded values (e.g., 0xBF) = instead of their >>>>> data values (e.g., 63 or 0x3F), including in the initial registry = in this section. >>>>>=20 >>>>> Please either revise the prose to speak in terms of VINT-encoded = values >>>>> (e.g., "MUST be between 0x81 and 0xFE"), or revise the = registration >>>>> tables to indicate the VINT data values (e.g., "0x3F" for CRC-32). >>>>=20 >>>> I understand the request and the reason for it and am interested in = assessing rough consensus amongst the other authors before making this = change. These elements have been long-associated with these particular = vint expressions of the Element IDs, so I have some concerns that a = global change of Element ID reference from VINT to the Element Data of = that VINT would confuse readers. >>>=20 >>> Given that information, I imagine that the better path would be = revising the IANA instructions to operate on VINTs ("MUST be between = 0x81 and 0xFE") instead of VINT element data. This should be very = straightforward, as the encoding of VINTs results in contiguous ranges = that should be easy for IANA to deal with. >>=20 >> Thanks. I=E2=80=99ve updated the section to use the VINT value rather = than the decimal of the Element Data of that VINT. The commit is at = https://github.com/cellar-wg/ebml-specification/pull/313/commits/948291dfd= defa02f857c83a7155519b980d9b2f6 = . >>=20 >> Dave Rice >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --Apple-Mail=_AD256537-FE02-4A16-81BB-152C9D4158F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Adam,

On Dec 17, 2019, at 4:37 PM, Adam Roach = <adam@nostrum.com> wrote:

=20 =20
Thanks for your responses. Modulo the comment I left in github [1], these two PRs (combined with the other PR you cited in an earlier message) address the concerns I had. I'll clear my DISCUSS when a new version with these PRs incorporated is put in the i-d = repository.

Thanks, this comment addresses your github comment = and references the other reserved one-octet Element ID value: https://github.com/cellar-wg/ebml-specification/pull/313/commit= s/689cbdb6882bc409628774cfa2854ee981d3ce87.

Also, to be clear what hex ranges are not valid = for use as Element IDs, I restated these ranges specifically within this = section at https://github.com/cellar-wg/ebml-specification/pull/313/commit= s/06d1960f9208e58f56972870b72f2c95fe1d8fe3.

Dave


Thanks!

/a


____
[1] https://github.com/cel= lar-wg/ebml-specification/pull/313/commits/948291dfddefa02f857c83a7155519b= 980d9b2f6#r359039422

On 12/17/19 3:16 PM, Dave Rice = wrote:


On Dec 17, 2019, at 2:56 PM, Adam Roach <adam@nostrum.com> wrote:

Dave --

Thanks for the quick response! The issues that the PR addresses look good to me. Two comments inline below.

On 12/17/19 9:27 AM, Dave Rice wrote:


Abstract:

I see that the Introduction has been revised to address Ben Campbell's AD
review comment regarding the document positioning itself as a general-purpose
data format rather than being scoped to its use in Matroska. The Abstract
still claims the much broader scope -- please update it to match the reduced
scope in the Introduction.


I didn't see a response to this discuss point. See also the GENART review, which raises this issue in some = detail.

IIUC, this issue is discussed in https://github.com/cellar-wg/ebml-specification/p= ull/311/files.

=C2=A717.1:

The VINT Data = value of one-octet Element IDs MUST be between 0x01 and
0x7E.  These items are valuable because they = are short, and need to
be used for commonly repeated elements.  Values = from 1 to 126 are to
be allocated according to the "RFC Required" policy [RFC8126].

This, combined with the values that are being registered, is extremely
confusing, and I don't know how IANA is supposed to understand what's going on
without reading and understanding the VINT bit encoding scheme (which is way
too much to ask of them). This is because of the document-wide practice
of speaking of IDs in their VINT-encoded values (e.g., 0xBF) instead of their
data values (e.g., 63 or 0x3F), including in the initial registry in this section.

Please either revise the prose to speak in terms of VINT-encoded values
(e.g., "MUST be between 0x81 and 0xFE"), or revise the registration
tables to indicate the VINT data values (e.g., "0x3F" for CRC-32).

I understand the request and the reason for it and am interested in assessing rough consensus amongst the other authors before making this change. These elements have been long-associated with these particular vint expressions of the Element IDs, so I have some concerns that a global change of Element ID reference from VINT to the Element Data of that VINT would confuse = readers.

Given that information, I imagine that the better path would be revising the IANA instructions to operate on VINTs ("MUST be between 0x81 and 0xFE") instead of VINT element data. This should be very straightforward, as the encoding of VINTs results in contiguous ranges that should be easy for IANA to deal with.

Thanks. I=E2=80=99ve updated the section to use = the VINT value rather than the decimal of the Element Data of that VINT. The commit is at https://github.com/cellar-wg/ebml-specification/p= ull/313/commits/948291dfddefa02f857c83a7155519b980d9b2f6.

Dave Rice


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

= --Apple-Mail=_AD256537-FE02-4A16-81BB-152C9D4158F3-- From nobody Wed Dec 18 21:45:36 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 6BB80120018; Wed, 18 Dec 2019 21:45:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-cellar-ebml@ietf.org, Steven Villereal , cellar-chairs@ietf.org, villereal@gmail.com, cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <157673433343.4965.3950484582725131414.idtracker@ietfa.amsl.com> Date: Wed, 18 Dec 2019 21:45:33 -0800 Archived-At: Subject: [Cellar] Barry Leiba's No Objection on draft-ietf-cellar-ebml-15: (with COMMENT) 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, 19 Dec 2019 05:45:34 -0000 Barry Leiba has entered the following ballot position for draft-ietf-cellar-ebml-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This was a very difficult read: I found a lot of the document to be convoluted and hard to follow, and I considered balloting Abstain, as I’m not sure that DISCUSS is appropriate for my complaints, but I can’t really say that I have “no objection”. In the end I decided to go with a “No Objection” ballot, to call out the worst of the issues, and to hope that you will consider the changes I suggest and that others will follow the text more easily than I could. — Section 4.1 — Each Variable Size Integer begins with a VINT_WIDTH which consists of zero or many zero-value bits. The count of consecutive zero-values of the VINT_WIDTH plus one equals the length in octets of the Variable Size Integer. For example, a Variable Size Integer that starts with a VINT_WIDTH which contains zero consecutive zero-value bits is one octet in length and a Variable Size Integer that starts with one consecutive zero-value bit is two octets in length. The VINT_WIDTH MUST only contain zero-value bits or be empty. I found this very hard to follow, and had to read it several times before I understood what you’re getting at. I found things such as “zero or many zero-value bits” to be confusing. May I suggest alternative text, which describes the concept and then gets to the details?: NEW Each Variable Size Integer begins with a VINT_WIDTH followed by a VINT_MARKER. VINT_WIDTH is a sequence of zero or more bits of value 0, and is terminated by the VINT_MARKER, which is a single bit of value 1. The total number of bits (VINT_WIDTH and VINT_MARKER combined) is the number of octets of the Variable Size Integer. Thus, the single bit “1” describes a Variable Size Integer with a length of one octet. The sequence of bits “01” describes a Variable Size Integer with a length of two octets. “001” describes a Variable Size Integer with a length of three octets, and so on, with each additional 0-bit adding one octet to the length of the Variable Size Integer. END I, at least, find that easier to follow. Does it work for you? For the next paragraph, which limits the length under various circumstances, I suggest putting it in terms of the number of octets in the integer, rather than the number of bits in the VINT_WIDTH, which might be better put into Section 4.3, rather than 4.1. Text such as, “A Variable Size Integer in an EBML Header can be at most 4 octets long, except [...] , where it can be up to 8 octets long,” is easier to understand than the text explaining limits on the number of bits in VINT_WIDTH. — Section 4.4 — Table 2 and the text that introduces it would be better if they talked about the integer that’s represented (2), rather than the binary value (0b10 in the text and 10 in the table), considering that it is a Variable Size INTEGER, yes? — Section 6.2 — An EBML Element with an unknown Element Data Size is referred to as an Unknown-Sized Element. A Master Element MAY be an Unknown-Sized Element; however an EBML Element that is not a Master Element MUST NOT be an Unknown-Sized Element. Master Elements MUST NOT use an unknown size unless the unknownsizeallowed attribute of their EBML Schema is set to true (see Section 11.1.5.10). This also seems confusing and perhaps contradictory because of how it uses the BCP 14 key words. May I suggest this, which neither uses nor needs the key words?: NEW An EBML Element with an unknown Element Data Size is referred to as an Unknown-Sized Element. Only a Master Element is allowed to be of unknown size, and it can only be so if the unknownsizeallowed attribute of its EBML Schema is set to true (see Section 11.1.5.10). END — Section 7.7 — The Master Element MAY also use an unknown length. The “MAY” isn’t really correct, is it? There are restrictions that make it not entirely optional, as noted in the next sentence. I suggest not using BCP 14 here, and just saying, “The Master Element may be of unknown length.” The Master Element contains zero, one, or many other elements. Does this mean anything more than the simpler, “The Master Element contains zero or more other elements.”? As written, one tends to ask what “many” means here. — Section 8.2 — The EBML Body MUST NOT contain any data that is not part of an EBML Element. Why is this repetition needed? Doesn’t the similar sentence in Section 8 cover this? — Section 10 — An EBML Document handles 2 different versions: the version of the EBML Header and the version of the EBML Body. Both versions are meant to be backward compatible. I don’t see how that’s practical, as, taken strictly, it means you’ll never be able to make a significant change that is not backward compatible, so you’ll be stuck with errors or limitations forever. Are you sure you won’t need to allow for incompatible versions at some point? — Section 17.1 — Values from 1 to 126 are to be allocated according to the "RFC Required" policy [RFC8126]. Why did you choose that policy? Are you aware that this allows registrations from non-IETF-stream RFCs? In particular, anyone can get an RFC published in the Independent stream with a very light level of review. Did you consider IETF Review, which requires an RFC in the IETF stream (including Informational and Experimental RFCs)? Or even Standards Action, which requires standards-track RFCs? The same comment applies to "matroska" and "webm" in Section 17.2. From nobody Thu Dec 19 06:02:33 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 A445912080E; Thu, 19 Dec 2019 06:02:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Magnus Westerlund via Datatracker To: "The IESG" Cc: draft-ietf-cellar-ebml@ietf.org, Steven Villereal , cellar-chairs@ietf.org, villereal@gmail.com, cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Magnus Westerlund Message-ID: <157676414666.27346.14188913386068032568.idtracker@ietfa.amsl.com> Date: Thu, 19 Dec 2019 06:02:26 -0800 Archived-At: Subject: [Cellar] Magnus Westerlund's Discuss on draft-ietf-cellar-ebml-15: (with DISCUSS and COMMENT) 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, 19 Dec 2019 14:02:27 -0000 Magnus Westerlund has entered the following ballot position for draft-ietf-cellar-ebml-15: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 1. Section 5: The Element ID is encoded as a Variable Size Integer. +-----------------------+-------------------------+---------------+ | VINT Length in octets | Range of Possible IDs | Number of IDs | +=======================+=========================+===============+ | 1 | 0x81 - 0xFE | 126 | +-----------------------+-------------------------+---------------+ | 2 | 0x407F - 0x7FFE | 16,256 | +-----------------------+-------------------------+---------------+ | 3 | 0x203FFF - 0x3FFFFE | 2,080,768 | +-----------------------+-------------------------+---------------+ | 4 | 0x101FFFFF - 0x1FFFFFFE | 268,338,304 | +-----------------------+-------------------------+---------------+ To me it appears that this whole section can't decide if the Element ID is encoded integer using VINT or an VINT format octet sequence that is self describing in length? If it is the first then the above quoted table would to me state that the IDs are 1-126 for 1 octet, and the second two-octet 127-16382. But based on later section it is actually the later. As the ID values defined in Section 11.2 for the various elements are actually the encoded form rather than a representation of the Integer value encoded. This needs to be clarified. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1. Section 5: Any Element ID with the VINT_DATA component set as all zero values or all one values MUST be ignored. What does it mean to ignore an Element ID in the general case. Can you really say this in the general case, rather than state that it is not a valid Element ID? Or is the intention that an Element ID with all data is the equivalent to padding and simply skipped and a parser needs to expect to find the real Element ID in the next octet sequence? Considering the Element Length that do allow zero values and non-efficient encoding, if the element should be ignored or not depends on the expected element to find by the parser. I might have missed some later explanation of this, as I didn't manage to read the whole document in detail. From nobody Thu Dec 19 07:35:16 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 B45D21200A4; Thu, 19 Dec 2019 07:35:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-cellar-ebml@ietf.org, Steven Villereal , cellar-chairs@ietf.org, villereal@gmail.com, cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <157676970970.27491.11040479061607849531.idtracker@ietfa.amsl.com> Date: Thu, 19 Dec 2019 07:35:09 -0800 Archived-At: Subject: [Cellar] Benjamin Kaduk's Discuss on draft-ietf-cellar-ebml-15: (with DISCUSS and COMMENT) 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, 19 Dec 2019 15:35:10 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-cellar-ebml-15: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 7.7 says: A Master Element MUST declare a length in octets from zero to VINTMAX. The Master Element MAY also use an unknown length. See Section 6 for rules that apply to elements of unknown length. but the second sentence contradicts the immediately prior MUST. We need to resolve the internal inconsistency. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Adam's Discuss regarding the Abstract. Section 2 "Parent Element": A relative term to describe the "Master Element" which contains a specified element. For any specified "EBML Element" that is not at "Root Level", the "Parent Element" refers to the "Master Element" in which that "EBML Element" is contained. It sounds like this is intended to be "directly" or "immediately" contained (in order to be unique), right? If not, then it sould be ''refers to a "Master Element" in which [...]'' Section 4.1 Each Variable Size Integer begins with a VINT_WIDTH which consists of zero or many zero-value bits. The count of consecutive zero-values of the VINT_WIDTH plus one equals the length in octets of the Variable Size Integer. [...] Does the following attempted rewording change the meaning? % Each Variable Size Integer begins with a VINT_WIDTH which consists of % zero or more bits set to zero. The length in octets of the entire % Variable Size Integer is determined as one plus the number of % consecutive bits set to zero. (I find the current formulation rather hard to parse.) Section 6.2 | "\root\level1\level2\" | Global Element cannot be | | | assumed to have this path, | | | while parsing "elt" it can | | | only be a child of "elt" | Cannot be assumed by who/what? My brain is trying to parse this as just "cannot assume this path". Section 7.5 Should we say anything about termination of a UTF-8 string needing to still result in valid UTF-8 (i.e., not insert NULs in the middle of a codepoint)? Section 7.7 stored within Master Elements SHOULD only consist of EBML Elements and SHOULD NOT contain any data that is not part of an EBML Element. When might this SHOULD (NOT) be violated? Section 8.2 part of an EBML Element. This document defines precisely which EBML Elements are to be used within the EBML Header, but does not name or (for EBMLVersion 1 only, right?) Section 11.1 Element; for example matroska or webm (see Section 11.2.6). The DocType value for an EBML Document Type MUST be unique and persistent. It might be appropriate to refer to Section 17.2 and/or the IANA registry for DocType values, here. 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 Does "as-is" imply some level of future-compatibility/extensibility for when EBMLVersions other than "1" are defined? Section 11.1.1 It's a little amusing that we bother to provide "default" attributes when the "range" attribute uniquely determines the allowed value. Section 11.1.4 Each "" defines one EBML Element through the use of several attributes that are defined in Section 11.1.3. EBML Schemas MAY I think this makes more sense as "Section 11.1.5". Section 11.1.5.2 This ABNF seems to only allow "direct" recursion where element appears directly inside element , without any intermediate elements. I assume that's the intent, though it would be surprising in a general-purpose markup language. In some cases the EBMLLastParent part of the path is an EBMLGlobalParent. A path with a EBMLGlobalParent defines a Section 11.3. Any path that starts with the EBMLFixedParent of the That second sentence doesn't parse. As an example, a "path" of "1*(\Segment\Info)" means the element Info is found inside the Segment elements at least once and with no maximum iteration. An element SeekHead with path "0*2(\Segment\SeekHead)" may not be found at all in its Segment parent, once or twice but no more than that. The way this text is written makes me want to interpret the path occurence counts more like the (regular) minOccurs/maxOccurs element attributes, as opposed to applying to the path components to get to the specific element in question. Section 11.1.9.2 A set of items. Is this "name" supposed to be "Item" or "Items"? Section 11.1.10-11.1.12 I'm not sure I have a full understanding of how / are used; perhaps a reference to the corresponding XML behavior is in order? Section 11.1.13-11.1.14 The usage seems underspecified. Section 11.1.15 Why do we include this commented-out snippet? Don't we effectively set default values for these two in the prose description? Section 11.1.16 Identically Recurring Elements SHOULD include a CRC-32 Element as a Child Element; this is especially recommended when EBML is used for long-term storage or transmission. If a Parent Element contains more I'm not sure if the "long-term" is intended to also bind as "long-term transmission" (though I'm not sure what it would mean in that case). It's also not entirely clear what kinds of transmission would benefit from this, as reliable media presumably don't need redundancy for reliability, but unreliable media can't really be used to carry EBML without some framing requirements to know when elements start. Section 11.1.18 If a Mandatory EBML Element has no default value declared by an EBML Schema and its Parent Element is present then the EBML Element MUST be present as well. If a Mandatory EBML Element has a default value declared by an EBML Schema and its Parent Element is present and the value of the EBML Element is NOT equal to the declared default value then the EBML Element MUST be present. This seems almost tautological, in that how would an EBML Element have a value if it was not present? (The following paragraph that talks about when to write such elements, does make more sense.) Section 11.3.1 path: "*1((1*\)\CRC-32)" Using backslash as both an escape character and a path separator makes my head hurt, and I did not have enough caffeine yet this morning to figure it out. 8.1.1.6.2 of [ITU.V42.1994], with initial value of 0xFFFFFFFF. The CRC value MUST be computed on a little endian bitstream and MUST use little endian storage. bitstream or bytestream? Section 12 If a Master Element contains a CRC-32 Element that doesn't validate, then the EBML Reader MAY ignore all contained data except for Descendant Elements that contain their own valid CRC-32 Element. Ignoring only part of the known questionable content could have significant security considerations, if (e.g.) security-relevant restrictions are in the garbled part of the document but the sensitive content has a (valid) redundant CRC. [review terminated early] From nobody Thu Dec 19 13:32: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 44FE81208F8; Thu, 19 Dec 2019 13:32:28 -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_HELO_NONE=0.001, 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 M6uyVp6L-EUh; Thu, 19 Dec 2019 13:32:26 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 7ED29120865; Thu, 19 Dec 2019 13:32:26 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBJLWLSE001848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Dec 2019 16:32:23 -0500 Date: Thu, 19 Dec 2019 13:32:20 -0800 From: Benjamin Kaduk To: The IESG , villereal@gmail.com, draft-ietf-cellar-ebml@ietf.org, cellar-chairs@ietf.org, cellar@ietf.org Message-ID: <20191219213220.GM81833@kduck.mit.edu> References: <157676970970.27491.11040479061607849531.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <157676970970.27491.11040479061607849531.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Cellar] Benjamin Kaduk's Discuss on draft-ietf-cellar-ebml-15: (with DISCUSS and COMMENT) 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, 19 Dec 2019 21:32:28 -0000 On Thu, Dec 19, 2019 at 07:35:09AM -0800, Benjamin Kaduk via Datatracker wrote: > Benjamin Kaduk has entered the following ballot position for > > [review terminated early] It turns out there would only have been a little more if it hadn't terminated early: Section 14.1.2 The same value for Element Data Size MAY be written in variable lengths, so for minor reductions in octet length the Element Data Size MAY be written to a longer octet length to fill the freed space. Is "reductions" the right word, here? Section 16 Side channel attacks could exploit: The following list of items do all involve potential side channels, but there's not a whole lot of clarity on what exactly is being attacked. -Ben From nobody Fri Dec 20 09:20: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 1CD5C120856; Fri, 20 Dec 2019 09:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 X7wgW5F41NFI; Fri, 20 Dec 2019 09:20:10 -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 E885B12084D; Fri, 20 Dec 2019 09:20:09 -0800 (PST) Received: from [146.96.19.240] (port=46812 helo=[10.10.201.20]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iiLwY-002kHS-Bw; Fri, 20 Dec 2019 12:20:07 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Dave Rice In-Reply-To: <157660987147.26437.3406623415377049016.idtracker@ietfa.amsl.com> Date: Fri, 20 Dec 2019 12:20:00 -0500 Cc: The IESG , Steven Villereal , draft-ietf-cellar-ebml@ietf.org, cellar-chairs@ietf.org, cellar@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <157660987147.26437.3406623415377049016.idtracker@ietfa.amsl.com> To: Alissa Cooper X-Mailer: Apple Mail (2.3445.104.8) X-OutGoing-Spam-Status: No, score=-2.1 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] Alissa Cooper's No Objection on draft-ietf-cellar-ebml-15: (with COMMENT) 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: Fri, 20 Dec 2019 17:20:11 -0000 > On Dec 17, 2019, at 2:11 PM, Alissa Cooper via Datatracker = wrote: >=20 > Alissa Cooper has entered the following ballot position for > draft-ietf-cellar-ebml-15: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I support Adam's DISCUSS point about the abstract. >=20 > I'm not clear on why the IANA registry names are prefixed with = "CELLAR." Are > there more general EBML Element ID and DocType registries envisioned? = If not, I > would suggest dropping the "CELLAR.=E2=80=9D Thanks. I made a pull request to respond to this suggestion at = https://github.com/cellar-wg/ebml-specification/pull/314/files for = others to consider. > For future documents I would expect the authors to respond to the = Gen-ART > reviewer's comments via email after fixes have been applied to address = the > issues raised in the review. There is an open pull request at = https://github.com/cellar-wg/ebml-specification/pull/311 which responds = to the Gen-ART review. It=E2=80=99s being discussed and hopefully to be = resolved and merged soon. Best Regards, Dave Rice= From nobody Fri Dec 20 12:01: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 A2EA61209CE; Fri, 20 Dec 2019 12:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 aaish1pSG92f; Fri, 20 Dec 2019 12:01:49 -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 13D2E1209CF; Fri, 20 Dec 2019 12:01:49 -0800 (PST) Received: from [146.96.19.240] (port=36784 helo=[10.10.201.20]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iiOT2-000Fpp-3L; Fri, 20 Dec 2019 15:01:48 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Dave Rice In-Reply-To: <157676414666.27346.14188913386068032568.idtracker@ietfa.amsl.com> Date: Fri, 20 Dec 2019 15:01:42 -0500 Cc: The IESG , villereal@gmail.com, draft-ietf-cellar-ebml@ietf.org, cellar-chairs@ietf.org, cellar@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5253C5B6-EFAA-4DF0-B7B2-FC11E4C02507@dericed.com> References: <157676414666.27346.14188913386068032568.idtracker@ietfa.amsl.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.3445.104.8) X-OutGoing-Spam-Status: No, score=-2.1 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] Magnus Westerlund's Discuss on draft-ietf-cellar-ebml-15: (with DISCUSS and COMMENT) 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: Fri, 20 Dec 2019 20:01:51 -0000 Hi Magnus, > On Dec 19, 2019, at 9:02 AM, Magnus Westerlund via Datatracker = wrote: >=20 > Magnus Westerlund has entered the following ballot position for > draft-ietf-cellar-ebml-15: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > 1. Section 5: >=20 > The Element ID is encoded as a Variable Size Integer. >=20 > +-----------------------+-------------------------+---------------+ > | VINT Length in octets | Range of Possible IDs | Number of IDs | > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ > | 1 | 0x81 - 0xFE | 126 | > +-----------------------+-------------------------+---------------+ > | 2 | 0x407F - 0x7FFE | 16,256 | > +-----------------------+-------------------------+---------------+ > | 3 | 0x203FFF - 0x3FFFFE | 2,080,768 | > +-----------------------+-------------------------+---------------+ > | 4 | 0x101FFFFF - 0x1FFFFFFE | 268,338,304 | > +-----------------------+-------------------------+---------------+ >=20 > To me it appears that this whole section can't decide if the Element = ID is > encoded integer using VINT or an VINT format octet sequence that is = self > describing in length? If it is the first then the above quoted table = would to > me state that the IDs are 1-126 for 1 octet, and the second two-octet > 127-16382. But based on later section it is actually the later. As the = ID > values defined in Section 11.2 for the various elements are actually = the > encoded form rather than a representation of the Integer value = encoded. This > needs to be clarified. Thanks, this topic came up in Adam Roach=E2=80=99s review [1] as well = and ended with a use of an Element ID as a VINT format octet sequence. I = have rewritten this section in the referenced pull request [2] according = to your suggestions and comments. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > 1. Section 5: >=20 > Any Element ID with the VINT_DATA > component set as all zero values or all one values MUST be ignored. >=20 > What does it mean to ignore an Element ID in the general case. Can you = really > say this in the general case, rather than state that it is not a valid = Element > ID? Or is the intention that an Element ID with all data is the = equivalent to > padding and simply skipped and a parser needs to expect to find the = real > Element ID in the next octet sequence? Considering the Element Length = that do > allow zero values and non-efficient encoding, if the element should be = ignored > or not depends on the expected element to find by the parser. >=20 > I might have missed some later explanation of this, as I didn't manage = to read > the whole document in detail. I considered changing this sentence from saying that such an Element ID = should be ignored to simply asserting that it is not valid; however the = prior sentence "The bits of the VINT\_DATA component of the Element ID = MUST NOT be all `0` values or all `1` values.=E2=80=9D already makes = this clear. Thus I simply removed the sentence in the second commit of = the pull request. I think this sentence is okay to remove as there are = later statements in Section 7.7 that make the same point more clearly = about skipping invalid data. Thanks much, Dave [1] = https://mailarchive.ietf.org/arch/msg/cellar/yvXmJPWGkUISXbdt0aZ-UkC57I8 [2] https://github.com/cellar-wg/ebml-specification/pull/315/files From nobody Fri Dec 20 13:08: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 1F7F11209D3; Fri, 20 Dec 2019 13:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 synmdeA-7jJj; Fri, 20 Dec 2019 13:08:29 -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 35C6D120859; Fri, 20 Dec 2019 13:08:29 -0800 (PST) Received: from [146.96.19.240] (port=43669 helo=[10.10.201.20]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iiPVX-0013MF-Kv; Fri, 20 Dec 2019 16:08:28 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Dave Rice In-Reply-To: <157673433343.4965.3950484582725131414.idtracker@ietfa.amsl.com> Date: Fri, 20 Dec 2019 16:08:21 -0500 Cc: The IESG , Steven Villereal , draft-ietf-cellar-ebml@ietf.org, cellar-chairs@ietf.org, Codec Encoding for LossLess Archiving and Realtime transmission Content-Transfer-Encoding: quoted-printable Message-Id: <4B8173E7-1A15-44E2-98C3-C8D08DAE3F1D@dericed.com> References: <157673433343.4965.3950484582725131414.idtracker@ietfa.amsl.com> To: Barry Leiba X-Mailer: Apple Mail (2.3445.104.8) X-OutGoing-Spam-Status: No, score=-2.1 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] Barry Leiba's No Objection on draft-ietf-cellar-ebml-15: (with COMMENT) 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: Fri, 20 Dec 2019 21:08:31 -0000 Hi Barry, Thanks for your review. Comments are below, including nudges to Michael = Richardson and Steve Lhomme for review. My comments below refer to work = that is reviewable within a pull request at = https://github.com/cellar-wg/ebml-specification/pull/316/files, though = in a few parts below I call for greater discussion. > On Dec 19, 2019, at 12:45 AM, Barry Leiba via Datatracker = wrote: >=20 > Barry Leiba has entered the following ballot position for > draft-ietf-cellar-ebml-15: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > This was a very difficult read: I found a lot of the document to be = convoluted > and hard to follow, and I considered balloting Abstain, as I=E2=80=99m = not sure that > DISCUSS is appropriate for my complaints, but I can=E2=80=99t really = say that I have > =E2=80=9Cno objection=E2=80=9D. In the end I decided to go with a = =E2=80=9CNo Objection=E2=80=9D ballot, to > call out the worst of the issues, and to hope that you will consider = the > changes I suggest and that others will follow the text more easily = than I could. >=20 > =E2=80=94 Section 4.1 =E2=80=94 >=20 > Each Variable Size Integer begins with a VINT_WIDTH which consists = of > zero or many zero-value bits. The count of consecutive zero-values > of the VINT_WIDTH plus one equals the length in octets of the > Variable Size Integer. For example, a Variable Size Integer that > starts with a VINT_WIDTH which contains zero consecutive zero-value > bits is one octet in length and a Variable Size Integer that starts > with one consecutive zero-value bit is two octets in length. The > VINT_WIDTH MUST only contain zero-value bits or be empty. >=20 > I found this very hard to follow, and had to read it several times = before I > understood what you=E2=80=99re getting at. I found things such as = =E2=80=9Czero or many > zero-value bits=E2=80=9D to be confusing. May I suggest alternative = text, which > describes the concept and then gets to the details?: >=20 > NEW > Each Variable Size Integer begins with a VINT_WIDTH followed by a = VINT_MARKER.=20 > VINT_WIDTH is a sequence of zero or more bits of value 0, and is = terminated by > the VINT_MARKER, which is a single bit of value 1. The total number = of bits > (VINT_WIDTH and VINT_MARKER combined) is the number of octets of the = Variable > Size Integer. >=20 > Thus, the single bit =E2=80=9C1=E2=80=9D describes a Variable Size = Integer with a length of one > octet. The sequence of bits =E2=80=9C01=E2=80=9D describes a Variable = Size Integer with a > length of two octets. =E2=80=9C001=E2=80=9D describes a Variable Size = Integer with a length of > three octets, and so on, with each additional 0-bit adding one octet = to the > length of the Variable Size Integer. END >=20 > I, at least, find that easier to follow. Does it work for you? Yes, I think that=E2=80=99s helpful. I changed the term =E2=80=98begins=E2= =80=99 and =E2=80=98describes=E2=80=99 to =E2=80=99starts=E2=80=99, so = there=E2=80=99s a little rewording but I have it now as: NEW Each Variable Size Integer starts with a VINT\_WIDTH followed by a VINT\_MARKER. VINT\_WIDTH is a sequence of zero or more bits of value `0`, and is terminated by the VINT\_MARKER, which is a single bit of value `1`. The total number of bits (VINT\_WIDTH and VINT\_MARKER = combined) is the number of octets in length of the Variable Size = Integer. Thus, the single bit `1` starts a Variable Size Integer with a length of = one octet. The sequence of bits `01` starts a Variable Size Integer = with a length of two octets. `001` starts a Variable Size Integer with a = length of three octets, and so on, with each additional 0-bit adding one = octet to the length of the Variable Size Integer. END > For the next paragraph, which limits the length under various = circumstances, I > suggest putting it in terms of the number of octets in the integer, = rather than > the number of bits in the VINT_WIDTH, which might be better put into = Section > 4.3, rather than 4.1. Text such as, =E2=80=9CA Variable Size Integer = in an EBML Header > can be at most 4 octets long, except [...] , where it can be up to 8 = octets > long,=E2=80=9D is easier to understand than the text explaining limits = on the number of > bits in VINT_WIDTH. I agree with your rewording but prefer to split this paragraph and move = it to section 8.1 which pertains to the =E2=80=9CEBML Header=E2=80=9D = and 8.2 which pertains to =E2=80=9CEBML Body=E2=80=9D. After rewording = the content is: Added to 8.1 Elements within an EBML Header can be at most 4 octets long, except for = the EBML Element with Element Name EBML and Element ID `0x1A45DFA3` (see = (#ebml-element)), which can be up to 8 octets long. Added to 8.2 Within the EBML Body, the maximum octet length allowed for any Element = ID is set by the EBMLMaxIDLength Element and the maximum octet length = allowed for any Element Data Size is set by the EBMLMaxSizeLength = Element. > =E2=80=94 Section 4.4 =E2=80=94 > Table 2 and the text that introduces it would be better if they talked = about > the integer that=E2=80=99s represented (2), rather than the binary = value (0b10 in the > text and 10 in the table), considering that it is a Variable Size = INTEGER, yes? That makes sense, I rewrote to focus on integer and parenthetically = mentioned the binary value since the VINT is expressed in binary (though = I added a hex representation as well). > =E2=80=94 Section 6.2 =E2=80=94 >=20 > An EBML Element with an unknown Element Data Size > is referred to as an Unknown-Sized Element. A Master Element MAY be > an Unknown-Sized Element; however an EBML Element that is not a > Master Element MUST NOT be an Unknown-Sized Element. Master = Elements > MUST NOT use an unknown size unless the unknownsizeallowed attribute > of their EBML Schema is set to true (see Section 11.1.5.10). >=20 > This also seems confusing and perhaps contradictory because of how it = uses the > BCP 14 key words. May I suggest this, which neither uses nor needs = the key > words?: >=20 > NEW > An EBML Element with an unknown Element Data Size > is referred to as an Unknown-Sized Element. Only a Master Element > is allowed to be of unknown size, and it can only be so if the > unknownsizeallowed attribute of its EBML Schema is set to true > (see Section 11.1.5.10). > END I updated the section as suggested in the pull request. > =E2=80=94 Section 7.7 =E2=80=94 >=20 > The Master Element MAY also use an unknown length. >=20 > The =E2=80=9CMAY=E2=80=9D isn=E2=80=99t really correct, is it? There = are restrictions that make it not > entirely optional, as noted in the next sentence. I suggest not using = BCP 14 > here, and just saying, =E2=80=9CThe Master Element may be of unknown = length.=E2=80=9D I reworded this sentence with the prior one to avoid the use of MAY. The = new paragraph is: A Master Element MUST declare a length in octets from zero to VINTMAX or = be of unknown length. See (#element-data-size) for rules that apply to = elements of unknown length. > The Master Element contains zero, one, or many other elements. >=20 > Does this mean anything more than the simpler, =E2=80=9CThe Master = Element contains > zero or more other elements.=E2=80=9D? As written, one tends to ask = what =E2=80=9Cmany=E2=80=9D means > here. I updated the sentence as suggested in the pull request. > =E2=80=94 Section 8.2 =E2=80=94 >=20 > The EBML Body MUST NOT contain any data that is not > part of an EBML Element. >=20 > Why is this repetition needed? Doesn=E2=80=99t the similar sentence = in Section 8 cover > this? True. I removed this repetitive statement. > =E2=80=94 Section 10 =E2=80=94 >=20 > An EBML Document handles 2 different versions: the version of the > EBML Header and the version of the EBML Body. Both versions are > meant to be backward compatible. >=20 > I don=E2=80=99t see how that=E2=80=99s practical, as, taken strictly, = it means you=E2=80=99ll never be > able to make a significant change that is not backward compatible, so = you=E2=80=99ll be > stuck with errors or limitations forever. Are you sure you won=E2=80=99= t need to allow > for incompatible versions at some point? Nudging to Steve for review/comment. This part was written at: = https://github.com/cellar-wg/ebml-specification/commit/f9820d50d5279e11efb= b6cdd70dd8021b8a05dc9 = https://github.com/cellar-wg/ebml-specification/commit/10d359d637af02c15b1= c3191e260707adf0c29dc > =E2=80=94 Section 17.1 =E2=80=94 >=20 > Values from 1 to 126 are to > be allocated according to the "RFC Required" policy [RFC8126]. >=20 > Why did you choose that policy? Are you aware that this allows = registrations > from non-IETF-stream RFCs? In particular, anyone can get an RFC = published in > the Independent stream with a very light level of review. Did you = consider > IETF Review, which requires an RFC in the IETF stream (including = Informational > and Experimental RFCs)? Or even Standards Action, which requires > standards-track RFCs? >=20 > The same comment applies to "matroska" and "webm" in Section 17.2. Nudging to Michael, who recommended this policy here. Best Regards, Dave Rice From nobody Fri Dec 20 13:41:09 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 846AD1208BB; Fri, 20 Dec 2019 13:41:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 6u4izb_tgNAL; Fri, 20 Dec 2019 13:41:00 -0800 (PST) Received: from mail-io1-f48.google.com (mail-io1-f48.google.com [209.85.166.48]) (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 C8A0F120885; Fri, 20 Dec 2019 13:41:00 -0800 (PST) Received: by mail-io1-f48.google.com with SMTP id c16so9407881ioh.6; Fri, 20 Dec 2019 13:41:00 -0800 (PST) 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=nOc8lG8ekByHsbPWvVdm4taVh6Hctg56aUllAarF414=; b=o6jd4LhJqIrq1vlQWQSq95kY9DJxNudlDhKWPb3A0O9ZvPRqQ42xUtcfwakr5XcIeh D2ZP/uqkCoDbxJP9+xs1tjZejRDq239pr7AOdRonAzQ/0VbgDlm/PLhtuO9Cgyui7xmP H1cUwPytiSz7Ek+5KCZ/ug1FJYpPih+TJDnQOUnUZalbYSKUk8812WdaAvqFT2Hol/Jg +WS4X5Jj3wfysUEkjbDN6B2bBa0/5cYF8oKu0JblY5ac1i5mvT2+LlbSMhbWCrLu+SeS QCVF6b/9YKdfDfZ14MsNAL3HraR7fWXf/rh1QDx9cW4Pm0fqeB9CUYiFedeokccMg2vD zTqg== X-Gm-Message-State: APjAAAXJLESsYINXH7GLVhzhF5VmeMRwbLy2jcpLg9nMlvKoQ9Ox6J2f Vz5XBBWoHmG951u+x/ATIVwJprp8iAItYPZkX7Ui2Q== X-Google-Smtp-Source: APXvYqz0noDMaN4LeXPfVzHy3VYwE6njmLMNMhIUk/+TrinHDJPLCsnDv5hqEaSYsL3GKiKzkp3bFK91u9ETWJq93A4= X-Received: by 2002:a6b:8f41:: with SMTP id r62mr11398850iod.140.1576878059648; Fri, 20 Dec 2019 13:40:59 -0800 (PST) MIME-Version: 1.0 References: <157673433343.4965.3950484582725131414.idtracker@ietfa.amsl.com> <4B8173E7-1A15-44E2-98C3-C8D08DAE3F1D@dericed.com> In-Reply-To: <4B8173E7-1A15-44E2-98C3-C8D08DAE3F1D@dericed.com> From: Barry Leiba Date: Fri, 20 Dec 2019 16:40:48 -0500 Message-ID: To: Dave Rice Cc: draft-ietf-cellar-ebml@ietf.org, Steven Villereal , The IESG , cellar-chairs@ietf.org, 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] Barry Leiba's No Objection on draft-ietf-cellar-ebml-15: (with COMMENT) 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: Fri, 20 Dec 2019 21:41:03 -0000 Thanks, Dave, and I appreciate your addressing my concerns (and accepting most of my text!). We're good on all the items you handled. Barry On Fri, Dec 20, 2019 at 4:08 PM Dave Rice wrote: > > Hi Barry, > Thanks for your review. Comments are below, including nudges to Michael R= ichardson and Steve Lhomme for review. My comments below refer to work that= is reviewable within a pull request at https://github.com/cellar-wg/ebml-s= pecification/pull/316/files, though in a few parts below I call for greater= discussion. > > > On Dec 19, 2019, at 12:45 AM, Barry Leiba via Datatracker wrote: > > > > Barry Leiba has entered the following ballot position for > > draft-ietf-cellar-ebml-15: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > This was a very difficult read: I found a lot of the document to be con= voluted > > and hard to follow, and I considered balloting Abstain, as I=E2=80=99m = not sure that > > DISCUSS is appropriate for my complaints, but I can=E2=80=99t really sa= y that I have > > =E2=80=9Cno objection=E2=80=9D. In the end I decided to go with a =E2= =80=9CNo Objection=E2=80=9D ballot, to > > call out the worst of the issues, and to hope that you will consider th= e > > changes I suggest and that others will follow the text more easily than= I could. > > > > =E2=80=94 Section 4.1 =E2=80=94 > > > > Each Variable Size Integer begins with a VINT_WIDTH which consists of > > zero or many zero-value bits. The count of consecutive zero-values > > of the VINT_WIDTH plus one equals the length in octets of the > > Variable Size Integer. For example, a Variable Size Integer that > > starts with a VINT_WIDTH which contains zero consecutive zero-value > > bits is one octet in length and a Variable Size Integer that starts > > with one consecutive zero-value bit is two octets in length. The > > VINT_WIDTH MUST only contain zero-value bits or be empty. > > > > I found this very hard to follow, and had to read it several times befo= re I > > understood what you=E2=80=99re getting at. I found things such as =E2= =80=9Czero or many > > zero-value bits=E2=80=9D to be confusing. May I suggest alternative te= xt, which > > describes the concept and then gets to the details?: > > > > NEW > > Each Variable Size Integer begins with a VINT_WIDTH followed by a VINT_= MARKER. > > VINT_WIDTH is a sequence of zero or more bits of value 0, and is termin= ated by > > the VINT_MARKER, which is a single bit of value 1. The total number of= bits > > (VINT_WIDTH and VINT_MARKER combined) is the number of octets of the Va= riable > > Size Integer. > > > > Thus, the single bit =E2=80=9C1=E2=80=9D describes a Variable Size Inte= ger with a length of one > > octet. The sequence of bits =E2=80=9C01=E2=80=9D describes a Variable = Size Integer with a > > length of two octets. =E2=80=9C001=E2=80=9D describes a Variable Size = Integer with a length of > > three octets, and so on, with each additional 0-bit adding one octet to= the > > length of the Variable Size Integer. END > > > > I, at least, find that easier to follow. Does it work for you? > > Yes, I think that=E2=80=99s helpful. I changed the term =E2=80=98begins= =E2=80=99 and =E2=80=98describes=E2=80=99 to =E2=80=99starts=E2=80=99, so t= here=E2=80=99s a little rewording but I have it now as: > > NEW > Each Variable Size Integer starts with a VINT\_WIDTH followed by a > VINT\_MARKER. VINT\_WIDTH is a sequence of zero or more bits of value > `0`, and is terminated by the VINT\_MARKER, which is a single bit of > value `1`. The total number of bits (VINT\_WIDTH and VINT\_MARKER combine= d) is the number of octets in length of the Variable Size Integer. > > Thus, the single bit `1` starts a Variable Size Integer with a length of = one octet. The sequence of bits `01` starts a Variable Size Integer with a= length of two octets. `001` starts a Variable Size Integer with a length o= f three octets, and so on, with each additional 0-bit adding one octet to t= he length of the Variable Size Integer. END > > > For the next paragraph, which limits the length under various circumsta= nces, I > > suggest putting it in terms of the number of octets in the integer, rat= her than > > the number of bits in the VINT_WIDTH, which might be better put into Se= ction > > 4.3, rather than 4.1. Text such as, =E2=80=9CA Variable Size Integer i= n an EBML Header > > can be at most 4 octets long, except [...] , where it can be up to 8 oc= tets > > long,=E2=80=9D is easier to understand than the text explaining limits = on the number of > > bits in VINT_WIDTH. > > I agree with your rewording but prefer to split this paragraph and move i= t to section 8.1 which pertains to the =E2=80=9CEBML Header=E2=80=9D and 8.= 2 which pertains to =E2=80=9CEBML Body=E2=80=9D. After rewording the conten= t is: > > Added to 8.1 > Elements within an EBML Header can be at most 4 octets long, except for t= he EBML Element with Element Name EBML and Element ID `0x1A45DFA3` (see (#e= bml-element)), which can be up to 8 octets long. > > Added to 8.2 > Within the EBML Body, the maximum octet length allowed for any Element ID= is set by the EBMLMaxIDLength Element and the maximum octet length allowed= for any Element Data Size is set by the EBMLMaxSizeLength Element. > > > =E2=80=94 Section 4.4 =E2=80=94 > > Table 2 and the text that introduces it would be better if they talked = about > > the integer that=E2=80=99s represented (2), rather than the binary valu= e (0b10 in the > > text and 10 in the table), considering that it is a Variable Size INTEG= ER, yes? > > That makes sense, I rewrote to focus on integer and parenthetically menti= oned the binary value since the VINT is expressed in binary (though I added= a hex representation as well). > > > =E2=80=94 Section 6.2 =E2=80=94 > > > > An EBML Element with an unknown Element Data Size > > is referred to as an Unknown-Sized Element. A Master Element MAY be > > an Unknown-Sized Element; however an EBML Element that is not a > > Master Element MUST NOT be an Unknown-Sized Element. Master Elements > > MUST NOT use an unknown size unless the unknownsizeallowed attribute > > of their EBML Schema is set to true (see Section 11.1.5.10). > > > > This also seems confusing and perhaps contradictory because of how it u= ses the > > BCP 14 key words. May I suggest this, which neither uses nor needs the= key > > words?: > > > > NEW > > An EBML Element with an unknown Element Data Size > > is referred to as an Unknown-Sized Element. Only a Master Element > > is allowed to be of unknown size, and it can only be so if the > > unknownsizeallowed attribute of its EBML Schema is set to true > > (see Section 11.1.5.10). > > END > > I updated the section as suggested in the pull request. > > > =E2=80=94 Section 7.7 =E2=80=94 > > > > The Master Element MAY also use an unknown length. > > > > The =E2=80=9CMAY=E2=80=9D isn=E2=80=99t really correct, is it? There a= re restrictions that make it not > > entirely optional, as noted in the next sentence. I suggest not using = BCP 14 > > here, and just saying, =E2=80=9CThe Master Element may be of unknown le= ngth.=E2=80=9D > > I reworded this sentence with the prior one to avoid the use of MAY. The = new paragraph is: > > A Master Element MUST declare a length in octets from zero to VINTMAX or = be of unknown length. See (#element-data-size) for rules that apply to elem= ents of unknown length. > > > The Master Element contains zero, one, or many other elements. > > > > Does this mean anything more than the simpler, =E2=80=9CThe Master Elem= ent contains > > zero or more other elements.=E2=80=9D? As written, one tends to ask wh= at =E2=80=9Cmany=E2=80=9D means > > here. > > I updated the sentence as suggested in the pull request. > > > =E2=80=94 Section 8.2 =E2=80=94 > > > > The EBML Body MUST NOT contain any data that is not > > part of an EBML Element. > > > > Why is this repetition needed? Doesn=E2=80=99t the similar sentence in= Section 8 cover > > this? > > True. I removed this repetitive statement. > > > =E2=80=94 Section 10 =E2=80=94 > > > > An EBML Document handles 2 different versions: the version of the > > EBML Header and the version of the EBML Body. Both versions are > > meant to be backward compatible. > > > > I don=E2=80=99t see how that=E2=80=99s practical, as, taken strictly, i= t means you=E2=80=99ll never be > > able to make a significant change that is not backward compatible, so y= ou=E2=80=99ll be > > stuck with errors or limitations forever. Are you sure you won=E2=80= =99t need to allow > > for incompatible versions at some point? > > Nudging to Steve for review/comment. This part was written at: > https://github.com/cellar-wg/ebml-specification/commit/f9820d50d5279e11ef= bb6cdd70dd8021b8a05dc9 > https://github.com/cellar-wg/ebml-specification/commit/10d359d637af02c15b= 1c3191e260707adf0c29dc > > > =E2=80=94 Section 17.1 =E2=80=94 > > > > Values from 1 to 126 are to > > be allocated according to the "RFC Required" policy [RFC8126]. > > > > Why did you choose that policy? Are you aware that this allows registr= ations > > from non-IETF-stream RFCs? In particular, anyone can get an RFC publis= hed in > > the Independent stream with a very light level of review. Did you cons= ider > > IETF Review, which requires an RFC in the IETF stream (including Inform= ational > > and Experimental RFCs)? Or even Standards Action, which requires > > standards-track RFCs? > > > > The same comment applies to "matroska" and "webm" in Section 17.2. > > Nudging to Michael, who recommended this policy here. > > Best Regards, > Dave Rice > From nobody Sun Dec 22 12:38:31 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 2FFCC12001A; Sun, 22 Dec 2019 12:38:30 -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.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <157704711012.11803.5786734745550510048@ietfa.amsl.com> Date: Sun, 22 Dec 2019 12:38:30 -0800 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-ebml-16.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: Sun, 22 Dec 2019 20:38:30 -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 : Extensible Binary Meta Language Authors : Steve Lhomme Dave Rice Moritz Bunkus Filename : draft-ietf-cellar-ebml-16.txt Pages : 59 Date : 2019-12-22 Abstract: This document defines the Extensible Binary Meta Language (EBML) format as a binary container format designed for audio/video storage. EBML is designed as a binary equivalent to XML and uses a storage- efficient approach to build nested Elements with identifiers, lengths, and values. Similar to how an XML Schema defines the structure and semantics of an XML Document, this document defines how EBML Schemas are created to convey the semantics of an EBML Document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cellar-ebml-16 https://datatracker.ietf.org/doc/html/draft-ietf-cellar-ebml-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ebml-16 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 Sun Dec 22 12:50:36 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 B58A712006D; Sun, 22 Dec 2019 12:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 pH0TQ9ooe5Uq; Sun, 22 Dec 2019 12:50:33 -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 B3FB0120033; Sun, 22 Dec 2019 12:50:33 -0800 (PST) Received: from cpe-104-162-94-162.nyc.res.rr.com ([104.162.94.162]:42756 helo=[10.0.1.6]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1ij8BI-002EaN-IW; Sun, 22 Dec 2019 15:50:33 -0500 From: Dave Rice Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_FE0123EF-09E6-4693-A46B-387FA74CDCFA" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Sun, 22 Dec 2019 15:50:26 -0500 In-Reply-To: <5253C5B6-EFAA-4DF0-B7B2-FC11E4C02507@dericed.com> Cc: The IESG , villereal@gmail.com, draft-ietf-cellar-ebml@ietf.org, cellar-chairs@ietf.org, cellar@ietf.org To: Magnus Westerlund References: <157676414666.27346.14188913386068032568.idtracker@ietfa.amsl.com> <5253C5B6-EFAA-4DF0-B7B2-FC11E4C02507@dericed.com> X-Mailer: Apple Mail (2.3601.0.10) X-OutGoing-Spam-Status: No, score=-2.9 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] Magnus Westerlund's Discuss on draft-ietf-cellar-ebml-15: (with DISCUSS and COMMENT) 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, 22 Dec 2019 20:50:36 -0000 --Apple-Mail=_FE0123EF-09E6-4693-A46B-387FA74CDCFA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Magnus, Version 16 at https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/16 = is posted and should address all comments below. Thanks for your review. Best Regards, Dave Rice > On Dec 20, 2019, at 3:01 PM, Dave Rice wrote: >=20 > Hi Magnus, >=20 >> On Dec 19, 2019, at 9:02 AM, Magnus Westerlund via Datatracker = wrote: >>=20 >> Magnus Westerlund has entered the following ballot position for >> draft-ietf-cellar-ebml-15: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> 1. Section 5: >>=20 >> The Element ID is encoded as a Variable Size Integer. >>=20 >> +-----------------------+-------------------------+---------------+ >> | VINT Length in octets | Range of Possible IDs | Number of IDs | >> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >> | 1 | 0x81 - 0xFE | 126 | >> +-----------------------+-------------------------+---------------+ >> | 2 | 0x407F - 0x7FFE | 16,256 | >> +-----------------------+-------------------------+---------------+ >> | 3 | 0x203FFF - 0x3FFFFE | 2,080,768 | >> +-----------------------+-------------------------+---------------+ >> | 4 | 0x101FFFFF - 0x1FFFFFFE | 268,338,304 | >> +-----------------------+-------------------------+---------------+ >>=20 >> To me it appears that this whole section can't decide if the Element = ID is >> encoded integer using VINT or an VINT format octet sequence that is = self >> describing in length? If it is the first then the above quoted table = would to >> me state that the IDs are 1-126 for 1 octet, and the second two-octet >> 127-16382. But based on later section it is actually the later. As = the ID >> values defined in Section 11.2 for the various elements are actually = the >> encoded form rather than a representation of the Integer value = encoded. This >> needs to be clarified. >=20 > Thanks, this topic came up in Adam Roach=E2=80=99s review [1] as well = and ended with a use of an Element ID as a VINT format octet sequence. I = have rewritten this section in the referenced pull request [2] according = to your suggestions and comments. >=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> 1. Section 5: >>=20 >> Any Element ID with the VINT_DATA >> component set as all zero values or all one values MUST be ignored. >>=20 >> What does it mean to ignore an Element ID in the general case. Can = you really >> say this in the general case, rather than state that it is not a = valid Element >> ID? Or is the intention that an Element ID with all data is the = equivalent to >> padding and simply skipped and a parser needs to expect to find the = real >> Element ID in the next octet sequence? Considering the Element Length = that do >> allow zero values and non-efficient encoding, if the element should = be ignored >> or not depends on the expected element to find by the parser. >>=20 >> I might have missed some later explanation of this, as I didn't = manage to read >> the whole document in detail. >=20 > I considered changing this sentence from saying that such an Element = ID should be ignored to simply asserting that it is not valid; however = the prior sentence "The bits of the VINT\_DATA component of the Element = ID MUST NOT be all `0` values or all `1` values.=E2=80=9D already makes = this clear. Thus I simply removed the sentence in the second commit of = the pull request. I think this sentence is okay to remove as there are = later statements in Section 7.7 that make the same point more clearly = about skipping invalid data. >=20 > Thanks much, > Dave >=20 > [1] = https://mailarchive.ietf.org/arch/msg/cellar/yvXmJPWGkUISXbdt0aZ-UkC57I8 = = > [2] https://github.com/cellar-wg/ebml-specification/pull/315/files = --Apple-Mail=_FE0123EF-09E6-4693-A46B-387FA74CDCFA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Magnus,

Version 16 = at https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/16&= nbsp;is posted and should address all comments below. Thanks for your = review.

Best = Regards,
Dave Rice

On Dec = 20, 2019, at 3:01 PM, Dave Rice <dave@dericed.com> wrote:

Hi Magnus,

On = Dec 19, 2019, at 9:02 AM, Magnus Westerlund via Datatracker <noreply@ietf.org> = wrote:

Magnus Westerlund has entered the = following ballot position for
draft-ietf-cellar-ebml-15: = Discuss

When responding, please keep the = subject line intact and reply to all
email addresses = included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/


---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

1. Section 5:

 The Element ID is encoded as a Variable Size = Integer.

  +-----------------------+-------------------------+= ---------------+
  | VINT Length in octets | =  Range of Possible IDs  | Number of IDs |
  +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
  | =           1 =           | =       0x81 - 0xFE =       | =           126 |
  +-----------------------+-------------------------+= ---------------+
  | =           2 =           | =     0x407F - 0x7FFE     | =        16,256 |
  +-----------------------+-------------------------+= ---------------+
  | =           3 =           | =   0x203FFF - 0x3FFFFE   | =     2,080,768 |
  +-----------------------+-------------------------+= ---------------+
  | =           4 =           | 0x101FFFFF = - 0x1FFFFFFE |   268,338,304 |
  +-----------------------+-------------------------+= ---------------+

To me it appears that this = whole section can't decide if the Element ID is
encoded = integer using VINT or an VINT format octet sequence that is self
describing in length? If it is the first then the above = quoted table would to
me state that the IDs are 1-126 for = 1 octet, and the second two-octet
127-16382. But based on = later section it is actually the later. As the ID
values = defined in Section 11.2 for the various elements are actually the
encoded form rather than a representation of the Integer = value encoded. This
needs to be clarified.

Thanks, this topic came up in Adam Roach=E2=80=99s review [1] = as well and ended with a use of an Element ID as a VINT format octet = sequence. I have rewritten this section in the referenced pull request = [2] according to your suggestions and comments.

---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

1. Section 5:

Any Element ID with the VINT_DATA
 component= set as all zero values or all one values MUST be ignored.

What does it mean to ignore an Element ID in = the general case. Can you really
say this in the general = case, rather than state that it is not a valid Element
ID? = Or is the intention that an Element ID with all data is the equivalent = to
padding and simply skipped and a parser needs to expect = to find the real
Element ID in the next octet sequence? = Considering the Element Length that do
allow zero values = and non-efficient encoding, if the element should be ignored
or not depends on the expected element to find by the = parser.

I might have missed some later = explanation of this, as I didn't manage to read
the whole = document in detail.

I considered changing this sentence from saying that such an = Element ID should be ignored to simply asserting that it is not valid; = however the prior sentence "The bits of the VINT\_DATA component of the = Element ID MUST NOT be all `0` values or all `1` values.=E2=80=9D = already makes this clear. Thus I simply removed the sentence in the = second commit of the pull request. I think this sentence is okay to = remove as there are later statements in Section 7.7 that make the same = point more clearly about skipping invalid data.

Thanks much,
Dave

[1] https://mailarchive.ietf.org/arch/msg/cellar/yvXmJPWGkUISXbdt0a= Z-UkC57I8
[2] https://github.com/cellar-wg/ebml-specification/pull/315/files<= /a>

= --Apple-Mail=_FE0123EF-09E6-4693-A46B-387FA74CDCFA-- From nobody Sun Dec 22 12:50: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 3A577120033; Sun, 22 Dec 2019 12:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 fLvkvsg53Dmy; Sun, 22 Dec 2019 12:50:43 -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 90FED12006D; Sun, 22 Dec 2019 12:50:43 -0800 (PST) Received: from cpe-104-162-94-162.nyc.res.rr.com ([104.162.94.162]:42756 helo=[10.0.1.6]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1ij8BS-002EaN-I4; Sun, 22 Dec 2019 15:50:43 -0500 From: Dave Rice Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C5A52BFB-504B-40D6-8328-8A17B129D7DA" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Sun, 22 Dec 2019 15:50:37 -0500 In-Reply-To: Cc: Steven Villereal , draft-ietf-cellar-ebml@ietf.org, The IESG , cellar-chairs@ietf.org, Codec Encoding for LossLess Archiving and Realtime transmission To: Adam Roach References: <157656052355.24550.17056837047628625307.idtracker@ietfa.amsl.com> <2D4A95A1-B570-47C7-B040-923EF3F24C9C@dericed.com> <69d0eb8f-f790-293c-0cd9-deadc915254f@nostrum.com> <4A5AD779-2C48-460B-A34C-672D98F39C98@dericed.com> <09ddd4eb-ee6e-7eb3-dd56-f58946116103@nostrum.com> X-Mailer: Apple Mail (2.3601.0.10) X-OutGoing-Spam-Status: No, score=-2.6 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] Adam Roach's Discuss on draft-ietf-cellar-ebml-15: (with DISCUSS and COMMENT) 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, 22 Dec 2019 20:50:45 -0000 --Apple-Mail=_C5A52BFB-504B-40D6-8328-8A17B129D7DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Adam, > On Dec 17, 2019, at 9:17 PM, Dave Rice wrote: >=20 > Hi Adam, >=20 >> On Dec 17, 2019, at 4:37 PM, Adam Roach > wrote: >>=20 >> Thanks for your responses. Modulo the comment I left in github [1], = these two PRs (combined with the other PR you cited in an earlier = message) address the concerns I had. I'll clear my DISCUSS when a new = version with these PRs incorporated is put in the i-d repository. >=20 > Thanks, this comment addresses your github comment and references the = other reserved one-octet Element ID value: = https://github.com/cellar-wg/ebml-specification/pull/313/commits/689cbdb68= 82bc409628774cfa2854ee981d3ce87 = . >=20 > Also, to be clear what hex ranges are not valid for use as Element = IDs, I restated these ranges specifically within this section at = https://github.com/cellar-wg/ebml-specification/pull/313/commits/06d1960f9= 208e58f56972870b72f2c95fe1d8fe3 = . Version 16 at https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/16 = is posted and should address all comments presented below. Thanks much = for your review. Dave Rice > Dave >=20 >=20 >> Thanks! >>=20 >> /a >>=20 >>=20 >> ____ >> [1] = https://github.com/cellar-wg/ebml-specification/pull/313/commits/948291dfd= defa02f857c83a7155519b980d9b2f6#r359039422 = >>=20 >> On 12/17/19 3:16 PM, Dave Rice wrote: >>>=20 >>>=20 >>>> On Dec 17, 2019, at 2:56 PM, Adam Roach > wrote: >>>>=20 >>>> Dave -- >>>>=20 >>>> Thanks for the quick response! The issues that the PR addresses = look good to me. Two comments inline below. >>>>=20 >>>> On 12/17/19 9:27 AM, Dave Rice wrote: >>>>>=20 >>>>>>=20 >>>>>> Abstract: >>>>>>=20 >>>>>> I see that the Introduction has been revised to address Ben = Campbell's AD >>>>>> review comment regarding the document positioning itself as a = general-purpose >>>>>> data format rather than being scoped to its use in Matroska. The = Abstract >>>>>> still claims the much broader scope -- please update it to match = the reduced >>>>>> scope in the Introduction. >>>>>>=20 >>>>=20 >>>> I didn't see a response to this discuss point. See also the GENART = review, which raises this issue in some detail. >>>=20 >>> IIUC, this issue is discussed in = https://github.com/cellar-wg/ebml-specification/pull/311/files = . >>>=20 >>>>>> =C2=A717.1: >>>>>>=20 >>>>>>> The VINT Data value of one-octet Element IDs MUST be between = 0x01 and >>>>>>> 0x7E. These items are valuable because they are short, and need = to >>>>>>> be used for commonly repeated elements. Values from 1 to 126 = are to >>>>>>> be allocated according to the "RFC Required" policy [RFC8126]. >>>>>>=20 >>>>>> This, combined with the values that are being registered, is = extremely >>>>>> confusing, and I don't know how IANA is supposed to understand = what's going on >>>>>> without reading and understanding the VINT bit encoding scheme = (which is way >>>>>> too much to ask of them). This is because of the document-wide = practice >>>>>> of speaking of IDs in their VINT-encoded values (e.g., 0xBF) = instead of their >>>>>> data values (e.g., 63 or 0x3F), including in the initial registry = in this section. >>>>>>=20 >>>>>> Please either revise the prose to speak in terms of VINT-encoded = values >>>>>> (e.g., "MUST be between 0x81 and 0xFE"), or revise the = registration >>>>>> tables to indicate the VINT data values (e.g., "0x3F" for = CRC-32). >>>>>=20 >>>>> I understand the request and the reason for it and am interested = in assessing rough consensus amongst the other authors before making = this change. These elements have been long-associated with these = particular vint expressions of the Element IDs, so I have some concerns = that a global change of Element ID reference from VINT to the Element = Data of that VINT would confuse readers. >>>>=20 >>>> Given that information, I imagine that the better path would be = revising the IANA instructions to operate on VINTs ("MUST be between = 0x81 and 0xFE") instead of VINT element data. This should be very = straightforward, as the encoding of VINTs results in contiguous ranges = that should be easy for IANA to deal with. >>>=20 >>> Thanks. I=E2=80=99ve updated the section to use the VINT value = rather than the decimal of the Element Data of that VINT. The commit is = at = https://github.com/cellar-wg/ebml-specification/pull/313/commits/948291dfd= defa02f857c83a7155519b980d9b2f6 = . >>>=20 >>> Dave Rice >>=20 >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar = >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar = --Apple-Mail=_C5A52BFB-504B-40D6-8328-8A17B129D7DA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Adam,

On Dec 17, 2019, at 9:17 PM, Dave Rice <dave@dericed.com> = wrote:

Hi Adam,

On Dec = 17, 2019, at 4:37 PM, Adam Roach <adam@nostrum.com> wrote:

Thanks for = your responses. Modulo the comment I left in github [1], these two PRs = (combined with the other PR you cited in an earlier message) address the = concerns I had. I'll clear my DISCUSS when a new version with these PRs = incorporated is put in the i-d = repository.

Thanks, this comment addresses your = github comment and references the other reserved one-octet Element ID = value: https://github.com/cellar-wg/ebml-specification/pull/313/commit= s/689cbdb6882bc409628774cfa2854ee981d3ce87.

Also, to be clear what hex ranges are = not valid for use as Element IDs, I restated these ranges specifically = within this section at https://github.com/cellar-wg/ebml-specification/pull/313/commit= s/06d1960f9208e58f56972870b72f2c95fe1d8fe3.

Version 16 at https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/16&= nbsp;is posted and should address all comments presented below. Thanks = much for your review.
Dave Rice


Dave


Thanks!

/a


____
[1] https://github.com/cel= lar-wg/ebml-specification/pull/313/commits/948291dfddefa02f857c83a7155519b= 980d9b2f6#r359039422

On 12/17/19 3:16 PM, Dave Rice wrote:


On Dec 17, 2019, at 2:56 PM, = Adam Roach <adam@nostrum.com> wrote:

Dave = --

Thanks for the quick response! The = issues that the PR addresses look good to me. Two comments inline = below.

On 12/17/19 9:27 AM, Dave Rice = wrote:


Abstract:

I see that the = Introduction has been revised to address Ben Campbell's AD
review comment regarding the document positioning itself as a = general-purpose
data format rather than being scoped to = its use in Matroska. The Abstract
still claims the much = broader scope -- please update it to match the reduced
scope= in the Introduction.


I didn't see a = response to this discuss point. See also the GENART review, which raises = this issue in some detail.

IIUC, this issue is = discussed in https://github.com/cellar-wg/ebml-specification/p= ull/311/files.

=C2=A717.1:

The VINT = Data value of one-octet Element IDs MUST be between 0x01 and
0x7E.  These items are valuable because they are short, = and need to
be used for commonly repeated elements. =  Values from 1 to 126 are to
be allocated according = to the "RFC Required" policy [RFC8126].

This, combined with the values that are being registered, is = extremely
confusing, and I don't know how IANA is supposed = to understand what's going on
without reading and = understanding the VINT bit encoding scheme (which is way
too= much to ask of them). This is because of the document-wide practice
of speaking of IDs in their VINT-encoded values (e.g., 0xBF) = instead of their
data values (e.g., 63 or 0x3F), including = in the initial registry in this section.

Please either revise the prose to speak in terms of = VINT-encoded values
(e.g., "MUST be between 0x81 and = 0xFE"), or revise the registration
tables to indicate the = VINT data values (e.g., "0x3F" for CRC-32).
I understand the request and the reason for it and am = interested in assessing rough consensus amongst the other authors before = making this change. These elements have been long-associated with these = particular vint expressions of the Element IDs, so I have some concerns = that a global change of Element ID reference from VINT to the Element = Data of that VINT would confuse readers.

Given that information, I imagine that the better path would = be revising the IANA instructions to operate on VINTs ("MUST be between = 0x81 and 0xFE") instead of VINT element data. This should be very = straightforward, as the encoding of VINTs results in contiguous ranges = that should be easy for IANA to deal with.

Thanks. I=E2=80=99ve updated the section to use the VINT = value rather than the decimal of the Element Data of that VINT. The = commit is at https://github.com/cellar-wg/ebml-specification/p= ull/313/commits/948291dfddefa02f857c83a7155519b980d9b2f6.

Dave = Rice


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

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

= --Apple-Mail=_C5A52BFB-504B-40D6-8328-8A17B129D7DA-- From nobody Sun Dec 22 13:07:03 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 768A812006D; Sun, 22 Dec 2019 13:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 I-H5erYunfuC; Sun, 22 Dec 2019 13:06:59 -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 E3DB612004D; Sun, 22 Dec 2019 13:06:59 -0800 (PST) Received: from cpe-104-162-94-162.nyc.res.rr.com ([104.162.94.162]:42756 helo=[10.0.1.6]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1ij8Bk-002EaN-Gs; Sun, 22 Dec 2019 15:51:01 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Dave Rice In-Reply-To: Date: Sun, 22 Dec 2019 15:50:55 -0500 Cc: Steven Villereal , draft-ietf-cellar-ebml@ietf.org, The IESG , cellar-chairs@ietf.org, Codec Encoding for LossLess Archiving and Realtime transmission Content-Transfer-Encoding: quoted-printable Message-Id: <92890066-7A1C-4F91-B519-4A0E57174C23@dericed.com> References: <157673433343.4965.3950484582725131414.idtracker@ietfa.amsl.com> <4B8173E7-1A15-44E2-98C3-C8D08DAE3F1D@dericed.com> To: Barry Leiba X-Mailer: Apple Mail (2.3601.0.10) X-OutGoing-Spam-Status: No, score=-2.1 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] Barry Leiba's No Objection on draft-ietf-cellar-ebml-15: (with COMMENT) 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, 22 Dec 2019 21:07:01 -0000 Hi Barry, > On Dec 20, 2019, at 4:40 PM, Barry Leiba = wrote: >=20 > Thanks, Dave, and I appreciate your addressing my concerns (and > accepting most of my text!). We're good on all the items you handled. Version 16 at https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/16 = is posted and addresses everything you listed below, except your = comments on Section 10 and Section 17.1. Nudges to Michael Richardson = and Steve Lhomme on these points. Dave > Barry >=20 > On Fri, Dec 20, 2019 at 4:08 PM Dave Rice wrote: >>=20 >> Hi Barry, >> Thanks for your review. Comments are below, including nudges to = Michael Richardson and Steve Lhomme for review. My comments below refer = to work that is reviewable within a pull request at = https://github.com/cellar-wg/ebml-specification/pull/316/files, though = in a few parts below I call for greater discussion. >>=20 >>> On Dec 19, 2019, at 12:45 AM, Barry Leiba via Datatracker = wrote: >>>=20 >>> Barry Leiba has entered the following ballot position for >>> draft-ietf-cellar-ebml-15: No Objection >>>=20 >>> When responding, please keep the subject line intact and reply to = all >>> email addresses included in the To and CC lines. (Feel free to cut = this >>> introductory paragraph, however.) >>>=20 >>>=20 >>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/ >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> This was a very difficult read: I found a lot of the document to be = convoluted >>> and hard to follow, and I considered balloting Abstain, as I=E2=80=99m= not sure that >>> DISCUSS is appropriate for my complaints, but I can=E2=80=99t really = say that I have >>> =E2=80=9Cno objection=E2=80=9D. In the end I decided to go with a = =E2=80=9CNo Objection=E2=80=9D ballot, to >>> call out the worst of the issues, and to hope that you will consider = the >>> changes I suggest and that others will follow the text more easily = than I could. >>>=20 >>> =E2=80=94 Section 4.1 =E2=80=94 >>>=20 >>> Each Variable Size Integer begins with a VINT_WIDTH which consists = of >>> zero or many zero-value bits. The count of consecutive zero-values >>> of the VINT_WIDTH plus one equals the length in octets of the >>> Variable Size Integer. For example, a Variable Size Integer that >>> starts with a VINT_WIDTH which contains zero consecutive zero-value >>> bits is one octet in length and a Variable Size Integer that starts >>> with one consecutive zero-value bit is two octets in length. The >>> VINT_WIDTH MUST only contain zero-value bits or be empty. >>>=20 >>> I found this very hard to follow, and had to read it several times = before I >>> understood what you=E2=80=99re getting at. I found things such as = =E2=80=9Czero or many >>> zero-value bits=E2=80=9D to be confusing. May I suggest alternative = text, which >>> describes the concept and then gets to the details?: >>>=20 >>> NEW >>> Each Variable Size Integer begins with a VINT_WIDTH followed by a = VINT_MARKER. >>> VINT_WIDTH is a sequence of zero or more bits of value 0, and is = terminated by >>> the VINT_MARKER, which is a single bit of value 1. The total number = of bits >>> (VINT_WIDTH and VINT_MARKER combined) is the number of octets of the = Variable >>> Size Integer. >>>=20 >>> Thus, the single bit =E2=80=9C1=E2=80=9D describes a Variable Size = Integer with a length of one >>> octet. The sequence of bits =E2=80=9C01=E2=80=9D describes a = Variable Size Integer with a >>> length of two octets. =E2=80=9C001=E2=80=9D describes a Variable = Size Integer with a length of >>> three octets, and so on, with each additional 0-bit adding one octet = to the >>> length of the Variable Size Integer. END >>>=20 >>> I, at least, find that easier to follow. Does it work for you? >>=20 >> Yes, I think that=E2=80=99s helpful. I changed the term =E2=80=98begins= =E2=80=99 and =E2=80=98describes=E2=80=99 to =E2=80=99starts=E2=80=99, = so there=E2=80=99s a little rewording but I have it now as: >>=20 >> NEW >> Each Variable Size Integer starts with a VINT\_WIDTH followed by a >> VINT\_MARKER. VINT\_WIDTH is a sequence of zero or more bits of value >> `0`, and is terminated by the VINT\_MARKER, which is a single bit of >> value `1`. The total number of bits (VINT\_WIDTH and VINT\_MARKER = combined) is the number of octets in length of the Variable Size = Integer. >>=20 >> Thus, the single bit `1` starts a Variable Size Integer with a length = of one octet. The sequence of bits `01` starts a Variable Size Integer = with a length of two octets. `001` starts a Variable Size Integer with a = length of three octets, and so on, with each additional 0-bit adding one = octet to the length of the Variable Size Integer. END >>=20 >>> For the next paragraph, which limits the length under various = circumstances, I >>> suggest putting it in terms of the number of octets in the integer, = rather than >>> the number of bits in the VINT_WIDTH, which might be better put into = Section >>> 4.3, rather than 4.1. Text such as, =E2=80=9CA Variable Size = Integer in an EBML Header >>> can be at most 4 octets long, except [...] , where it can be up to 8 = octets >>> long,=E2=80=9D is easier to understand than the text explaining = limits on the number of >>> bits in VINT_WIDTH. >>=20 >> I agree with your rewording but prefer to split this paragraph and = move it to section 8.1 which pertains to the =E2=80=9CEBML Header=E2=80=9D= and 8.2 which pertains to =E2=80=9CEBML Body=E2=80=9D. After rewording = the content is: >>=20 >> Added to 8.1 >> Elements within an EBML Header can be at most 4 octets long, except = for the EBML Element with Element Name EBML and Element ID `0x1A45DFA3` = (see (#ebml-element)), which can be up to 8 octets long. >>=20 >> Added to 8.2 >> Within the EBML Body, the maximum octet length allowed for any = Element ID is set by the EBMLMaxIDLength Element and the maximum octet = length allowed for any Element Data Size is set by the EBMLMaxSizeLength = Element. >>=20 >>> =E2=80=94 Section 4.4 =E2=80=94 >>> Table 2 and the text that introduces it would be better if they = talked about >>> the integer that=E2=80=99s represented (2), rather than the binary = value (0b10 in the >>> text and 10 in the table), considering that it is a Variable Size = INTEGER, yes? >>=20 >> That makes sense, I rewrote to focus on integer and parenthetically = mentioned the binary value since the VINT is expressed in binary (though = I added a hex representation as well). >>=20 >>> =E2=80=94 Section 6.2 =E2=80=94 >>>=20 >>> An EBML Element with an unknown Element Data Size >>> is referred to as an Unknown-Sized Element. A Master Element MAY = be >>> an Unknown-Sized Element; however an EBML Element that is not a >>> Master Element MUST NOT be an Unknown-Sized Element. Master = Elements >>> MUST NOT use an unknown size unless the unknownsizeallowed = attribute >>> of their EBML Schema is set to true (see Section 11.1.5.10). >>>=20 >>> This also seems confusing and perhaps contradictory because of how = it uses the >>> BCP 14 key words. May I suggest this, which neither uses nor needs = the key >>> words?: >>>=20 >>> NEW >>> An EBML Element with an unknown Element Data Size >>> is referred to as an Unknown-Sized Element. Only a Master Element >>> is allowed to be of unknown size, and it can only be so if the >>> unknownsizeallowed attribute of its EBML Schema is set to true >>> (see Section 11.1.5.10). >>> END >>=20 >> I updated the section as suggested in the pull request. >>=20 >>> =E2=80=94 Section 7.7 =E2=80=94 >>>=20 >>> The Master Element MAY also use an unknown length. >>>=20 >>> The =E2=80=9CMAY=E2=80=9D isn=E2=80=99t really correct, is it? = There are restrictions that make it not >>> entirely optional, as noted in the next sentence. I suggest not = using BCP 14 >>> here, and just saying, =E2=80=9CThe Master Element may be of unknown = length.=E2=80=9D >>=20 >> I reworded this sentence with the prior one to avoid the use of MAY. = The new paragraph is: >>=20 >> A Master Element MUST declare a length in octets from zero to VINTMAX = or be of unknown length. See (#element-data-size) for rules that apply = to elements of unknown length. >>=20 >>> The Master Element contains zero, one, or many other elements. >>>=20 >>> Does this mean anything more than the simpler, =E2=80=9CThe Master = Element contains >>> zero or more other elements.=E2=80=9D? As written, one tends to ask = what =E2=80=9Cmany=E2=80=9D means >>> here. >>=20 >> I updated the sentence as suggested in the pull request. >>=20 >>> =E2=80=94 Section 8.2 =E2=80=94 >>>=20 >>> The EBML Body MUST NOT contain any data that is not >>> part of an EBML Element. >>>=20 >>> Why is this repetition needed? Doesn=E2=80=99t the similar sentence = in Section 8 cover >>> this? >>=20 >> True. I removed this repetitive statement. >>=20 >>> =E2=80=94 Section 10 =E2=80=94 >>>=20 >>> An EBML Document handles 2 different versions: the version of the >>> EBML Header and the version of the EBML Body. Both versions are >>> meant to be backward compatible. >>>=20 >>> I don=E2=80=99t see how that=E2=80=99s practical, as, taken = strictly, it means you=E2=80=99ll never be >>> able to make a significant change that is not backward compatible, = so you=E2=80=99ll be >>> stuck with errors or limitations forever. Are you sure you won=E2=80=99= t need to allow >>> for incompatible versions at some point? >>=20 >> Nudging to Steve for review/comment. This part was written at: >> = https://github.com/cellar-wg/ebml-specification/commit/f9820d50d5279e11efb= b6cdd70dd8021b8a05dc9 >> = https://github.com/cellar-wg/ebml-specification/commit/10d359d637af02c15b1= c3191e260707adf0c29dc >>=20 >>> =E2=80=94 Section 17.1 =E2=80=94 >>>=20 >>> Values from 1 to 126 are to >>> be allocated according to the "RFC Required" policy [RFC8126]. >>>=20 >>> Why did you choose that policy? Are you aware that this allows = registrations >>> from non-IETF-stream RFCs? In particular, anyone can get an RFC = published in >>> the Independent stream with a very light level of review. Did you = consider >>> IETF Review, which requires an RFC in the IETF stream (including = Informational >>> and Experimental RFCs)? Or even Standards Action, which requires >>> standards-track RFCs? >>>=20 >>> The same comment applies to "matroska" and "webm" in Section 17.2. >>=20 >> Nudging to Michael, who recommended this policy here. >>=20 >> Best Regards, >> Dave Rice >>=20 >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Tue Dec 24 01:49:55 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 7FB0212012E for ; Tue, 24 Dec 2019 01:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] 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 GEsttRKWhYTq for ; Tue, 24 Dec 2019 01:49:46 -0800 (PST) Received: from mail-pg1-x544.google.com (mail-pg1-x544.google.com [IPv6:2607:f8b0:4864:20::544]) (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 A7FC9120D2E for ; Tue, 24 Dec 2019 01:49:46 -0800 (PST) Received: by mail-pg1-x544.google.com with SMTP id r11so10190504pgf.1 for ; Tue, 24 Dec 2019 01:49:46 -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=MBrmLjnPcvmXN6VhEiUMOmV/pxQIUNZqqZlh6Exglbk=; b=T2naKQn/Xz3M2b1q0LaNWJ/fvkiVDX89DLhu6VPmyvuep4m5F89VeQEpFdJlb7VLPs Swx2IL2JztgOowpu2u1hh+CbMThtmuwa7Pol1YqX+N/JwnftS5sq/3QiIUYVdjBAAZxB pbidzM5JI3D9/NFruEo73VSUfuuKL0S11PElSJamohuhXiTP18ubsdiomTIQ/B1vMIUM AMj/MkkU93KEji4t2TO4qfDyJuZxvZf3qCbJ905Sf/g6k97oViwAo9+t4Tgg86MqVGUR pZCrjje1Z5Tf4HxkRNccdrr9/tOuFu+YO5hv9JhUzKt2nRyqThBfQ/EvyA+Wk4sqdB/E Khcw== 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=MBrmLjnPcvmXN6VhEiUMOmV/pxQIUNZqqZlh6Exglbk=; b=mMo2QaAizDWptI3+EamaS28Q0cifwqKoDYJi6UuDUqKrfekbmvWz1s4vLaKazzuXRx oC7gw5n1fKrzjh5hY/UvLT0OOnGIK/RRtoRi4h3MHh/uujWQ+4vXH8YIF9RnGtcYCbIM MvSJH3ZF3o64gMFIAhHwPlC6zOikJaWzcSjTWUG8q0n8nWBYNrNImwfFkv2PB/ohJAep 0Xk2UrfKFwXoCZFw2pH1EIRnOfjlR4S8ERgv76dj2YNzyUC47BSgOEKCjWTnNjoXAUKW f7lDcYn+xLLw4SGUhvZL+8AzKsy8uy6gBRTc/Wi7RropTL6GsjCNdqhcCWsa6ifcWJ6b onqA== X-Gm-Message-State: APjAAAUh4NUduUabXxvdgQ9CtJe3iBj7loxc6w8rkAa9DOhST1NkeARW OXHCr/JvzYxMdQKlLZWBLbHTJDnFTFxibTgrQLv5Qg== X-Google-Smtp-Source: APXvYqyRhYc+f1Ul/Oezj0k71aNlNKMxhpq2Joj9+rQMgm5fvnKvi7LbtSuUokC24N5o2K2ZMfSnmFSPgFvTdF2oOTM= X-Received: by 2002:a63:213:: with SMTP id 19mr36745114pgc.160.1577180985875; Tue, 24 Dec 2019 01:49:45 -0800 (PST) MIME-Version: 1.0 References: <157673433343.4965.3950484582725131414.idtracker@ietfa.amsl.com> <4B8173E7-1A15-44E2-98C3-C8D08DAE3F1D@dericed.com> In-Reply-To: <4B8173E7-1A15-44E2-98C3-C8D08DAE3F1D@dericed.com> From: Steve Lhomme Date: Tue, 24 Dec 2019 10:49:33 +0100 Message-ID: To: Dave Rice Cc: Barry Leiba , draft-ietf-cellar-ebml@ietf.org, Steven Villereal , The IESG , cellar-chairs@ietf.org, 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] Barry Leiba's No Objection on draft-ietf-cellar-ebml-15: (with COMMENT) 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, 24 Dec 2019 09:49:49 -0000 Hi, Le ven. 20 d=C3=A9c. 2019 =C3=A0 22:08, Dave Rice a =C3= =A9crit : > > =E2=80=94 Section 10 =E2=80=94 > > > > An EBML Document handles 2 different versions: the version of the > > EBML Header and the version of the EBML Body. Both versions are > > meant to be backward compatible. > > > > I don=E2=80=99t see how that=E2=80=99s practical, as, taken strictly, i= t means you=E2=80=99ll never be > > able to make a significant change that is not backward compatible, so y= ou=E2=80=99ll be > > stuck with errors or limitations forever. Are you sure you won=E2=80= =99t need to allow > > for incompatible versions at some point? > > Nudging to Steve for review/comment. This part was written at: > https://github.com/cellar-wg/ebml-specification/commit/f9820d50d5279e11ef= bb6cdd70dd8021b8a05dc9 > https://github.com/cellar-wg/ebml-specification/commit/10d359d637af02c15b= 1c3191e260707adf0c29dc We are not entirely stuck with past issues. For example we can bump DocTypeReadVersion to mark that a file cannot be read by parsers meant for older versions of the file. That breaks backward compatibility for the reader. The old files should always be readable by new code, even if it means checking the DocType version to see how a value was implemented and may have changed. In 17 years of Matroska we hardly ever had such issues. We added SimpleBlock when the BlockGroup was deemed too big when unnecessary, but we always kept the old system in place. Forcing backward compatibility is not a big burden when adding things. It just means you have to pick a default value that matches the old files or not set a value that old parser may misinterpret. It also means you can't change defined values (in an enumerate) but just add some. In the end it forces extra thinking to make sure you don't break anything. But it's really not hard, EBML can be extended and tells old parsers what to do with unknown data. It's different than other formats with hardcoded sizes for structures or the size of structures not stored at all. > > =E2=80=94 Section 17.1 =E2=80=94 > > > > Values from 1 to 126 are to > > be allocated according to the "RFC Required" policy [RFC8126]. > > > > Why did you choose that policy? Are you aware that this allows registr= ations > > from non-IETF-stream RFCs? In particular, anyone can get an RFC publis= hed in > > the Independent stream with a very light level of review. Did you cons= ider > > IETF Review, which requires an RFC in the IETF stream (including Inform= ational > > and Experimental RFCs)? Or even Standards Action, which requires > > standards-track RFCs? > > For Matroska that's probably not an issue. It's OK if it's extended independently. For the IDs in the EBML Header I don't have a strong opinion. If someone defines extra data in the header that only them plan to use, why not. If they make it public through the IETF it's already a better step. The problem is if there's a collision between 2 independent extensions or a planned addition to the format and an extension. In this case the first published should have priority. There can be an issue if someone just comes and assign *all* the remaining one-octet IDs in their EBML extension and there's nothing left for the main EBML. Does the "light review" cover this kind of problem ? Otherwise we probably need to raise the level of scrutiny. > > The same comment applies to "matroska" and "webm" in Section 17.2. > > Nudging to Michael, who recommended this policy here. > > Best Regards, > Dave Rice > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Tue Dec 24 07:20:47 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 F08F2120119 for ; Tue, 24 Dec 2019 07:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] 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 S3zio6CEO9iG for ; Tue, 24 Dec 2019 07:20:38 -0800 (PST) Received: from mail-pj1-x1044.google.com (mail-pj1-x1044.google.com [IPv6:2607:f8b0:4864:20::1044]) (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 0EF01120111 for ; Tue, 24 Dec 2019 07:20:38 -0800 (PST) Received: by mail-pj1-x1044.google.com with SMTP id s7so1347554pjc.0 for ; Tue, 24 Dec 2019 07:20:38 -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=RNucmmKeli9IAq1dEzy6/52xD0+cqv7PePI09o8tuis=; b=xFrV2TSAd9pM6AlxFQGDDL3vER3EdtYjmKikRrMy/rJEKl3EFBvBsiW4ebB4tZV25N MovAxpYgkgy/HqF+zQ8Zbl8CkIBAHM5qK/uh2lcZdfbPPKNV0UmbWUULScMFr9RsqMW0 KrRrpOmUPxCwkb72dXmB9mbG9ybKFC9AUBDToYG3sRI0vL1cWMza8pLxpsRK5A7fkBen vdKo59gfAeD97Tp96Obq8pOBgulf1AYUKVYcsbDk/LxerLl6SD61reOrmKGyNuzAngqT 2+gz0OhtzCTeeOg3Z1TMx0tmu6an/pObrydOIIOjPvE1qB5DX0IqjB5tQxlTCDdH0mGC AzhA== 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=RNucmmKeli9IAq1dEzy6/52xD0+cqv7PePI09o8tuis=; b=eZUkJkls31D0PURKk93U8NQudY37eU23WTvsQ8Iu07jGW/jVMRW2/zk3P1NndrvsUK hi//wi6BMoZ9Enyx3Toog83AfWlP5Hkern3PC+vCyDJ9mBgQi/2sNFwTY/fF9NqqucLm O0LF3CMROX882xC6f2/ETF2+IfG3jcYPptmxefHC2sAI1WzgahCRB2wZbJQJegu+GBEV 5OSVWNjzgWmcQufYISTheZsDnaTE/f4yyuzC1bZPCt70i8qSLRoUksO9taXdMDppGfeB Mfrn8GWLyZeItXtJcDe+CGoIxcYR5mnyDP7OB6sbkcaQm/A/z0jJ9R86IdBlKJ88BYOM aeIg== X-Gm-Message-State: APjAAAXrQkCQxRO7qbxDDKvf5nSqNEWJPxvVa9Y19C1xuabLWw+eOeuQ Hhff/y5I1pUwK84jr4B/WTDXkc82thDp0D3jqQnksRVSdG8ZWg== X-Google-Smtp-Source: APXvYqyltYa4z6uDiW870xG7/aQjCDEreEZotRWVvFplTLdlWmrSbsOda9Hz3eHMOP4JsRFiOsyKlW8sE2mPTypIfPk= X-Received: by 2002:a17:90a:3ae3:: with SMTP id b90mr6699695pjc.62.1577200837199; Tue, 24 Dec 2019 07:20:37 -0800 (PST) MIME-Version: 1.0 References: <157676970970.27491.11040479061607849531.idtracker@ietfa.amsl.com> In-Reply-To: <157676970970.27491.11040479061607849531.idtracker@ietfa.amsl.com> From: Steve Lhomme Date: Tue, 24 Dec 2019 16:20:25 +0100 Message-ID: To: Benjamin Kaduk Cc: The IESG , Steven Villereal , draft-ietf-cellar-ebml@ietf.org, cellar-chairs@ietf.org, 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] Benjamin Kaduk's Discuss on draft-ietf-cellar-ebml-15: (with DISCUSS and COMMENT) 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, 24 Dec 2019 15:20:41 -0000 Hi Benjamin, Thanks a lot for your detailed review. Below are my comments and fixes: Le jeu. 19 d=C3=A9c. 2019 =C3=A0 16:35, Benjamin Kaduk via Datatracker a =C3=A9crit : > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-cellar-ebml-15: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Section 7.7 says: > > A Master Element MUST declare a length in octets from zero to > VINTMAX. The Master Element MAY also use an unknown length. See > Section 6 for rules that apply to elements of unknown length. > > but the second sentence contradicts the immediately prior MUST. We need > to resolve the internal inconsistency. I think this has been address with this change https://github.com/cellar-wg/ebml-specification/commit/a76fcb5a42ff543698d7= 292ee8a7752fe44ea1a0 "A Master Element MUST declare a length in octets from zero to VINTMAX or be of unknown length." > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I support Adam's Discuss regarding the Abstract. > > Section 2 > > "Parent Element": A relative term to describe the "Master Element" > which contains a specified element. For any specified "EBML Element" > that is not at "Root Level", the "Parent Element" refers to the > "Master Element" in which that "EBML Element" is contained. > > It sounds like this is intended to be "directly" or "immediately" > contained (in order to be unique), right? If not, then it sould be > ''refers to a "Master Element" in which [...]'' Added the word "directly"here https://github.com/cellar-wg/ebml-specification/pull/318 > Section 4.1 > > Each Variable Size Integer begins with a VINT_WIDTH which consists of > zero or many zero-value bits. The count of consecutive zero-values > of the VINT_WIDTH plus one equals the length in octets of the > Variable Size Integer. [...] > > Does the following attempted rewording change the meaning? Nope, maybe the meaning wasn't clear before. Hopefully it's better now. > % Each Variable Size Integer begins with a VINT_WIDTH which consists of > % zero or more bits set to zero. The length in octets of the entire > % Variable Size Integer is determined as one plus the number of > % consecutive bits set to zero. > > (I find the current formulation rather hard to parse.) > > Section 6.2 > > | "\root\level1\level2\" | Global Element cannot be | > | | assumed to have this path, | > | | while parsing "elt" it can | > | | only be a child of "elt" | > > Cannot be assumed by who/what? My brain is trying to parse this as just > "cannot assume this path". Rephrased to Global Element cannot be interpreted with this path, while parsing `elt` a Global Element can only be a child of `elt` https://github.com/cellar-wg/ebml-specification/pull/319 > Section 7.5 > > Should we say anything about termination of a UTF-8 string needing to > still result in valid UTF-8 (i.e., not insert NULs in the middle of a > codepoint)? We already say: A UTF-8 Element contains only a valid Unicode string as defined in [RFC3629], with an exception made for termination We also describe in Section 13 how NUL can be added at the end of strings. That's probably where we should mention it should still be a valid string. See this Pull Request https://github.com/cellar-wg/ebml-specification/pull/320 > Section 7.7 > > stored within Master Elements SHOULD only consist of EBML Elements > and SHOULD NOT contain any data that is not part of an EBML Element. > > When might this SHOULD (NOT) be violated? I think the idea is that a reader should not assume data are always correct/clean. Files can get damaged, in which case some parts of them may not look valid anymore. I'm OK with changing it to MUST NOT, since error recovery is described elsewhere. It would not be an error if junk data was considered OK. > Section 8.2 > > part of an EBML Element. This document defines precisely which EBML > Elements are to be used within the EBML Header, but does not name or > > (for EBMLVersion 1 only, right?) Yes, we kind of mention it here: The EBML Header of an EBML Document that uses an EBMLVersion of 1 MUST only contain EBML Elements that are defined as part of this document. > Section 11.1 > > Element; for example matroska or webm (see Section 11.2.6). The > DocType value for an EBML Document Type MUST be unique and > persistent. > > It might be appropriate to refer to Section 17.2 and/or the IANA > registry for DocType values, here. Added in https://github.com/cellar-wg/ebml-specification/pull/321 > 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 > > Does "as-is" imply some level of future-compatibility/extensibility for > when EBMLVersions other than "1" are defined? That's currently a grey area. If there was an EBML Header version 2 we can't assume the Matroska Schema to use it because we don't know if we would want modifications (as we already do) on top of it or not. So the EBML Schema should probably tell which EBML Header version it's based on. Probably a ebml=3D"1" attribute in the EBMLSchema element. See Pull Request https://github.com/cellar-wg/ebml-specification/pull/322 > Section 11.1.1 > > It's a little amusing that we bother to provide "default" attributes > when the "range" attribute uniquely determines the allowed value. > > Section 11.1.4 > > Each "" defines one EBML Element through the use of several > attributes that are defined in Section 11.1.3. EBML Schemas MAY > > I think this makes more sense as "Section 11.1.5". You're right. Fixed in https://github.com/cellar-wg/ebml-specification/pull= /323 > Section 11.1.5.2 > > This ABNF seems to only allow "direct" recursion where element > appears directly inside element , without any intermediate elements. > I assume that's the intent, though it would be surprising in a > general-purpose markup language. Are you referring to the EBMLPathAtomRecursive ? It still has a parent so it can be in another element as well. > In some cases the EBMLLastParent part of the path is an > EBMLGlobalParent. A path with a EBMLGlobalParent defines a > Section 11.3. Any path that starts with the EBMLFixedParent of the > > That second sentence doesn't parse. Fixed in https://github.com/cellar-wg/ebml-specification/commit/55876fc0c30= 6a54b08c79963a85d6aa3d4f9cfd6 > As an example, a "path" of "1*(\Segment\Info)" means the element Info > is found inside the Segment elements at least once and with no > maximum iteration. An element SeekHead with path > "0*2(\Segment\SeekHead)" may not be found at all in its Segment > parent, once or twice but no more than that. > > The way this text is written makes me want to interpret the path > occurence counts more like the (regular) minOccurs/maxOccurs element > attributes, as opposed to applying to the path components to get to the > specific element in question. In fact it's a remaining part of text from when the path did include minOccurs/maxOccurs . This is not the case anymore and this text will be removed: https://github.com/cellar-wg/ebml-specification/pull/324 > Section 11.1.9.2 > > minOccurs=3D"1" maxOccurs=3D"1"> > > A set of items. > > Is this "name" supposed to be "Item" or "Items"? It's a typo. Also the path should not contain the occurrences. Fixed in the #324 PR. > Section 11.1.10-11.1.12 > > I'm not sure I have a full understanding of how / are > used; perhaps a reference to the corresponding XML behavior is in order? Ping Dave Rice on that one. > Section 11.1.13-11.1.14 > > The usage seems underspecified. > > Section 11.1.15 > > > > > > Why do we include this commented-out snippet? It's an include of a XSD file that is actually usable to validate an EBML Schema. This commented out code is there because we should fix it to parse properly the path values. Should it be removed ? > > > > Don't we effectively set default values for these two in the prose > description? "If the unknownsizeallowed attribute is not used then that EBML Element is not allowed to use an unknown Element Data Size." I guess we could use false as the default value. "If the recurring attribute is not present then the EBML Element is not an Identically Recurring Element." Same here See https://github.com/cellar-wg/ebml-specification/pull/325 > Section 11.1.16 > > Identically Recurring Elements SHOULD include a CRC-32 Element as a > Child Element; this is especially recommended when EBML is used for > long-term storage or transmission. If a Parent Element contains more > > I'm not sure if the "long-term" is intended to also bind as "long-term > transmission" (though I'm not sure what it would mean in that case). > It's also not entirely clear what kinds of transmission would benefit > from this, as reliable media presumably don't need redundancy for > reliability, but unreliable media can't really be used to carry EBML > without some framing requirements to know when elements start. Actually, as long as you have the "packets" in the right order you can use the EBML stream. You can also use it if you're missing some packets. The Checksum can help determine if the data are valid or not, even if the underlying transport loses some bits. It could technically be used as-is as protocol on top of IP, like TCP or UDP. > Section 11.1.18 > > If a Mandatory EBML Element has no default value declared by an EBML > Schema and its Parent Element is present then the EBML Element MUST > be present as well. If a Mandatory EBML Element has a default value > declared by an EBML Schema and its Parent Element is present and the > value of the EBML Element is NOT equal to the declared default value > then the EBML Element MUST be present. > > This seems almost tautological, in that how would an EBML Element have a > value if it was not present? (The following paragraph that talks about > when to write such elements, does make more sense.) The difference here is whether the element has a value and is present. If you read the negative of that sentence, an EBML Element MAY NOT be present if it has the default value even if it's mandatory. > Section 11.3.1 > > path: "*1((1*\)\CRC-32)" > > Using backslash as both an escape character and a path separator makes > my head hurt, and I did not have enough caffeine yet this morning to > figure it out. All the pathes actually have the remaining minOccurs/maxOccurs that were removed recently. I'll remove them via #324 After that the two global elements (which used to be tricky to read even for a trained eye) do not match the ABNF. Which also adds extra parenthesis a little too much. I created an issue to fix once #324 is merge https://github.com/cellar-wg/ebml-specification/issues/326 > 8.1.1.6.2 of [ITU.V42.1994], with initial value of 0xFFFFFFFF. The > CRC value MUST be computed on a little endian bitstream and MUST use > little endian storage. > > bitstream or bytestream? Should be bytestream. https://github.com/cellar-wg/ebml-specification/pull/327 > Section 12 > > If a Master Element contains a CRC-32 Element that doesn't validate, > then the EBML Reader MAY ignore all contained data except for > Descendant Elements that contain their own valid CRC-32 Element. > > Ignoring only part of the known questionable content could have > significant security considerations, if (e.g.) security-relevant > restrictions are in the garbled part of the document but the sensitive > content has a (valid) redundant CRC. That's why it's a MAY. If a Matroska Segment has a CRC and each frame in it has a CRC. If the top CRC is invalid, we can still use some of the frames that have a valid CRC. It's not a requirement but a possibility. > [review terminated early] > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Tue Dec 24 07:34: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 9AA2F120120 for ; Tue, 24 Dec 2019 07:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=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 E4VhZO0-rlYT for ; Tue, 24 Dec 2019 07:34:23 -0800 (PST) Received: from mail-pg1-x542.google.com (mail-pg1-x542.google.com [IPv6:2607:f8b0:4864:20::542]) (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 E90951200B8 for ; Tue, 24 Dec 2019 07:34:22 -0800 (PST) Received: by mail-pg1-x542.google.com with SMTP id r11so10565841pgf.1 for ; Tue, 24 Dec 2019 07:34:22 -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=9Yd86uNoaGdur5lLIOh1IC5vju5yCQzrUYjRIlq/ChE=; b=iHLLvzcjTHz8kXThU4T/ym4dOcor06iXnzS+7mHxHJ6gNu1KLr7VgbVUIaZGkIONSZ 1Oa3QqhnY8ScpYOzZBO804vPeVzJfzBjKkUKAa4ybqA72gt/+Rd5C+TCdZUJqeRPqid0 gT5Cp0TdhwvQwpiOigdjIVW6Pjg2+JB9lP68U228OxoAa+Y7i6A+3iSP+F7D28aaQTQ0 VD7LWTJg2/8RaLvAzJ2/oB5ailk6GPgdvQQAg1yCOCDOneTFXFdXg1Di72o/jqeJX7XI EgVPzBZtqsLnEWulwG7BDm+Si3BRWIUC1IUxIVfcCJrUHCYOWg/c9MmCD3QEODyblICZ l0cA== 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=9Yd86uNoaGdur5lLIOh1IC5vju5yCQzrUYjRIlq/ChE=; b=Lo5YsMQokntknsvi1qlQoFZRAzJSt0s2Pc0UbubSkr3QP24U5Myr7GnaLPJs+QmlLL wjIPeBbpQxVZ4xOyPBW2rpBo0yKuQd1CbvbN2sTsoxB/VSiZXgWGpr4dHPvhHYvLPUJb BmRdy9874sXtHB8sS5tLOVC0ih1v/bOujGseKrHNtx1ERgE68YWn7Y3kzxxKoIcOcRrZ 4vQDflj4ZIbqd2L/h9jrfjk1C9/h6ovNifFw+WVmFKU4WU7MvahM1l2T+vF2MwZFV+9m jqFXt/bNEBoH0I0MyJZA29QsGiU3zB7/4XLSU2QDDrmbn7DNGRzyuJZMwVVPInVVwbMY l9Ng== X-Gm-Message-State: APjAAAXkSFgU/AMyX/CY23t2TI9hFCym2esD40wJmqjDsvX2SIogIYjR LJ8X198Q5/QSCAAHMnqMNYK2AnkIrtTrO7LAEliq7A== X-Google-Smtp-Source: APXvYqxmSQEx68/YdOLn88bE9Dy3ewoOKsEJs9AkYNBEDVPsS+s0gKqNrLJ0EtWgkEbpYZp5JNiEUj53aPC7knxnNR4= X-Received: by 2002:a62:14cc:: with SMTP id 195mr31309532pfu.160.1577201662481; Tue, 24 Dec 2019 07:34:22 -0800 (PST) MIME-Version: 1.0 References: <157676970970.27491.11040479061607849531.idtracker@ietfa.amsl.com> <20191219213220.GM81833@kduck.mit.edu> In-Reply-To: <20191219213220.GM81833@kduck.mit.edu> From: Steve Lhomme Date: Tue, 24 Dec 2019 16:34:10 +0100 Message-ID: To: Benjamin Kaduk Cc: The IESG , Steven Villereal , draft-ietf-cellar-ebml@ietf.org, cellar-chairs@ietf.org, 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] Benjamin Kaduk's Discuss on draft-ietf-cellar-ebml-15: (with DISCUSS and COMMENT) 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, 24 Dec 2019 15:34:26 -0000 Le jeu. 19 d=C3=A9c. 2019 =C3=A0 22:32, Benjamin Kaduk a = =C3=A9crit : > > On Thu, Dec 19, 2019 at 07:35:09AM -0800, Benjamin Kaduk via Datatracker = wrote: > > Benjamin Kaduk has entered the following ballot position for > > > > [review terminated early] > > It turns out there would only have been a little more if it hadn't > terminated early: > > Section 14.1.2 > > The same value for Element Data Size MAY be written in variable > lengths, so for minor reductions in octet length the Element Data > Size MAY be written to a longer octet length to fill the freed space. > > Is "reductions" the right word, here? Yes, it's the data that is reduced, and thus the storage of the size value that is increased. I rewrote the paragraph. Hopefully it's clearer https://github.com/cellar-wg/ebml-specification/pull/328 > Section 16 > > Side channel attacks could exploit: > > The following list of items do all involve potential side channels, but > there's not a whole lot of clarity on what exactly is being attacked. Mostly on the data parser which could be made slow or not able to use the data by misleading or bogus files. > -Ben > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Tue Dec 24 10:42: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 817F01208AA; Tue, 24 Dec 2019 10:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 8uknWGvEjN5f; Tue, 24 Dec 2019 10:41:56 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 7E11F120894; Tue, 24 Dec 2019 10:41:54 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBOIfm5R018456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Dec 2019 13:41:50 -0500 Date: Tue, 24 Dec 2019 10:41:47 -0800 From: Benjamin Kaduk To: Steve Lhomme Cc: The IESG , Steven Villereal , draft-ietf-cellar-ebml@ietf.org, cellar-chairs@ietf.org, Codec Encoding for LossLess Archiving and Realtime transmission Message-ID: <20191224184147.GP35479@kduck.mit.edu> References: <157676970970.27491.11040479061607849531.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Cellar] Benjamin Kaduk's Discuss on draft-ietf-cellar-ebml-15: (with DISCUSS and COMMENT) 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, 24 Dec 2019 18:42:00 -0000 On Tue, Dec 24, 2019 at 04:20:25PM +0100, Steve Lhomme wrote: > Hi Benjamin, > > Thanks a lot for your detailed review. Below are my comments and fixes: > > Le jeu. 19 dc. 2019 16:35, Benjamin Kaduk via Datatracker > a crit : > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-cellar-ebml-15: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Section 7.7 says: > > > > A Master Element MUST declare a length in octets from zero to > > VINTMAX. The Master Element MAY also use an unknown length. See > > Section 6 for rules that apply to elements of unknown length. > > > > but the second sentence contradicts the immediately prior MUST. We need > > to resolve the internal inconsistency. > > I think this has been address with this change > https://github.com/cellar-wg/ebml-specification/commit/a76fcb5a42ff543698d7292ee8a7752fe44ea1a0 > > "A Master Element MUST declare a length in octets from zero to VINTMAX > or be of unknown length." I agree, and have already updated my ballot position in the datatracker to reflect just the non-blocking COMMENTs that we discuss (sic) below. > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I support Adam's Discuss regarding the Abstract. > > > > Section 2 > > > > "Parent Element": A relative term to describe the "Master Element" > > which contains a specified element. For any specified "EBML Element" > > that is not at "Root Level", the "Parent Element" refers to the > > "Master Element" in which that "EBML Element" is contained. > > > > It sounds like this is intended to be "directly" or "immediately" > > contained (in order to be unique), right? If not, then it sould be > > ''refers to a "Master Element" in which [...]'' > > Added the word "directly"here > https://github.com/cellar-wg/ebml-specification/pull/318 Thanks. I think that all three uses of "parent" in the non-table parts of Section 6.2 are consistent with this definition and would not need a broader definition (e.g., "ancestor element"), but please double check. > > Section 4.1 > > > > Each Variable Size Integer begins with a VINT_WIDTH which consists of > > zero or many zero-value bits. The count of consecutive zero-values > > of the VINT_WIDTH plus one equals the length in octets of the > > Variable Size Integer. [...] > > > > Does the following attempted rewording change the meaning? > > Nope, maybe the meaning wasn't clear before. Hopefully it's better now. I think Barry had some good suggestions here as well, so I think it's better, yes. > > % Each Variable Size Integer begins with a VINT_WIDTH which consists of > > % zero or more bits set to zero. The length in octets of the entire > > % Variable Size Integer is determined as one plus the number of > > % consecutive bits set to zero. > > > > (I find the current formulation rather hard to parse.) > > > > Section 6.2 > > > > | "\root\level1\level2\" | Global Element cannot be | > > | | assumed to have this path, | > > | | while parsing "elt" it can | > > | | only be a child of "elt" | > > > > Cannot be assumed by who/what? My brain is trying to parse this as just > > "cannot assume this path". > > Rephrased to > Global Element cannot be interpreted with this path, while parsing > `elt` a Global Element can only be a child of `elt` > > https://github.com/cellar-wg/ebml-specification/pull/319 > > > Section 7.5 > > > > Should we say anything about termination of a UTF-8 string needing to > > still result in valid UTF-8 (i.e., not insert NULs in the middle of a > > codepoint)? > > We already say: > > A UTF-8 Element contains only a valid Unicode string as defined in > [RFC3629], with an exception made for termination > > We also describe in Section 13 how NUL can be added at the end of > strings. That's probably where we should mention it should still be a > valid string. See this Pull Request > https://github.com/cellar-wg/ebml-specification/pull/320 (I'm leaving minor comments on github; the general trend of these is looking good.) > > Section 7.7 > > > > stored within Master Elements SHOULD only consist of EBML Elements > > and SHOULD NOT contain any data that is not part of an EBML Element. > > > > When might this SHOULD (NOT) be violated? > > I think the idea is that a reader should not assume data are always > correct/clean. Files can get damaged, in which case some parts of them > may not look valid anymore. > I'm OK with changing it to MUST NOT, since error recovery is described > elsewhere. It would not be an error if junk data was considered OK. > > > Section 8.2 > > > > part of an EBML Element. This document defines precisely which EBML > > Elements are to be used within the EBML Header, but does not name or > > > > (for EBMLVersion 1 only, right?) > > Yes, we kind of mention it here: > The EBML Header of an EBML Document that uses an EBMLVersion of 1 MUST > only contain EBML Elements that are defined as part of this document. So it does, sorry for missing the forest for the trees. > > Section 11.1 > > > > Element; for example matroska or webm (see Section 11.2.6). The > > DocType value for an EBML Document Type MUST be unique and > > persistent. > > > > It might be appropriate to refer to Section 17.2 and/or the IANA > > registry for DocType values, here. > > Added in https://github.com/cellar-wg/ebml-specification/pull/321 > > > 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 > > > > Does "as-is" imply some level of future-compatibility/extensibility for > > when EBMLVersions other than "1" are defined? > > That's currently a grey area. If there was an EBML Header version 2 we > can't assume the Matroska Schema to use it because we don't know if we > would want modifications (as we already do) on top of it or not. > > So the EBML Schema should probably tell which EBML Header version it's > based on. Probably a ebml="1" attribute in the EBMLSchema element. > See Pull Request https://github.com/cellar-wg/ebml-specification/pull/322 That seems reasonable. > > Section 11.1.1 > > > > It's a little amusing that we bother to provide "default" attributes > > when the "range" attribute uniquely determines the allowed value. > > > > Section 11.1.4 > > > > Each "" defines one EBML Element through the use of several > > attributes that are defined in Section 11.1.3. EBML Schemas MAY > > > > I think this makes more sense as "Section 11.1.5". > > You're right. Fixed in https://github.com/cellar-wg/ebml-specification/pull/323 > > > Section 11.1.5.2 > > > > This ABNF seems to only allow "direct" recursion where element > > appears directly inside element , without any intermediate elements. > > I assume that's the intent, though it would be surprising in a > > general-purpose markup language. > > Are you referring to the EBMLPathAtomRecursive ? It still has a parent > so it can be in another element as well. The EBMLPathAtomRecursive construction, yes. It looks like the stuff inside the (1*()) is limited to a single EBMLPathAtom, and if the atom is only one path component, then there is no opportunity to do x\y\x\y\x\y\... as "co-recursion". But maybe I am misreading things. Regardless, I am not proposing any change to the document, so this discussion would just be for my own edification. > > In some cases the EBMLLastParent part of the path is an > > EBMLGlobalParent. A path with a EBMLGlobalParent defines a > > Section 11.3. Any path that starts with the EBMLFixedParent of the > > > > That second sentence doesn't parse. > > Fixed in https://github.com/cellar-wg/ebml-specification/commit/55876fc0c306a54b08c79963a85d6aa3d4f9cfd6 > > > As an example, a "path" of "1*(\Segment\Info)" means the element Info > > is found inside the Segment elements at least once and with no > > maximum iteration. An element SeekHead with path > > "0*2(\Segment\SeekHead)" may not be found at all in its Segment > > parent, once or twice but no more than that. > > > > The way this text is written makes me want to interpret the path > > occurence counts more like the (regular) minOccurs/maxOccurs element > > attributes, as opposed to applying to the path components to get to the > > specific element in question. > > In fact it's a remaining part of text from when the path did include > minOccurs/maxOccurs . This is not the case anymore and this text will > be removed: > https://github.com/cellar-wg/ebml-specification/pull/324 Oh! That makes me feel less bad about being confused by it; thanks. > > Section 11.1.9.2 > > > > > minOccurs="1" maxOccurs="1"> > > > > A set of items. > > > > Is this "name" supposed to be "Item" or "Items"? > > It's a typo. Also the path should not contain the occurrences. Fixed > in the #324 PR. > > > Section 11.1.10-11.1.12 > > > > I'm not sure I have a full understanding of how / are > > used; perhaps a reference to the corresponding XML behavior is in order? > > Ping Dave Rice on that one. > > > Section 11.1.13-11.1.14 > > > > The usage seems underspecified. > > > > Section 11.1.15 > > > > > > > > > > > > Why do we include this commented-out snippet? > > It's an include of a XSD file that is actually usable to validate an > EBML Schema. This commented out code is there because we should fix it > to parse properly the path values. Should it be removed ? My preference would be to not include it in the immutable RFC, but I defer to Alexey. > > > > > > > > Don't we effectively set default values for these two in the prose > > description? > > "If the unknownsizeallowed attribute is not used then that EBML > Element is not allowed to use an unknown Element Data Size." > I guess we could use false as the default value. > > "If the recurring attribute is not present then the EBML Element is > not an Identically Recurring Element." > Same here > > See https://github.com/cellar-wg/ebml-specification/pull/325 > > > Section 11.1.16 > > > > Identically Recurring Elements SHOULD include a CRC-32 Element as a > > Child Element; this is especially recommended when EBML is used for > > long-term storage or transmission. If a Parent Element contains more > > > > I'm not sure if the "long-term" is intended to also bind as "long-term > > transmission" (though I'm not sure what it would mean in that case). > > It's also not entirely clear what kinds of transmission would benefit > > from this, as reliable media presumably don't need redundancy for > > reliability, but unreliable media can't really be used to carry EBML > > without some framing requirements to know when elements start. > > Actually, as long as you have the "packets" in the right order you can > use the EBML stream. You can also use it if you're missing some > packets. The Checksum can help determine if the data are valid or not, > even if the underlying transport loses some bits. It could technically > be used as-is as protocol on top of IP, like TCP or UDP. Huh, interesting. Though I thought that UDP (and IP itself) didn't guarantee in-order delivery. > > Section 11.1.18 > > > > If a Mandatory EBML Element has no default value declared by an EBML > > Schema and its Parent Element is present then the EBML Element MUST > > be present as well. If a Mandatory EBML Element has a default value > > declared by an EBML Schema and its Parent Element is present and the > > value of the EBML Element is NOT equal to the declared default value > > then the EBML Element MUST be present. > > > > This seems almost tautological, in that how would an EBML Element have a > > value if it was not present? (The following paragraph that talks about > > when to write such elements, does make more sense.) > > The difference here is whether the element has a value and is present. > If you read the negative of that sentence, an EBML Element MAY NOT be > present if it has the default value even if it's mandatory. Ah, I see it now; thanks. > > Section 11.3.1 > > > > path: "*1((1*\)\CRC-32)" > > > > Using backslash as both an escape character and a path separator makes > > my head hurt, and I did not have enough caffeine yet this morning to > > figure it out. > > All the pathes actually have the remaining minOccurs/maxOccurs that > were removed recently. I'll remove them via #324 > > After that the two global elements (which used to be tricky to read > even for a trained eye) do not match the ABNF. Which also adds extra > parenthesis a little too much. I created an issue to fix once #324 is > merge https://github.com/cellar-wg/ebml-specification/issues/326 Thanks :) > > 8.1.1.6.2 of [ITU.V42.1994], with initial value of 0xFFFFFFFF. The > > CRC value MUST be computed on a little endian bitstream and MUST use > > little endian storage. > > > > bitstream or bytestream? > > Should be bytestream. > https://github.com/cellar-wg/ebml-specification/pull/327 > > > Section 12 > > > > If a Master Element contains a CRC-32 Element that doesn't validate, > > then the EBML Reader MAY ignore all contained data except for > > Descendant Elements that contain their own valid CRC-32 Element. > > > > Ignoring only part of the known questionable content could have > > significant security considerations, if (e.g.) security-relevant > > restrictions are in the garbled part of the document but the sensitive > > content has a (valid) redundant CRC. > > That's why it's a MAY. If a Matroska Segment has a CRC and each frame > in it has a CRC. If the top CRC is invalid, we can still use some of > the frames that have a valid CRC. It's not a requirement but a > possibility. I agree that it's an implementation choice for whether or not to do this, but please add some text in the Security Considerations that mentions the risk of handling incomplete-but-interdependent data when implementations choose to do this sort of thing. Thanks for all the updates! -Ben From nobody Wed Dec 25 05:13:22 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 8C48312084A for ; Wed, 25 Dec 2019 05:13:20 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.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 omvK6pWpY8cg for ; Wed, 25 Dec 2019 05:13:17 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 9B10712007C for ; Wed, 25 Dec 2019 05:13:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1577279593; bh=aYofbf/7I9m3HV3Yx3TD7v6ODrbp66Q+VVAfiTHupOI=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=KzblbGA7WWYNaJuUksranBCBeEHJ/cRBbr23Ycpzrj513dksVyhO/p6+3rm2sp/cK 0k571foT7EV0iQ7KewnHdaIvAZLM+J8+bFehZeIxcD9BHDS1+2U8uLobjPEzJcuFpc 7OmGHXSqGBCP9VnLdN9TQypoJ16nkazkxfVVGrEw= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.2.101] ([93.242.204.134]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MatRT-1jKpGd3YXT-00cUMS for ; Wed, 25 Dec 2019 14:13:13 +0100 To: cellar@ietf.org References: <157676970970.27491.11040479061607849531.idtracker@ietfa.amsl.com> <20191224184147.GP35479@kduck.mit.edu> From: hubblec4 Message-ID: <88ed13cf-c9d6-5f60-f4bf-23eeb6163e4a@gmx.ch> Date: Wed, 25 Dec 2019 14:13:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20191224184147.GP35479@kduck.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:e5ii71nFaJvZjT/29zt0v2OWEynbfMuq7RMWOFXXVvUm3pV7nrd nqZC4enof20kblJCokT9uA+R4Ukfu7oxopbpEoGCRT2BPnMOiiHzemV50lhJbbnqzU+eRbF TkAL0uuPtXhBSedkwl91gyHrjbZR+lB41lqrtfregWARLaQrB6la14WyEzja/iFyalfgw1r FtWRIMYK+J+vEZVnBQxDQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:lp4hF3HgiSE=:z3LWMJQtUMRDdpAtyqtFWe trC2y1rlD9mBI+khziflbOEHt47zsILwwYs31Fvhl5mMbGzIjG8frhDtZhH49Lcv7lpB2d1WM +BYfsa3PZRypI8XkjKvdezBKZXVJ7O5vZlICl8vb7QHbTJ/LDRN0HMV3Ej3Od8su4BisZk01X JsuwV5LJvrCugx/mhoEULeIqVtqiRrj6hoFloClZT0xbY6k23dV3FW2BhpMp0ILKvbIAJSfhI /pnEAg3bmvsFNGGG/MR8qDiOiwCwHUAA3eV7bfLA+/4er3UMgAEZBhEYugaES9OukKIU8ljN4 Eov50ZV0qz4itjm30pnqU2ALiyjoL2821iedZ+Lpnm4rb8p8aFyMg7q/p4VqeimtdbL7UA4rH 0gZfH3A4102Da90SrERXnI/11TBbFJ4xkiX/yZYi/NhZRHHWUGZ0hz0BWZ6zUaalJ8qo8APoS LtS6NHxWhqPTOOw5LWtU6qaAqRvjQFWCUvngdacdOm5QsYqMTUTSfQyjXoeg+MOiwe+yrrIiJ QuXDeEJx6bGnQwy/8uD1owFSLoZZjGGF170N27fH2dtVEq0CuXgC+rJR80ODfNFqa/GA8MhaY qp1vaFSWLvubKBZ1IRSQu1lzOsQ3lLP/8eH0/3almWEhO9Oy6hTe9+pEoLhe5mlIuEfVaz7Id EGkZYn5qSxrUkedtsZnDLqH6trmuaU1+1LM0mcLauJXKs0vV3OLWYY5gbGQE8Zu5Zl5x76fm2 RRB8NvQkEWj2AuNacDRkp24UyLFRdQjiL+JeaTlgTaE8ZL28W4/J5zyBh9dldqfvjoGn3Ivx3 GiR6Vv2F/T12W8PnodT/8NudEsmIYy2iCkDXpfl+EP3vBcmanSL6p3XcwHHHZ1FOcy9WWkJg6 vOk51GubPdl+bR1ikMej3sGZZpE3Ph+AzhEubY21t82+nnj/BI8gQePARjIlXQgh3r/OGlq9/ TGCdGsO7SGrLcL9IERaQsiQzIP5M5RQt/zwyPwlWFAPEUlR8ANcuKd/My6LMWdiUQL7K/R1Sv vKr4XYhtoEYEKZjdMswgeQLK8Qx9jgWZGjbNkqr4eTSo5gBeyNt6aeagvL2jcNl4qMilq3+r+ 7JzriSj7mZTMpWqdQ5WuTFsm9zKKFziG+uNQMJLIYUeqx18rLvs075er9z3gfFHYb6Pgi57gx 7WguSMVSc8/8AqzxvU/BsR79mm7rkUCacIvRcr/+/NpYTmUPznyhiLBBSSTinZmMNyK5d8uxQ fPnSbGHCxP+T3oIFrQFpo63UnaZXlWEWMsAnfp2nCHgTqjr+0SeRzircj8/0= Archived-At: Subject: Re: [Cellar] Benjamin Kaduk's Discuss on draft-ietf-cellar-ebml-15: (with DISCUSS and COMMENT) 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, 25 Dec 2019 13:13:20 -0000 Hello Am 24.12.2019 um 19:41 schrieb Benjamin Kaduk: > On Tue, Dec 24, 2019 at 04:20:25PM +0100, Steve Lhomme wrote: >> Hi Benjamin, >> >> Thanks a lot for your detailed review. Below are my comments and fixes: >> >> Le jeu. 19 d=C3=A9c. 2019 =C3=A0 16:35, Benjamin Kaduk via Datatracker >> a =C3=A9crit : >>> Benjamin Kaduk has entered the following ballot position for >>> draft-ietf-cellar-ebml-15: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut thi= s >>> introductory paragraph, however.) >>> >>> >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.h= tml >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> Section 7.7 says: >>> >>> A Master Element MUST declare a length in octets from zero to >>> VINTMAX. The Master Element MAY also use an unknown length. See >>> Section 6 for rules that apply to elements of unknown length. >>> >>> but the second sentence contradicts the immediately prior MUST. We ne= ed >>> to resolve the internal inconsistency. >> I think this has been address with this change >> https://github.com/cellar-wg/ebml-specification/commit/a76fcb5a42ff5436= 98d7292ee8a7752fe44ea1a0 >> >> "A Master Element MUST declare a length in octets from zero to VINTMAX >> or be of unknown length." > I agree, and have already updated my ballot position in the datatracker = to > reflect just the non-blocking COMMENTs that we discuss (sic) below. > >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> I support Adam's Discuss regarding the Abstract. >>> >>> Section 2 >>> >>> "Parent Element": A relative term to describe the "Master Element" >>> which contains a specified element. For any specified "EBML Eleme= nt" >>> that is not at "Root Level", the "Parent Element" refers to the >>> "Master Element" in which that "EBML Element" is contained. >>> >>> It sounds like this is intended to be "directly" or "immediately" >>> contained (in order to be unique), right? If not, then it sould be >>> ''refers to a "Master Element" in which [...]'' >> Added the word "directly"here >> https://github.com/cellar-wg/ebml-specification/pull/318 > Thanks. I think that all three uses of "parent" in the non-table parts = of > Section 6.2 are consistent with this definition and would not need a > broader definition (e.g., "ancestor element"), but please double check. > >>> Section 4.1 >>> >>> Each Variable Size Integer begins with a VINT_WIDTH which consists= of >>> zero or many zero-value bits. The count of consecutive zero-value= s >>> of the VINT_WIDTH plus one equals the length in octets of the >>> Variable Size Integer. [...] >>> >>> Does the following attempted rewording change the meaning? >> Nope, maybe the meaning wasn't clear before. Hopefully it's better now. > I think Barry had some good suggestions here as well, so I think it's > better, yes. Some ideas from me: As I started to write my own Matroska parser it was not easy to understand what is mean with all this and how I have to do. After many reading and try, I understood it. For me is the VINT_MARKER the key. The position of the VINT_MARKER is the VINT_WIDTH. Lazarus(my programming language) use a function "pos()", it gives me the position of the first occurence of what I want. In our case the VINT_MARKER is a "1". VINT_WIDTH =3D pos(FIRST-BYTE-OF-VINT , VINT_MARKER); Thats all what I have to code. No counting zero values, no adding one to counted zero values. > >>> % Each Variable Size Integer begins with a VINT_WIDTH which consists = of >>> % zero or more bits set to zero. The length in octets of the entire >>> % Variable Size Integer is determined as one plus the number of >>> % consecutive bits set to zero. >>> >>> (I find the current formulation rather hard to parse.) >>> >>> Section 6.2 >>> >>> | "\root\level1\level2\" | Global Element cannot be = | >>> | | assumed to have this path,= | >>> | | while parsing "elt" it can= | >>> | | only be a child of "elt" = | >>> >>> Cannot be assumed by who/what? My brain is trying to parse this as ju= st >>> "cannot assume this path". >> Rephrased to >> Global Element cannot be interpreted with this path, while parsing >> `elt` a Global Element can only be a child of `elt` >> >> https://github.com/cellar-wg/ebml-specification/pull/319 >> >>> Section 7.5 >>> >>> Should we say anything about termination of a UTF-8 string needing to >>> still result in valid UTF-8 (i.e., not insert NULs in the middle of a >>> codepoint)? >> We already say: >> >> A UTF-8 Element contains only a valid Unicode string as defined in >> [RFC3629], with an exception made for termination >> >> We also describe in Section 13 how NUL can be added at the end of >> strings. That's probably where we should mention it should still be a >> valid string. See this Pull Request >> https://github.com/cellar-wg/ebml-specification/pull/320 > (I'm leaving minor comments on github; the general trend of these is > looking good.) > >>> Section 7.7 >>> >>> stored within Master Elements SHOULD only consist of EBML Elements >>> and SHOULD NOT contain any data that is not part of an EBML Elemen= t. >>> >>> When might this SHOULD (NOT) be violated? >> I think the idea is that a reader should not assume data are always >> correct/clean. Files can get damaged, in which case some parts of them >> may not look valid anymore. >> I'm OK with changing it to MUST NOT, since error recovery is described >> elsewhere. It would not be an error if junk data was considered OK. >> >>> Section 8.2 >>> >>> part of an EBML Element. This document defines precisely which EB= ML >>> Elements are to be used within the EBML Header, but does not name = or >>> >>> (for EBMLVersion 1 only, right?) >> Yes, we kind of mention it here: >> The EBML Header of an EBML Document that uses an EBMLVersion of 1 MUST >> only contain EBML Elements that are defined as part of this document. > So it does, sorry for missing the forest for the trees. > >>> Section 11.1 >>> >>> Element; for example matroska or webm (see Section 11.2.6). The >>> DocType value for an EBML Document Type MUST be unique and >>> persistent. >>> >>> It might be appropriate to refer to Section 17.2 and/or the IANA >>> registry for DocType values, here. >> Added in https://github.com/cellar-wg/ebml-specification/pull/321 >> >>> EBMLVersion to only support a value of "1". If an EBML Schema ado= pts >>> the EBML Header Element as-is, then it is not required to document >>> that Element within the EBML Schema. If an EBML Schema constrains >>> >>> Does "as-is" imply some level of future-compatibility/extensibility fo= r >>> when EBMLVersions other than "1" are defined? >> That's currently a grey area. If there was an EBML Header version 2 we >> can't assume the Matroska Schema to use it because we don't know if we >> would want modifications (as we already do) on top of it or not. >> >> So the EBML Schema should probably tell which EBML Header version it's >> based on. Probably a ebml=3D"1" attribute in the EBMLSchema element. >> See Pull Request https://github.com/cellar-wg/ebml-specification/pull/3= 22 > That seems reasonable. > >>> Section 11.1.1 >>> >>> It's a little amusing that we bother to provide "default" attributes >>> when the "range" attribute uniquely determines the allowed value. >>> >>> Section 11.1.4 >>> >>> Each "" defines one EBML Element through the use of sever= al >>> attributes that are defined in Section 11.1.3. EBML Schemas MAY >>> >>> I think this makes more sense as "Section 11.1.5". >> You're right. Fixed in https://github.com/cellar-wg/ebml-specification/= pull/323 >> >>> Section 11.1.5.2 >>> >>> This ABNF seems to only allow "direct" recursion where element >>> appears directly inside element , without any intermediate elements= . >>> I assume that's the intent, though it would be surprising in a >>> general-purpose markup language. >> Are you referring to the EBMLPathAtomRecursive ? It still has a parent >> so it can be in another element as well. > The EBMLPathAtomRecursive construction, yes. It looks like the stuff > inside the (1*()) is limited to a single EBMLPathAtom, and if the atom i= s > only one path component, then there is no opportunity to do x\y\x\y\x\y\= ... > as "co-recursion". But maybe I am misreading things. Regardless, I am = not > proposing any change to the document, so this discussion would just be f= or > my own edification. > >>> In some cases the EBMLLastParent part of the path is an >>> EBMLGlobalParent. A path with a EBMLGlobalParent defines a >>> Section 11.3. Any path that starts with the EBMLFixedParent of th= e >>> >>> That second sentence doesn't parse. >> Fixed in https://github.com/cellar-wg/ebml-specification/commit/55876fc= 0c306a54b08c79963a85d6aa3d4f9cfd6 >> >>> As an example, a "path" of "1*(\Segment\Info)" means the element I= nfo >>> is found inside the Segment elements at least once and with no >>> maximum iteration. An element SeekHead with path >>> "0*2(\Segment\SeekHead)" may not be found at all in its Segment >>> parent, once or twice but no more than that. >>> >>> The way this text is written makes me want to interpret the path >>> occurence counts more like the (regular) minOccurs/maxOccurs element >>> attributes, as opposed to applying to the path components to get to th= e >>> specific element in question. >> In fact it's a remaining part of text from when the path did include >> minOccurs/maxOccurs . This is not the case anymore and this text will >> be removed: >> https://github.com/cellar-wg/ebml-specification/pull/324 > Oh! That makes me feel less bad about being confused by it; thanks. > >>> Section 11.1.9.2 >>> >>> >> minOccurs=3D"1" maxOccurs=3D"1"> >>> >>> A set of items. >>> >>> Is this "name" supposed to be "Item" or "Items"? >> It's a typo. Also the path should not contain the occurrences. Fixed >> in the #324 PR. >> >>> Section 11.1.10-11.1.12 >>> >>> I'm not sure I have a full understanding of how / a= re >>> used; perhaps a reference to the corresponding XML behavior is in orde= r? >> Ping Dave Rice on that one. >> >>> Section 11.1.13-11.1.14 >>> >>> The usage seems underspecified. >>> >>> Section 11.1.15 >>> >>> >>> >>> >>> >>> Why do we include this commented-out snippet? >> It's an include of a XSD file that is actually usable to validate an >> EBML Schema. This commented out code is there because we should fix it >> to parse properly the path values. Should it be removed ? > My preference would be to not include it in the immutable RFC, but I def= er > to Alexey. > >>> >>> >>> >>> Don't we effectively set default values for these two in the prose >>> description? >> "If the unknownsizeallowed attribute is not used then that EBML >> Element is not allowed to use an unknown Element Data Size." >> I guess we could use false as the default value. >> >> "If the recurring attribute is not present then the EBML Element is >> not an Identically Recurring Element." >> Same here >> >> See https://github.com/cellar-wg/ebml-specification/pull/325 >> >>> Section 11.1.16 >>> >>> Identically Recurring Elements SHOULD include a CRC-32 Element as = a >>> Child Element; this is especially recommended when EBML is used fo= r >>> long-term storage or transmission. If a Parent Element contains m= ore >>> >>> I'm not sure if the "long-term" is intended to also bind as "long-term >>> transmission" (though I'm not sure what it would mean in that case). >>> It's also not entirely clear what kinds of transmission would benefit >>> from this, as reliable media presumably don't need redundancy for >>> reliability, but unreliable media can't really be used to carry EBML >>> without some framing requirements to know when elements start. >> Actually, as long as you have the "packets" in the right order you can >> use the EBML stream. You can also use it if you're missing some >> packets. The Checksum can help determine if the data are valid or not, >> even if the underlying transport loses some bits. It could technically >> be used as-is as protocol on top of IP, like TCP or UDP. > Huh, interesting. Though I thought that UDP (and IP itself) didn't > guarantee in-order delivery. > >>> Section 11.1.18 >>> >>> If a Mandatory EBML Element has no default value declared by an EB= ML >>> Schema and its Parent Element is present then the EBML Element MUS= T >>> be present as well. If a Mandatory EBML Element has a default val= ue >>> declared by an EBML Schema and its Parent Element is present and t= he >>> value of the EBML Element is NOT equal to the declared default val= ue >>> then the EBML Element MUST be present. >>> >>> This seems almost tautological, in that how would an EBML Element have= a >>> value if it was not present? (The following paragraph that talks abou= t >>> when to write such elements, does make more sense.) >> The difference here is whether the element has a value and is present. >> If you read the negative of that sentence, an EBML Element MAY NOT be >> present if it has the default value even if it's mandatory. > Ah, I see it now; thanks. > >>> Section 11.3.1 >>> >>> path: "*1((1*\)\CRC-32)" >>> >>> Using backslash as both an escape character and a path separator makes >>> my head hurt, and I did not have enough caffeine yet this morning to >>> figure it out. >> All the pathes actually have the remaining minOccurs/maxOccurs that >> were removed recently. I'll remove them via #324 >> >> After that the two global elements (which used to be tricky to read >> even for a trained eye) do not match the ABNF. Which also adds extra >> parenthesis a little too much. I created an issue to fix once #324 is >> merge https://github.com/cellar-wg/ebml-specification/issues/326 > Thanks :) > >>> 8.1.1.6.2 of [ITU.V42.1994], with initial value of 0xFFFFFFFF. Th= e >>> CRC value MUST be computed on a little endian bitstream and MUST u= se >>> little endian storage. >>> >>> bitstream or bytestream? >> Should be bytestream. >> https://github.com/cellar-wg/ebml-specification/pull/327 >> >>> Section 12 >>> >>> If a Master Element contains a CRC-32 Element that doesn't validat= e, >>> then the EBML Reader MAY ignore all contained data except for >>> Descendant Elements that contain their own valid CRC-32 Element. >>> >>> Ignoring only part of the known questionable content could have >>> significant security considerations, if (e.g.) security-relevant >>> restrictions are in the garbled part of the document but the sensitive >>> content has a (valid) redundant CRC. >> That's why it's a MAY. If a Matroska Segment has a CRC and each frame >> in it has a CRC. If the top CRC is invalid, we can still use some of >> the frames that have a valid CRC. It's not a requirement but a >> possibility. > I agree that it's an implementation choice for whether or not to do this= , > but please add some text in the Security Considerations that mentions th= e > risk of handling incomplete-but-interdependent data when implementations > choose to do this sort of thing. > > Thanks for all the updates! > > -Ben > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Fri Dec 27 01:18:05 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 CD48D120104 for ; Fri, 27 Dec 2019 01:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 X0SbbFuXcle7 for ; Fri, 27 Dec 2019 01:18:01 -0800 (PST) Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (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 5A5B3120103 for ; Fri, 27 Dec 2019 01:18:01 -0800 (PST) Received: by mail-wm1-x342.google.com with SMTP id c127so6520289wme.1 for ; Fri, 27 Dec 2019 01:18:01 -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-language:content-transfer-encoding; bh=Q4RdH0V/HV9FV1JdlFvzGmBqLg6kkfGHFccD7x0/tSw=; b=nsibdEbF4Nt9M4RPizcW4OUHPj94TF1+lk4U6TPgIhLvyKfiFirNR52G2olc32U1FY dV9I3E6zdWa09/yit4boBa8G75xvFLA1sQm64hQf8WEkITwhyaqKyrNtYe59qUVYktAF omnzNWuNvTuAqMSA3MiSH4UnvxCXbHOwYFzyhg59zzwso0eCKcMwqSRx+a+LDYjKJorC gCsgcjr4wbDWSZQotUmVheQONigRVGkz5GHXx4C1T2fx8F8fZBSrtweUcCHdUwhEMoc7 5u7VdNpjNqHu+sXDfJ22gygFJ6DbQeT43sJFWZMLwacHTST5AvT4/R3Q3vgK40LRk8B3 073A== 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-language :content-transfer-encoding; bh=Q4RdH0V/HV9FV1JdlFvzGmBqLg6kkfGHFccD7x0/tSw=; b=dfBrDMYcEuO8hkgALc5SDyxhf5HDeh3US1nsmB1ArKhXl8vooEK965v7jBbcK4Uj0m YObBRhtiTPyxkP1WfYoih999wggHV7K5SxIGJ3YrPZY4Eid0T4GyepnxGmT9dkOEj5DP 9bhXvQJwSClYuIqNQ9stOgSiJnlvTktLTCKgprdGfJ65NBsYxm1HY/TAYVZ5wodRpxI/ ke/5U0pyBJHu6cOQpf927E6nbqNz+X7VeyMgXRmNoQuPi2KtRxmBjO8V1xNazSEDEhD3 O5ZYr3h2Ar1so46AeY3pmGvk7A0k2wwaOV/dkhgfKmX9UwQ6krsJuov890R/6IqusAiR +Xmg== X-Gm-Message-State: APjAAAWXnXqGvQk9ol4yQJhFTW9VbOnLaYJJqNQ0lh8DWyPK1T3fJMn0 2YrkER5fQIbv3527NnNttgXXyiRxxNc= X-Google-Smtp-Source: APXvYqxMTvbzZyK1b08WMOawjbDRgrE/qFALxwnPiXPwtJ3+ztJhvNn8oG84OvxfsTbXgAlThOcT+Q== X-Received: by 2002:a1c:66d5:: with SMTP id a204mr17372678wmc.64.1577438279501; Fri, 27 Dec 2019 01:17:59 -0800 (PST) Received: from [192.168.3.26] (229.74.9.109.rev.sfr.net. [109.9.74.229]) by smtp.gmail.com with ESMTPSA id b17sm33241000wrp.49.2019.12.27.01.17.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Dec 2019 01:17:58 -0800 (PST) To: Benjamin Kaduk Cc: The IESG , Steven Villereal , draft-ietf-cellar-ebml@ietf.org, cellar-chairs@ietf.org, Codec Encoding for LossLess Archiving and Realtime transmission References: <157676970970.27491.11040479061607849531.idtracker@ietfa.amsl.com> <20191224184147.GP35479@kduck.mit.edu> From: Steve Lhomme Message-ID: <3fb0107e-a5d3-5d3a-0d15-f556b97755ae@matroska.org> Date: Fri, 27 Dec 2019 10:17:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20191224184147.GP35479@kduck.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] Benjamin Kaduk's Discuss on draft-ietf-cellar-ebml-15: (with DISCUSS and COMMENT) 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: Fri, 27 Dec 2019 09:18:03 -0000 On 2019-12-24 19:41, Benjamin Kaduk wrote: > On Tue, Dec 24, 2019 at 04:20:25PM +0100, Steve Lhomme wrote: >>> Section 11.1.16 >>> >>> Identically Recurring Elements SHOULD include a CRC-32 Element as a >>> Child Element; this is especially recommended when EBML is used for >>> long-term storage or transmission. If a Parent Element contains more >>> >>> I'm not sure if the "long-term" is intended to also bind as "long-term >>> transmission" (though I'm not sure what it would mean in that case). >>> It's also not entirely clear what kinds of transmission would benefit >>> from this, as reliable media presumably don't need redundancy for >>> reliability, but unreliable media can't really be used to carry EBML >>> without some framing requirements to know when elements start. >> >> Actually, as long as you have the "packets" in the right order you can >> use the EBML stream. You can also use it if you're missing some >> packets. The Checksum can help determine if the data are valid or not, >> even if the underlying transport loses some bits. It could technically >> be used as-is as protocol on top of IP, like TCP or UDP. > > Huh, interesting. Though I thought that UDP (and IP itself) didn't > guarantee in-order delivery. UDP and IP have no notion or order. But you can create protocols on top that do. Basically an EBML-based streaming format would just be: [Packet Number][EBML element] With EBML element smaller than 4000 or 1512 octets to fit nicely in Ethernet. Anyway, that's definitely out of the scope of this document ;) >>> Section 12 >>> >>> If a Master Element contains a CRC-32 Element that doesn't validate, >>> then the EBML Reader MAY ignore all contained data except for >>> Descendant Elements that contain their own valid CRC-32 Element. >>> >>> Ignoring only part of the known questionable content could have >>> significant security considerations, if (e.g.) security-relevant >>> restrictions are in the garbled part of the document but the sensitive >>> content has a (valid) redundant CRC. >> >> That's why it's a MAY. If a Matroska Segment has a CRC and each frame >> in it has a CRC. If the top CRC is invalid, we can still use some of >> the frames that have a valid CRC. It's not a requirement but a >> possibility. > > I agree that it's an implementation choice for whether or not to do this, > but please add some text in the Security Considerations that mentions the > risk of handling incomplete-but-interdependent data when implementations > choose to do this sort of thing. I think it really depends on the dependency of the data at the semantic level. For example and EBML Element may define the type of data found in another EBML Element. If the type is damaged the interpretation of the data can create many kind of issues. As for the CRC I think it's similar. It depends on what the CRC covers and the decision should probably be done at the semantic level, even with various options on how to handle the data. From nobody Fri Dec 27 01:18: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 DD09E120105 for ; Fri, 27 Dec 2019 01:18:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 d39o2YeKi-qn for ; Fri, 27 Dec 2019 01:18:10 -0800 (PST) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 6F9471200FE for ; Fri, 27 Dec 2019 01:18:10 -0800 (PST) Received: by mail-wr1-x42c.google.com with SMTP id q6so25507792wro.9 for ; Fri, 27 Dec 2019 01:18:10 -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-language:content-transfer-encoding; bh=Yjk3ehK4rOX0gH96S7TirfIRfX/+wCHrdtURK0eXFm4=; b=zvN8kgoHNw46Oq/9TZzwDf12WN0tTM6HBp7BRIzO0eoOWXORmTzBbVu4rG18Lz2nKJ qXEooZjRG1BEPmBKg3Ar6urbktOA9p7fX8jyuxN9diplms0YLXaUgzqcvI5ouzkM4B2t mdI6Iu3euLu3pJRpEn/vt+0OkVvnpMhG99WOKc3jQEM0Hv+CT4rGrL2iTLnxRTuWPbz6 HT25Q0Re2qrCjPeOup9Tt38Et/179weG/EbZC5XYf4Ns6nS9UKwuoOgTlK2u5cMdeN22 xgqGQ28imuABY4EE0HcF1Ft5Flsyt/QWGiu5hDjaWRtoIAQiF4uQCwoMJExqcvLFESLe 3MCw== 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-language :content-transfer-encoding; bh=Yjk3ehK4rOX0gH96S7TirfIRfX/+wCHrdtURK0eXFm4=; b=q+0nnUMqlbrXIe8ok/Nih4cTxVHezMPWUt4VNfI7lO5mZpOj/Y5Ylji9RmdlXGnT+g HVE6dLOvd32N2ZAbls4Ajte13NBlSb3Cd0b1A9yIv88aDsj9DhVcn/K+2r7qFvp3jLmQ RMTqUHsfgBYlZv4rlz/m0v02+Z2qOFZxkVOa5aTng+2h7UfkJcilq1jsDt5LLw4MBThK 3RzZQtxns/ZXiTOM+O1HE9tB2RNtku+pjht0ipFfOZkmqhqAqkMfT9TlC1abW5cvJrC4 WY0/EZYLMlbf3eclqzVqaJHuiLGQz92dCc7UEoVZaoIqEJD2FantCZoaP4cg4t7BQVp8 VwUQ== X-Gm-Message-State: APjAAAXJGDK/PxbYK0gSoIy3Jb6tuGsVNwntA84X5BuFVV3MC0cymIuM xKkCsyzlrl9l99xFnrFNGNpL1eegLaM= X-Google-Smtp-Source: APXvYqxKYZ8fUfFw1b+Z38mkpFwrItw/Re7yjYbpjB2L/0ejbLtZkvF1+NyhFwFTi3FNDlcCAxIZJQ== X-Received: by 2002:adf:fe0e:: with SMTP id n14mr49214960wrr.116.1577438288612; Fri, 27 Dec 2019 01:18:08 -0800 (PST) Received: from [192.168.3.26] (229.74.9.109.rev.sfr.net. [109.9.74.229]) by smtp.gmail.com with ESMTPSA id f1sm34631623wrp.93.2019.12.27.01.18.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Dec 2019 01:18:08 -0800 (PST) To: cellar@ietf.org References: <157676970970.27491.11040479061607849531.idtracker@ietfa.amsl.com> <20191224184147.GP35479@kduck.mit.edu> <88ed13cf-c9d6-5f60-f4bf-23eeb6163e4a@gmx.ch> From: Steve Lhomme Message-ID: Date: Fri, 27 Dec 2019 10:18:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <88ed13cf-c9d6-5f60-f4bf-23eeb6163e4a@gmx.ch> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Cellar] Benjamin Kaduk's Discuss on draft-ietf-cellar-ebml-15: (with DISCUSS and COMMENT) 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: Fri, 27 Dec 2019 09:18:12 -0000 On 2019-12-25 14:13, hubblec4 wrote: > Hello > > Am 24.12.2019 um 19:41 schrieb Benjamin Kaduk: >> On Tue, Dec 24, 2019 at 04:20:25PM +0100, Steve Lhomme wrote: >>>> Section 4.1 >>>> >>>>     Each Variable Size Integer begins with a VINT_WIDTH which >>>> consists of >>>>     zero or many zero-value bits.  The count of consecutive zero-values >>>>     of the VINT_WIDTH plus one equals the length in octets of the >>>>     Variable Size Integer.  [...] >>>> >>>> Does the following attempted rewording change the meaning? >>> Nope, maybe the meaning wasn't clear before. Hopefully it's better now. >> I think Barry had some good suggestions here as well, so I think it's >> better, yes. > > Some ideas from me: > > As I started to write my own Matroska parser it was not easy to > understand what is mean with all this and how I have to do. > After many reading and try, I understood it. For me is the VINT_MARKER > the key. > > The position of the VINT_MARKER is the VINT_WIDTH. > > Lazarus(my programming language) use a function "pos()", it gives me the > position of the first occurence of what I want. > In our case the VINT_MARKER is a "1". > > VINT_WIDTH = pos(FIRST-BYTE-OF-VINT , VINT_MARKER); > Thats all what I have to code. No counting zero values, no adding one to > counted zero values. For the record many processors have an instruction to find this value easily: https://en.wikipedia.org/wiki/Find_first_set From nobody Fri Dec 27 07:06:32 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 AA4BA120112; Fri, 27 Dec 2019 07:06:31 -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_HELO_NONE=0.001, 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 tzllgb_mBiwJ; Fri, 27 Dec 2019 07:06:29 -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 A0AA4120103; Fri, 27 Dec 2019 07:06:29 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6E30E3897B; Fri, 27 Dec 2019 10:06:17 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 68576AAD; Fri, 27 Dec 2019 10:06:28 -0500 (EST) From: Michael Richardson To: Steve Lhomme , Benjamin Kaduk , draft-ietf-cellar-ebml@ietf.org, Steven Villereal , The IESG , cellar-chairs@ietf.org, Codec Encoding for LossLess Archiving and Realtime transmission In-Reply-To: <3fb0107e-a5d3-5d3a-0d15-f556b97755ae@matroska.org> References: <157676970970.27491.11040479061607849531.idtracker@ietfa.amsl.com> <20191224184147.GP35479@kduck.mit.edu> <3fb0107e-a5d3-5d3a-0d15-f556b97755ae@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 Archived-At: Subject: Re: [Cellar] Benjamin Kaduk's Discuss on draft-ietf-cellar-ebml-15: (with DISCUSS and COMMENT) 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: Fri, 27 Dec 2019 15:06:32 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Steve Lhomme wrote: >>>> Identically Recurring Elements SHOULD include a CRC-32 Element as a >>>> Child Element; this is especially recommended when EBML is used for >>>> long-term storage or transmission. If a Parent Element contains >>>> more >>>> I'm not sure if the "long-term" is intended to also bind as >>>> "long-term transmission" (though I'm not sure what it would mean in >>>> that case). It's also not entirely clear what kinds of transmissi= on >>>> would benefit from this, as reliable media presumably don't need >>>> redundancy for reliability, but unreliable media can't really be >>>> used to carry EBML without some framing requirements to know when >>>> elements start. >>> Actually, as long as you have the "packets" in the right order you >>> can use the EBML stream. You can also use it if you're missing some >>> packets. The Checksum can help determine if the data are valid or >>> not, even if the underlying transport loses some bits. It could >>> technically be used as-is as protocol on top of IP, like TCP or UDP. >>=20 >> Huh, interesting. Though I thought that UDP (and IP itself) didn't >> guarantee in-order delivery. > UDP and IP have no notion or order. But you can create protocols on t= op > that do. Basically an EBML-based streaming format would just be: > [Packet Number][EBML element] With EBML element smaller than 4000 or > 1512 octets to fit nicely in Ethernet. Anyway, that's definitely out > of the scope of this document ;) Yes. I read it as binding more to long-term storage than transmission. But, not every transmission system is TCP, and EBML would certainly be appr= opriate format for video transmissions from a multi-decade long flight of an interstellar space-craft, and those don't do retransmissions :-) This is an 'archival' format afterall, so it such a transmission would need to survive multiple generations of base-station systems. > As for the CRC I think it's similar. It depends on what the CRC covers > and the decision should probably be done at the semantic level, even > with various options on how to handle the data. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4GHfQACgkQgItw+93Q 3WXh4gf8CrF6cYalrgLsqhm6WJxxn/pvFYoPl1g7w+y31tKzNqfWlC9fh9+ziLgx vzvk3mMtsklRLQOVOxwel9hzgVpK2UVWn6yqAjBby4EmErZNpZxOGNBMamSzgcjU MvVlwme1X1rdbZ9O3/JSuIDb/mYVgh6fZ0hBF4Knmy4ad8jQZ4XER3Nert+bGAV1 2sgkau9epoVtOpLDIQAWREW/r8KiQL2THKZpSCev3Im4hek2+ut9I081m16+379y 5IRvdO5kfdqEHitrQXJDjRBhLZmwUhNcOh/NmBdASpCUYu3XHm68J5fIGYh8pLci 6vOwKpcwljvjh2oJBgCsZqlaK8aivA== =aU3W -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Dec 29 06:05: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 EF028120019; Sun, 29 Dec 2019 06:05:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 cdI_g0TB1r1e; Sun, 29 Dec 2019 06:05:47 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on060b.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0d::60b]) (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 61FBF12000F; Sun, 29 Dec 2019 06:05:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SxBJN5gGZFXdkDdlbRnpqv0I5MdjUNR8gHF+iaFJU2KvVYh48Cxt7SH1cRaowAIc157Na9ZwunsvFC4Sqci2Ph2Zor1OJcCSQq98hcy/TlQKy0GMhkvS0D+IUB+uWSiGrT6VTBicrW2jrVcq2YzUjDnZkB/Qs1PRB9YtgVOJI0lkxPVllT5D4Q9j1pUkicjI6I/+uOLVLRhJabDf0KrW/yIXZCjKWmHdFp9JlSokBDLAGQjHaH0Ss4mhhsnTFQSK7LdWXCW+Oc0DjbzhkesLJUXlf+/uac9PD1+eypy6734D43pvcA/pXWMHtYvTp8v8SE0Tt/KCnZVaTu7eb2Jk1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DOQlRZ7rnYFfwgLJPPxWZzgrKtnHDf89lGDSJO4UZ48=; b=JCH3iHbELn+KmqIUx8+/rTGcx1wc3x8R+RjYYH69OD/rTOdcX1KR8DEOlUSaQnfl7Wfv14IDqWW57H0+ufjulWcGU2vpG8jB84SgxE06tI9gMYEf6lwqcz4bJ3OhDRzCawJSl+7zbm+daiS+blMn7SflUjsOS1Kn+oZ5JMAd2UtdAfIbKRV+Ii2I1gwKU7v0xQ2kuFhBfUXNMBmKJDpAW1QUJ3KmoLuHs0FxfnqfSYm+Dy6M6VAyb1VSGj46sLTcZEYX5PocIreGw0GhYLJPIBf2ueEIE4c8eBmcQAZO0cdjBLFvwQJdZdN/63jAQ6agmbYByVLQI1eXavAy3TdFDg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DOQlRZ7rnYFfwgLJPPxWZzgrKtnHDf89lGDSJO4UZ48=; b=OjlnzyNDHP80r612iTgyJteM1rShJpkx5izc1xBdYftqpxlZr4sDMpwc04alrYKjPXqWKPC9qdMR5YixtLlcaHAEL8GTZA7Wrn3Nd0NMrmur2CNRPqmUOrPxuU5e0tcU4gStMnzuFGsTqi0znYpITmwp7S56NgNpPrmDutoHc8Q= Received: from VI1PR07MB5310.eurprd07.prod.outlook.com (20.178.12.13) by VI1PR07MB5472.eurprd07.prod.outlook.com (20.178.15.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.9; Sun, 29 Dec 2019 14:05:43 +0000 Received: from VI1PR07MB5310.eurprd07.prod.outlook.com ([fe80::7d33:e10e:8fcd:64]) by VI1PR07MB5310.eurprd07.prod.outlook.com ([fe80::7d33:e10e:8fcd:64%4]) with mapi id 15.20.2602.009; Sun, 29 Dec 2019 14:05:42 +0000 From: Magnus Westerlund To: "dave@dericed.com" CC: "draft-ietf-cellar-ebml@ietf.org" , "cellar-chairs@ietf.org" , "iesg@ietf.org" , "villereal@gmail.com" , "cellar@ietf.org" Thread-Topic: [Cellar] Magnus Westerlund's Discuss on draft-ietf-cellar-ebml-15: (with DISCUSS and COMMENT) Thread-Index: AQHVtnUcXOt6KGNFb0iTWAskf6Jel6fDc64AgAMyRwCACo8+gA== Date: Sun, 29 Dec 2019 14:05:42 +0000 Message-ID: References: <157676414666.27346.14188913386068032568.idtracker@ietfa.amsl.com> <5253C5B6-EFAA-4DF0-B7B2-FC11E4C02507@dericed.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [158.174.130.211] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 68c95db1-6de6-472f-7f01-08d78c68315a x-ms-traffictypediagnostic: VI1PR07MB5472: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0266491E90 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(396003)(136003)(366004)(39860400002)(346002)(199004)(189003)(44832011)(6506007)(4326008)(26005)(86362001)(186003)(53546011)(71200400001)(4001150100001)(478600001)(5660300002)(2616005)(8936002)(316002)(6916009)(66446008)(81156014)(76116006)(8676002)(6486002)(66556008)(2906002)(54906003)(36756003)(91956017)(6512007)(66476007)(66616009)(64756008)(66946007)(966005)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB5472; H:VI1PR07MB5310.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: rFGpAY0MWM0T13bwJq+xf+fWQIxzHnlCbC2vTstNf1p0qhsbXG7cJEzti+OzMLnY90ucrayS4kx/2GLxtTyyvQZI5uOWN/Kllh3/f+sLp5ItLDcAClW9pzpPKumChrT92VKU7n/QeNGe8apSq60iXdNNAxvwqoIR0OQgu9RB+Z/KVc36mdCLKHGZKUYp0IXDEgvvjdPM3av8lUWLg+K6/oPV0r+5uwynKXn7f9n36CttxvTLxrDbFD3wKttiOOS/hZQ4fW9Hz4SSM8gdPZLDu/6azMqMwmsIZveKxXKGn3xgUXm0l9V3vSSPGGzq3BNemS8v6uLA890lLjA1jpF9/AL9JYDhoF9rJFDrpER9KFD8XEpdOwZ/A/HfwiJF5nVyMfTcSHq4pDw8kBf0e2t2SKAFGeeFFptMgiAcrjgxaBXK+8emyviqa2Km7yQM52+0w7tk8YZYbDpEidOWv5VDM/uskb8wWw3G4R3gKe3+eQ8= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-tGAHemJPuTazI+pVk8+J" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 68c95db1-6de6-472f-7f01-08d78c68315a X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Dec 2019 14:05:42.6957 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: gl7q/5dDjqO0CF1dIhRuJxjtL/ak0JI04NBk2Cr6qluprLT4VSDWDThPvyUTPoyAV6imPROoHBb1BnPwnC+3FaXytDbuFkVmZYhNgnmOOck= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5472 Archived-At: Subject: Re: [Cellar] Magnus Westerlund's Discuss on draft-ietf-cellar-ebml-15: (with DISCUSS and COMMENT) 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, 29 Dec 2019 14:05:50 -0000 --=-tGAHemJPuTazI+pVk8+J Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Thanks, those changes do resolve my issue. I will clear my discuss.=20 Cheers Magnus On Sun, 2019-12-22 at 15:50 -0500, Dave Rice wrote: > Hi Magnus, >=20 > Version 16 at https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/16 = is > posted and should address all comments below. Thanks for your review. >=20 > Best Regards, > Dave Rice >=20 > > On Dec 20, 2019, at 3:01 PM, Dave Rice wrote: > >=20 > > Hi Magnus, > >=20 > > > On Dec 19, 2019, at 9:02 AM, Magnus Westerlund via Datatracker < > > > noreply@ietf.org> wrote: > > >=20 > > > Magnus Westerlund has entered the following ballot position for > > > draft-ietf-cellar-ebml-15: Discuss > > >=20 > > > When responding, please keep the subject line intact and reply to all > > > email addresses included in the To and CC lines. (Feel free to cut th= is > > > introductory paragraph, however.) > > >=20 > > >=20 > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.= html > > > for more information about IESG DISCUSS and COMMENT positions. > > >=20 > > >=20 > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/ > > >=20 > > >=20 > > >=20 > > > ---------------------------------------------------------------------= - > > > DISCUSS: > > > ---------------------------------------------------------------------= - > > >=20 > > > 1. Section 5: > > >=20 > > > The Element ID is encoded as a Variable Size Integer. > > >=20 > > > +-----------------------+-------------------------+---------------+ > > > | VINT Length in octets | Range of Possible IDs | Number of IDs | > > > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ > > > | 1 | 0x81 - 0xFE | 126 | > > > +-----------------------+-------------------------+---------------+ > > > | 2 | 0x407F - 0x7FFE | 16,256 | > > > +-----------------------+-------------------------+---------------+ > > > | 3 | 0x203FFF - 0x3FFFFE | 2,080,768 | > > > +-----------------------+-------------------------+---------------+ > > > | 4 | 0x101FFFFF - 0x1FFFFFFE | 268,338,304 | > > > +-----------------------+-------------------------+---------------+ > > >=20 > > > To me it appears that this whole section can't decide if the Element = ID is > > > encoded integer using VINT or an VINT format octet sequence that is s= elf > > > describing in length? If it is the first then the above quoted table = would > > > to > > > me state that the IDs are 1-126 for 1 octet, and the second two-octet > > > 127-16382. But based on later section it is actually the later. As th= e ID > > > values defined in Section 11.2 for the various elements are actually = the > > > encoded form rather than a representation of the Integer value encode= d. > > > This > > > needs to be clarified. > >=20 > > Thanks, this topic came up in Adam Roach=E2=80=99s review [1] as well a= nd ended with > > a use of an Element ID as a VINT format octet sequence. I have rewritte= n > > this section in the referenced pull request [2] according to your > > suggestions and comments. > >=20 > > > ---------------------------------------------------------------------= - > > > COMMENT: > > > ---------------------------------------------------------------------= - > > >=20 > > > 1. Section 5: > > >=20 > > > Any Element ID with the VINT_DATA > > > component set as all zero values or all one values MUST be ignored. > > >=20 > > > What does it mean to ignore an Element ID in the general case. Can yo= u > > > really > > > say this in the general case, rather than state that it is not a vali= d > > > Element > > > ID? Or is the intention that an Element ID with all data is the equiv= alent > > > to > > > padding and simply skipped and a parser needs to expect to find the r= eal > > > Element ID in the next octet sequence? Considering the Element Length= that > > > do > > > allow zero values and non-efficient encoding, if the element should b= e > > > ignored > > > or not depends on the expected element to find by the parser. > > >=20 > > > I might have missed some later explanation of this, as I didn't manag= e to > > > read > > > the whole document in detail. > >=20 > > I considered changing this sentence from saying that such an Element ID > > should be ignored to simply asserting that it is not valid; however the > > prior sentence "The bits of the VINT\_DATA component of the Element ID = MUST > > NOT be all `0` values or all `1` values.=E2=80=9D already makes this cl= ear. Thus I > > simply removed the sentence in the second commit of the pull request. I > > think this sentence is okay to remove as there are later statements in > > Section 7.7 that make the same point more clearly about skipping invali= d > > data. > >=20 > > Thanks much, > > Dave > >=20 > > [1] https://mailarchive.ietf.org/arch/msg/cellar/yvXmJPWGkUISXbdt0aZ-Uk= C57I8 > > [2] https://github.com/cellar-wg/ebml-specification/pull/315/files >=20 >=20 --=20 Cheers Magnus Westerlund=20 ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --=-tGAHemJPuTazI+pVk8+J Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEtww ggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYT AlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+laqg5eXTqonqnzT9ykEGL2dx9mBT +2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJHGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9 uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iVIiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpig GFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36ogzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkr bdmdnjKGrYSnJigmxw14pJugxL/Vb2EeVcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYD VR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIu dHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEu Y29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUH AgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEB CwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4QihhoQR3c vhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXDyF9mhWYbSAkJ yx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6H3zO3nsq++KBmsOi SKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvElup5n7l864FqxnC2friD o4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl60rmc8SJlt6QXKw0wXEOE1Mu bauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwDig3SZi1qP7D/Ds4V+JLIjjUJc25l 9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8Kv7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLC QaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Z la71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzYVBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd/ /n4YbY2QhDCCBgcwggPvoAMCAQICEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQELBQAwRzEL MAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRp dmlkdWFsIENBIHYzMB4XDTE3MTIxNTA3MjIyM1oXDTIwMTIxNTA3MjIyMlowcDERMA8GA1UECgwI RXJpY3Nzb24xGjAYBgNVBAMMEU1hZ251cyBXZXN0ZXJsdW5kMS0wKwYJKoZIhvcNAQkBFh5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VyYW1zd2QwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCwqUdm8HdOyYsQO09KIUUoCHvdLbACm36VqqDl5dOqieqfNP3K QQYvZ3H2YFP7ZZmIgrGjjDayKxWXcQRhOpdORy2m6vtw3b2AsLwXe0kcYjaxRWk70DClWs35S4cR V60e3uF3Fb25h3QsknxM/r/AaQh8AVpnGVlSfv07Z4cSV+KHWJUiJNlctwR7WsEm3OFQ1EdaA6ba 9CUMniwKmKAYWrnD5dJG+IRAyRBlG/DUJCZvflBL8L9PfqiDMhEcO4B2ShJqJQ5j9LZ0ungeTC84 6D60AOloeStt2Z2eMoathKcmKCbHDXikm6DEv9VvYR5VyCkB9VWy3subg849Ejz7AgMBAAGjggHE MIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6 Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxp YXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjApBgNVHREEIjAggR5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4 BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBTmK+6GlTnVbhSEEMFbB/xe xTzftjAfBgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJ KoZIhvcNAQELBQADggIBAGfQUq6SDTRQ39z8RKnFIhphOux3yWIccy7msuk4E05pykY0EwY2BQMO 3hCKGGhBHdy+FhcKsAzn01O/DQc2WCodmgR5VjtickliclcMItR+QrkOfbwTdCvPKSQXqCJQ5cPI X2aFZhtICQnLHRiPRdzx6ffBg3KgVgSqOUq1mt1XSlyAXMR5dUtLwNavNLLv4p9S0M4SIzoffM7e eyr74oGaw6JIqRafihgRFmDkoSUQAeKz1q/7cohoQ+c4C3xBFZGkV8Znh3z0XXqoW8SW6nmfuXzr gWrGcLZ+uIOjiEtBjoQ1o5pgiKFeFuXZRjEAYOTz1omb9LmljKrvDOb4orchxSXrSuZzxImW3pBc rDTBcQ4TUy5tq5goyxp3azyMP6sSRen5qBNGX6x7NZpHEcGnG5QoN3oyHAOKDdJmLWo/sP8OzhX4 ksiONQlzbmX228wYL36WojQ/68wjdnKui7Q019vnm4tBqrXw77sFnwq/uO8V3FjJSBvFDRI8SLKH KVwscCYl4sJBqJkeYJEQGQIspJ/Q7iUTZOtXN04PfzCPO5DbtTdR11UIP0RDe0XujoRWGnEklSUH rF7/ZRbDLhmVrvV0otSFqR1Ws3lpvPGoVa/M4BP2cFrYfNhUG2lty7ooaHvZgn4zv19r2IiRxAKB SfDeAgB5Z3/+fhhtjZCEMIIGwjCCBKqgAwIBAgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0B AQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBD QSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5D tjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK 6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1Nwk TepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJ kwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2 haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhO UbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW 9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP0 5tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QL sgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8 MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUH MAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJv b3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQEC MDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20v Q1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20v dGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU 8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PL Fpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUb AL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4 Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2 d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1Pwu zAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg 0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F 04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d 1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7 C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i6Ds5j0Qpj5aQMYICzTCCAskCAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJYIZIAWUDBAIBBQCgggFDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MTIyOTE0MDU0M1owLwYJKoZIhvcN AQkEMSIEICpwmjcRy4r7OLn8I7iqPzVr0/yIFDopfsr2TP5Z30fVMGoGCSsGAQQBgjcQBDFdMFsw RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMGwGCyqGSIb3DQEJEAILMV2gWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAe/ZLh92jSYE2 aUtk0d3BKnGmDa12n/4hozqfXH6q2KKBggQH/W2AWW5wldgmv7OSb83Dt6arq/+lABGba7mx701m eIqTZb7Z8GCRLnaKE4bz65QZUJrjCCFT0xdrO3e8Jrvk2bC0lLRH0AKNgSbHtzczkDzqmhEKgt/n 6wWBCQFpDv5EE8LIYgv1pIPVGdp1MthSFZKB+Ym+Qc1ni1VVVKBqtWrcb5IxtXXHjduyVGeTtRA8 Z5xf3FG/5I0a1OS63/n8L/JhH2OiXnRlDWT8WV7wSe6vm4FJMDm8Y+Rj9HpGaBy8ccPibueLoE5P /0vVs3XVsV7Yt2zos061sgU/SgAAAAAAAA== --=-tGAHemJPuTazI+pVk8+J-- From nobody Sun Dec 29 19:50:34 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 D97FE120100; Sun, 29 Dec 2019 19:50:31 -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_HELO_NONE=0.001, 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 Lt5NgOYR7Kos; Sun, 29 Dec 2019 19:50:30 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 197961200D6; Sun, 29 Dec 2019 19:50:29 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBU3oOcb020149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 29 Dec 2019 22:50:26 -0500 Date: Sun, 29 Dec 2019 19:50:23 -0800 From: Benjamin Kaduk To: Steve Lhomme Cc: The IESG , Steven Villereal , draft-ietf-cellar-ebml@ietf.org, cellar-chairs@ietf.org, Codec Encoding for LossLess Archiving and Realtime transmission Message-ID: <20191230035023.GI35479@kduck.mit.edu> References: <157676970970.27491.11040479061607849531.idtracker@ietfa.amsl.com> <20191224184147.GP35479@kduck.mit.edu> <3fb0107e-a5d3-5d3a-0d15-f556b97755ae@matroska.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3fb0107e-a5d3-5d3a-0d15-f556b97755ae@matroska.org> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Cellar] Benjamin Kaduk's Discuss on draft-ietf-cellar-ebml-15: (with DISCUSS and COMMENT) 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, 30 Dec 2019 03:50:32 -0000 On Fri, Dec 27, 2019 at 10:17:58AM +0100, Steve Lhomme wrote: > On 2019-12-24 19:41, Benjamin Kaduk wrote: > > On Tue, Dec 24, 2019 at 04:20:25PM +0100, Steve Lhomme wrote: > > >>> Section 12 > >>> > >>> If a Master Element contains a CRC-32 Element that doesn't validate, > >>> then the EBML Reader MAY ignore all contained data except for > >>> Descendant Elements that contain their own valid CRC-32 Element. > >>> > >>> Ignoring only part of the known questionable content could have > >>> significant security considerations, if (e.g.) security-relevant > >>> restrictions are in the garbled part of the document but the sensitive > >>> content has a (valid) redundant CRC. > >> > >> That's why it's a MAY. If a Matroska Segment has a CRC and each frame > >> in it has a CRC. If the top CRC is invalid, we can still use some of > >> the frames that have a valid CRC. It's not a requirement but a > >> possibility. > > > > I agree that it's an implementation choice for whether or not to do this, > > but please add some text in the Security Considerations that mentions the > > risk of handling incomplete-but-interdependent data when implementations > > choose to do this sort of thing. > > I think it really depends on the dependency of the data at the semantic > level. For example and EBML Element may define the type of data found in > another EBML Element. If the type is damaged the interpretation of the > data can create many kind of issues. > > As for the CRC I think it's similar. It depends on what the CRC covers > and the decision should probably be done at the semantic level, even > with various options on how to handle the data. I entirely agree that it depneds on the semantics of the particular data in question. That said, even if it only would happen for a small fraction of actual usage, typically we still see fit to document the existence of the risk for the affected cases, in the security considerations. -Ben