From nobody Sun Aug 1 00:41:15 2021 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 53E8B3A3108 for ; Sun, 1 Aug 2021 00:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=nMQWYHA6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZDjfgWGh 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 fsMtGVbcvNd4 for ; Sun, 1 Aug 2021 00:41:08 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87A653A3103 for ; Sun, 1 Aug 2021 00:41:08 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id AC96B32000EB for ; Sun, 1 Aug 2021 03:34:22 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Sun, 01 Aug 2021 03:34:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm3; bh=q1BekRWnOtL SFJwLZv7BzBJV8RSssMGHLbr1J58phgQ=; b=nMQWYHA65qwA/g9yFsUYqEDz0sa F9s+TVkOu3HINJWcabUY9sWpSFFJerkYjaZvxRmPmH9cqqxcIVqrrOZ2oSoOv87/ /0yUYb3Smg8gxLAdPV79u5Rv2hUsAEO5+ZJ75LkZWHD01n90qVRuP5oAD/vOlfX1 Bg0yIl3w77zVwhS7LYVGzEgZJIZlmBGYahMUnt9DpdnN5Uk/36l3OoCHODEpJuRV NJC6ru5ZRCvz6JSilFp0g04JxqDLgRbOl+VcqCTgnQAWkZrUXvlnTmzAz5m8BTSc zkPhutR3zozc+DBYEMs0ElvU7vgP/ul7xalZs+dBC3eBK18AVy7bH8gH6FA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:from:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=q1BekRWnOtLSFJwLZv7BzBJV8RSssMGHLbr1J58phgQ=; b=ZDjfgWGh UpfYo56RlZr3vrV70QH/EO9H7UTrNd6grt1l1ZLkmgc/PA0ik7Wr3Ta+SEk9a2Rx v1kSigiOrIBkLcFXwHSEi31p8qckp5mvKsoSABOn5/BBbZqwfl1hKLgPto8UEW25 u08E6brjacTJysnRzLMpqvCHdyeq5s7UPWsxCdCsyYY3E3x7BBQEF69/VnslaXqO +4D8RMWkfVy+3ec3xzpeIbRm8OMdaDNpGXTnJ8OkuiZdSFX8qA9JtBk97AZXtjs8 teEHCFEEn34DH43SfRUvxet9dC/4CX9FFYVbICNgE3s395tNmB+mbvcjrhBg2vQf OooKHQyZm9it6w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrheelgddugecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecupfhoucgurghtvgcufhhivghlugculdegledmnecujf gurheptggghffvufesrgdttdertddtjeenucfhrhhomheptfgvphhoshhithhorhihucet tghtihhvihhthicuufhumhhmrghrhicuuehothcuoeguohgpnhhothgprhgvphhlhiesmh hnohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeekfedvudetjedvfeekheeiveeugfef hfetteevgeffkefffeetffdvleehudeiteenucffohhmrghinhepghhithhhuhgsrdgtoh hmnecuvehluhhsthgvrhfuihiivgepudenucfrrghrrghmpehmrghilhhfrhhomhepugho pghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 1 Aug 2021 03:34:22 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============4066705819161800242==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20210801074108.87A653A3103@ietfa.amsl.com> Date: Sun, 1 Aug 2021 00:41:08 -0700 (PDT) Archived-At: Subject: [Cellar] Weekly github digest (CELLAR Activity Summary) 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 Aug 2021 07:41:13 -0000 --===============4066705819161800242== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * ietf-wg-cellar/ebml-specification (+0/-0/=F0=9F=92=AC2) 1 issues received 2 new comments: - #411 Date Element specs: fix miscalculation & clarification about leap = seconds (2 by Liisachan, robUx4) https://github.com/ietf-wg-cellar/ebml-specification/issues/411 [bug] [= errata-rfc8794]=20 Pull requests ------------- * ietf-wg-cellar/ebml-specification (+1/-0/=F0=9F=92=AC0) 1 pull requests submitted: - Clarify how to handle leap seconds (by robUx4) https://github.com/ietf-wg-cellar/ebml-specification/pull/415 [clarific= ations] [errata-rfc8794]=20 * ietf-wg-cellar/matroska-specification (+1/-0/=F0=9F=92=AC0) 1 pull requests submitted: - Fix typos of "identifier" and "interpretation" (by wader) https://github.com/ietf-wg-cellar/matroska-specification/pull/526=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-cellar/ebml-specification * https://github.com/ietf-wg-cellar/matroska-specification * https://github.com/FFmpeg/FFV1 * https://github.com/ietf-wg-cellar/Cellar-FLAC * https://github.com/ietf-wg-cellar/chair-notes --===============4066705819161800242== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

Sunday August 01, 2021

Events without label "editorial"

Issues

ietf-wg-cellar/ebml-specification (+0/-0/=F0=9F=92=AC2)

1 issues received 2 new comments:

Pull requests

ietf-wg-cellar/ebml-specification (+1/-0/=F0=9F=92=AC0)

1 pull requests submitted:

ietf-wg-cellar/matroska-specification (+1/-0/=F0=9F=92=AC0)

1 pull requests submitted:

Repositories tracked by this digest:

--===============4066705819161800242==-- From nobody Sun Aug 8 00:40:58 2021 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 D598D3A1FAD for ; Sun, 8 Aug 2021 00:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=Y7MFiD6q; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SJqt6Ho1 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 cPbsVUKsea_L for ; Sun, 8 Aug 2021 00:40:48 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 151BF3A1FAC for ; Sun, 8 Aug 2021 00:40:48 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id F110C5C00E1 for ; Sun, 8 Aug 2021 03:34:06 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Sun, 08 Aug 2021 03:34:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm3; bh=1jCT/t76J0n 25Ll9zChQZzGyxzzcTn7Hg1BvkrESrV0=; b=Y7MFiD6q1EOeVLg7B/mRriTrYyT AmyKHrukGfWkMWKpxxyiVj5nRYP8LDbZdhIXJM5uu0Aw7BivWg10XQ6PAsmczWGX JCVG/XJap5XZ+zMObogQcSn4QiaBoXc4yBJSmVVybWlsrcSg4c/BimeU5RvrPm/b kUETv9H/OPA6f0IkeAuNUbuDN9PSU0nI+x+Dsoevr7+b+WseVjpJ3o1qCGfPntQj BDMZ1o4sIeXy+u4DnMYhmLVoVXtmuyVCMidH5bFxqAugvgHMOxQ8sDgyZGNb1swO mSHYKDLo3Z9j1vhKg78Y05pthQ1bV6rqzae3mUqbeQY9i++DJsvva9b/LpQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:from:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=1jCT/t76J0n25Ll9zChQZzGyxzzcTn7Hg1BvkrESrV0=; b=SJqt6Ho1 tpU3kQ7HY5RRraEunMOGbROhKq403yvAZNEEnsOa40vYba31cZ7yyVFq6vX5TQKO a+/w255PHxVOuAu/czyGe0wimKCwV9omsi1UGI7+KnBjUWspGPHS1JSvjyHofT1h 34EnBgRs1wCxiwuRaxR2yX+NM2T1BnaHt/n4EaCreK0ji3iPqM+sug3BZLRKM9Xf 4ujN/w/rrGnkIY9DI9QPIjTqtb8vmh8SGiFddhxXCFyhkLItR804LS9JIb+w9SVJ 7daZ8fOfsUH/lBJoQt7fQjs6jTQmP8jvMLiMaGCMEh+vQMCaEUajnUniW13Q+IY9 RXVeHSICD1d+kg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrjeeggddutdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucfpohcuuggrthgvuchfihgvlhguucdlgeelmdenuc fjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpeftvghpohhsihhtohhrhicu tegtthhivhhithihucfuuhhmmhgrrhihuceuohhtuceoughopghnohhtpghrvghplhihse hmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeefvdduteejvdefkeehieevuefg fefhteetveegffekffefteffvdelheduieetnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 8 Aug 2021 03:34:06 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============8111245528425139405==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20210808074048.151BF3A1FAC@ietfa.amsl.com> Date: Sun, 8 Aug 2021 00:40:48 -0700 (PDT) Archived-At: Subject: [Cellar] Weekly github digest (CELLAR Activity Summary) 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, 08 Aug 2021 07:40:53 -0000 --===============8111245528425139405== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Pull requests ------------- * ietf-wg-cellar/matroska-specification (+0/-2/=F0=9F=92=AC1) 1 pull requests received 1 new comments: - #526 Fix typos of "identifier" and "interpretation" (1 by robUx4) https://github.com/ietf-wg-cellar/matroska-specification/pull/526 [bug]= [spec_main]=20 2 pull requests merged: - fix some Markdown formatting https://github.com/ietf-wg-cellar/matroska-specification/pull/520 [form= atting]=20 - Fix typos of "identifier" and "interpretation" https://github.com/ietf-wg-cellar/matroska-specification/pull/526 [bug]= [spec_main]=20 * FFmpeg/FFV1 (+0/-1/=F0=9F=92=AC0) 1 pull requests merged: - Auth48 upstream take 2 https://github.com/FFmpeg/FFV1/pull/266=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-cellar/ebml-specification * https://github.com/ietf-wg-cellar/matroska-specification * https://github.com/FFmpeg/FFV1 * https://github.com/ietf-wg-cellar/Cellar-FLAC * https://github.com/ietf-wg-cellar/chair-notes --===============8111245528425139405== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

Sunday August 08, 2021

Events without label "editorial"

Pull requests

ietf-wg-cellar/matroska-specification (+0/-2/=F0=9F=92=AC1)

1 pull requests received 1 new comments:

2 pull requests merged:

FFmpeg/FFV1 (+0/-1/=F0=9F=92=AC0)

1 pull requests merged:

Repositories tracked by this digest:

--===============8111245528425139405==-- From nobody Mon Aug 9 12:39:23 2021 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 660713A1411 for ; Mon, 9 Aug 2021 12:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 gwjy4fwUFD_C for ; Mon, 9 Aug 2021 12:39:15 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 607513A140F for ; Mon, 9 Aug 2021 12:39:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 4FC42389B7 for ; Mon, 9 Aug 2021 15:43:47 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CJ8HEHvna10S for ; Mon, 9 Aug 2021 15:43:41 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B037F389B3 for ; Mon, 9 Aug 2021 15:43:41 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C4F09622 for ; Mon, 9 Aug 2021 15:39:06 -0400 (EDT) From: Michael Richardson To: cellar@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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] [ietf-wg-cellar/matroska-specification] register MIME types in the IANA considerations (#529) 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, 09 Aug 2021 19:39:22 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Spencer Dawkins wrote: > According to [the IANA Media Types > registry](https://www.iana.org/assignments/media-types/media-types.xh= tml), > some guy named @mskucherawy is a backup reviewer for Media Types, and > he's also the AD who would be doing initial AD review on the Matroska > drafts. @mcr, do we need to ask him about this resolution? > As part of IESG Evaluation, IANA is asked to review all documents for > possible IANA actions, and I usually try to ask for early IANA review > when registries are under Expert Review registration procedures, but > since this resolution is an "IANA **non-action**", I think it would = be > especially good to have that conversation directly with Murray before > we get anywhere close to requesting publication. I agree: lets have a conversation first. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmERhFoACgkQgItw+93Q 3WU0eQf9Hm/dbqID7OAGK9iS5s98gTHihOmsE3ab+JxTKUkHVndBWAPyOmhQyFeX KIukMFLI2wmG+URkVFPfxpwkwuesJwthARPfET8FhtQAlExxypq5OuftDV/jpILj xgGfzRYhqfRpVNoida7HPeeQgI53iXcaUV/WgcKCyBdSiRCyS4CUMF++egz/vXGm AMIskt1anP3kNXe9EKzexjHYDFM+4JT0Mv1S4lkbfhl8nQXdYg3F2kpoTy3FgVZU GYhVsh2Oh8n3nirUWA74PgdzX04vUOh6UWxBpxAg1HreP7OfjMeJbYU5t2LenUhx 9fNIliXSATnq4pEG+RLBrQMYeNOi0Q== =BpXy -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 10 10:18:15 2021 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 B00223A152E for ; Tue, 10 Aug 2021 10:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 (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 eiij-VPyX56h for ; Tue, 10 Aug 2021 10:18:11 -0700 (PDT) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (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 C037B3A152D for ; Tue, 10 Aug 2021 10:18:10 -0700 (PDT) Received: by mail-vs1-xe35.google.com with SMTP id b10so252441vsp.2 for ; Tue, 10 Aug 2021 10:18:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=sS24kkWj4n2lTiQHGetsq5+V1L06fJEaUnTInA2+yGE=; b=s9tN2qs7lUK2CsB26kfjJwUOwx9ZyD2Dz/lOcUDOfFHtLg1vEC6goyP+AHuMnHQlFu +liVhF05GG08a7LMQ0C1UQfvpHwU6PYzKgK1awLv79XsmWo8g1VxyThGcMzpsD/RXWcW xqOgd++kYomeiu7DIuUZ06Awrz25xUgWaNibWxS+DWvU+8rd0pKVW15qC8/uTxlLmmb9 h0k+BRExE/avgLKCrtzr6RiHYC2wEhyUwVgCbOXUPjlXWIrpcgl7/JCT5CE3o64QHySj qRznxECJn5qBsqBg8ETlxXu56BeeTHhQ7Gd0u8CQ9HI/0mg0SKpp3Z/NOvbkJQq5+TyE DM4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=sS24kkWj4n2lTiQHGetsq5+V1L06fJEaUnTInA2+yGE=; b=uaqRIkAhhruP6RHPcbvy/2lIStLq6332ueUsYXyXaprbENgsJhG7oYTRBIxE6Se0Db p1uqBoOe8JHzpYSc3gqdn+DH3N+apZqdwo4856eI2db4Uq0YNmQxN9lCc9zYX8P/4VyW +mrSx2ZoLSLOxBxxy1KJHam1w1VWamRII+OlmqhBh3Xn9Wz49CuD6c+YalMZsbytx3YZ h0t3IUl0Wa7okNZR8sHKVIsU1dFPSlg9Pe+oL4obfXsNDR//xP/2fcViWeWgXaE0p8g5 D/uKFjJ7LuTxTSE30oWtaUkro1BldeXVrfCytcUJSQ0BH9Frj2o/JE3oPdyMsn+YeiTU p05g== X-Gm-Message-State: AOAM531GVQE0BymMaONo6jLI9g7lGAYQgjhiGf2Vnf6QWeLTFyfNKxng iKmDGT0D4InuDO/VWU0DcGbSk4VLptnnZNVHxIM= X-Google-Smtp-Source: ABdhPJzWk5WofW/W75ji5a6kftz/2nHfgJb5WpcsaZT2Pp8E/Yj1sv2t0TXYbYtE/9AQHwgAXQTRns5O2WnothvPR/M= X-Received: by 2002:a67:f854:: with SMTP id b20mr23303085vsp.32.1628615889001; Tue, 10 Aug 2021 10:18:09 -0700 (PDT) MIME-Version: 1.0 From: Spencer Dawkins at IETF Date: Tue, 10 Aug 2021 12:17:42 -0500 Message-ID: To: Murray Kucherawy Cc: Francesca Palombini , Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="0000000000008a1f5b05c937af18" Archived-At: Subject: [Cellar] Conversation about a NON-IANA request in Matroska 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 Aug 2021 17:18:14 -0000 --0000000000008a1f5b05c937af18 Content-Type: text/plain; charset="UTF-8" Hi, Murray, the backup expert reviewer for Media Types, and our responsible AD, Cellar is working on the Matroska specification, and one issue we've tripped over is that Matrosks implementations have traditionally used unregistered MIME types such as "video/x-matroska" and file extension ".mkv", which have never been registered in the Media Types registry, and (for extra credit) use "x-dash" notation that someone is likely to ask us to change, if we were registering something now. Specifically, the media types mentioned in https://github.com/ietf-wg-cellar/matroska-specification/pull/529/files have been in use for up to 19 years, and the sense of the Github discussion is that actually registering them now won't have much impact on anything. (You should be tagged in that PR, and that's where most of the discussion I've seen has happened) And we'd prefer not to start that conversation during AD Evaluation, IETF Last Call, or (especially not!) during IESG Evaluation and formal IANA review. As this work moves forward in the IETF stream, we wanted to ask, is this a thing we should talk with you about, sooner rather than later? Best, Spencer --0000000000008a1f5b05c937af18 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Murray, the backup expert reviewer for Media Types, an= d our responsible AD,

Cellar is working on the Matroska = specification, and one issue we've tripped over is that Matrosks implem= entations have traditionally used unregistered MIME types such as=C2=A0&quo= t;video/x-matroska" and file extension ".mkv", which have ne= ver been registered=C2=A0in the Media Types registry, and (for extra=C2=A0c= redit) use "x-dash" notation that someone is likely to ask us to = change, if we were registering=C2=A0something now.=C2=A0

Specifically, the media types mentioned in=C2=A0https://git= hub.com/ietf-wg-cellar/matroska-specification/pull/529/files have been = in use for up to 19 years, and the sense of the Github discussion is that a= ctually registering them now won't have much impact on anything.
<= div>
(You should be tagged in that PR, and that's where m= ost of the discussion I've seen has happened)

= And we'd prefer not to start that conversation during AD Evaluation, IE= TF Last Call, or (especially not!) during IESG Evaluation and formal IANA r= eview.=C2=A0

As this work moves forward in the IET= F stream, we wanted to ask, is this a thing we should talk with you about, = sooner rather than later?

Best,

Spencer
--0000000000008a1f5b05c937af18-- From nobody Thu Aug 12 11:22:33 2021 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 B22BB3A4558 for ; Thu, 12 Aug 2021 11:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 J2H-hhpmXss2 for ; Thu, 12 Aug 2021 11:22:26 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 734043A4557 for ; Thu, 12 Aug 2021 11:22:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9B3BB389B1 for ; Thu, 12 Aug 2021 14:27:07 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id u86TNFjxZOS8 for ; Thu, 12 Aug 2021 14:27:03 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 39497389B0 for ; Thu, 12 Aug 2021 14:27:03 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BD2E3A0 for ; Thu, 12 Aug 2021 14:22:17 -0400 (EDT) From: Michael Richardson To: cellar@ietf.org In-Reply-To: <162878988734.14553.1920203123749739326@ietfa.amsl.com> References: <162878988734.14553.1920203123749739326@ietfa.amsl.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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] New Non-WG Mailing List: moq 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, 12 Aug 2021 18:22:32 -0000 A new IETF non-working group email list has been created. List address:=C2=A0moq@ietf.org Archive:=C2=A0https://mailarchive.ietf.org/arch/browse/moq To subscribe:=C2=A0https://www.ietf.org/mailman/listinfo/moq Purpose: The IETF community expressed interested in standardizing a new protocol tha= t is specifically tailored to video transfer leveraging QUIC as the underlying transport. Thi= s list is to facilitate the discussion including the following topics: + General discussion of the video ingest and distribution problem space + Challenges and limitations of existing protocols + A draft charter for a new working group + Specific proposals relevant to this problem space This list belongs to IETF area: ART For additional information, please contact the list administrators. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From nobody Sun Aug 15 00:34:37 2021 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 CC5803A0A87 for ; Sun, 15 Aug 2021 00:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=FpEojsi6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lEuZywiw 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 3m2AUhfRwL0a for ; Sun, 15 Aug 2021 00:34:20 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18BEA3A0A39 for ; Sun, 15 Aug 2021 00:34:19 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 2DEB75C00FE for ; Sun, 15 Aug 2021 03:34:19 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sun, 15 Aug 2021 03:34:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm3; bh=+FDqR4qacYC QNebDFOJJLqHdWeTHP3E0tWXLTBNPo0c=; b=FpEojsi6QTw+8cb7WmhpullwtoP w/wL/Ysm5Opu9zI6gpgeEQb2MtCHuc4xlJrEhkTAcjBASOQ0WQ1hSgXVjQrFjh+f XuecYzElzhgMwqGjPRXaO69Lw9tzgtvXjTJy8C8p5WR/KpSZCtqzseqa+BYEfHgp AeIdvGnsqb27+ePdD9oxyqK6zU6WjHGWsarU10lBmzOwXtEgogvohF8+krtmZe7y 8Z8JzJ/J5rNI7QBA/AtmOEp4aDPaIjkfZ+JjB8ujcF2+v7wapz2OSP2Sl2CJNpN9 kZmyalD0zgPgVYhrX4AY0wpnQ9WOX1Eh6p71h7DM7MaenNR/Hvr0ea0dZHg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:from:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=+FDqR4qacYCQNebDFOJJLqHdWeTHP3E0tWXLTBNPo0c=; b=lEuZywiw lwNBIeRzMeIuouVOENSg/U5plN51DWzrTNfddQGX/RHbv+19hmJFihKDCX17UgES /8EjCnBYg7S5wVSTG+SOw0awCQmiVYAl80MD2j8X4fDSnD4Tyujn+qg2KGWEjBNP 4JKpJBn9QrJyrdVZioClhRYUmYLPSxjZPRg0n7Cba5CapCkps+usS8Tfqm0AOitg JntFzsmMq2vRyMCdMbTRoNCkv2xgQ8EoLqHmaiOvdHDGg3SO7f/8r2QTEtIlnRXH z8oCnllXZZbOc5wbyv+744mgef92kcRZtre9mITbLAgwZuWWkZqkzSjx+dgMJxfH byLGHL7LpA8xKw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrkeekgdduvddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucfpohcuuggrthgvuchfihgvlhguucdlgeelmdenuc fjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpeftvghpohhsihhtohhrhicu tegtthhivhhithihucfuuhhmmhgrrhihuceuohhtuceoughopghnohhtpghrvghplhihse hmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeefvdduteejvdefkeehieevuefg fefhteetveegffekffefteffvdelheduieetnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucevlhhushhtvghrufhiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 15 Aug 2021 03:34:19 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============2394543180928435036==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20210815073420.18BEA3A0A39@ietfa.amsl.com> Date: Sun, 15 Aug 2021 00:34:19 -0700 (PDT) Archived-At: Subject: [Cellar] Weekly github digest (CELLAR Activity Summary) 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 Aug 2021 07:34:35 -0000 --===============2394543180928435036== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Pull requests ------------- * ietf-wg-cellar/matroska-specification (+6/-1/=F0=9F=92=AC3) 6 pull requests submitted: - rename the "restrictions" field to "possible values" (by robUx4) https://github.com/ietf-wg-cellar/matroska-specification/pull/532 [form= atting]=20 - nit: UK colours > US colors (by retokromer) https://github.com/ietf-wg-cellar/matroska-specification/pull/531=20 - Add some encryption/compression links (by robUx4) https://github.com/ietf-wg-cellar/matroska-specification/pull/530 [enha= ncement] [clarifications] [spec_main]=20 - register MIME types in the IANA considerations (by robUx4) https://github.com/ietf-wg-cellar/matroska-specification/pull/529 [enha= ncement] [clarifications] [spec_main]=20 - Really deprecate TimeSlice elements (by robUx4) https://github.com/ietf-wg-cellar/matroska-specification/pull/528 [bug]= [clarifications] [spec_main]=20 - only include the definition for dead elements (by robUx4) https://github.com/ietf-wg-cellar/matroska-specification/pull/527 [form= atting] [spec_main]=20 3 pull requests received 3 new comments: - #532 rename the "restrictions" field to "possible values" (1 by retokro= mer) https://github.com/ietf-wg-cellar/matroska-specification/pull/532 [form= atting]=20 - #529 register MIME types in the IANA considerations (1 by SpencerDawkin= s) https://github.com/ietf-wg-cellar/matroska-specification/pull/529 [enha= ncement] [clarifications] [spec_main]=20 - #521 Rewrite timestamp intepretations using ticks (1 by robUx4) https://github.com/ietf-wg-cellar/matroska-specification/pull/521 [clar= ifications]=20 1 pull requests merged: - nit: UK colours > US colors https://github.com/ietf-wg-cellar/matroska-specification/pull/531 [bug]= [spec_main]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-cellar/ebml-specification * https://github.com/ietf-wg-cellar/matroska-specification * https://github.com/FFmpeg/FFV1 * https://github.com/ietf-wg-cellar/Cellar-FLAC * https://github.com/ietf-wg-cellar/chair-notes --===============2394543180928435036== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

Sunday August 15, 2021

Events without label "editorial"

Pull requests

ietf-wg-cellar/matroska-specification (+6/-1/=F0=9F=92=AC3)

6 pull requests submitted:

3 pull requests received 3 new comments:

1 pull requests merged:

Repositories tracked by this digest:

--===============2394543180928435036==-- From nobody Wed Aug 18 14:54:09 2021 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 93F863A0ADE for ; Wed, 18 Aug 2021 14:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 (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 ut0c1z36yMIm for ; Wed, 18 Aug 2021 14:54:04 -0700 (PDT) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (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 62F6D3A0AC1 for ; Wed, 18 Aug 2021 14:54:04 -0700 (PDT) Received: by mail-vs1-xe35.google.com with SMTP id v26so2794762vsa.0 for ; Wed, 18 Aug 2021 14:54:04 -0700 (PDT) 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=AhMOg+zPQ5hSKXReDH3Crvk291S2P0DUkIkIxm577aM=; b=X2f0bbbi4rPD1I0vMixVz048o0VIEqR2Kf9uNvx0ZgLgOcIZt/sbFyiPd6+T3uRZ3Q cWUfzdikdbVbKq/iLLfb4XU/eTINxN4ungmhY6YzRzKvJ1F55TMi0YD7hQ3Agwslrg/V rLBa50JJltCXzMIvlUEtPbIWyaeE7iHD+PEeL+dQ4+01soqQR70DuxEE7sd+7G4Y9bD5 3VKLcnT7Y32KbZgLLp+F4Spe3/hc6oD+hTqmFBlzy1/qvj9Fgwg9uE83/0fLaHFRIIJQ sl2f1ym4G273pQGh+mYtHqBzLLf9BQ9aNTGuUaUvm+hQtAMVFYiLMXMla698t1d5nCTi P/RA== 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=AhMOg+zPQ5hSKXReDH3Crvk291S2P0DUkIkIxm577aM=; b=RNCrtM8rnsiwVSLJ1/Y6u4KnE7L9OqH35KUciUwHJS0eVOh62b8QPui0GTmPf6lNuY RICz3AiRCEseZCjP7L8C+eKFBwTICs9CSRuzerSBY2WpzS2YPseazJL9gzDZzU1YeKPk 4NrQGnIZj1IL+bZ1j5ObNbfcE5zdtFABCi7gEsmD9NcLpgePEpkdL/2FegBtDl0fk4DF YYJaLpWvudCIHDSNo58mqEWcMrGNCgfkcTJp4UHq4WYTqZncQoz8yntCpzTlA3okMtGC 7oOPt8+Uvdm2XPvSKEDGK/MiR3ADjKKYPBiv1xknjZOcMM6sQegfGSa4qO0dqL4cI/mz RtzQ== X-Gm-Message-State: AOAM530yy2XSFTriKD2sEaAVkIdrZI0aY9w+b2Xp68gGHBfNmtnjvgaN i9/fG5cyDl6F/OgmRGV/HsQE2LOlEdziYTRMhvo= X-Google-Smtp-Source: ABdhPJyQUHXELBCdvlUDVanaMceEBBWZWhNXg1bjEnDmJHoluzycd04Bc28GaQmjze5QDkljAlMnXtLIcQ+M8zTnExQ= X-Received: by 2002:a67:7ccd:: with SMTP id x196mr10011687vsc.7.1629323641598; Wed, 18 Aug 2021 14:54:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Spencer Dawkins at IETF Date: Wed, 18 Aug 2021 16:53:35 -0500 Message-ID: To: Murray Kucherawy Cc: Francesca Palombini , Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="000000000000e1b4fc05c9dc78cd" Archived-At: Subject: Re: [Cellar] Conversation about a NON-IANA request in Matroska 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 Aug 2021 21:54:08 -0000 --000000000000e1b4fc05c9dc78cd Content-Type: text/plain; charset="UTF-8" Hi, Murray, Just following up - have you had an opportunity to think about this yet? If you have questions, Cellar is having our monthly interim meeting next Tuesday, and you are, of course, welcome to swing by! Best, Spencer On Tue, Aug 10, 2021 at 12:17 PM Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Hi, Murray, the backup expert reviewer for Media Types, and our > responsible AD, > > Cellar is working on the Matroska specification, and one issue we've > tripped over is that Matrosks implementations have traditionally used > unregistered MIME types such as "video/x-matroska" and file extension > ".mkv", which have never been registered in the Media Types registry, and > (for extra credit) use "x-dash" notation that someone is likely to ask us > to change, if we were registering something now. > > Specifically, the media types mentioned in > https://github.com/ietf-wg-cellar/matroska-specification/pull/529/files > have been in use for up to 19 years, and the sense of the Github discussion > is that actually registering them now won't have much impact on anything. > > (You should be tagged in that PR, and that's where most of the discussion > I've seen has happened) > > And we'd prefer not to start that conversation during AD Evaluation, IETF > Last Call, or (especially not!) during IESG Evaluation and formal IANA > review. > > As this work moves forward in the IETF stream, we wanted to ask, is this a > thing we should talk with you about, sooner rather than later? > > Best, > > Spencer > --000000000000e1b4fc05c9dc78cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Murray,

Just following up - have you had an opportunity to think about this= yet?

If you have questions, Cellar is having our = monthly interim meeting next Tuesday, and you are, of course, welcome to sw= ing by!

Best,

Spencer
On T= ue, Aug 10, 2021 at 12:17 PM Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:=
Hi, Murray, the backup expert reviewer for Media Types, and our responsib= le AD,

Cellar is working on the Matroska specification, = and one issue we've tripped over is that Matrosks implementations have = traditionally used unregistered MIME types such as=C2=A0"video/x-matro= ska" and file extension ".mkv", which have never been regist= ered=C2=A0in the Media Types registry, and (for extra=C2=A0credit) use &quo= t;x-dash" notation that someone is likely to ask us to change, if we w= ere registering=C2=A0something now.=C2=A0

Specific= ally, the media types mentioned in=C2=A0https://= github.com/ietf-wg-cellar/matroska-specification/pull/529/files have be= en in use for up to 19 years, and the sense of the Github discussion is tha= t actually registering them now won't have much impact on anything.

(You should be tagged in that PR, and that's wher= e most of the discussion I've seen has happened)

And we'd prefer not to start that conversation during AD Evaluation,= IETF Last Call, or (especially not!) during IESG Evaluation and formal IAN= A review.=C2=A0

As this work moves forward in the = IETF stream, we wanted to ask, is this a thing we should talk with you abou= t, sooner rather than later?

Best,

<= /div>
Spencer
--000000000000e1b4fc05c9dc78cd-- From nobody Wed Aug 18 15:31:47 2021 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 812673A0DE8 for ; Wed, 18 Aug 2021 15:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 (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 ys6LT2u3nQTK for ; Wed, 18 Aug 2021 15:31:41 -0700 (PDT) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 E7B443A0DE5 for ; Wed, 18 Aug 2021 15:31:40 -0700 (PDT) Received: by mail-ua1-x92e.google.com with SMTP id x21so1718941uau.0 for ; Wed, 18 Aug 2021 15:31:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=UQFgNRargMMj6IbmP0QPd+LN23u7gHIrnFRj++HjTe4=; b=jul6OIDG21nnEUgs+ReIfcKcb2wosvvWRSzD9hMceznQ5bVtMfgoUEubAUjj7miHpY yakX6417yTPS1gLz7WxakEXUeEZ9AywCXnBXKmRADiu5dzvEQ71XzU/dsXk9VNfhTNs6 CI3qwaYX7Zu8ES2oiE3tBy50HnQ6WWH5RfaAQU2ihBqgyyBRS+xQHgeKXxIyepQB6qnY SLEKdAEFTRFtgsfismEfSZnZxpoSJPQgS/tYUPTPOde4GDDkmyZvYrDTYgX/MHPCLlYr mBjgDCIHub8qtqnwUsrdlOQTtQQiVMxBLXAcewZTRAHzAQoLlAFPou4gv7Df+FHyWm7n ofBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=UQFgNRargMMj6IbmP0QPd+LN23u7gHIrnFRj++HjTe4=; b=jLRpdCtUw8zQmc/VlZ/pHMALmzmzUDrjJAQedbHrawS6iHf6i4cywDeYMZxuDAx5Id lWaLyxsk8V8q/OVzl6CLPknreZ+xrOCi5HWbWnZQDAV2thDtI1VkJlS6GJVM7d2+lu1s mRdLRX7R7iqsRe8olxyRMT2hSbY/EXFg5IwAASz1DrcdZkRpUPCRr6FJR7sl2tiVYut7 I/Q3xfMG9raSxhQFkjW/ponOkMYc6I82NfWlGhlG8iNvgvvPAyjUbp0Gzd0p0bM+Mg9a lCDen5iSzlXKfT/8M8eE5lihUaMLpRzxvu5xtgpFH5pjRsjRjBDfhofcDnxITJ4i/S8G Mylg== X-Gm-Message-State: AOAM530ft75UZy2YayOc1vsJozyZvxaJo44RiRJoezps/yG1Y2sBGBwW UmiF/mmSCMP4eRjXKCXbgaDb6rwx+xvQbAO0R0klGepsOGo= X-Google-Smtp-Source: ABdhPJxFqTaXrAmRZzM7wnvgLJNHwC4CB74MHi2tz7i3phPdFftZjVPeeGo9dhNEhd9jwiTBTqAjHdvSLcP8xXxhrmY= X-Received: by 2002:ab0:7299:: with SMTP id w25mr8874256uao.45.1629325898843; Wed, 18 Aug 2021 15:31:38 -0700 (PDT) MIME-Version: 1.0 From: Spencer Dawkins at IETF Date: Wed, 18 Aug 2021 17:31:12 -0500 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="0000000000006c88c305c9dcfff9" Archived-At: Subject: [Cellar] Agenda items for August Cellar meeting? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2021 22:31:46 -0000 --0000000000006c88c305c9dcfff9 Content-Type: text/plain; charset="UTF-8" Dear Cellar, Michael and I will be putting together our agenda for next week's meeting soon. I know we are finishing up AUTH48 on https://www.rfc-editor.org/auth48/rfc9043 - the RFC Editor has asked Murray to approve some non-editorial changes that happened after the IESG approved the draft for publication (this is normal, don't worry - all of the listed authors have approved the text). I've followed up with Murray about our question on IANA non-registration for IANA codepoints that Matroska used without registering. He said he'd take a look. Are there any other specific topics that we should put at the top of the agenda? Best, Spencer --0000000000006c88c305c9dcfff9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Cellar,

Michael and I will be putt= ing together our agenda for next week's meeting soon.

I know we are finishing up AUTH48 on=C2=A0https://www.rfc-editor.org/auth48/rfc9043 = - the RFC Editor has asked Murray to approve some non-editorial changes tha= t happened after the IESG approved=C2=A0the draft for publication (this is = normal, don't worry - all of the listed authors have approved the text)= .=C2=A0

I've followed up with Murray about our= question on IANA non-registration for IANA codepoints that Matroska used w= ithout registering. He said he'd take a look.

= Are there any other specific=C2=A0topics that we should put at the top of t= he agenda?

Best,

Spencer<= /div>
--0000000000006c88c305c9dcfff9-- From nobody Wed Aug 18 16:07:13 2021 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 B2BC43A1D11 for ; Wed, 18 Aug 2021 16:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 (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 fZqhOiYKG2tN for ; Wed, 18 Aug 2021 16:07:06 -0700 (PDT) Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 2DD5A3A1D0E for ; Wed, 18 Aug 2021 16:07:06 -0700 (PDT) Received: by mail-ua1-x933.google.com with SMTP id a4so1717634uae.6 for ; Wed, 18 Aug 2021 16:07:06 -0700 (PDT) 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=OG3WIFUy6CF6K0blWgiJlb7xnvzRNcwW16b+OV2vrTs=; b=N7YcxHEYsiqb60O9yrIRfm/GilL1sFUdGVLNo/Njwn2fygmwGYHmtQMRwBH1zvytR7 egPctuCWqhWLAwAZzMx+znF/6xYiAui5tztWPDcGchE+/+oBaCz865oiOu4L9TMn/uYc 6tr7WA6b3EVO9RnGI9jaNWUSImCr5YcVP1R0q7VUmgxDu8Tkb4nv/r7eOOBjbt6AmQU6 F+B20nRBBaTqRU3x5xuiS0jFMgT6cEyDuT1pKF17haNTKqtePuScKt0HrzfQ5XRwqhEI vT/5uFrSXicq5e6NxMfFuhikrxswWuCCT/wPbK8VGppjprzfCB3kfvxmKbR4PEhbS8nB /0KQ== 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=OG3WIFUy6CF6K0blWgiJlb7xnvzRNcwW16b+OV2vrTs=; b=Wi1053cw9/kjfdb3bm0umlF0Sxnv+yoDnMnMcnWyF8xdzPi+biIkfNQIder+kkk0Yv z/D0vZ9YvTs8nsfkqGjAHF9E6QnlNWIQwVSQi2a1FvlNX2Z18rCym2oylX42RXnmnQXV CSmViINtM9AiPpS9qwePbrHtgynHvC3DjH/JJuEtCYE3TMzUZxiXCFi6pVyx0RabfWgo Gi9fTaUf0U0XfSwVUtd8kmALSGvDSwCYVohwUYqjN8BxhIMn7hAO4JobWEiBQRlPEGOd J1HjFWDDa6EnG1EbC+QOm2g8jhK+kz4xKjDAKmV6OD3DjW4o0GbHOmYSWkJ+yl8xZcto usrA== X-Gm-Message-State: AOAM533S5nfVQ+xDwceRGb+5rIMIaNQKRGvAdgpIk+lUAakIfY6feEdL Qf5erEpgomCSt9hqMg/jKMop2Vj/Ev3mGHcVQs4= X-Google-Smtp-Source: ABdhPJyYoWNbGtrCk2kOdLs1tQyA7F5H0GJRku8qG3+UjCR9sOC/Ox2eeNvg4kpqrIel3sjPHwfT1NVzpxH4asEUbY0= X-Received: by 2002:ab0:205a:: with SMTP id g26mr9158804ual.101.1629328023764; Wed, 18 Aug 2021 16:07:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Wed, 18 Aug 2021 16:06:52 -0700 Message-ID: To: Spencer Dawkins at IETF Cc: Francesca Palombini , Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="00000000000014420205c9dd7ebb" Archived-At: Subject: Re: [Cellar] Conversation about a NON-IANA request in Matroska 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 Aug 2021 23:07:12 -0000 --00000000000014420205c9dd7ebb Content-Type: text/plain; charset="UTF-8" Hi there, sorry for the delay. On Tue, Aug 10, 2021 at 10:18 AM Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Hi, Murray, the backup expert reviewer for Media Types, and our > responsible AD, > You flatter me. Cellar is working on the Matroska specification, and one issue we've > tripped over is that Matrosks implementations have traditionally used > unregistered MIME types such as "video/x-matroska" and file extension > ".mkv", which have never been registered in the Media Types registry, and > (for extra credit) use "x-dash" notation that someone is likely to ask us > to change, if we were registering something now. > > Specifically, the media types mentioned in > https://github.com/ietf-wg-cellar/matroska-specification/pull/529/files > have been in use for up to 19 years, and the sense of the Github discussion > is that actually registering them now won't have much impact on anything. > > (You should be tagged in that PR, and that's where most of the discussion > I've seen has happened) > > And we'd prefer not to start that conversation during AD Evaluation, IETF > Last Call, or (especially not!) during IESG Evaluation and formal IANA > review. > > As this work moves forward in the IETF stream, we wanted to ask, is this a > thing we should talk with you about, sooner rather than later? > Well, glad you asked. In the spirit of the media types registry, I'm inclined to say we'd rather have something registered under what's perhaps a bit of a non-ideal name so that people can interoperate from a common, registered reference, than not. This is why the rules for the vendor tree are so loose. So as your AD, I'd be prepared to argue in favor of registering the x-dash name, and including a sentence or two about why we're making an exception with respect to BCP 178 this time. Of course, we can confirm with the actual media type reviewers that I'm not crazy here. -MSK --00000000000014420205c9dd7ebb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi there, sorry for the delay.
<= br>
On Tue,= Aug 10, 2021 at 10:18 AM Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
H= i, Murray, the backup expert reviewer for Media Types, and our responsible = AD,

You flatter me.

Cellar is working on the Matroska specification, and one issue we've t= ripped over is that Matrosks implementations have traditionally used unregi= stered MIME types such as=C2=A0"video/x-matroska" and file extens= ion ".mkv", which have never been registered=C2=A0in the Media Ty= pes registry, and (for extra=C2=A0credit) use "x-dash" notation t= hat someone is likely to ask us to change, if we were registering=C2=A0some= thing now.=C2=A0

Specifically, the media types men= tioned in=C2=A0https://github.com/ietf-wg-cellar= /matroska-specification/pull/529/files have been in use for up to 19 ye= ars, and the sense of the Github discussion is that actually registering th= em now won't have much impact on anything.

(Yo= u should be tagged in that PR, and that's where most of the discussion = I've seen has happened)

And we'd prefer no= t to start that conversation during AD Evaluation, IETF Last Call, or (espe= cially not!) during IESG Evaluation and formal IANA review.=C2=A0

As this work moves forward in the IETF stream, we wanted to= ask, is this a thing we should talk with you about, sooner rather than lat= er?

Well, glad you asked.
=

In the spirit of the media types registry, I'm inclined to say we'd r= ather have something registered under what's perhaps a bit of a non-ideal na= me so that people can=20 interoperate from a common, registered reference, than not. This is why the rules for the vendor tree are so loose.

So as your AD, I'd be prepar= ed to argue in favor of registering the x-dash name, and including a senten= ce or two about why we're making an exception with respect to BCP 178 t= his time.=C2=A0 Of course, we can confirm with the actual media type review= ers that I'm not crazy here.

<= /span>
-MSK
--00000000000014420205c9dd7ebb-- From nobody Thu Aug 19 08:22:09 2021 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 B5A523A1FA2 for ; Thu, 19 Aug 2021 08:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 cB70EDDCuhzv for ; Thu, 19 Aug 2021 08:21:56 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C6F63A1FA3 for ; Thu, 19 Aug 2021 08:21:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 6276F389B0; Thu, 19 Aug 2021 11:27:02 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id XCufRciQP5C7; Thu, 19 Aug 2021 11:26:57 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 6126B389AF; Thu, 19 Aug 2021 11:26:57 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9515A64; Thu, 19 Aug 2021 11:21:46 -0400 (EDT) From: Michael Richardson To: "Murray S. Kucherawy" , Spencer Dawkins at IETF , Codec Encoding for LossLess Archiving and Realtime transmission , Francesca Palombini In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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] Conversation about a NON-IANA request in Matroska 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 Aug 2021 15:22:01 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Murray S. Kucherawy wrote: > So as your AD, I'd be prepared to argue in favor of registering the > x-dash name, and including a sentence or two about why we're making an > exception with respect to BCP 178 this time. Of course, we can confi= rm > with the actual media type reviewers that I'm not crazy here. Could we register "dash" and "x-dash"? Could we write something like: Implementations MUST accept both in perpetuity. (that's easy to implement, and it's an archive format, so disk files and resource forks...) Until 2025, implementations SHOULD use video/x-matroska when creating files. After 2025, implementations SHOULD use video/matroska when creating files. (or another year sufficiently far in the future) =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmEedwoACgkQgItw+93Q 3WXN7QgAkDAKstW6cDc8xQ1Nj5cmcjJSBFveJmOpj2JRs22SoprhM+FcbgLVq5ae oWMrjKForjomVwTPl/b1JwYFK+GjnT+TaY4IJIFNT/8QIVgcQH+lBTvLVgMcEJ2q fSE6vQAMqhvENBzfQ05Pv+9SqskfybA/A6DeHe28GMUHRhTcc5QZuT/uF3EWe4U4 KNoVf5ZJb92qGNS0d57LU3gQOswnB8gayYGWrSo2KNu7qum0vVCYzqrTyhMmDNDV 4M+zT6uh2SJdajsyaZ7XbgYj/4CYuLdUzEFBnYRUUB+Yxoky9czQY8KnRcZBPfut ii7V+YCMw1Ms8+jq20BgurxHnY4T2A== =V1h8 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 19 08:36:04 2021 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 5EFBF3A207A for ; Thu, 19 Aug 2021 08:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mjWEjoFXSiE1 for ; Thu, 19 Aug 2021 08:35:56 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEDC23A2077 for ; Thu, 19 Aug 2021 08:35:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 12DA4389B6; Thu, 19 Aug 2021 11:41:04 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id PNTSQuR79C5D; Thu, 19 Aug 2021 11:40:58 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B657B389AE; Thu, 19 Aug 2021 11:40:58 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E197464; Thu, 19 Aug 2021 11:35:47 -0400 (EDT) From: Michael Richardson To: Spencer Dawkins at IETF , Codec Encoding for LossLess Archiving and Realtime transmission In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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] Agenda items for August Cellar meeting? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2021 15:36:03 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Spencer Dawkins at IETF wrote: > Are there any other specific topics that we should put at the top of > the agenda? For health reasons, I've asked our ADs to relieve me of some my duties as a co-chair of WGs. (Two WGs and a BOF-almost-WG is too many) The challenge is that the communities of each group are small, and it's hard to find people who are plugged-in enough to spend the time to care, yet, sufficiently uninvolved in the documents that their reclusal from the document won't be a problem. Perhaps there is someone else in this community who would like to help here. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmEeelMACgkQgItw+93Q 3WWwHAgAh7dONTxdb7oBuesyC8G8e1Xy8jE+Tv7YYzJOzDmlxHKIptcIVSvfQEWj Pt2B+J6w91RM2xE2sMVgHJfPNJw/vnFKAXKUVDR/myexQ2S7kqJjfGiotar+uEV1 UtXvWS2CBLhDUJEpTTiZh4NJ0LvwJizPYenWntb3qxl/Ab/0bIZgMq1BD8B9ElY2 /Akur/+5xbR63MW7hzG5BgSnhtDddiFx7e1izE7SxssaeRZiFM0UQq4eDHDFXeBO fCoQ83xBZV8OfExEJwOzN6IGhdS+4bVz80PItpkKKgPI0umlBLHbuAJ/i7Jnabcc qlEsSgTPRFKIzvEWdgGqYDzxtRxq7w== =G5/Y -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 19 12:05:14 2021 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 AC4DC3A170A for ; Thu, 19 Aug 2021 12:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 (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 0KboU6jdxpsr for ; Thu, 19 Aug 2021 12:05:06 -0700 (PDT) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 B4A403A1708 for ; Thu, 19 Aug 2021 12:05:06 -0700 (PDT) Received: by mail-vs1-xe2f.google.com with SMTP id a20so4689498vsh.4 for ; Thu, 19 Aug 2021 12:05:06 -0700 (PDT) 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=tBsNDm1NXk4P3vXxGi+AmWSdWDQkVKUGXPIxSTl9sx4=; b=lVfTcrjTTlopyi0Apmv+KHWB3ZpqU/aXgIomjhhq3VuQ+L07wYrQtNWlrQf0WSHejO 8/yIpud4FIe4DV20CObXr6Xmo1c9dVgfHphbDQorvIsuqNqQrnvel6jmc8j4nq06NS9k Km2ugFJMYQZRYPLdU1jGJ0mTYPFNxSJbA8570Z4jIAYhat7+QyK2q55UxmGzHFI6Keb3 nbEMYFGhovFZIzEK9LlA6qNFnchFGhRgdyFOFA0PpSKt7gOVBPVTnP6c6xpXsnmNG+i3 CmkIR+7MlyjX66cJmfX2QwVdowMqNIqrAAg4aGfe+qEYWz4iHUhaBkdkYriYE4chWFBm 70BA== 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=tBsNDm1NXk4P3vXxGi+AmWSdWDQkVKUGXPIxSTl9sx4=; b=uUdtmrde6nJqx3w3C8I8u8pmOiRwl9CxmGT4b38UmxZ5fkTCzVdvxBhCS+iySGZm5D pmqpCzOlfHiwaH2uM7tR56ZYWx51N0T4Zpr6o8jUvt57Y4Ti00U0E9r49XumIMHRvgmn fjO/JMydYBKLsBSucHqYvSYV317LnmIm/KDn3hjvrKwtazRiRTtlnDrFoN6AAkzR6Dsj mf7HPeZ2+dKyINQ8sPd1aC+R+oJ1c0VBcCeUaSu3yLCE4w/Wr5xeTskVvFBC3oNttTOn MT9p65YuVvO7BJwAwrpSllL+SBjUDaf5RxZAiZq8gm3pZfotVLqZ2D0TjOP0WtdT8NX/ 3+EA== X-Gm-Message-State: AOAM530mUqAlwJGm7MwsOEGsPutYOZJpcH/K2jyaNvkEaoZik7SwjCDb y+3+W9cLEQsJrbmvAJPjeJAhr2XbZHqCGXI8UHs= X-Google-Smtp-Source: ABdhPJwkgVepKhLFYcRvYG250hVySob2srrNmasHXrdsd0yzYJ681RyPHQ32HembzCZ8uGJgJ/3aRdGpk83y7iMfBtI= X-Received: by 2002:a67:df0c:: with SMTP id s12mr14095787vsk.0.1629399903554; Thu, 19 Aug 2021 12:05:03 -0700 (PDT) MIME-Version: 1.0 References: <4945.1629386506@localhost> In-Reply-To: <4945.1629386506@localhost> From: "Murray S. Kucherawy" Date: Thu, 19 Aug 2021 12:04:51 -0700 Message-ID: To: Michael Richardson Cc: Spencer Dawkins at IETF , Codec Encoding for LossLess Archiving and Realtime transmission , Francesca Palombini Content-Type: multipart/alternative; boundary="00000000000072d28d05c9ee3a0f" Archived-At: Subject: Re: [Cellar] Conversation about a NON-IANA request in Matroska 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 Aug 2021 19:05:13 -0000 --00000000000072d28d05c9ee3a0f Content-Type: text/plain; charset="UTF-8" On Thu, Aug 19, 2021 at 8:21 AM Michael Richardson wrote: > Murray S. Kucherawy wrote: > > So as your AD, I'd be prepared to argue in favor of registering the > > x-dash name, and including a sentence or two about why we're making > an > > exception with respect to BCP 178 this time. Of course, we can > confirm > > with the actual media type reviewers that I'm not crazy here. > > Could we register "dash" and "x-dash"? > You could, but... Could we write something like: > > Implementations MUST accept both in perpetuity. > (that's easy to implement, and it's an archive format, so disk files and > resource forks...) > > Until 2025, implementations SHOULD use video/x-matroska when creating > files. > After 2025, implementations SHOULD use video/matroska when creating files. > > (or another year sufficiently far in the future) > If you're going to register "x-dash" on the basis of indeterminate inertia, I would argue the "dash" one isn't worth registering. I would encourage something like: - register "dash", indicating it is the current and the only officially supported one - register "x-dash", indicating that it's officially deprecated and new implementations MUST NOT generate it - indicate that for supporting legacy implementations, all implementations SHOULD accept both At some point in the future if/when you are convinced nothing generates "x-dash" anymore, you could do an update that turns "x-dash" into an error. -MSK --00000000000072d28d05c9ee3a0f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Aug 19, 2021 at 8:21 AM Michael R= ichardson <mcr+ietf@sandelman= .ca> wrote:
Murray S. Kucherawy <superuser@gmail.com> wrote:
=C2=A0 =C2=A0 > So as your AD, I'd be prepared to argue in favor of = registering the
=C2=A0 =C2=A0 > x-dash name, and including a sentence or two about why w= e're making an
=C2=A0 =C2=A0 > exception with respect to BCP 178 this time.=C2=A0 Of co= urse, we can confirm
=C2=A0 =C2=A0 > with the actual media type reviewers that I'm not cr= azy here.

Could we register "dash" and "x-dash"?
=

You could, but...

Could we write something like:

Implementations MUST accept both in perpetuity.
(that's easy to implement, and it's an archive format, so disk file= s and
resource forks...)

Until 2025, implementations SHOULD use video/x-matroska when creating files= .
After 2025, implementations SHOULD use video/matroska when creating files.<= br>
(or another year sufficiently far in the future)

<= /div>
If you're going to register "x-dash" on the basis o= f indeterminate inertia, I would argue the "dash" one isn't w= orth registering.

I would encourage something like:
- register "dash", indicating it is the current and = the only officially supported one
- register "x-dash&quo= t;, indicating that it's officially deprecated and new implementations = MUST NOT generate it
- indicate that for supporting legacy im= plementations, all implementations SHOULD accept both

At = some point in the future if/when you are convinced nothing generates "= x-dash" anymore, you could do an update that turns "x-dash" = into an error.

-MSK
--00000000000072d28d05c9ee3a0f-- From nobody Thu Aug 19 13:01:35 2021 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 4ACCF3A1C8C for ; Thu, 19 Aug 2021 13:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7KvZujaGsStG for ; Thu, 19 Aug 2021 13:01:24 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 052A63A1C80 for ; Thu, 19 Aug 2021 13:01:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 5FBB4389A4; Thu, 19 Aug 2021 16:06:31 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id PbgMxCotbYsh; Thu, 19 Aug 2021 16:06:26 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 371EC38994; Thu, 19 Aug 2021 16:06:26 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8F46E78B; Thu, 19 Aug 2021 16:01:14 -0400 (EDT) From: Michael Richardson To: "Murray S. Kucherawy" cc: Spencer Dawkins at IETF , Codec Encoding for LossLess Archiving and Realtime transmission , Francesca Palombini In-Reply-To: References: <4945.1629386506@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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] Conversation about a NON-IANA request in Matroska 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 Aug 2021 20:01:33 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Murray S. Kucherawy wrote: >> Implementations MUST accept both in perpetuity. (that's easy to >> implement, and it's an archive format, so disk files and resource >> forks...) >> >> Until 2025, implementations SHOULD use video/x-matroska when creating >> files. After 2025, implementations SHOULD use video/matroska when >> creating files. >> >> (or another year sufficiently far in the future) >> > If you're going to register "x-dash" on the basis of indeterminate > inertia, I would argue the "dash" one isn't worth registering. okay. > I would encourage something like: > - register "dash", indicating it is the current and the only official= ly > supported one > - register "x-dash", indicating that it's officially > deprecated and new implementations MUST NOT generate it > - indicate that > for supporting legacy implementations, all implementations SHOULD > accept both > At some point in the future if/when you are convinced nothing generat= es > "x-dash" anymore, you could do an update that turns "x-dash" into an > error. That's why I suggested a transition date, so that this process could be essentially automatic. Readers would have some time to catch up. If readers will never catch up, then I agree, just go with "x-dash", althou= gh it sets a weird precedent to me. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmEeuIoACgkQgItw+93Q 3WW36Qf/SWTgM9vEhzIWcz2O6mTM9smXIcLebfDoZ/ULSX4Ct7NSfLszGHxOHpgt TlEDZmZhZxvLcswjWvfLJPjSEHEnBnf7s8ybQWoLonyZXkVktp8nFAABrYxD8yPx TEymsfH51tJIhreLtj4buTvpSpEaNSdh5F7+yIpN8v3C3ktjWzLX8r4oe3Q0gvO0 lJFrVTSy+t/sg0URoVnzrjhmf26mj6JvfSW3UBnmrqJGZ0ohqT2FvuJtmMOg7BTD 4QHDMpGG3Fh8XOUE9QKCGIOry45bojF8aTh+IJT4fS5JUNT1dgMCKtl2Y0WfujgC /AahzSUu6iJU+ochMhv0J3xdops+Eg== =pLKx -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 19 14:14:38 2021 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 1F1863A095F for ; Thu, 19 Aug 2021 14:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 (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 hgoAtsk4TMov for ; Thu, 19 Aug 2021 14:14:30 -0700 (PDT) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (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 7F1E73A0953 for ; Thu, 19 Aug 2021 14:14:30 -0700 (PDT) Received: by mail-vs1-xe30.google.com with SMTP id i1so4893003vsk.8 for ; Thu, 19 Aug 2021 14:14:30 -0700 (PDT) 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=aYy/3kFGIypQ6khHaEhVr7vyyC7UzcSVmKvmQQ6ZBnw=; b=Ld8yY9+M08uKmUyT400zuvgxFEY9VhM+TgHv24pPnQIWIuvoM4uyl4oEFcWBpp1HiC 9ID1aNMEuMDOBgIg3kj/q82LECp4CuuiqXbMzRe59Y3eFSbLwQXpImVwXdWMGSj6urpH N/n/X/T7DzUW95te3Xhk74wmzQi6/ycTDARD0qwtV9z4JdRSM4XqNvSOUN54eK1CttoE 2tEz7vuHP3T4a3UHbQukVnXXZyhrM4Re3UxZzRSHZD6HkOPQqoXXahPkyZh+0YyH72nw klW3jb8/WuCGRkYgn9CVQCwho14Io8XnpjOhjy6jNQiu46+Oc9zue5DMT/WJqJaiyTmn FQbw== 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=aYy/3kFGIypQ6khHaEhVr7vyyC7UzcSVmKvmQQ6ZBnw=; b=Pnf6pbEJoke8KmE8qhZLqTwxWeG8mDLKiC+GRY/fOQoWQPpmAFXpd3N80TwCb8qKH0 hfJSeL/B18Zkmy3bZ9o41gA2RziH8IFPfIqSy/DQSm20E3CLJe4e3NR9NQ1CcQCLokUc co8+pHknohVemN3eioKJ4Vqtbj+Ul27PiMRHGbpuElDR+zyXGoZW7ogBrZxme+63c+mi osEG/NwYAXmdtzv1H9hts5p9xTFcGyHbZ0BYtpHUb39Yk84zuD54vdYmHgCOfV+Rzi4B v1NY1qeELrAbJR3brHhgqpVC1HYgKPkZoxQ7qp4L4T1Jj8hdDV5YJeCwEA6qcZKqgexc cmYw== X-Gm-Message-State: AOAM530LrLm60Hd708mtNy2Ud52pR6hARVS1SEwCcz55PbulW/fD47sg NUNbxfwnllHrxMz4fFFGS8zlIzHn4eU7TlNR6SY= X-Google-Smtp-Source: ABdhPJxrTrW6Ge3Xi2em0uMNyFCjCbj6/m3sl3o1pkwcDy41NOA/KaOxgjyKO6j4X7F6RvLwrg+8ml8QDrF+R2vBHCM= X-Received: by 2002:a67:df0c:: with SMTP id s12mr14563381vsk.0.1629407667844; Thu, 19 Aug 2021 14:14:27 -0700 (PDT) MIME-Version: 1.0 References: <4945.1629386506@localhost> <22109.1629403274@localhost> In-Reply-To: <22109.1629403274@localhost> From: "Murray S. Kucherawy" Date: Thu, 19 Aug 2021 14:14:16 -0700 Message-ID: To: Michael Richardson Cc: Spencer Dawkins at IETF , Codec Encoding for LossLess Archiving and Realtime transmission , Francesca Palombini Content-Type: multipart/alternative; boundary="0000000000003c7c3305c9f009c2" Archived-At: Subject: Re: [Cellar] Conversation about a NON-IANA request in Matroska 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 Aug 2021 21:14:36 -0000 --0000000000003c7c3305c9f009c2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What I'm worried about is that picking a date effectively sets a flag day. Have we ever successfully asserted a flag day in a standards action before? But then the IETF has no control over whether anyone adheres to it, making it effectively arbitrary anyway. -MSK On Thu, Aug 19, 2021 at 1:01 PM Michael Richardson wrote: > > Murray S. Kucherawy wrote: > >> Implementations MUST accept both in perpetuity. (that's easy to > >> implement, and it's an archive format, so disk files and resource > >> forks...) > >> > >> Until 2025, implementations SHOULD use video/x-matroska when > creating > >> files. After 2025, implementations SHOULD use video/matroska when > >> creating files. > >> > >> (or another year sufficiently far in the future) > >> > > > If you're going to register "x-dash" on the basis of indeterminate > > inertia, I would argue the "dash" one isn't worth registering. > > okay. > > > I would encourage something like: > > > - register "dash", indicating it is the current and the only > officially > > supported one > > > - register "x-dash", indicating that it's officially > > deprecated and new implementations MUST NOT generate it > > > - indicate that > > for supporting legacy implementations, all implementations SHOULD > > accept both > > > At some point in the future if/when you are convinced nothing > generates > > "x-dash" anymore, you could do an update that turns "x-dash" into a= n > > error. > > That's why I suggested a transition date, so that this process could be > essentially automatic. Readers would have some time to catch up. > > If readers will never catch up, then I agree, just go with "x-dash", > although > it sets a weird precedent to me. > > -- > Michael Richardson . o O ( IPv6 I=C3=B8T consul= ting ) > Sandelman Software Works Inc, Ottawa and Worldwide > --0000000000003c7c3305c9f009c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What I'm worried about is that picking a date eff= ectively sets a flag day.=C2=A0 Have we ever successfully asserted a flag d= ay in a standards action before?

But then the IETF= has no control over whether anyone adheres to it, making it effectively ar= bitrary anyway.

-MSK

On Thu, Aug 19, 2021= at 1:01 PM Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Murray S. Kucherawy <superuser@gmail.com> wrote:
=C2=A0 =C2=A0 >> Implementations MUST accept both in perpetuity.=C2= =A0 (that's easy to
=C2=A0 =C2=A0 >> implement, and it's an archive format, so disk f= iles and resource
=C2=A0 =C2=A0 >> forks...)
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> Until 2025, implementations SHOULD use video/x-matro= ska when creating
=C2=A0 =C2=A0 >> files.=C2=A0 After 2025, implementations SHOULD use = video/matroska when
=C2=A0 =C2=A0 >> creating files.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> (or another year sufficiently far in the future)
=C2=A0 =C2=A0 >>

=C2=A0 =C2=A0 > If you're going to register "x-dash" on th= e basis of indeterminate
=C2=A0 =C2=A0 > inertia, I would argue the "dash" one isn'= t worth registering.

okay.

=C2=A0 =C2=A0 > I would encourage something like:

=C2=A0 =C2=A0 > - register "dash", indicating it is the curren= t and the only officially
=C2=A0 =C2=A0 > supported one

=C2=A0 =C2=A0 > - register "x-dash", indicating that it's = officially
=C2=A0 =C2=A0 > deprecated and new implementations MUST NOT generate it<= br>
=C2=A0 =C2=A0 > - indicate that
=C2=A0 =C2=A0 > for supporting legacy implementations, all implementatio= ns SHOULD
=C2=A0 =C2=A0 > accept both

=C2=A0 =C2=A0 > At some point in the future if/when you are convinced no= thing generates
=C2=A0 =C2=A0 > "x-dash" anymore, you could do an update that = turns "x-dash" into an
=C2=A0 =C2=A0 > error.

That's why I suggested a transition date, so that this process could be=
essentially automatic.=C2=A0 Readers would have some time to catch up.

If readers will never catch up, then I agree, just go with "x-dash&quo= t;, although
it sets a weird precedent to me.

--
Michael Richardson <mcr+IETF@sandelman.ca>=C2=A0 =C2=A0. o O ( IPv6 I=C3=B8T co= nsulting )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sandelman Software Works Inc, Otta= wa and Worldwide
--0000000000003c7c3305c9f009c2-- From nobody Thu Aug 19 19:55:31 2021 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 4F25C3A0AFD for ; Thu, 19 Aug 2021 19:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 a5efZvuD9jiV for ; Thu, 19 Aug 2021 19:55:24 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F03413A0AFB for ; Thu, 19 Aug 2021 19:55:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 29291389AB; Thu, 19 Aug 2021 23:00:32 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id m_DMAO-R2Lki; Thu, 19 Aug 2021 23:00:27 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8DEBA389B7; Thu, 19 Aug 2021 23:00:18 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D22FDFE; Thu, 19 Aug 2021 22:55:05 -0400 (EDT) From: Michael Richardson To: "Murray S. Kucherawy" , Spencer Dawkins at IETF , Codec Encoding for LossLess Archiving and Realtime transmission , Francesca Palombini In-Reply-To: References: <4945.1629386506@localhost> <22109.1629403274@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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] Conversation about a NON-IANA request in Matroska 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 Aug 2021 02:55:30 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain Murray S. Kucherawy wrote: > What I'm worried about is that picking a date effectively sets a flag day. > Have we ever successfully asserted a flag day in a standards action before? It's not a flag day. We don't have to coordinate upgrades. A flag day means that we have to change both senders and receivers. All receivers/readers will understand both. It's just that senders will start marking with the new one. > But then the IETF has no control over whether anyone adheres to it, making > it effectively arbitrary anyway. That's true. --=-=-= Content-Type: text/plain Content-Disposition: inline Content-Description: Signature -- ] 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 [ --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmEfGYkACgkQgItw+93Q 3WU9Mgf/ahoUTDPhIluJFTfwiXWXOC4wptBGnWgWDufXrK76QO/5A9LiIk3PBaz6 ZjKgjmNsn1OfKN++AIJ2He+dvsavZn9i+0b9VM4QM6AKCYPOrfEcW9LuQ4wApdBY z9Qu5UEF3e7ZSkmoIhLnUyqZkSfGg5PRvf00SotU0AYtMI7fWSiKJ3vWNlajmQBB bLO4kRXeXBt1gXZCjj1jJFeQeB28dPneZoycxpnBPmXfix8HJxotiXNmn4G5DUUx p8cwHeI5zIOKh3/bTZiFVDo2Jv7Rl1x2HVHW+cLFXYrAkpVOzwt1O6cn+Lswt+iW IZLqHnPQLLoYgpXUpJ9mFn4O0IAQDg== =TRch -----END PGP SIGNATURE----- --==-=-=-- From nobody Mon Aug 23 16:49:28 2021 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 4E85A3A0B3C; Mon, 23 Aug 2021 16:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 mh0ebzV_0Cze; Mon, 23 Aug 2021 16:49:18 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A83B93A0B21; Mon, 23 Aug 2021 16:49:18 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B6127F40769; Mon, 23 Aug 2021 16:49:07 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, cellar@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20210823234907.B6127F40769@rfc-editor.org> Date: Mon, 23 Aug 2021 16:49:07 -0700 (PDT) Archived-At: Subject: [Cellar] =?utf-8?q?RFC_9043_on_FFV1_Video_Coding_Format_Versions?= =?utf-8?q?_0=2C_1=2C_and_3?= 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, 23 Aug 2021 23:49:26 -0000 A new Request for Comments is now available in online RFC libraries. RFC 9043 Title: FFV1 Video Coding Format Versions 0, 1, and 3 Author: M. Niedermayer, D. Rice, J. Martinez Status: Informational Stream: IETF Date: August 2021 Mailbox: michael@niedermayer.cc, dave@dericed.com, jerome@mediaarea.net Pages: 51 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-cellar-ffv1-20.txt URL: https://www.rfc-editor.org/info/rfc9043 DOI: 10.17487/RFC9043 This document defines FFV1, a lossless, intra-frame video encoding format. FFV1 is designed to efficiently compress video data in a variety of pixel formats. Compared to uncompressed video, FFV1 offers storage compression, frame fixity, and self-description, which makes FFV1 useful as a preservation or intermediate video format. This document is a product of the Codec Encoding for LossLess Archiving and Realtime transmission Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Aug 23 19:33:51 2021 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 D319D3A0A8E for ; Mon, 23 Aug 2021 19:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 (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 1TlEESZgEZkv for ; Mon, 23 Aug 2021 19:33:47 -0700 (PDT) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 A03033A0A8D for ; Mon, 23 Aug 2021 19:33:46 -0700 (PDT) Received: by mail-ua1-x936.google.com with SMTP id t26so9574468uao.12 for ; Mon, 23 Aug 2021 19:33:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Pksd9AIm+VH7tG+6LvhRHq12qcrcITcIkRkP/jZ9qyI=; b=pTocz14mEhm7ocV1rod+N3EER0egE+Ly0UvnFdlxjY2fX15Olquas1lspZvS6F60Vf JTum0vJT2QGgeUS/9NSBV2GmCsxQJ+yk8A3BZzhc2AC1I3UtIvGZ8bvlakxsVI2x3tGs uVqEjEDBND58yiNzb3g3QGH1vWUcEz49FKbfRru3yPCiM+USaC/1LkWZ1/FN7nCoYLWq aIQJ56Su9VE61E4lzRK3xDf/gNyaCBLpezk2XepZeQnLE4lWUM9OXTJJCnX3blXDzJ4j eCHNJiqHwLbIFekxtUaymFG/eWJNMEeAvBgalf6Iep+vJ0Yz3PTz95Cv8Xnx57IG1Idd qWWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Pksd9AIm+VH7tG+6LvhRHq12qcrcITcIkRkP/jZ9qyI=; b=gaF7WwWEVb3Y1Ry74AEFpMnAR30fNKBN06CSKPxlmW21VD65M/Svv1WpwkhuyFnbMo mk4zIsJIGaaWG+c3gdgq1CRakxRhz7B3Q37IUefXcB4GHwN/T1uWzikIQNPj6kDdAa7t XvNx3fgfFkRVI/3pHIMYG+at/RstzEEJCuWxJy5yQJomtbraHNj71+Nt4WHji1qN2eEJ EFU3/dWAtP5JvjewOp7v20jAOm/Fw5B4QFTf85tzls+D5HiGml7NdFG0JAlLhKDgy16i k5qqk3ag4EF/Ic0YyuFI4xw7JNdD8fXZBMRILsECChkOii2KOx/pA8Ur5WQo8/6fP7po +fpg== X-Gm-Message-State: AOAM530kzRQvq8jfANg2fZdTMX5gh2ox6X5B2r2ZUT+NHJEmR76apcHY XRvNf4OWVUYVLB2jqi1CvutMf30AM5jRSoFoIBNwS3cAwns= X-Google-Smtp-Source: ABdhPJxdHglmaosl8yW6lXRESyi9Y9fyui7+AIAZjht8aQW2SpucZtpCHqR3/m6UJB3j6UZ8z5npTB2DYgFc0qI8Xec= X-Received: by 2002:a67:fe57:: with SMTP id m23mr25682460vsr.58.1629772425533; Mon, 23 Aug 2021 19:33:45 -0700 (PDT) MIME-Version: 1.0 From: Spencer Dawkins at IETF Date: Mon, 23 Aug 2021 21:33:19 -0500 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="0000000000007d1cbd05ca44f693" Archived-At: Subject: [Cellar] Minimal agenda for our meeting on 8/24/2021 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 Aug 2021 02:33:49 -0000 --0000000000007d1cbd05ca44f693 Content-Type: text/plain; charset="UTF-8" Dear All, I will be putting together a more familiar agenda for our meeting on Tuesdays, but here's what I have for the highlights: - Michael has asked to step down as Cellar co-chair - Murray has answered our question about IANA non-actions - Our usual consideration of Github issues. We'll be able to adjust this agenda at the beginning of the call, of course. Best, Spencer, who is running somewhat later than usual ... --0000000000007d1cbd05ca44f693 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,

I will be putting together a = more familiar agenda for our meeting on Tuesdays, but here's what I hav= e for the highlights:
  • Michael has asked to step down as C= ellar co-chair
  • Murray has answered=C2=A0our question about IANA non= -actions
  • Our usual consideration of Github issues.=C2=A0
<= div>We'll be able to adjust this agenda at the beginning of the call, o= f course.=C2=A0

Best,

Spencer, who is running somewhat later than usual ...=C2=A0
--0000000000007d1cbd05ca44f693-- From nobody Tue Aug 24 05:43:35 2021 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 6BAF33A10EE for ; Tue, 24 Aug 2021 05:43:33 -0700 (PDT) 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=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 NulPVbOuwrDg for ; Tue, 24 Aug 2021 05:43:27 -0700 (PDT) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 A43683A10E5 for ; Tue, 24 Aug 2021 05:43:27 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id r19so31448352eds.13 for ; Tue, 24 Aug 2021 05:43:27 -0700 (PDT) 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=aMYcee1v9IMthvWUDRDGCwcwUavLteo3RNS0uvB5jxM=; b=UcVOi/BoLboe/51byXyABnCfind3IAmHwRQgHsxHeBTQAggitqCParDvDYbBkxzssE ws0W6oY/yN+6XAqK+22NeHHhl3dM+72veSq6GgEFeeTHyYMVOQcD14AcaoV9pUzD09rk HEw5JVLEeLyeIuWqjVDGD1m+qw5FEALe/s8R85s+zPtFaLnp6ugNMC+FtlX1CQOU1+Pb a/dMewQF9rlrtOoNHW+o9M7mcO2r/IXWOnZ/SldmXsi5dcUhXXwFDlc42o7VjRV3wad5 DjisJQDnyANUWgkq12OdazKZPjcqP5rxZv5C6MSqyQCcsBJAp5CjtJc4WmxyNEw8c0nd OvtA== 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=aMYcee1v9IMthvWUDRDGCwcwUavLteo3RNS0uvB5jxM=; b=OUEBkiEbE8MbvZ9DMAs5Se5m/DphP/D2tP+0JZnYRxiKTVq8RtOJg69NprkdUiFt/7 L9TqPVB1D+BniAJNAbiVSKLXw6F6L5e4DiAgrpoboTy4tFTu2a0t8oUMUh3vGOtORmcY gSB7hqaBEpBFETcMn7Mo1UsadgifX5zgPwjyTE52xgOWteXUWcIJALtDxU2/HI5D1ykl bFIcfo3rOwF6zEEhr5fAdD9jilUbidi1TJXlBMcDNiFygK9NN+PK+uz5BIEKSwMhER3j X5ftETh1/xzEBdZw/9w7zwgU4PT+kcyHB7daz4gp7yfaXG79LlQ+RiDhkX9yrb3+UPfh 8C2A== X-Gm-Message-State: AOAM531QjyNn530exjVSUxDS+2CenL01aGg7FZ7WFJbEUddxEJZH8Xv+ KLhs6M51QU1H0mDwN999LDJBtNQ+2d7BNAfHCpy1pQ== X-Google-Smtp-Source: ABdhPJyOmE8iS3LcXLKoBiki7pPILuoAoknUInCh28J4VS49G+NA/oSGK4jBZp6RP9hECDONO12HYIskEToSDAetK2M= X-Received: by 2002:aa7:cb19:: with SMTP id s25mr43560467edt.194.1629809004255; Tue, 24 Aug 2021 05:43:24 -0700 (PDT) MIME-Version: 1.0 References: <4945.1629386506@localhost> <22109.1629403274@localhost> <31989.1629428105@localhost> In-Reply-To: <31989.1629428105@localhost> From: Steve Lhomme Date: Tue, 24 Aug 2021 14:43:13 +0200 Message-ID: To: Michael Richardson Cc: "Murray S. Kucherawy" , Spencer Dawkins at IETF , Codec Encoding for LossLess Archiving and Realtime transmission , Francesca Palombini Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] Conversation about a NON-IANA request in Matroska 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 Aug 2021 12:43:34 -0000 Hi, Given one of the goal on this Matroska specification is long time preservation, that would seem odd to design something that renders older systems incompatible with the current/new specifications. If any of the MIME types we have in attachments were to become invalid all of a sudden we wouldn't like it. I updated the Pull Request to clean the IANA explanation to reflect that the old names are known but should not be used, instead the new names should be used. https://github.com/ietf-wg-cellar/matroska-specification/pull/529 Le ven. 20 ao=C3=BBt 2021 =C3=A0 04:55, Michael Richardson a =C3=A9crit : > > > Murray S. Kucherawy wrote: > > What I'm worried about is that picking a date effectively sets a fl= ag day. > > Have we ever successfully asserted a flag day in a standards action= before? > > It's not a flag day. > We don't have to coordinate upgrades. > A flag day means that we have to change both senders and receivers. > > All receivers/readers will understand both. > It's just that senders will start marking with the new one. > > > But then the IETF has no control over whether anyone adheres to it,= making > > it effectively arbitrary anyway. > > That's true. > > -- > ] Never tell me the odds! | ipv6 mesh netwo= rks [ > ] Michael Richardson, Sandelman Software Works | IoT architec= t [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails= [ > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Tue Aug 24 10:13:44 2021 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 A829D3A02DC for ; Tue, 24 Aug 2021 10:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 (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 OU_jVgFo2iSm for ; Tue, 24 Aug 2021 10:13:36 -0700 (PDT) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 224133A02C1 for ; Tue, 24 Aug 2021 10:13:36 -0700 (PDT) Received: by mail-ua1-x92c.google.com with SMTP id x23so4792530uav.3 for ; Tue, 24 Aug 2021 10:13:36 -0700 (PDT) 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; bh=/XWMcuo+dvLj6p+b4XwbuUYIlJ0yx2+Tde8Yt1c5Xp0=; b=dZ/mY3c82a40/v3BbjvYMNvI2m4QnuN2H+cL2tspkMJcS9l7gdA3zJhLMePl6GC0Gx ByFWa0cWppc/9RSQrkYlwkH/lJjBzIRzJtH/x9fYLekYOHzL25OFcL6U80aslTqY/Aul w/MbXmuBDxSouaahlPhwq7LdJr3BFFUQAMXla9j8X5p7qts68voVOQPNrVJT/+Wwotxl 9z2rtNkeWbpE6erjbH8MHxiPk1JJW7I/QzTaHpxXdeVFgqSqWUpGM7YEwwjA6mDcDkn2 a3H43txv/d44dkIjkBdhAM2F33pytFVBgimiRtJhQG/XKMFL+8zfhrZo4IDZtpqRzRHh 043g== 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; bh=/XWMcuo+dvLj6p+b4XwbuUYIlJ0yx2+Tde8Yt1c5Xp0=; b=ET9swVFTI2GqKss1ohum+XMFsOAIVclk5Q7QwLSXg4kWz19Us7+ecrCPrI/ZYTCfCS B2s5U1MFByMGFlDuEgDDuoWX7TwFJSD+6eS8ghj4unwjm/Fz2TWlrHeqtR5iqkLbEJij gOYIOyPcjfqj2mq7WvAPSo678u1ljav+LDFJiMVErbdnyFMIX8mwghmYQl+jBmrZwJdK c2W3SW7C+aylaRuvyTVe37YT+Et7aht3EdIY/JQYykWn5+OksWrnw/wrpLnhPq+ZYppW MjGGgiGw1rpKwxEpMAtIAQGJTXfdYhgRj0u7tUUFqktKE7b16XYMhUj8o3dRZeNEeJ73 W2aQ== X-Gm-Message-State: AOAM530ZpeYQjio5mGasGigVRfrs3IORXDf3uHknZ0NqIbi0O6ZOZP6S rR6RXirKmfSUGaH6DsUC9DkhTTExbNJg3xXTpDo5flnYlZfhww== X-Google-Smtp-Source: ABdhPJz0d4QjOgfMO2ZNnFUjH0dxqLE8WiOz8DIiiZBQYMpDDhXApDmmjBI5Eo0WQa51GWh0YEDBrCKK1B8AdvwgaBE= X-Received: by 2002:a67:f70d:: with SMTP id m13mr29593449vso.32.1629825214386; Tue, 24 Aug 2021 10:13:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Spencer Dawkins at IETF Date: Tue, 24 Aug 2021 12:13:08 -0500 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="000000000000f3146c05ca514039" Archived-At: Subject: [Cellar] Our normal-looking agenda for our meeting on 8/24/2021 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 Aug 2021 17:13:43 -0000 --000000000000f3146c05ca514039 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable # CELLAR -- DRAFT AGENDA for Virtual Interim Meeting | Date |Time | Local Times | |:------:|:-----------:|:------| |2021-08-24 |21:00 Amsterdam |[Time Converter]( https://savvytime.com/converter/netherlands-amsterdam-to-utc-ny-new-york-ci= ty-ca-san-francisco/jun-22-2021/9pm)| | **Note** | Meeting time is anchored to Amsterdam | ## Administrivia ### INFO: https://github.com/ietf-wg-cellar/chair-notes/tree/master/interim-2021-0= 7 **Note that we're now pointing to the Github repo for chair notes here** ### WEB CONFERENCE: https://whereby.com/cellar-interim THERE IS NO TELEPHONE DIALIN (You can try connecting to the whereby.com link at any time.) #### Shared COMIMD for notetaking: https://codimd.ietf.org/notes-cellar-virtual * Note that if you log in to the IETF datatracker, you'll be able to edit these notes, add your name to attendee lists, etc. * Please ask Spencer if you have questions. :::warning The ComiMD URL is still redirecting, but the newly official location is https://notes.ietf.org/notes-cellar-virtual?edit - and that's active now. Please bookmark the new one when you're redirected to it. ::: ### Logistics for Meeting #### 2021 virtual interim meeting dates * Please note our 2021 dates listed at https://datatracker.ietf.org/wg/cellar/meetings/ * IETF 112 will also be a fully online meeting (announced 2021-08-04), so **we will not be meeting face-to-face in Madrid, right?** * **ACTION:** Co-chairs to propose 2022 meeting schedule in September meeting, for information and comment. ## Agenda Items ### Note Well: https://www.ietf.org/about/note-well/ #### Roll call Attendees * Spencer Dawkins Regrets * ### News You Can Use ### WG status update * draft-ietf-cellar-codec-06 was posted 2021-04-12, in ID Exists * draft-ietf-cellar-ffv1-20 was **PUBLISHED AS RFC 9043** * draft-ietf-cellar-ffv1-v4-17 was posted 2021-05-25, in ID Exists * draft-ietf-cellar-flac-01 was posted 2021-04-27, in ID Exists * draft-ietf-cellar-matroska-07 was posted 2021-04-12, in ID Exists * draft-ietf-cellar-tags-06 was posted 2021-04-12, in ID Exists ### Milestone review: * Matroska maybe at the end of Summer 2021? It's closer than we thought * Is it worth publishing an update to ffv1-v4 that includes the goals we've discussed previously? * Are we ready to submit a working group draft for EBML corrections yet? (https://github.com/ietf-wg-cellar/ebml-specification/tree/corrections-doc) * FLAC still needs an editor to complete the work. Michael did hear back from Florin, and he's unable to serve as editor, so the working group has a decision to make about FLAC. ##### Discussion on the call * #### Michael Richardson has asked to step down as co-chair for Cellar, after years of service in this role. * We need to have a conversation about succession planning. * IETF working groups do not name their own leadership - that's an Area Director responsibity - but ADs make their best choices when they have all the information we can give them to make choices. #### Accept draft minutes from previous meeting (attached below) * Any objections? None noted, so approved ... #### Follow-up on Possible switch to Meetecho for our calls ##### Discussion on previous calls * We discussed moving to Meetecho (from whereby.com) at the May meeting, and Spencer had an action to check on iOS and Android clients for Meetecho. * Spencer verified that Meetecho uses WebRTC, so should work with any browser, but does **not** currently have an iOS or Android client available. * Michael's experience is that Meetecho REALLY needs to run from a computer, and not a phone or tablet, just because you need a lot of screen real estate to keep track of queues, chats, and other stuff. ##### Discussion on the call * Is using a computer for Cellar interim meetings a dealbreaker for anyone? ### FFV1 v4 issues * Michael presented slides for https://github.com/FFmpeg/FFV1/blob/master/ffv1-v4-goals.md at the IETF 111 Dispatch session. #### Discussion on the call * ### Matroska issues * #### Discussion on the call * ### FLAC issues * #### Discussion on the call * ## AOB? * :::success NEXT MEETING 2021-09-28 :tada: ::: ## Notes from previous meeting for approval # CELLAR -- DRAFT AGENDA for Virtual Interim Meeting | Date |Time | Local Times | |:------:|:-----------:|:------| |2021-06-22 |21:00 Amsterdam |[Time Converter]( https://savvytime.com/converter/netherlands-amsterdam-to-utc-ny-new-york-ci= ty-ca-san-francisco/jun-22-2021/9pm)| | **Note** | Meeting time is anchored to Amsterdam | ## Administrivia ### INFO: https://github.com/ietf-wg-cellar/chair-notes/tree/master/interim-2021-0= 6 **Note that we're now pointing to the Github repo for chair notes here** ### WEB CONFERENCE: https://whereby.com/cellar-interim THERE IS NO TELEPHONE DIALIN (You can try connecting to the whereby.com link at any time.) Meetecho: https://meetings.conf.meetecho.com/interim/?short=3Dd85e39bd-d5a9-4bc5-a289= -1828f8e287f0 ### Logistics for Meeting #### 2021 virtual interim meeting dates * Please note our 2021 dates listed at https://datatracker.ietf.org/wg/cellar/meetings/ :::warning Note that we do not have a July meeting - (Virtual) IETF 111 will be 2021-07-26 to 2021-07-30. Qur next meeting will be 2021-08-24 :zap: ::: * IETF 111 in July will definitely be virtual. * Sometime around 2021-09-28, we=E2=80=99ll see if we want to meet at IE= TF 112 on November 6-12, 2021, in person in Madrid. #### Shared COMIMD for notetaking: https://codimd.ietf.org/notes-cellar-virtual * Note that if you log in to the IETF datatracker, you'll be able to edit these notes, add your name to attendee lists, etc. * Please ask Spencer if you have questions. #### APPEAR.IN is now called "whereby.com" ( https://whereby.com/cellar-interim) ## Agenda Items ### Note Well: https://www.ietf.org/about/note-well/ #### Roll call Attendees * Spencer Dawkins * Michael Richardson * Jerome Martinez * Michael Niedermeier * Steve Lhomme Regrets * Reto Kromer ### Accept draft minutes from previous meeting (attached below) * Any objections? None noted, so approved ... #### Follow-up on Meetecho * We discussed moving to Meetecho (from whereby.com) at the May meeting, and Spencer had an action to check on iOS and Android clients for Meetecho. * Spencer verified that Meetecho uses WebRTC, so should work with any browser, but does **not** currently have an iOS or Android client available. #### Discussion on the call * Michael's experience is that Meetecho REALLY needs to run from a computer, and not a phone or tablet, just because you need a lot of screen real estate to keep track of queues, chats, and other stuff. * Is that a dealbreaker for anyone? ### WG status update * draft-ietf-cellar-codec-06 was posted 2021-04-12, in ID Exists * draft-ietf-cellar-ffv1-20 was posted 2021-02-23, is now in RFC Editor Queue, in AUTH48 (see [AUTH48] below) * draft-ietf-cellar-ffv1-v4-17 was posted 2021-05-25, in ID Exists * draft-ietf-cellar-flac-01 was posted 2021-04-27, in ID Exists * draft-ietf-cellar-matroska-07 was posted 2021-04-12, in ID Exists * draft-ietf-cellar-tags-06 was posted 2021-04-12, in ID Exists ### Milestone review: * Close to celebrating on FFv1, but we need to get through AUTH48 * Matroska maybe at the end of Summer 2021? It's closer than we thought * FLAC still needs an editor to complete the work. Michael did hear back from Florin, and he's unable to serve as editor, so the working group has a decision to make about FLAC. #### Discussion on the call * None ### From the mailing list: From Steve, on EBML errata * We are proceeding with a short RFC that UPDATES RFC 8794, not replacing that RFC, and this draft will contain only corrections for the errata we are aware of. * Jerome asked for an example of such an RFC - Spencer suggested https://datatracker.ietf.org/doc/rfc8540/ on the mailing list ("Subject: Sample draft for updating RFC 8794"), with suggestions for how to map that example onto the new Cellar draft. * Steve submitted https://github.com/ietf-wg-cellar/ebml-specification/pull/413 to get this started - so we can reasonably 1. pick a date for this milestone, and 2. ask our AD to approve a new milestone (probably "Submit specification for RFC 8794 corrections to IESG (Standards Track)"), to make sure that we can publish this specification when that's appropriate. #### Discussion on the call * Jerome has been working on this. * We probably shouldn't plan to finish our EBML corrections draft before we finish Matroska, because we may find things in EBML that need to be corrected for Matroska. * We created the milestone for this document, for our AD to approve. ### AUTH48 for draft-ietf-cellar-ffv1-20 Email subject: AUTH48 [JM]: RFC 9043 NOW AVAILABLE Current files from RFC-Editor 1. https://www.rfc-editor.org/authors/rfc9043.txt https://www.rfc-editor.org/authors/rfc9043.pdf https://www.rfc-editor.org/authors/rfc9043.html https://www.rfc-editor.org/authors/rfc9043.xml 1. This diff shows all changes from the approved Internet-Draft: https://www.rfc-editor.org/authors/rfc9043-diff.html https://www.rfc-editor.org/authors/rfc9043-rfcdiff.html (side by side) 1. This diff shows only the most recent changes: https://www.rfc-editor.org/authors/rfc9043-lastdiff.html https://www.rfc-editor.org/authors/rfc9043-lastrfcdiff.html (side by side= ) 1. This diff compares the submitted and current XML files: https://www.rfc-editor.org/authors/rfc9043-xmldiff1.html https://www.rfc-editor.org/authors/rfc9043-xmldiff2.html (side by side) #### Discussion on the call * We didn't have Dave, but Jerome was also working on these corrections with the RFC Editor. * Jerome thinks that all of the corrections have been agreed by all of the authors. * **ACTION:** The authors should review the text provided by the RFC Editor and (if no further changes is needed) just reply toall to the AUTH48 email thread and say "I agree with the most recent text provided by the RFC Editor". * Michael and Spencer will be watching that e-mail thread in case the RFC Ediror identifies any changes that need to be approved by the document shepherd (which is Michael in this case). ### FFV1 v4 issues * We agreed at our previous meeting that we would use work on the introduction to the FFV1 v4 document as a way of agreeing on contents for FFV1v4, and Jerome said he would start work on the Introduction (added as an issue) * https://github.com/FFmpeg/FFV1/blob/master/ffv1-v4-goals.md as our current plan #### Discussion on the call * We discussed https://github.com/FFmpeg/FFV1/blob/master/ffv1-v4-goals.md on the call. * What about infrared images? That could immediately interest people like autonomous vehicle community (who have money). * What about signatures for stored media? * What is needed here? Integrity, nonrepudiation, timestamps, ... we may need to talk about specific use cases to understand the requirements. * No change to the current document contents for now * We can talk about this on the mailing list between now and IETF 111, and then between IETF 111 and our next working group meeting * **ACTION:** Spencer can take the action to do a short presentation in ARTAREA at IETF 111 in July, showing the proposed contents for FFV1 v4 and pointing people to Cellar. * ### Matroska issues * No discussion on the call ### FLAC issues * No discussion on the call ## AOB? * No discussion on the call :::success NEXT MEETING 2021-08-24 :tada: > --000000000000f3146c05ca514039 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
# CELLAR -- DRAFT AGENDA for Virtual Inte= rim Meeting

| Date |Time | Local Times |
|:------:|:-----------:|= :------|
|2021-08-24 |21:00 Amsterdam |[Time Converter](https://savvytime.com/converter/netherlan= ds-amsterdam-to-utc-ny-new-york-city-ca-san-francisco/jun-22-2021/9pm)|=
| **Note** | Meeting time is anchored to Amsterdam |

## Administ= rivia

### INFO:
=C2=A0 =C2=A0https://github.com/ietf-= wg-cellar/chair-notes/tree/master/interim-2021-07
**Note that we= 9;re now pointing to the Github repo for chair notes here**

### WEB = CONFERENCE:

=C2=A0 =C2=A0https://whereby.com/cellar-interim

=C2=A0 =C2=A0THERE IS NO = TELEPHONE DIALIN (You can try connecting to the whereby.com link at any time.)
=C2=A0 =C2=A0
#### Shared COMI= MD for notetaking: https://codimd.ietf.org/notes-cellar-virtual
* Note that if you log= in to the IETF datatracker, you'll
=C2=A0 =C2=A0 =C2=A0 =C2=A0be a= ble to edit these notes, add your name to attendee
=C2=A0 =C2=A0 =C2=A0= =C2=A0lists, etc.
* Please ask Spencer if you have questions.
:::wa= rning
=C2=A0 =C2=A0The ComiMD URL is still redirecting, but the newly of= ficial location is https://notes.ietf.org/notes-cellar-virtual?edit - and that's = active now. Please bookmark the new one when you're redirected to it. <= br>:::

### Logistics for Meeting

#### 2021 virtual interim me= eting dates

=C2=A0 =C2=A0* Please note our 2021 dates listed at https://datatracke= r.ietf.org/wg/cellar/meetings/
=C2=A0 =C2=A0* IETF 112 will also be = a fully online meeting (announced 2021-08-04), so **we will not be meeting = face-to-face in Madrid, right?**
=C2=A0 =C2=A0* **ACTION:** Co-chairs to= propose 2022 meeting schedule in September meeting, for information and co= mment.

## Agenda Items

### Note Well: =C2=A0https://www.ietf.org/about/note-well/<= br>
#### Roll call

=C2=A0 Attendees
=C2=A0 =C2=A0* Spencer Daw= kins

=C2=A0 Regrets
=C2=A0 =C2=A0*

### News You Can Use<= br>
### =C2=A0WG status update

=C2=A0 =C2=A0* draft-ietf-cellar-c= odec-06 was posted 2021-04-12, in ID Exists
=C2=A0 =C2=A0* draft-ietf-ce= llar-ffv1-20 was **PUBLISHED AS RFC 9043**
=C2=A0 =C2=A0* draft-ietf-cel= lar-ffv1-v4-17 was posted 2021-05-25, in ID Exists
=C2=A0 =C2=A0* draft= -ietf-cellar-flac-01 was posted 2021-04-27, in ID Exists
=C2=A0 =C2=A0*= draft-ietf-cellar-matroska-07 was posted 2021-04-12, in ID Exists
=C2= =A0 =C2=A0* draft-ietf-cellar-tags-06 was posted 2021-04-12, in ID Exists
### =C2=A0Milestone review:

=C2=A0 =C2=A0* Matroska maybe at = the end of Summer 2021? It's closer than we thought
=C2=A0 =C2=A0* = Is it worth publishing an update to ffv1-v4 that includes the goals we'= ve discussed previously?
=C2=A0 =C2=A0* Are we ready to submit a working= group draft for EBML corrections yet? (https://github.com/ietf-= wg-cellar/ebml-specification/tree/corrections-doc)
=C2=A0 =C2=A0* FL= AC still needs an editor to complete the work. Michael did hear back from F= lorin, and he's unable to serve as editor, so the working group has a d= ecision to make about FLAC.

##### Discussion on the call
=C2=A0 = =C2=A0*

#### Michael Richardson has asked to step down as co-chair f= or Cellar, after years of service in this role.
* We need to have a con= versation about succession planning.
* IETF working groups do not name = their own leadership - that's an Area Director responsibity - but ADs m= ake their best choices when they have all the information we can give them = to make choices.

#### Accept draft minutes from previous meeting (a= ttached below)

=C2=A0* Any objections? None noted, so approved ...=C2=A0 =C2=A0
#### Follow-up on Possible switch to Meetecho for our ca= lls

##### Discussion on previous calls
* We discussed moving to M= eetecho (from whereby.com) at the May me= eting, and Spencer had an action to check on iOS and Android clients for Me= etecho.
* Spencer verified that Meetecho uses WebRTC, so should work wi= th any browser, but does **not** currently have an iOS or Android client av= ailable.
* =C2=A0Michael's experience is that Meetecho REALLY needs= to run from a computer, and not a phone or tablet, just because you need a= lot of screen real estate to keep track of queues, chats, and other stuff.=

##### Discussion on the call
=C2=A0 =C2=A0* Is using a computer = for Cellar interim meetings a dealbreaker for anyone?

### FFV1 v4 is= sues
=C2=A0 =C2=A0* Michael presented slides for =C2=A0https://github.com/= FFmpeg/FFV1/blob/master/ffv1-v4-goals.md at the IETF 111 Dispatch sessi= on.

#### Discussion on the call
=C2=A0 =C2=A0*
=C2=A0 =C2=A0<= br>### Matroska issues
=C2=A0 =C2=A0*

#### Discussion on the cal= l
=C2=A0 =C2=A0*

### FLAC issues
=C2=A0 =C2=A0*
#### Disc= ussion on the call
=C2=A0 =C2=A0*

## AOB?
=C2=A0 =C2=A0*
=
:::success
NEXT MEETING 2021-09-28 :tada:
:::
=C2=A0 =C2=A0 ## Notes from previous meeting for approval
=C2=A0 =C2=A0
# CELLAR= -- DRAFT AGENDA for Virtual Interim Meeting

| Date |Time | Local Ti= mes |
|:------:|:-----------:|:------|
|2021-06-22 |21:00 Amsterdam |= [Time Converter](https://= savvytime.com/converter/netherlands-amsterdam-to-utc-ny-new-york-city-ca-sa= n-francisco/jun-22-2021/9pm)|
| **Note** | Meeting time is anchored = to Amsterdam |

## Administrivia

### INFO:
=C2=A0 =C2=A0https://github.com/ietf-wg-cellar/chair-notes/tree/master/interim-= 2021-06
**Note that we're now pointing to the Github repo for c= hair notes here**

### WEB CONFERENCE:

=C2=A0 =C2=A0https://whereby.com/cellar-interim=

=C2=A0 =C2=A0THERE IS NO TELEPHONE DIALIN (You can try connecting t= o the whereby.com link at any time.)
= =C2=A0 =C2=A0
=C2=A0 =C2=A0Meetecho:
=C2=A0 =C2=A0https://meetings.conf.meetecho.com/interim/?short=3Dd85e39bd-d5a9-4b= c5-a289-1828f8e287f0


### Logistics for Meeting

#### 2= 021 virtual interim meeting dates

=C2=A0 =C2=A0* Please note our 202= 1 dates listed at https://datatracker.ietf.org/wg/cellar/meetings/
:::warning
N= ote that we do not have a July meeting - (Virtual) IETF 111 will be 2021-07= -26 to 2021-07-30.
Qur next meeting will be 2021-08-24 :zap:
:::
= =C2=A0 =C2=A0* IETF 111 in July will definitely be virtual.
=C2=A0 =C2= =A0* Sometime around 2021-09-28, we=E2=80=99ll see if we want to meet at IE= TF 112 on November 6-12, 2021, in person in Madrid.

#### Shared COMI= MD for notetaking: https://codimd.ietf.org/notes-cellar-virtual
=C2=A0 =C2=A0 =C2=A0 = =C2=A0
* Note that if you log in to the IETF datatracker, you'll =C2=A0 =C2=A0 =C2=A0 =C2=A0be able to edit these notes, add your name to a= ttendee
=C2=A0 =C2=A0 =C2=A0 =C2=A0lists, etc.
* Please ask Spencer= if you have questions.

#### APPEAR.IN<= /a> is now called "whereby.com"= ; (https://whereby.com/cella= r-interim)

## Agenda Items

### Note Well: =C2=A0https://www.ietf.org/about/note-= well/

#### Roll call

=C2=A0 Attendees
=C2=A0 =C2=A0* S= pencer Dawkins
=C2=A0 =C2=A0* Michael Richardson
=C2=A0 =C2=A0* Jerom= e Martinez
=C2=A0 =C2=A0* Michael Niedermeier
=C2=A0 =C2=A0* Steve Lh= omme

=C2=A0 Regrets
=C2=A0 =C2=A0* =C2=A0Reto Kromer

### = Accept draft minutes from previous meeting (attached below)

=C2=A0* = Any objections? None noted, so approved ...
=C2=A0 =C2=A0
#### Follow= -up on Meetecho

* We discussed moving to Meetecho (from whereby.com) at the May meeting, and Spencer had an = action to check on iOS and Android clients for Meetecho.
* Spencer veri= fied that Meetecho uses WebRTC, so should work with any browser, but does *= *not** currently have an iOS or Android client available.

#### Disc= ussion on the call
=C2=A0 =C2=A0* Michael's experience is that Meete= cho REALLY needs to run from a computer, and not a phone or tablet, just be= cause you need a lot of screen real estate to keep track of queues, chats, = and other stuff.
=C2=A0 =C2=A0* Is that a dealbreaker for anyone?
### =C2=A0WG status update

=C2=A0 =C2=A0* draft-ietf-cellar-codec-0= 6 was posted 2021-04-12, in ID Exists
=C2=A0 =C2=A0* draft-ietf-cellar-f= fv1-20 was posted 2021-02-23, is now in RFC Editor Queue, in AUTH48 (see [A= UTH48] below)
=C2=A0 =C2=A0* draft-ietf-cellar-ffv1-v4-17 was posted 202= 1-05-25, in ID Exists
=C2=A0 =C2=A0* draft-ietf-cellar-flac-01 was post= ed 2021-04-27, in ID Exists
=C2=A0 =C2=A0* draft-ietf-cellar-matroska-0= 7 was posted 2021-04-12, in ID Exists
=C2=A0 =C2=A0* draft-ietf-cellar-t= ags-06 was posted 2021-04-12, in ID Exists

### =C2=A0Milestone revie= w:

=C2=A0 =C2=A0* Close to celebrating on FFv1, but we need to get = through AUTH48
=C2=A0 =C2=A0* Matroska maybe at the end of Summer 2021? = It's closer than we thought
=C2=A0 =C2=A0* FLAC still needs an edit= or to complete the work. Michael did hear back from Florin, and he's un= able to serve as editor, so the working group has a decision to make about = FLAC.

#### Discussion on the call
=C2=A0 =C2=A0* None

###= From the mailing list: From Steve, on EBML errata
=C2=A0 =C2=A0* We are= proceeding with a short RFC that UPDATES RFC 8794, not replacing that RFC,= and this draft will contain only corrections for the errata we are aware o= f.
=C2=A0 =C2=A0* Jerome asked for an example of such an RFC - Spencer = suggested https://dat= atracker.ietf.org/doc/rfc8540/ on the mailing list ("Subject: Samp= le draft for updating RFC 8794"), with suggestions for how to map that= example onto the new Cellar draft.
=C2=A0 =C2=A0* Steve submitted https= ://github.com/ietf-wg-cellar/ebml-specification/pull/413 to get this st= arted - so we can reasonably
=C2=A0 =C2=A01. pick a date for this miles= tone, and
=C2=A0 =C2=A02. ask our AD to approve a new milestone (probab= ly "Submit specification for RFC 8794 corrections to IESG (Standards T= rack)"), to make sure that we can publish this specification when that= 's appropriate.

#### Discussion on the call
=C2=A0 =C2=A0* Je= rome has been working on this.
=C2=A0 =C2=A0* We probably shouldn't= plan to finish our EBML corrections draft before we finish Matroska, becau= se we may find things in EBML that need to be corrected for Matroska.
= =C2=A0 =C2=A0* We created the milestone for this document, for our AD to ap= prove.

### AUTH48 for draft-ietf-cellar-ffv1-20

Email subject= : AUTH48 [JM]: RFC 9043 <draft-ietf-cellar-ffv1-20.txt> NOW AVAILABLE=

Current files from RFC-Editor
=C2=A01. =C2=A0https://www.rfc-editor.org/authors/= rfc9043.txt
=C2=A0 https://www.rfc-editor.org/authors/rfc9043.pdf
=C2=A0 https://www.rfc-edi= tor.org/authors/rfc9043.html
=C2=A0 https://www.rfc-editor.org/authors/rfc9043.xml

=C2=A01. This diff shows all changes from the approved Internet-D= raft:
=C2=A0 https://www.rfc-editor.org/authors/rfc9043-diff.html
=C2=A0 https://w= ww.rfc-editor.org/authors/rfc9043-rfcdiff.html (side by side)

= =C2=A01. This diff shows only the most recent changes:
=C2=A0 https://www.rfc-= editor.org/authors/rfc9043-lastdiff.html
=C2=A0 https://www.rfc-editor.= org/authors/rfc9043-lastrfcdiff.html (side by side)

=C2=A0 1. Th= is diff compares the submitted and current XML files:
=C2=A0 https://www.rfc-e= ditor.org/authors/rfc9043-xmldiff1.html
=C2=A0 https://www.rfc-editor.org/= authors/rfc9043-xmldiff2.html (side by side)
=C2=A0
#### Discuss= ion on the call
=C2=A0 =C2=A0* We didn't have Dave, but Jerome was a= lso working on these corrections with the RFC Editor.
=C2=A0 =C2=A0* Jer= ome thinks that all of the corrections have been agreed by all of the autho= rs.
=C2=A0 =C2=A0* **ACTION:** The authors should review the text provid= ed by the RFC Editor and (if no further changes is needed) just reply toall= to the AUTH48 email thread and say "I agree with the most recent text= provided by the RFC Editor".
=C2=A0 =C2=A0* Michael and Spencer wi= ll be watching that e-mail thread in case the RFC Ediror identifies any cha= nges that need to be approved by the document shepherd (which is Michael in= this case).

### FFV1 v4 issues
=C2=A0 =C2=A0* We agreed at our= previous meeting that we would use work on the introduction to the FFV1 v4= document as a way of agreeing on contents for FFV1v4, and Jerome said he w= ould start work on the Introduction (added as an issue)
=C2=A0 =C2=A0* <= a href=3D"https://github.com/FFmpeg/FFV1/blob/master/ffv1-v4-goals.md">http= s://github.com/FFmpeg/FFV1/blob/master/ffv1-v4-goals.md as our current = plan

#### Discussion on the call
=C2=A0 =C2=A0* We discussed https:/= /github.com/FFmpeg/FFV1/blob/master/ffv1-v4-goals.md on the call.
= =C2=A0 =C2=A0* What about infrared images? That could immediately interest = people like autonomous vehicle community (who have money).
=C2=A0 =C2=A0= * What about signatures for stored media?
=C2=A0 =C2=A0 =C2=A0* What is= needed here? Integrity, nonrepudiation, timestamps, ... we may need to tal= k about specific use cases to understand the requirements.
=C2=A0 =C2=A0= * No change to the current document contents for now
=C2=A0 =C2=A0* We c= an talk about this on the mailing list between now and IETF 111, and then b= etween IETF 111 and our next working group meeting
=C2=A0 =C2=A0* **ACTI= ON:** Spencer can take the action to do a short presentation in ARTAREA at = IETF 111 in July, showing the proposed contents for FFV1 v4 and pointing pe= ople to Cellar.
=C2=A0 =C2=A0*
=C2=A0 =C2=A0
### Matroska issues<= br>=C2=A0 =C2=A0* No discussion on the call

### FLAC issues
=C2= =A0 =C2=A0* No discussion on the call
=C2=A0 =C2=A0
## AOB?
=C2= =A0 =C2=A0* No discussion on the call

:::success
NEXT MEETING 202= 1-08-24 :tada:
--000000000000f3146c05ca514039-- From nobody Tue Aug 24 13:05:01 2021 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 9BFBA3A1039 for ; Tue, 24 Aug 2021 13:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 f97I_dVFbN9t for ; Tue, 24 Aug 2021 13:04:51 -0700 (PDT) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 46BE33A1038 for ; Tue, 24 Aug 2021 13:04:51 -0700 (PDT) Received: by mail-ua1-x934.google.com with SMTP id 90so12773972uax.5 for ; Tue, 24 Aug 2021 13:04:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=XkHeLMEKyrRzgjiU0fJbJakNU94J9i9ozQgv13/qTMA=; b=jMPNElGPUnYrL5Wd7T3mbRe+A5Zmcgm1sa6fgTwAYMxmnkqkH5x1MhvT9gGVQfWcHl RG/gHrjEErAtZei/Lpg4rAORQWl/bcLcKBPL/L2EHl6ajO4btPChmpqvjijO7sE/H2a8 93kTZKRMILgMCrG6ZcUfTpItkRK7esF1EOF+zvskKl2WEPOfdxFkCve/IMMggV7x0RwW 0OQvPSsVtnc56NaQMKEC9WNTHo0hk2yBzOrlC4QYV/U1eSKLYLDazcFOWkJyITUGuh4e sCV2263SMgbGaK7Wb4ckuaGGlxLwwA1T+GgIG7dFchd3YURM7vqszRUlH40RBPPBmrvZ 69vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=XkHeLMEKyrRzgjiU0fJbJakNU94J9i9ozQgv13/qTMA=; b=ALuGXtE5oG3ZcSlS/3p19anNZ+cCYSnaS+7Lg/vQoueatI3xEvvr7xNY5u+Nbce2Jn f8x8HK+MM/gS2Ubx5VkY5woFfhX8gh7KsEkZrYQUtO90s0ZEJ0GQRldp9xz6ZSWNNf2+ 5wsxXi9TMw8twuO8hqlK7/iFjn3sRFBi2VGT+7cZG6fxRgv24ZFFUP+fbbxKhJYm1qcV TGn4BpmXZJcHSvJqEf8AEqNBM/Ho3pz+j7xcuu//iQMShR0hcuabMHwqqmViPT/wHbWL y2M6RoljZsWqBIl/8n9GpvdIJOlrGeXqFCBgZRuzIspS2/ALTl0yB5gPMqnGsbIxc9zH C1Ug== X-Gm-Message-State: AOAM532yHDwmWhGZSB4bqCzkYdcpdc7aYuAkWTzMnsaiQ6IpCFJf07xo Th9ra09ulKJnAnZqpsYV4xA1haCH72FTTpJbSesBBzbGNT7cxA== X-Google-Smtp-Source: ABdhPJziEYtqBK6dxZkHMhkrwBmsICt0byJSNv+2FEsYZvr/RAmxNEQe2dE2ps2MjKND+1OQs2pSmS2Z6i3LHSU4sYg= X-Received: by 2002:a05:6102:a1a:: with SMTP id t26mr29232474vsa.46.1629835486784; Tue, 24 Aug 2021 13:04:46 -0700 (PDT) MIME-Version: 1.0 From: Spencer Dawkins at IETF Date: Tue, 24 Aug 2021 15:04:19 -0500 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="0000000000003cfd9305ca53a59a" Archived-At: Subject: [Cellar] Cellar Meeting minutes for 2021-08-24 Virtual Interim 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 Aug 2021 20:04:59 -0000 --0000000000003cfd9305ca53a59a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable CELLAR =E2=80=93 DRAFT AGENDA for Virtual Interim Meeting DateTimeLocal Times 2021-08-24 21:00 Amsterdam Time Converter Note Meeting time is anchored to Amsterdam Administrivia INFO: https://github.com/ietf-wg-cellar/chair-notes/tree/master/interim-2021-07 Note that we=E2=80=99re now pointing to the Github repo for chair notes her= e WEB CONFERENCE: https://whereby.com/cellar-interim THERE IS NO TELEPHONE DIALIN (You can try connecting to the whereby.com lin= k at any time.) Shared COMIMD for notetaking: https://codimd.ietf.org/notes-cellar-virtual - Note that if you log in to the IETF datatracker, you=E2=80=99ll be able to edit these notes, add your name to attendee lists, etc. - Please ask Spencer if you have questions. The ComiMD URL is still redirecting, but the newly official location is https://notes.ietf.org/notes-cellar-virtual?edit - and that=E2=80=99s activ= e now. Please bookmark the new one when you=E2=80=99re redirected to it. Logistics for Meeting 2021 virtual interim meeting dates - Please note our 2021 dates listed at https://datatracker.ietf.org/wg/cellar/meetings/ - IETF 112 will also be a fully online meeting (announced 2021-08-04), so we will not be meeting face-to-face in Madrid, right? Perhaps in early December, close to Amsterdam with a workshop on FFv1 and Matroska (also in person) More info at https://mediaarea.net/NoTimeToWait5 - ACTION: Co-chairs to propose 2022 meeting schedule in September meeting, for information and comment. - September 28, 2021: 21:00 Paris (1900 UTC) - October 26, 2021: 21:00 Paris (1900 UTC) - November 23, 2021: 21:00 Paris (2000 UTC) Agenda Items Note Well: https://www.ietf.org/about/note-well/ Ro= ll call Attendees - Spencer Dawkins - Steve Lhomme - Michael Richardson - Jerome Martinez - Michael Neidermayer - Dave Rice Regrets * News You Can Use WG status update - draft-ietf-cellar-codec-06 was posted 2021-04-12, in ID Exists - draft-ietf-cellar-ffv1-20 was PUBLISHED AS RFC 9043 - draft-ietf-cellar-ffv1-v4-17 was posted 2021-05-25, in ID Exists - draft-ietf-cellar-flac-01 was posted 2021-04-27, in ID Exists - draft-ietf-cellar-matroska-07 was posted 2021-04-12, in ID Exists - draft-ietf-cellar-tags-06 was posted 2021-04-12, in ID Exists Milestone review: - Matroska maybe at the end of Summer 2021? It=E2=80=99s closer than we = thought - Is it worth publishing an update to ffv1-v4 that includes the goals we=E2=80=99ve discussed previously? - Are we ready to submit a working group draft for EBML updates (errata plus additions) yet? ( https://github.com/ietf-wg-cellar/ebml-specification/tree/corrections-do= c ) - FLAC still needs an editor to complete the work. Michael did hear back from Florin, and he=E2=80=99s unable to serve as editor, so the working = group has a decision to make about FLAC. Discussion on the call - Almost all the Matroska issues have PRs waiting for reviews - 7 do not. Steve will work on this during the coming week, and then send a version for review (soon) (after the PRs are merged) - Jerome is now able to focus on FFV1-v4, since we=E2=80=99ve published = FFV1. ACTION Spencer to send e-mail to DISPATCH when we submit a (small) update. - We should wait until we have a bit more text, or bigger issues, to publish as a draft. Michael Richardson has asked to step down as co-chair for SOME WORKING GROUP, after years of service in this role. - This may be CELLAR, but also may not be. He=E2=80=99s asked the ADs to= pick one. - We need to have a conversation about succession planning. - Michael and Spencer are both IETF process resources, not technical resources - it would be good to have at least one of each. - We could be using document shepherds to develop talent, but they need to be involved with our work, on calls, etc. - Open call on the Cellar mailing list? Michael has reached out to individuals in the past - that worked with Matroska. - IETF working groups do not name their own leadership - that=E2=80=99s = an Area Director responsibity - but ADs make their best choices when they have a= ll the information we can give them to make choices. Accept draft minutes from previous meeting (attached below) - Any objections? Please let us know on the mailing list. Follow-up on Possible switch to Meetecho for our calls Discussion on previous calls - We discussed moving to Meetecho (from whereby.com) at the May meeting, and Spencer had an action to check on iOS and Android clients for Meetec= ho. - Spencer verified that Meetecho uses WebRTC, so should work with any browser, but does not currently have an iOS or Android client available. - Michael=E2=80=99s experience is that Meetecho REALLY needs to run from= a computer, and not a phone or tablet, just because you need a lot of scre= en real estate to keep track of queues, chats, and other stuff. Discussion on the call - Is using a computer for Cellar interim meetings a dealbreaker for anyone? - None on the call =E2=80=A6 - ACTION Spencer will request Meetecho for our September meeting. FFV1 v4 issues - Discussion on the call - Michael presented slides for https://github.com/FFmpeg/FFV1/blob/master/ffv1-v4-goals.md at the IETF 111 Dispatch session. - https://datatracker.ietf.org/meeting/111/materials/slides-111-dispatch-c= ellar-wg-overview-00 Matroska issues - Discussion on the call - https://github.com/ietf-wg-cellar/matroska-specification/pull/532 =E2=80=9Cpossible values=E2=80=9D maybe =E2=80=9Cdefined values=E2=80=9D=E2=80=A6 - https://github.com/ietf-wg-cellar/matroska-specification/pull/530 can be merged. - https://github.com/ietf-wg-cellar/matroska-specification/pull/437 FLAC issues - Discussion on the call - Were not discussed on the call AOB? - None noted, except that Spencer and Michael expressed their appreciation for the people in the working group! NEXT MEETING 2021-09-28 [image: :tada:] Notes from previous meeting for approval CELLAR =E2=80=93 DRAFT AGENDA for Virtual Interim Meeting DateTimeLocal Times 2021-06-22 21:00 Amsterdam Time Converter Note Meeting time is anchored to Amsterdam Administrivia INFO: https://github.com/ietf-wg-cellar/chair-notes/tree/master/interim-2021-06 Note that we=E2=80=99re now pointing to the Github repo for chair notes her= e WEB CONFERENCE: https://whereby.com/cellar-interim THERE IS NO TELEPHONE DIALIN (You can try connecting to the whereby.com lin= k at any time.) Meetecho: https://meetings.conf.meetecho.com/interim/?short=3Dd85e39bd-d5a9-4bc5-a289= -1828f8e287f0 Logistics for Meeting 2021 virtual interim meeting dates - Please note our 2021 dates listed at https://datatracker.ietf.org/wg/cellar/meetings/ Note that we do not have a July meeting - (Virtual) IETF 111 will be 2021-07-26 to 2021-07-30. Qur next meeting will be 2021-08-24 [image: :zap:] - IETF 111 in July will definitely be virtual. - Sometime around 2021-09-28, we=E2=80=99ll see if we want to meet at IE= TF 112 on November 6-12, 2021, in person in Madrid. Shared COMIMD for notetaking: https://codimd.ietf.org/notes-cellar-virtual - Note that if you log in to the IETF datatracker, you=E2=80=99ll be able to edit these notes, add your name to attendee lists, etc. - Please ask Spencer if you have questions. APPEAR.IN is now called =E2=80=9Cwhereby.com=E2=80=9D ( https://whereby.com/cellar-interim) Agenda Items Not= e Well: https://www.ietf.org/about/note-well/ Roll call Attendees - Spencer Dawkins - Michael Richardson - Jerome Martinez - Michael Niedermeier - Steve Lhomme Regrets - Reto Kromer Accept draft minutes from previous meeting (attached below) - Any objections? None noted, so approved =E2=80=A6 Follow-up on Meetecho - We discussed moving to Meetecho (from whereby.com) at the May meeting, and Spencer had an action to check on iOS and Android clients for Meetec= ho. - Spencer verified that Meetecho uses WebRTC, so should work with any browser, but does not currently have an iOS or Android client available. Discussion on the call - Michael=E2=80=99s experience is that Meetecho REALLY needs to run from= a computer, and not a phone or tablet, just because you need a lot of scre= en real estate to keep track of queues, chats, and other stuff. - Is that a dealbreaker for anyone? WG status update - draft-ietf-cellar-codec-06 was posted 2021-04-12, in ID Exists - draft-ietf-cellar-ffv1-20 was posted 2021-02-23, is now in RFC Editor Queue, in AUTH48 (see [AUTH48] below) - draft-ietf-cellar-ffv1-v4-17 was posted 2021-05-25, in ID Exists - draft-ietf-cellar-flac-01 was posted 2021-04-27, in ID Exists - draft-ietf-cellar-matroska-07 was posted 2021-04-12, in ID Exists - draft-ietf-cellar-tags-06 was posted 2021-04-12, in ID Exists Milestone review: - Close to celebrating on FFv1, but we need to get through AUTH48 - Matroska maybe at the end of Summer 2021? It=E2=80=99s closer than we = thought - FLAC still needs an editor to complete the work. Michael did hear back from Florin, and he=E2=80=99s unable to serve as editor, so the working = group has a decision to make about FLAC. Discussion on the call - None F= rom the mailing list: From Steve, on EBML errata - We are proceeding with a short RFC that UPDATES RFC 8794, not replacing that RFC, and this draft will contain only corrections for the errata we are aware of. - Jerome asked for an example of such an RFC - Spencer suggested https://datatracker.ietf.org/doc/rfc8540/ on the mailing list (=E2=80=9C= Subject: Sample draft for updating RFC 8794=E2=80=9D), with suggestions for how t= o map that example onto the new Cellar draft. - Steve submitted https://github.com/ietf-wg-cellar/ebml-specification/pull/413 to get this started - so we can reasonably 1. pick a date for this milestone, and 2. ask our AD to approve a new milestone (probably =E2=80=9CSubmit speci= fication for RFC 8794 corrections to IESG (Standards Track)=E2=80=9D), to make su= re that we can publish this specification when that=E2=80=99s appropriate. Discussion on the call - Jerome has been working on this. - We probably shouldn=E2=80=99t plan to finish our EBML corrections draf= t before we finish Matroska, because we may find things in EBML that need to be corrected for Matroska. - We created the milestone for this document, for our AD to approve. AUTH48 for draft-ietf-cellar-ffv1-20 Email subject: AUTH48 [JM]: RFC 9043 NOW AVAILABLE Current files from RFC-Editor 1. https://www.rfc-editor.org/authors/rfc9043.txt https://www.rfc-editor.org/authors/rfc9043.pdf https://www.rfc-editor.org/authors/rfc9043.html https://www.rfc-editor.org/authors/rfc9043.xml 2. This diff shows all changes from the approved Internet-Draft: https://www.rfc-editor.org/authors/rfc9043-diff.html https://www.rfc-editor.org/authors/rfc9043-rfcdiff.html (side by side) 3. This diff shows only the most recent changes: https://www.rfc-editor.org/authors/rfc9043-lastdiff.html https://www.rfc-editor.org/authors/rfc9043-lastrfcdiff.html (side by side) 4. This diff compares the submitted and current XML files: https://www.rfc-editor.org/authors/rfc9043-xmldiff1.html https://www.rfc-editor.org/authors/rfc9043-xmldiff2.html (side by side) Discussion on the call - We didn=E2=80=99t have Dave, but Jerome was also working on these corr= ections with the RFC Editor. - Jerome thinks that all of the corrections have been agreed by all of the authors. - ACTION: The authors should review the text provided by the RFC Editor and (if no further changes is needed) just reply toall to the AUTH48 ema= il thread and say =E2=80=9CI agree with the most recent text provided by th= e RFC Editor=E2=80=9D. - Michael and Spencer will be watching that e-mail thread in case the RFC Ediror identifies any changes that need to be approved by the docume= nt shepherd (which is Michael in this case). FFV1 v4 issues - We agreed at our previous meeting that we would use work on the introduction to the FFV1 v4 document as a way of agreeing on contents fo= r FFV1v4, and Jerome said he would start work on the Introduction (added a= s an issue) - https://github.com/FFmpeg/FFV1/blob/master/ffv1-v4-goals.md as our current plan Discussion on the call - We discussed https://github.com/FFmpeg/FFV1/blob/master/ffv1-v4-goals.md on the call. - What about infrared images? That could immediately interest people like autonomous vehicle community (who have money). - What about signatures for stored media? - What is needed here? Integrity, nonrepudiation, timestamps, =E2=80= =A6 we may need to talk about specific use cases to understand the requireme= nts. - No change to the current document contents for now - We can talk about this on the mailing list between now and IETF 111, and then between IETF 111 and our next working group meeting - ACTION: Spencer can take the action to do a short presentation in ARTAREA at IETF 111 in July, showing the proposed contents for FFV1 v4 a= nd pointing people to Cellar. - Matroska issues - No discussion on the call FLAC issues - No discussion on the call AOB? - No discussion on the call NEXT MEETING 2021-08-24 --0000000000003cfd9305ca53a59a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

CELLAR =E2=80=93 DRAFT AGEN= DA for Virtual Interim Meeting

DateTimeLocal Times
2021-08-2421:00 AmsterdamTime Converter
NoteMeeting time is anc= hored to Amsterdam

Administrivia

INFO:

https://gith= ub.com/ietf-wg-cellar/chair-notes/tree/master/interim-2021-07
Note that we=E2=80=99re now pointing to the Github repo for chair not= es here

= WEB CONFERENCE:

https://whereby.com/cellar-interi= m

THERE IS NO TELEPHONE= DIALIN (You can try connecting to the=C2=A0where= by.com=C2=A0link at any time.)

Shared COMIMD for notetaking:=C2=A0https://codimd.ietf.org/notes-cellar-vir= tual

  • Note th= at if you log in to the IETF datatracker, you=E2=80=99ll
    be able to edit these notes, add your name to attendee
    lists, etc.
  • Please ask Spencer if you have= questions.

The ComiMD URL is still redirecting, but the newly off= icial location is=C2=A0https://notes.ietf.org/notes-cellar-virtual?edit=C2=A0- and that=E2= =80=99s active now. Please bookmark the new one when you=E2=80=99re redirec= ted to it.

Logistics for Meeting

2021 virtual interim meeting dates

  • Please note our 2021 dates listed a= t=C2=A0https://data= tracker.ietf.org/wg/cellar/meetings/
  • IETF 112 will also be a fully onli= ne meeting (announced 2021-08-04), so=C2=A0we will not be meeting face-to-face in Madrid, right?= =C2=A0Perhaps in early December, close to Amsterdam with a workshop = on FFv1 and Matroska (also in person) More info at=C2=A0https://mediaarea.net/NoTimeToWait5
  • ACTION:=C2=A0Co-chairs to= propose 2022 meeting schedule in September meeting, for information and co= mment.
    • Septe= mber 28, 2021: 21:00 Paris (1900 UTC)
    • October 26, 2021: 21:00 Paris (1900 U= TC)
    • November 23, 2021: 21:00 Paris (2000 UTC)

Agenda Items

Note Well:=C2=A0https://www.ietf.org/about/note-well/

Roll call

Attendees

  • Spencer Dawkins
  • Steve Lhomme
  • Michael Richardson
  • Jerome Martinez
    • Michael= Neidermayer
  • Dave Rice

*

News You Can Use

WG sta= tus update

  • draft= -ietf-cellar-codec-06 was posted 2021-04-12, in ID Exists
  • draft-ietf-cellar= -ffv1-20 was=C2=A0PUB= LISHED AS RFC 9043
  • draft-ietf-cellar-ffv1-v4-17 was posted 2021-05-2= 5, in ID Exists
  • draft-ietf-cellar-flac-01 was posted 2021-04-27, in ID Exis= ts
  • draft-ietf-cellar-matroska-07 was posted 2021-04-12, in ID Exists
    • draft-= ietf-cellar-tags-06 was posted 2021-04-12, in ID Exists

Milestone = review:

  • Matroska= maybe at the end of Summer 2021? It=E2=80=99s closer than we thought
    • <= li class=3D"gmail-" style=3D"box-sizing:border-box;margin-top:0.25em">Is it= worth publishing an update to ffv1-v4 that includes the goals we=E2=80=99v= e discussed previously?
  • Are we ready to submit a working group draft for EB= ML updates (errata plus additions) yet? (https://github.com/ietf-wg-= cellar/ebml-specification/tree/corrections-doc)
  • FLAC still needs an edi= tor to complete the work. Michael did hear back from Florin, and he=E2=80= =99s unable to serve as editor, so the working group has a decision to make= about FLAC.
Discussion on the call
  • Almost all the Matroska issu= es have PRs waiting for reviews - 7 do not. Steve will work on this during = the coming week, and then send a version for review (soon) (after the PRs a= re merged)
  • Jerome is now able to focus on FFV1-v4, since we=E2=80=99ve publ= ished FFV1.=C2=A0ACTI= ON=C2=A0Spencer to send e-mail to DISPATCH when we submit a (small) = update.
  • We should wait until we have a bit more text, or bigger issues, to = publish as a draft.

M= ichael Richardson has asked to step down as co-chair for SOME WORKING GROUP= , after years of service in this role.

  • This may be CELLAR, but also may not be. He=E2= =80=99s asked the ADs to pick one.
  • We need to have a conversation about suc= cession planning.
  • Michael and Spencer are both IETF process resources, not = technical resources - it would be good to have at least one of each.
    • We cou= ld be using document shepherds to develop talent, but they need to be invol= ved with our work, on calls, etc.
  • Open call on the Cellar mailing list? Mic= hael has reached out to individuals in the past - that worked with Matroska= .
  • IETF working groups do not name their own leadership - that=E2=80=99s an = Area Director responsibity - but ADs make their best choices when they have= all the information we can give them to make choices.

Accept draft minutes from previous meeting (attached= below)

  • Any obje= ctions? Please let us know on the mailing list.

<= /a>Follow-up on Possible switch to Meetecho for our calls

Discussion on previous calls
  • We discussed moving to Meetecho (from= =C2=A0whereby.com) at the May meeting, and Sp= encer had an action to check on iOS and Android clients for Meetecho.
    • <= li class=3D"gmail-" style=3D"box-sizing:border-box;margin-top:0.25em">Spenc= er verified that Meetecho uses WebRTC, so should work with any browser, but= does=C2=A0not= =C2=A0currently have an iOS or Android client available.
  • Michael=E2=80=99s = experience is that Meetecho REALLY needs to run from a computer, and not a = phone or tablet, just because you need a lot of screen real estate to keep = track of queues, chats, and other stuff.
Disc= ussion on the call
  • Is using a computer for Cellar interim meetings a dealbreaker for anyone= ?
  • None on the call =E2=80=A6
  • ACTION=C2=A0Spencer will request Meetecho for our September = meeting.

= FFV1 v4 issues - Discussion on the call

Matroska i= ssues - Discussion on the call

FLAC issues - Discussion on the call

  • Were not discussed on the call

    • AOB?

    • Non= e noted, except that Spencer and Michael expressed their appreciation for t= he people in the working group!

    NEXT MEETING 2021-09-28=C2=A03D":tada:"

    Notes from previous meeting for approval

    CELLAR =E2=80=93 D= RAFT AGENDA for Virtual Interim Meeting

    Date
    Time= Local Times
    2021-06-2221:00 AmsterdamTime Converter
    NoteMeeting t= ime is anchored to Amsterdam

    <= a class=3D"gmail-anchor gmail-hidden-xs" href=3D"https://notes.ietf.org/#Ad= ministrivia1" title=3D"Administrivia1" style=3D"box-sizing:border-box;backg= round-color:transparent;color:rgb(51,122,183);text-decoration-line:none;flo= at:left;padding-right:4px;line-height:1">Administrivia

    INFO:

    https://github.com/ietf-wg-cellar/chair-notes/tree/master/interim-2021-0= 6
    Note that we=E2=80=99re now pointing to the Github repo= for chair notes here

    WEB CONFERENCE:

    https://whereby= .com/cellar-interim

    THE= RE IS NO TELEPHONE DIALIN (You can try connecting to the=C2=A0whereby.com=C2=A0link at any time.)

    Meetecho:
    https://meetings.conf.meetecho.com/interim/?short=3Dd85e39b= d-d5a9-4bc5-a289-1828f8e287f0

    Logistics for Meeting=

    2021 virtual interim meeting da= tes

    Not= e that we do not have a July meeting - (Virtual) IETF 111 will be 2021-07-2= 6 to 2021-07-30.
    Qur next meeting will b= e 2021-08-24=C2=A03D":zap:"

  • IETF 111 in July will definitely b= e virtual.
  • Sometime around 2021-09-28, we=E2=80=99ll see if we want to meet= at IETF 112 on November 6-12, 2021, in person in Madrid.

Shared COMIMD for no= tetaking:=C2=A0https://c= odimd.ietf.org/notes-cellar-virtual

  • Note that if you log in to the IETF datatracker,= you=E2=80=99ll
    be able to edit these no= tes, add your name to attendee
    lists, et= c.
  • Please ask Spencer if you have questions.

APPEAR.IN=C2=A0is now called =E2=80=9C= whereby.com=E2=80=9D (https://whereby.com/cellar-interim)

Agenda Items

Note Well:=C2=A0https://www.ietf.org/about/note-well/

Roll call

Attendees

  • Spencer Dawkins
  • Michael Richardson
  • Jerome Martinez
  • Michael Niede= rmeier
  • Steve Lhomme

R= egrets

  • Reto Krome= r

Accept draft m= inutes from previous meeting (attached below)

  • Any objections? None noted, so approved =E2= =80=A6

Follow-up on Meetecho

  • We discussed moving to Meetecho (from=C2=A0whereby.com) at the May meeting, and Spencer had an act= ion to check on iOS and Android clients for Meetecho.
  • Spencer verified that= Meetecho uses WebRTC, so should work with any browser, but does=C2=A0not=C2=A0currently = have an iOS or Android client available.

= Discussion on the call=

  • Michael=E2=80= =99s experience is that Meetecho REALLY needs to run from a computer, and n= ot a phone or tablet, just because you need a lot of screen real estate to = keep track of queues, chats, and other stuff.
  • Is that a dealbreaker for any= one?

WG status update

  • draft-ietf-cellar-codec-06 was posted 2021-04-12, in ID = Exists
  • draft-ietf-cellar-ffv1-20 was posted 2021-02-23, is now in RFC Edito= r Queue, in AUTH48 (see [AUTH48] below)
  • draft-ietf-cellar-ffv1-v4-17 was po= sted 2021-05-25, in ID Exists
  • draft-ietf-cellar-flac-01 was posted 2021-04-= 27, in ID Exists
  • draft-ietf-cellar-matroska-07 was posted 2021-04-12, in ID= Exists
  • draft-ietf-cellar-tags-06 was posted 2021-04-12, in ID Exists
    • <= /ul>

    Milestone review:

    • Close to celebrating on FFv1, but we need to get through AUTH48
    • Mat= roska maybe at the end of Summer 2021? It=E2=80=99s closer than we thought<= /li>
    • = FLAC still needs an editor to complete the work. Michael did hear back from= Florin, and he=E2=80=99s unable to serve as editor, so the working group h= as a decision to make about FLAC.

    Discussion on the call

    =
  • None

From the mailing list: From Steve, on EBML errata

  • We are proceeding with a shor= t RFC that UPDATES RFC 8794, not replacing that RFC, and this draft will co= ntain only corrections for the errata we are aware of.
  • Jerome asked for an = example of such an RFC - Spencer suggested=C2=A0https://datatracker.ietf.org/doc/rfc8540/=C2=A0on = the mailing list (=E2=80=9CSubject: Sample draft for updating RFC 8794=E2= =80=9D), with suggestions for how to map that example onto the new Cellar d= raft.
  • Steve submitted=C2=A0https://github.com/ietf-wg-cellar/ebml-specification/pu= ll/413=C2=A0to get this started - so we can reasonably
  1. pick a date for this milest= one, and
  2. ask our AD to approve a new milestone (probably =E2=80=9CSubmit sp= ecification for RFC 8794 corrections to IESG (Standards Track)=E2=80=9D), t= o make sure that we can publish this specification when that=E2=80=99s appr= opriate.

Discussion on the call

  • Jerome has been working on this.
  • We probably s= houldn=E2=80=99t plan to finish our EBML corrections draft before we finish= Matroska, because we may find things in EBML that need to be corrected for= Matroska.
  • We created the milestone for this document, for our AD to approv= e.

A= UTH48 for draft-ietf-cellar-ffv1-20

Email subject: AUTH48 [JM]: RFC 9043 <draft-ietf-cellar-ffv1-2= 0.txt> NOW AVAILABLE

Cur= rent files from RFC-Editor

  1. https://www.rfc-editor.org/authors/r= fc9043.txt
    https://www.rfc-editor.org/authors/rfc9043.pdf=
    https://www.rfc-editor.org/authors/rfc9043.html
    https://www.rfc-editor.org/authors/rfc9043.xml

  2. This diff shows all changes from th= e approved Internet-Draft:
    https://www.rfc-editor.org/= authors/rfc9043-diff.html
    https://www.rfc-editor.= org/authors/rfc9043-rfcdiff.html=C2=A0(side by side)

  3. This diff shows only the most recent = changes:
    https://www.rfc-editor.org/authors/rfc9043-= lastdiff.html
    https://www.rfc-editor.org/auth= ors/rfc9043-lastrfcdiff.html=C2=A0(side by side)

  4. This diff compares the submitted and curre= nt XML files:
    https://www.rfc-editor.org/authors/rfc= 9043-xmldiff1.html
    https://www.rfc-editor.org/= authors/rfc9043-xmldiff2.html=C2=A0(side by side)

Discu= ssion on the call

  • We didn=E2=80=99t have Dave, but Jerome was also working on these correct= ions with the RFC Editor.
  • Jerome thinks that all of the corrections have be= en agreed by all of the authors.
  • ACTION:=C2=A0The authors should review the text provided= by the RFC Editor and (if no further changes is needed) just reply toall t= o the AUTH48 email thread and say =E2=80=9CI agree with the most recent tex= t provided by the RFC Editor=E2=80=9D.
  • Michael and Spencer will be watching= that e-mail thread in case the RFC Ediror identifies any changes that need= to be approved by the document shepherd (which is Michael in this case).

= FFV1 v4 issues

  • We agreed at our previous meeting that we would use work on the introduc= tion to the FFV1 v4 document as a way of agreeing on contents for FFV1v4, a= nd Jerome said he would start work on the Introduction (added as an issue)<= /li>
  • = https://g= ithub.com/FFmpeg/FFV1/blob/master/ffv1-v4-goals.md=C2=A0as our current = plan

Discussion on the call

  • We discussed=C2=A0https://github.com/FFmpeg/FFV1/blob/mas= ter/ffv1-v4-goals.md=C2=A0on the call.
  • What about infrared images? Th= at could immediately interest people like autonomous vehicle community (who= have money).
  • What about signatures for stored media?
    • What is needed here? Integrity,= nonrepudiation, timestamps, =E2=80=A6 we may need to talk about specific u= se cases to understand the requirements.
  • No change to the current= document contents for now
  • We can talk about this on the mailing list betwe= en now and IETF 111, and then between IETF 111 and our next working group m= eeting
  • ACTION:= =C2=A0Spencer can take the action to do a short presentation in ARTAREA at = IETF 111 in July, showing the proposed contents for FFV1 v4 and pointing pe= ople to Cellar.

Matroska issues

  • No discussion on the call

FLAC issues

  • No discussion on the call

<= a class=3D"gmail-anchor gmail-hidden-xs" href=3D"https://notes.ietf.org/#AO= B1" title=3D"AOB1" style=3D"box-sizing:border-box;background-color:transpar= ent;color:rgb(51,122,183);text-decoration-line:none;float:left;padding-righ= t:4px;line-height:1">AOB?

  • No discussion on the call

NEXT MEETING 2021-08-24=C2=A0

--0000000000003cfd9305ca53a59a-- From nobody Tue Aug 24 14:02:16 2021 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 6C60A3A12FB for ; Tue, 24 Aug 2021 14:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 B5SmI_zM8Csg for ; Tue, 24 Aug 2021 14:02:08 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 558C53A12F7 for ; Tue, 24 Aug 2021 14:02:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id E314738A2E; Tue, 24 Aug 2021 17:07:33 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id E5XgcbOaGAZ0; Tue, 24 Aug 2021 17:07:28 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 48C2738A28; Tue, 24 Aug 2021 17:07:28 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 47CD516E; Tue, 24 Aug 2021 17:01:58 -0400 (EDT) From: Michael Richardson To: Steve Lhomme , "Murray S. Kucherawy" , Spencer Dawkins at IETF , Codec Encoding for LossLess Archiving and Realtime transmission , Francesca Palombini In-Reply-To: References: <4945.1629386506@localhost> <22109.1629403274@localhost> <31989.1629428105@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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] Conversation about a NON-IANA request in Matroska 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 Aug 2021 21:02:15 -0000 --=-=-= Content-Type: text/plain Steve Lhomme wrote: > Given one of the goal on this Matroska specification is long time > preservation, that would seem odd to design something that renders > older systems incompatible with the current/new specifications. If any > of the MIME types we have in attachments were to become invalid all of > a sudden we wouldn't like it. That's not what I suggested. I suggested that every reader would always accept both values. But that, at some date in the future, writers would start using the new values. I suggested that the date be decided now in order to: a) establish a deadline for readers to get updated. b) allow writing software to gracefully transition without having to be updated. (of course, such software could also have an option) We assume that the files are forever, but that the software that reads them will get updated now and then. In reality, the mime type doesn't really go anywhere specific unless the file is being transfered over email or http. On MAC, with HFS, the MIME type might lookup a resource type which gets associated with the file. But I suspect that one can associate two things with one resource, and I also suspect (having really never coded for MacOS) that it doesn't take mime types as input anyway. -- ] 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 [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmElXkUACgkQgItw+93Q 3WWNGAf/aMoa2tRKeu1rxiXLRbLzBL2GHuWapBbn/o88okNQpjswPseX5+3ek4Yn ZA+kQCBSdqbCw6bvnM0G/YtcUZhaqp4ueqog9jbZ6E1sgVKl+kk6q03VMo8cvH1s wWPXHolWpgcP+V+1GIPDSqbCk6phCmrEsqzIyZF0o1/bXFlmGofGe/3BoU8blIc1 LvqF2wmehJUIIyn1FMrPtRTiGQO0+wVh/VqMRtTyRI+HTqSRkoyAK++TmTCle9Z0 MbU5dZdXyKCly62vIP2+1S1SMQRhNWOSxk3y9wrWJVmzNrRBtIHmyjxYd4fzMslm ZHL8uZJkxr4/tvmUdRotlQggScey2g== =MPBr -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 25 00:04:00 2021 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 600BE3A0B3C for ; Wed, 25 Aug 2021 00:03:57 -0700 (PDT) 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, NICE_REPLY_A=-0.001, 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 9ck6HKHCl5Yu for ; Wed, 25 Aug 2021 00:03:50 -0700 (PDT) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 0523B3A0B37 for ; Wed, 25 Aug 2021 00:03:49 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id v20-20020a1cf714000000b002e71f4d2026so3036913wmh.1 for ; Wed, 25 Aug 2021 00:03:49 -0700 (PDT) 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=eYJTODi+i7hGEoHfct3mN++lgnmMsJ68s37ghpZh9d8=; b=g1lQTeZwkzckUGRnCnMTMb3T/tFV9wbO4V8kQ9SLzoEPdQD9JaUXibQH3ZWoJwackQ r/8S4ZTYyl2eS/feKxSUr6WI2gfEKfKYf8qt/qfq3vDLZZg0J3j0NpK8WEPQ2Ge646cQ j2ZF5Wdp8vsWvxovBFTKae4ZL7eDe5JE442eH+tmzyWgBOG2GAcYXRGzTBAuY1SgjRIu 6QnU+H3afWT8KtbWBgymyR2NuuJWWyJobEWiYsEYSIZl8wWOyK2u8AJU7AiakpEipkx3 8uwEhplFBNkDsoPxTNrslV0re0T7bMWLQKKGDktcGba2RL5N6B2RjvZrj67NkdcOtgKh O3Jg== 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=eYJTODi+i7hGEoHfct3mN++lgnmMsJ68s37ghpZh9d8=; b=hq3JZt99HlWPoNToTkqUTBzWyRmCkNSBZ5zJGhkjr6gl4aFSO5OGl1cr55/yU5KlQs mIqNbokBRrwK8eGhLWnLoGvdq4Yfl/HZkKpT+4RjYvmdLhEkPG4S9qyqG486eRiBuwck WWDuHzJQ18lopu1Sh0VZJbG0dDlkArhVRK8QoshkrOUgG+HWdvR6fw3GcZ2FReFRAk1N 7fRS8GTnUKvpEWEbXQD8guRNWFvO3wUCun34qBCqgju2z9WKJoqRPNoAKc5QO6QCJRCI IxJb1Qwg9fmaAsa0UjSsEaMtplrRO7KmL+zFPm7rwVmIA6pAPpgRPIgOsVk8oHZBef+H oqUQ== X-Gm-Message-State: AOAM531fnSG3YM+kglJwnKJLATdDazdMCPsxmhwfTAFak+Ziq0jZnb+6 VAKIhZjX8KtwKrDDUAovGWvQzQ== X-Google-Smtp-Source: ABdhPJzmynsWcgdBlR663pRVlV0SL7GUmdr6drrNT+K7Y4WtZ/RYg7PWnAbTSamxPU9nRmcblx6Wrw== X-Received: by 2002:a7b:c041:: with SMTP id u1mr7389626wmc.95.1629875023368; Wed, 25 Aug 2021 00:03:43 -0700 (PDT) Received: from ?IPv6:2a01:cb0c:20:e900:e4c9:8e45:d76b:34fd? (2a01cb0c0020e900e4c98e45d76b34fd.ipv6.abo.wanadoo.fr. [2a01:cb0c:20:e900:e4c9:8e45:d76b:34fd]) by smtp.gmail.com with ESMTPSA id l15sm4245902wms.38.2021.08.25.00.03.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Aug 2021 00:03:43 -0700 (PDT) To: Michael Richardson , "Murray S. Kucherawy" , Spencer Dawkins at IETF , Codec Encoding for LossLess Archiving and Realtime transmission , Francesca Palombini References: <4945.1629386506@localhost> <22109.1629403274@localhost> <31989.1629428105@localhost> <14770.1629838918@localhost> From: Steve Lhomme Message-ID: <26ac55ea-2f04-d21a-8dee-ef819fa249c2@matroska.org> Date: Wed, 25 Aug 2021 09:03:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <14770.1629838918@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] Conversation about a NON-IANA request in Matroska 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 Aug 2021 07:03:58 -0000 Hi, On 2021-08-24 23:01, Michael Richardson wrote: > > Steve Lhomme wrote: > > Given one of the goal on this Matroska specification is long time > > preservation, that would seem odd to design something that renders > > older systems incompatible with the current/new specifications. If any > > of the MIME types we have in attachments were to become invalid all of > > a sudden we wouldn't like it. > > That's not what I suggested. Sorry for misinterpreting your words. > I suggested that every reader would always accept both values. > > But that, at some date in the future, writers would start using the new > values. I suggested that the date be decided now in order to: > a) establish a deadline for readers to get updated. > b) allow writing software to gracefully transition without having to be updated. > (of course, such software could also have an option) > > We assume that the files are forever, but that the software that reads them > will get updated now and then. > > In reality, the mime type doesn't really go anywhere specific unless the file > is being transfered over email or http. On MAC, with HFS, the MIME type > might lookup a resource type which gets associated with the file. > > But I suspect that one can associate two things with one resource, and I also > suspect (having really never coded for MacOS) that it doesn't take mime types > as input anyway. I agree with that. But I have the same concern as Murray that a hardcoded deadline may not really work. It also doesn't seem like how our RFCs are designed, where we have some legacy values that should not be used throughout the Matroska format. Then we would also need to set some deadline for these values not be allowed to be written. In the end when we say it SHOULD NOT be used, it applies right away, not some date in the future. That's the same approach I took with the transition of MIME types. Just like updating muxers may take some time, updating web servers and UPNP servers to update they MIME database will take some time. > -- > ] 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 [ >