From nobody Sun May 2 00:28:50 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 6FF713A21D1 for ; Sun, 2 May 2021 00:28:47 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKtx1OBVlNDm for ; Sun, 2 May 2021 00:28:43 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 013473A21D0 for ; Sun, 2 May 2021 00:28:42 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id m9so2295729wrx.3 for ; Sun, 02 May 2021 00:28:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ZM2tEx3+u7Eeqfli0fjZvA8ZLdzelqGG/dYgtHKMDFg=; b=rMrbwjpHYA6AWmXTpp4E25Jfx71/DnHXcqwU7UvkVydkP27Du5nInPg4j8x9miQXME 0h7JoGDMSo8fOofd4cElnFSliyu2CX1amos/vPuo/30OQIOzxM+8+bsbQu7Em0wkzzMZ QI9S/520cWrRR1GeD7wVSN5RGF3zge/y9IJ3U7a2rkL4Oi9x8PABtchXFEK3ZVB+q3Vs B7DW4Djq76uPxJNybPS77W0OP4Cr+qpOdqLF+14lSvA96iCKubkiajjBQ8LeCgWoGlDj 90QdLRYKaom0O9q+TYEbyL8ZQzf4MKme+XoIpuSBIPazemD6zBiRKJ/dkT2QWdjRS3ea HlEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ZM2tEx3+u7Eeqfli0fjZvA8ZLdzelqGG/dYgtHKMDFg=; b=rblxhpXDGiYwT5K+p90BanOzmBDx65ZhJXvvMZ1/p0ZGYPiVnih59+N7WFNhaK3Sgg EBY4o7LRGs7fk6D8/htJaxJVXQLIbFXq4yepxygBh8KUznDtq7Tf/zLAM2zGrsdBNj1Z zxj1Rx0fAyszRzg36XvijmGaAXQQWYmxvo4ggOE95GWb3HKak+cEhhD1fbVMBBtWDJCW ltk/zqi59In6BaA7h+mPHw/7l+Qnw0zl6SYFeIdWb2xQR8VM+2LOi4qcKg9nFdk7R+86 ANKANLpToEKUwnne/Z4li44BjG5UM/jdyNr/Sbr562MiW04XvRJh/SQCBQswUud39BtI y1qQ== X-Gm-Message-State: AOAM532kPx3Uwkcbw71v/8mca60DBoeRRbPW6tPm4RWCsszp1UieXR3Y dZikHR5o/hVxxAR/3R06PdnTaH5NGBqtpQGt X-Google-Smtp-Source: ABdhPJxsEPG7Knrey9nkIe+fkNQjkq/YEavVBun7KlNUiHHKlStUiQkyCF7zcqkrXsyko8ickT7jeQ== X-Received: by 2002:a5d:628c:: with SMTP id k12mr17312463wru.206.1619940519748; Sun, 02 May 2021 00:28:39 -0700 (PDT) Received: from ?IPv6:2a01:cb0c:20:e900:8c00:89aa:106f:59b8? (2a01cb0c0020e9008c0089aa106f59b8.ipv6.abo.wanadoo.fr. [2a01:cb0c:20:e900:8c00:89aa:106f:59b8]) by smtp.gmail.com with ESMTPSA id g19sm7318770wme.48.2021.05.02.00.28.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 02 May 2021 00:28:38 -0700 (PDT) To: Spencer Dawkins at IETF Cc: Codec Encoding for LossLess Archiving and Realtime transmission References: <0b3b9f34-187b-3420-18df-f75c1b75744f@matroska.org> <630dbd55-3f84-ce9e-18c6-5d6a7063dd53@matroska.org> From: Steve Lhomme Message-ID: <0b86371c-976a-3417-4f26-4992e2790883@matroska.org> Date: Sun, 2 May 2021 09:28:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] Special topics for April 2021 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: Sun, 02 May 2021 07:28:48 -0000 On 2021-04-28 19:52, Spencer Dawkins at IETF wrote: > Hi, Steve, >=20 > On Wed, Apr 28, 2021 at 8:30 AM Steve Lhomme > wrote: >=20 > On 2021-04-27 21:58, Spencer Dawkins at IETF wrote: > > Hi, Steve, > > > > On Fri, Apr 23, 2021 at 1:23 AM Steve Lhomme > > > >> wro= te: > > > >=C2=A0 =C2=A0 =C2=A0On 2021-04-20 23:47, Spencer Dawkins at IETF = wrote: > >=C2=A0 =C2=A0 =C2=A0 > Dear Cellar, > >=C2=A0 =C2=A0 =C2=A0 > > >=C2=A0 =C2=A0 =C2=A0 > We have a monthly meeting scheduled for Tu= esday, April 27. > >=C2=A0 =C2=A0 =C2=A0 > > >=C2=A0 =C2=A0 =C2=A0 > Are there special topics that we should ma= ke sure are on > the=C2=A0agenda? > > > >=C2=A0 =C2=A0 =C2=A0Hi Spencer, > > > >=C2=A0 =C2=A0 =C2=A0There are 2 main topics I'd like to see discu= ssed: > > > > > > We talked about both of these on today's call (CodiMD=C2=A0is at= > > https://codimd.ietf.org/notes-cellar-virtual?edit > > > >). >=20 > Uh. I'm so sorry. My internal clock is all messed up these days. I > though the meeting was *today* ! > I must setup some more efficient alarms for next time... >=20 >=20 > It happens! Michael and I tried to take good notes during the meeting. >=20 >=20 > >=C2=A0 =C2=A0 =C2=A0- the reordering of some sections in Matroska=20 #495 which is > needed IMO > >=C2=A0 =C2=A0 =C2=A0and is blocking other changes in the text sec= tions that are > moved. It > >=C2=A0 =C2=A0 =C2=A0may be necessary to build the txt/html file t= o see how it > changes. I > >=C2=A0 =C2=A0 =C2=A0could send the before and after versions to t= he mailing list. > > > > > > We thought your suggestion to send before/after versions to the > mailing > > list was excellent - please proceed as you suggested! >=20 >=20 > Are you OK to send these versions to the mailing list? Since they are huge files I posted them on my own repo on Github, with a = before and after version. More details and links here https://github.com/ietf-wg-cellar/matroska-specification/pull/495#issueco= mment-830764409 > Best, >=20 > Spencer >=20 > > > > > >=C2=A0 =C2=A0 =C2=A0- how to handle the errata to the EBML RFC, w= e have 2 merged > changes > >=C2=A0 =C2=A0 =C2=A0and > >=C2=A0 =C2=A0 =C2=A02 pending changes. > > > > > > We actually worked on submitting these errata to the RFC Errata > system > > on the call. > > > > Thanks for helping keep us on track! > > > > Spencer > > > > > >=C2=A0 =C2=A0 =C2=A0 > Best, > >=C2=A0 =C2=A0 =C2=A0 > > >=C2=A0 =C2=A0 =C2=A0 > Spencer, who is trying to do a better job = of sending out > >=C2=A0 =C2=A0 =C2=A0reminders :-) > >=C2=A0 =C2=A0 =C2=A0 > > >=C2=A0 =C2=A0 =C2=A0 > __________________________________________= _____ > >=C2=A0 =C2=A0 =C2=A0 > Cellar mailing list > >=C2=A0 =C2=A0 =C2=A0 > Cellar@ietf.org > > > >=C2=A0 =C2=A0 =C2=A0 > https://www.ietf.org/mailman/listinfo/cell= ar > > >=C2=A0 =C2=A0 =C2=A0 > > >=C2=A0 =C2=A0 =C2=A0 > > > > > > >=C2=A0 =C2=A0 =C2=A0_____________________________________________= __ > >=C2=A0 =C2=A0 =C2=A0Cellar mailing list > > Cellar@ietf.org > > > https://www.ietf.org/mailman/listinfo/cellar > > >=C2=A0 =C2=A0 =C2=A0 > > > >=20 From nobody Sun May 2 00:51:08 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 8BBF13A228C for ; Sun, 2 May 2021 00:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 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_DNSWL_LOW=-0.7, 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=I2oijSmP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XZOxRXyH 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 XEUaghT9GGqT for ; Sun, 2 May 2021 00:51:00 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.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 DCE8F3A228A for ; Sun, 2 May 2021 00:51:00 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id F24EA13C6 for ; Sun, 2 May 2021 03:41:46 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 02 May 2021 03:41:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm2; bh=XOLxFon6lH3 qu3shhTbl95DKY0S0FVWJphpvL0FjnT8=; b=I2oijSmPGSfXzh1sBOPPZ7ocFst +ZTkxKBH8IJmgTZWExWIyEp10om9PW6oQy1fPlyV4papbbIMhoVYu6gHsPsLGeAd LxSV5gYLL7TcBqkcT/jmV4T9n//GuggidW+fZgrMov1+h8e8GRwc85Y0L3QH5xeN iLtzqGiS2sn00K9zpNQCFxWox4Z5CP5iTNoBT69d1WPUlZyHbv0Slk0sj/1BIV3O PJC2FD1cqF4Fo3qceH8gEIMpKed9/sbh4ihSje3dnOmEtEjdx7wr3NV30sfLdmEL mm1qz8U3PBSUvdUn5NTyHL749CIiBjksYlrb4leJB9SIIgrkzfyvz7njcFw== 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= fm2; bh=XOLxFon6lH3qu3shhTbl95DKY0S0FVWJphpvL0FjnT8=; b=XZOxRXyH T4wX0pFtxRs6AEodssGhUm+7jSiZURsNy4WH8xIgjmqrP61+QGOK6t8OBShQS807 +JcP4q+Wk6H7j4lvQJGRfLz/xieiJafruYIXYdAcm9sfqgLoBFRLUrUN8Trw5LmW V+Y8bxL8vsgy5NVsNZd27zJ2ZWv2DYQXhPgXPRIzZD6ijPj0+2EK+uxTIqI8J5+j OBVKb256p0UTrMORH5vRAZjq3+VupdKK0nXvWyqP5p5H8x8obM7B8e9edqd7KZWs +IG4YjJWGS1acqf+asz/ZvazVKvaheKUnRa5yJy6OVFizJMqrix6BVC3cuxaB9ll l5O66XmWAEn7GQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdefuddggeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucfpohcuuggrthgvuchfihgvlhguucdlgeelmdenuc fjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpeftvghpohhsihhtohhrhicu tegtthhivhhithihucfuuhhmmhgrrhihuceuohhtuceoughopghnohhtpghrvghplhihse hmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeefvdduteejvdefkeehieevuefg fefhteetveegffekffefteffvdelheduieetnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucfkphepudefrdekvddruddrudekleenucevlhhushhtvghrufhiiigvpedunecu rfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvg ht X-ME-Proxy: Received: from fv-az201-515.ett4tu3jvdse5ovc2mkgjqcs5a.bx.internal.cloudapp.net (unknown [13.82.1.189]) by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 2 May 2021 03:41:46 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============6145308879304033184==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20210502075100.DCE8F3A228A@ietfa.amsl.com> Date: Sun, 2 May 2021 00:51:00 -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, 02 May 2021 07:51:06 -0000 --===============6145308879304033184== 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/matroska-specification (+0/-0/=F0=9F=92=AC3) 2 issues received 3 new comments: - #500 Add an EBML constraint about 0-length elements (1 by hubblec4) https://github.com/ietf-wg-cellar/matroska-specification/issues/500 [cl= arifications] [format addition] [spec_main]=20 - #478 fix ChapterTimeEnd section (2 by hubblec4) https://github.com/ietf-wg-cellar/matroska-specification/issues/478 [bu= g] [spec_main]=20 * FFmpeg/FFV1 (+1/-1/=F0=9F=92=AC0) 1 issues created: - add list of ffv4 goals and promises (by mcr) https://github.com/FFmpeg/FFV1/issues/262=20 1 issues closed: - add list of ffv4 goals and promises https://github.com/FFmpeg/FFV1/issu= es/262=20 * ietf-wg-cellar/Cellar-FLAC (+1/-0/=F0=9F=92=AC0) 1 issues created: - list of authors is unclear (by mcr) https://github.com/ietf-wg-cellar/Cellar-FLAC/issues/93=20 Pull requests ------------- * ietf-wg-cellar/matroska-specification (+0/-0/=F0=9F=92=AC2) 2 pull requests received 2 new comments: - #495 Reorder/Reparent sections in the Matroska RFC (1 by robUx4) https://github.com/ietf-wg-cellar/matroska-specification/pull/495 [form= atting] [spec_main]=20 - #473 make ChapterTimeEnd mandatory for ordered chapters (1 by hubblec4) https://github.com/ietf-wg-cellar/matroska-specification/pull/473 [clar= ifications] [spec_main]=20 * ietf-wg-cellar/Cellar-FLAC (+1/-1/=F0=9F=92=AC0) 1 pull requests submitted: - update flac to build with xml2rfc v3 and bump version (by dericed) https://github.com/ietf-wg-cellar/Cellar-FLAC/pull/92=20 1 pull requests merged: - update flac to build with xml2rfc v3 and bump version https://github.com/ietf-wg-cellar/Cellar-FLAC/pull/92=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 --===============6145308879304033184== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

Sunday May 02, 2021

Events without label "editorial"

Issues

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

2 issues received 3 new comments:

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

1 issues created:

1 issues closed:

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

1 issues created:

Pull requests

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

2 pull requests received 2 new comments:

ietf-wg-cellar/Cellar-FLAC (+1/-1/=F0=9F=92=AC0)

1 pull requests submitted:

1 pull requests merged:

Repositories tracked by this digest:

--===============6145308879304033184==-- From nobody Mon May 3 16:57:12 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 2ACBC3A19B9 for ; Mon, 3 May 2021 16:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_BLOCKED=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 r9DcsRMQgxRv for ; Mon, 3 May 2021 16:57:01 -0700 (PDT) Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (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 B47733A19B8 for ; Mon, 3 May 2021 16:57:01 -0700 (PDT) Received: by mail-yb1-xb2d.google.com with SMTP id h202so847928ybg.11 for ; Mon, 03 May 2021 16:57:01 -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=8rSEv17ZU/xAEU8nyXz0/xHBlj9qLzLZFLlyUCD+VxU=; b=jVZQ0Q+5X16ZbSqgJ4rH7l7+k4b7BIuP+n5aUg1QGbUk8q5aUyCQ1TyCKhvW1LAAxn Oa0KIioH3L6SqqqmvSYhysDvBo5Xp+ZVCrocNgxfsavX6iWX+NaYoPt3YwoSdk5X3e9o h+1988XaBUhuLfFMwaR0cECGYImxAl3pOpImALo2tMDplEpLh+rJzjaRv8faJ8yFoxhD J03y8ue82IWnZFk9x1zKhZyR8fUZWzVZ/qxkJcIugHeMecgqDBJm3TLKbGVcnxtxgYeJ GeyF0kh9FLXODmYsEqTihM8jOgsMSafiY4AXbiMyRhILgFOFacmzZ4CxkY+1BCSfL3cQ hiTg== 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=8rSEv17ZU/xAEU8nyXz0/xHBlj9qLzLZFLlyUCD+VxU=; b=AsqjHo1aq+PjbeVuG3F3NFDPiz7+T9gdA0xIgrfC/bIxp1aemjwMNrSvIO6cGbER+3 lADpHmKmxiKxIQbnZjlmNAZg9fSLJX33NyelnyWxSzM0VwmB6RxivZLJi4MzH1o3AeqA 4Snlr9657Iak0spp/Bsxo7PmZsQXQOrtgqqSj6joIXujmpu8aUyOGikhQU/nAszPl3sK aWWIvoIsms41ppTx7tGa+wu5zkiULTE1/iYs5fDEzb7QPrjMWnVMgKGeuyTZcjMiQv2f wPcIx/Wj5KMQHwnesLkwBgokr2IiNmwDD2/goTBJErgBZXsR3BeKri27L4Dcu25gK/co Yohw== X-Gm-Message-State: AOAM530qs+Rilx5v/w4DqrXAlSz0FSIenZIprCBNkO/OOqgLDxG1XOzM hUrd2sBeAIpZKscaky41IrOoUjryuV9d/c6owDvY8UE4RYY= X-Google-Smtp-Source: ABdhPJwvkjS1f0wjyNlbGOL9fbA9IrO+IsKek8/adOYuxjBsPz8x0my8dS4bS82uRzdwD9nWxMluC9IVFJVSVSYxvhk= X-Received: by 2002:a25:afc8:: with SMTP id d8mr30873508ybj.389.1620086220118; Mon, 03 May 2021 16:57:00 -0700 (PDT) MIME-Version: 1.0 References: <0b3b9f34-187b-3420-18df-f75c1b75744f@matroska.org> <630dbd55-3f84-ce9e-18c6-5d6a7063dd53@matroska.org> <0b86371c-976a-3417-4f26-4992e2790883@matroska.org> In-Reply-To: <0b86371c-976a-3417-4f26-4992e2790883@matroska.org> From: Spencer Dawkins at IETF Date: Mon, 3 May 2021 18:56:33 -0500 Message-ID: To: Steve Lhomme Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="000000000000a7e16e05c175b73e" Archived-At: Subject: Re: [Cellar] Special topics for April 2021 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: Mon, 03 May 2021 23:57:10 -0000 --000000000000a7e16e05c175b73e Content-Type: text/plain; charset="UTF-8" Hi, Steve, On Sun, May 2, 2021 at 2:28 AM Steve Lhomme wrote: > On 2021-04-28 19:52, Spencer Dawkins at IETF wrote: > > Hi, Steve, > > > > On Wed, Apr 28, 2021 at 8:30 AM Steve Lhomme > > wrote: > > > > On 2021-04-27 21:58, Spencer Dawkins at IETF wrote: > > > Hi, Steve, > > > > > > On Fri, Apr 23, 2021 at 1:23 AM Steve Lhomme > > > > > >> > wrote: > > > > > > On 2021-04-20 23:47, Spencer Dawkins at IETF wrote: > > > > Dear Cellar, > > > > > > > > We have a monthly meeting scheduled for Tuesday, April 27. > > > > > > > > Are there special topics that we should make sure are on > > the agenda? > > > > > > Hi Spencer, > > > > > > There are 2 main topics I'd like to see discussed: > > > > > > > > > We talked about both of these on today's call (CodiMD is at > > > https://codimd.ietf.org/notes-cellar-virtual?edit > > > > > > >). > > > > Uh. I'm so sorry. My internal clock is all messed up these days. I > > though the meeting was *today* ! > > I must setup some more efficient alarms for next time... > > > > > > It happens! Michael and I tried to take good notes during the meeting. > > > > > > > - the reordering of some sections in Matroska > #495 which is > > needed IMO > > > and is blocking other changes in the text sections that are > > moved. It > > > may be necessary to build the txt/html file to see how it > > changes. I > > > could send the before and after versions to the mailing list. > > > > > > > > > We thought your suggestion to send before/after versions to the > > mailing > > > list was excellent - please proceed as you suggested! > > > > > > Are you OK to send these versions to the mailing list? > > Since they are huge files I posted them on my own repo on Github, with a > before and after version. More details and links here > > https://github.com/ietf-wg-cellar/matroska-specification/pull/495#issuecomment-830764409 Perfect! Spencer > > Best, > > > > Spencer > > > > > > > > > > > - how to handle the errata to the EBML RFC, we have 2 merged > > changes > > > and > > > 2 pending changes. > > > > > > > > > We actually worked on submitting these errata to the RFC Errata > > system > > > on the call. > > > > > > Thanks for helping keep us on track! > > > > > > Spencer > > > > > > > > > > Best, > > > > > > > > Spencer, who is trying to do a better job of sending out > > > reminders :-) > > > > > > > > _______________________________________________ > > > > Cellar mailing list > > > > Cellar@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/cellar > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Cellar mailing list > > > Cellar@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/cellar > > > > > > > > > > > > > > > --000000000000a7e16e05c175b73e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Steve,=C2=A0

On Sun, May 2, 2021 at 2:= 28 AM Steve Lhomme <slhomme@matr= oska.org> wrote:
On 2021-04-28 19:52, Spencer Dawkins at IETF wrote:
> Hi, Steve,
>
> On Wed, Apr 28, 2021 at 8:30 AM Steve Lhomme <slhomme@matroska.org
> <mailto:s= lhomme@matroska.org>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 2021-04-27 21:58, Spencer Dawkins at IETF wrote:=
>=C2=A0 =C2=A0 =C2=A0 > Hi, Steve,
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > On Fri, Apr 23, 2021 at 1:23 AM Steve Lhomme<= br> >=C2=A0 =C2=A0 =C2=A0<slhomme@matroska.org <mailto:slhomme@matroska.org>
>=C2=A0 =C2=A0 =C2=A0 > <mailto:slhomme@matroska.org <mailto:slhomme@matroska.org>>= > wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0On 2021-04-20 23:47, Spenc= er Dawkins at IETF wrote:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Dear Cellar,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > We have a monthly me= eting scheduled for Tuesday, April 27.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Are there special to= pics that we should make sure are on
>=C2=A0 =C2=A0 =C2=A0the=C2=A0agenda?
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Hi Spencer,
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0There are 2 main topics I&= #39;d like to see discussed:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > We talked about both of these on today's = call (CodiMD=C2=A0is at
>=C2=A0 =C2=A0 =C2=A0 > https://codimd.ietf.o= rg/notes-cellar-virtual?edit
>=C2=A0 =C2=A0 =C2=A0<https://codimd.ietf.org= /notes-cellar-virtual?edit>
>=C2=A0 =C2=A0 =C2=A0 > <https://codimd.ie= tf.org/notes-cellar-virtual?edit
>=C2=A0 =C2=A0 =C2=A0<https://codimd.ietf.org= /notes-cellar-virtual?edit>>).
>
>=C2=A0 =C2=A0 =C2=A0Uh. I'm so sorry. My internal clock is all mess= ed up these days. I
>=C2=A0 =C2=A0 =C2=A0though the meeting was *today* !
>=C2=A0 =C2=A0 =C2=A0I must setup some more efficient alarms for next ti= me...
>
>
> It happens! Michael and I tried to take good notes during the meeting.=
>
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0- the reordering of some s= ections in Matroska
#495 which is
>=C2=A0 =C2=A0 =C2=A0needed IMO
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0and is blocking other chan= ges in the text sections that are
>=C2=A0 =C2=A0 =C2=A0moved. It
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0may be necessary to build = the txt/html file to see how it
>=C2=A0 =C2=A0 =C2=A0changes. I
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0could send the before and = after versions to the mailing list.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > We thought your suggestion to send before/aft= er versions to the
>=C2=A0 =C2=A0 =C2=A0mailing
>=C2=A0 =C2=A0 =C2=A0 > list was excellent - please proceed as you su= ggested!
>
>
> Are you OK to send these versions to the mailing list?

Since they are huge files I posted them on my own repo on Github, with a before and after version. More details and links here
https://gith= ub.com/ietf-wg-cellar/matroska-specification/pull/495#issuecomment-83076440= 9

Perfect!

Spe= ncer
=C2=A0
Cellar@ietf.org <mailto:Cellar@ietf.org>
>=C2=A0 =C2=A0 =C2=A0<mailto:Cellar@ietf.org <mailto:Cellar@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > h= ttps://www.ietf.org/mailman/listinfo/cellar
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman= /listinfo/cellar>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<htt= ps://www.ietf.org/mailman/listinfo/cellar
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman= /listinfo/cellar>>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0__________________________= _____________________
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Cellar mailing list
>=C2=A0 =C2=A0 =C2=A0 > Cellar@ietf.org <mailto:Cellar@ietf.org> <mailto:Cellar@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:Cellar@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0 > https://www.ietf.org/mailm= an/listinfo/cellar
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman= /listinfo/cellar>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<htt= ps://www.ietf.org/mailman/listinfo/cellar
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman= /listinfo/cellar>>
>=C2=A0 =C2=A0 =C2=A0 >
>


--000000000000a7e16e05c175b73e-- From nobody Sat May 8 23:46:57 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 C94523A1D24 for ; Sat, 8 May 2021 23:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=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 a8o3alylFS9N for ; Sat, 8 May 2021 23:46:51 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57CD23A1D22 for ; Sat, 8 May 2021 23:46:51 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id l14so13297409wrx.5 for ; Sat, 08 May 2021 23:46:50 -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=NVpnlqTwYCgitL4gtR9VWmZ5JetTX+FLIfcpxeg3FSA=; b=DbUns3rQGIi9ua9iD0XbqzRe++CwGvb54lre4xTm7nByDBUsxKDp/5cF8u79uYpdVw bYHylPp39iiwDmPHxuWovJ3luwbCdR6zNN6bioGFZ3cCQCR9QbOhWYFR/v84cOjrM1i+ Af2zmCytsx/r6zSxmxOlCTkfbb2tRQneqlrDpBrbKzBeh9VV+eAVvA+CrHDLy2qJZF5J +/O2aXAE36/EwAcoPpllMfs3euWouF3FbNXK+fekcsJBN2xAfn/XPlQae1htwdAJx1Ol z3RBiKpUO8elnswekx40VTJD1tl91jbRA4AW4lVN6AxWLJKii7GUYEoldFxaeOwGfBEm b4Bw== 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=NVpnlqTwYCgitL4gtR9VWmZ5JetTX+FLIfcpxeg3FSA=; b=YK5YupCu8WDmQGv5DnyUBuM1UmAd/WloaWQXLyQN5TFyjukdy2icSBXYMIzBZpfwSi +MOMadlc3YkztY7nrUn0wGgOFIv8Q28XetOdKRHrL5zQxsYMT+Dhkh38pAl3SxgZzGWt wjiv6ADMuf2Z+Zo1B7At3wPgEcHdmQxxg2uGIZsBldb3PzxS7WFz0Xtwi945CrHwpE9+ koZpi0MVYf6ockvQxS9gZ0rRIEqxl5iFx32i2SX9UoE9yN5CftNIPH4cIbUVWrLQsy/j HNWn37IMrPkFxcyWrS+adU5VJpbHTz/lAddwzvxbv57E4OD6ybPhH9JIWEy8YfIQ77aw TtIw== X-Gm-Message-State: AOAM533w5PPlIYTCJD1O7BoRWZ1m5c/D/S9Ut6NrXFJgJy1lgm2yfh46 pasDCcuiN6Y2iqjgdZy1FAZ4rRqvL6a9PFYa X-Google-Smtp-Source: ABdhPJzkp/U/d5sYngkhKT5gR9b28iksCKLrlkuLMVEq+EKwlyWAkRjsvGutKi6RcnVyXVxjoOUHVw== X-Received: by 2002:adf:ec4f:: with SMTP id w15mr23384230wrn.122.1620542808483; Sat, 08 May 2021 23:46:48 -0700 (PDT) Received: from ?IPv6:2a01:cb0c:20:e900:d434:b5fa:81d:ef4d? (2a01cb0c0020e900d434b5fa081def4d.ipv6.abo.wanadoo.fr. [2a01:cb0c:20:e900:d434:b5fa:81d:ef4d]) by smtp.gmail.com with ESMTPSA id z9sm14451089wmi.17.2021.05.08.23.46.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 08 May 2021 23:46:47 -0700 (PDT) To: Paul Foley , Codec Encoding for LossLess Archiving and Realtime transmission References: From: Steve Lhomme Message-ID: <2bcf60e1-293c-8b51-d3ce-6ff8fe491336@matroska.org> Date: Sun, 9 May 2021 08:46:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] Bug in Matroska spec? 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, 09 May 2021 06:46:56 -0000 Hi Paul, For discussions on the format, you should email the IETF mailing list [1] which is still very active for Matroska, FFv1, etc. You can also raise issues on GitHub [2] [3]. I'm posting this reply to the CELLAR mailing list as we will need to discuss your points further in the community. On 2021-05-02 14:56, Paul Foley wrote: > EBML RFC 8794, Section 5 states that > > The bits of the VINT_DATA component of the Element ID MUST NOT be all > "0" values > > however, Matroska defines the ChapterDisplay element with id 0x80, > which, unless I'm very confused, has all "0" values in the VINT_DATA > component(!) You are correct. That's a very good catch ! Not sure yet how we can get around this issue. ChapterDisplay is a widely used element. We should probably issue an errata on the IETF spec. Even the IANA registry table is bogus in that regard... > [I wrote code to read and write EBML/Matroska based on the RFC and > parsing ebml_matroska.xml from > {https://github.com/ietf-wg-cellar/matroska-specification}, but had to > ignore the "not zero" rule, and add stuff to the xml file because it's > incomplete. Specifically, EditionFlagHidden 0x45DB, ChapterFlagEnabled > 0x4598, ChapterTrack 0x8F, ChapterTrackUID 0x89 are missing, and These elements have been moved out as they are specific to control track which are unused right now. See [4] This is not ideal for code generators though. The 2 XML files should be concatenated before being processed. > TagDefault's element id was obviously changed from 0x44B4 to 0x4484 > (typo?) at some point; I have many files written before the change ... > should there be there with maxver set?] 0x44B4 is a bug in old versions of libavcodec. Or maybe that's not where it originates but it's referenced there: #define MATROSKA_ID_TAGDEFAULT 0x4484 #define MATROSKA_ID_TAGDEFAULT_BUG 0x44B4 Since we are putting in the RFC what is currently used, we should probably add it in the XML as you suggest. Probably with a maxver="0" making the element invalid in any case (it should have never been used). But as for other such elements, it will be listed in the RFC with some explanation on how to interpret it if it's found. [5] This value is not present in libmatroska so VLC and mkvmerge won't even read the element when found. > I also note that > {https://www.iana.org/assignments/ebml/ebml.xhtml#ebml-doctype} has no > registrations: surely "matroska" and "webm" ought to be registered. They are mentioned in RFC text [6] but not in the IANA registry. This issue was raised during the RFC editor phase but I can't find any answer to this. My understanding was that the "matroska" would be added to the registry once the RFC for Matroska is ready. And the "webm" one should be done by WebM people. I think the word RESERVED would mean something else. But maybe I'm wrong. Ultimately we will add the "matroska" one for sure. Thanks a lot for your very useful feedback! [1] https://www.ietf.org/mailman/listinfo/cellar [2] https://github.com/ietf-wg-cellar/ebml-specification/issues [3] https://github.com/ietf-wg-cellar/matroska-specification/issues [4] https://github.com/ietf-wg-cellar/matroska-specification/pull/461 [5] https://github.com/ietf-wg-cellar/matroska-specification/pull/487 [6] https://datatracker.ietf.org/doc/html/rfc8794#section-17.2 From nobody Sun May 9 00:24:49 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 98E323A1EB1 for ; Sun, 9 May 2021 00:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hGRXvj6n6m2 for ; Sun, 9 May 2021 00:24:43 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 CBA293A1EAE for ; Sun, 9 May 2021 00:24:42 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id l24-20020a7bc4580000b029014ac3b80020so9396792wmi.1 for ; Sun, 09 May 2021 00:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=54HG7K6KAOodbYUGKPDr7wwO3kOPoLhbVVWrQmqCuEE=; b=JQK/mY/eSkd5wWf8Rq4CJ7LtIDpRxoCytNYDwmp4KPZ4JC2WmTnd8qJVHYxQMSFv2x RNokxcvQHRjLehSkRm+hCS6bpM6cttzK1qJrR1bhYa5ovYFi3uJacUJWanpBwG6LTq5v sa84b44h4ZP5YZtyZD2wkDoc19L5ND26UU6LGdOTBoWavnY8YMjI/YyrJKepr0hHSu3z BLXetdI59wbAm1V212juEpsiDsQobeQHI3WM/kfej4aL3JgPbeX5m0eF9DF/gEzGaVf0 sbYrv47yOl9XXI5Lo9SePMLZoVRIdjs4AApTQ7fXCxt/KLo+FVKA62dMp8iwG8d1rbyB hkaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=54HG7K6KAOodbYUGKPDr7wwO3kOPoLhbVVWrQmqCuEE=; b=d4czqSETi9lDl0GySQWGQk2a5SBWFZ42RuzHJaRYVmL9TrF35X/G7Wsk0vwR/XpB8M RNGLkzz0lrL7+zOixxymNC78Rt5g5VAbgvAUGfr07TrObRoN4blu5ehGTg/oIO7V/K7c MOZRfiCO77DGfxFEdUd5lHa3kaXasaX94gjMP2K1OQXC3Bau7JLffJ5G3Z6QL7myqbLs jCZ53D8zAl3PJ2LrVqkgmeJ9FRy7fM3+nixjrQnzQuhJJe4WeS+BYkfDsH9JCSrnTIN6 wy2jtJ8AL9ABm3PRIFuNZ5HuXxZ45LO9qfdxvpF7dBlHjPrmkN/Na/V221x5FBMiJSH5 d3eQ== X-Gm-Message-State: AOAM530o+RwBA/1P4BykkL72ndj9bZlF9hEr26yOIl2wXwZ/cKfBoHu9 8pTpZhJpVgnlqELoOhNxMeOVmZb8fJ1S7jXP X-Google-Smtp-Source: ABdhPJwaC+BdmwF/1bTsjHIprmCnCvOcYnlFirC0r3Pv/jmhlsr8DnBgyzDyYlCXYeG7kmmkg4hTqA== X-Received: by 2002:a05:600c:2f17:: with SMTP id r23mr30429692wmn.28.1620545075890; Sun, 09 May 2021 00:24:35 -0700 (PDT) Received: from ?IPv6:2a01:cb0c:20:e900:d434:b5fa:81d:ef4d? (2a01cb0c0020e900d434b5fa081def4d.ipv6.abo.wanadoo.fr. [2a01:cb0c:20:e900:d434:b5fa:81d:ef4d]) by smtp.gmail.com with ESMTPSA id z66sm23375143wmc.4.2021.05.09.00.24.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 09 May 2021 00:24:35 -0700 (PDT) From: Steve Lhomme To: Paul Foley , Codec Encoding for LossLess Archiving and Realtime transmission References: <2bcf60e1-293c-8b51-d3ce-6ff8fe491336@matroska.org> Message-ID: <05e0d9ab-8808-48b8-e13c-4bef90decce1@matroska.org> Date: Sun, 9 May 2021 09:24:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <2bcf60e1-293c-8b51-d3ce-6ff8fe491336@matroska.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] Bug in Matroska spec? 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, 09 May 2021 07:24:48 -0000 On 2021-05-09 8:46, Steve Lhomme wrote: > Hi Paul, >=20 > For discussions on the format, you should email the IETF mailing list=20 > [1] which is still very active for Matroska, FFv1, etc. > You can also raise issues on GitHub [2] [3]. >=20 > I'm posting this reply to the CELLAR mailing list as we will need to=20 > discuss your points further in the community. >=20 > On 2021-05-02 14:56, Paul Foley wrote: >> EBML RFC 8794, Section 5 states that >> >> =C2=A0=C2=A0=C2=A0 The bits of the VINT_DATA component of the Element = ID MUST NOT be all >> =C2=A0=C2=A0=C2=A0 "0" values >> >> however, Matroska defines the ChapterDisplay element with id 0x80, >> which, unless I'm very confused, has all "0" values in the VINT_DATA >> component(!) >=20 > You are correct. That's a very good catch ! > Not sure yet how we can get around this issue. ChapterDisplay is a=20 > widely used element. We should probably issue an errata on the IETF=20 > spec. Even the IANA registry table is bogus in that regard... Issue https://github.com/ietf-wg-cellar/ebml-specification/issues/407 >> [I wrote code to read and write EBML/Matroska based on the RFC and >> parsing ebml_matroska.xml from >> {https://github.com/ietf-wg-cellar/matroska-specification}, but had to= >> ignore the "not zero" rule, and add stuff to the xml file because it's= >> incomplete. Specifically, EditionFlagHidden 0x45DB, ChapterFlagEnabled= >> 0x4598, ChapterTrack 0x8F, ChapterTrackUID 0x89 are missing, and >=20 > These elements have been moved out as they are specific to control trac= k=20 > which are unused right now. See [4] > This is not ideal for code generators though. The 2 XML files should be= =20 > concatenated before being processed. Issue https://github.com/ietf-wg-cellar/matroska-specification/issues/509= >> TagDefault's element id was obviously changed from 0x44B4 to 0x4484 >> (typo?) at some point; I have many files written before the change ...= >> should there be there with maxver set?] >=20 > 0x44B4 is a bug in old versions of libavcodec. Or maybe that's not wher= e=20 > it originates but it's referenced there: > #define MATROSKA_ID_TAGDEFAULT=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 0x4484 > #define MATROSKA_ID_TAGDEFAULT_BUG=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0x44B4= >=20 > Since we are putting in the RFC what is currently used, we should=20 > probably add it in the XML as you suggest. Probably with a maxver=3D"0"= =20 > making the element invalid in any case (it should have never been used)= =2E=20 > But as for other such elements, it will be listed in the RFC with some = > explanation on how to interpret it if it's found. [5] Issue https://github.com/ietf-wg-cellar/matroska-specification/issues/508= > This value is not present in libmatroska so VLC and mkvmerge won't even= =20 > read the element when found. >=20 >> I also note that >> {https://www.iana.org/assignments/ebml/ebml.xhtml#ebml-doctype} has no= >> registrations: surely "matroska" and "webm" ought to be registered. >=20 > They are mentioned in RFC text [6] but not in the IANA registry. This=20 > issue was raised during the RFC editor phase but I can't find any answe= r=20 > to this. My understanding was that the "matroska" would be added to the= =20 > registry once the RFC for Matroska is ready. And the "webm" one should = > be done by WebM people. > I think the word RESERVED would mean something else. But maybe I'm=20 > wrong. Ultimately we will add the "matroska" one for sure. >=20 > Thanks a lot for your very useful feedback! >=20 > [1] https://www.ietf.org/mailman/listinfo/cellar > [2] https://github.com/ietf-wg-cellar/ebml-specification/issues > [3] https://github.com/ietf-wg-cellar/matroska-specification/issues > [4] https://github.com/ietf-wg-cellar/matroska-specification/pull/461 > [5] https://github.com/ietf-wg-cellar/matroska-specification/pull/487 > [6] https://datatracker.ietf.org/doc/html/rfc8794#section-17.2 From nobody Sun May 9 01:36:12 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 24DB03A2181 for ; Sun, 9 May 2021 01:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.897 X-Spam-Level: X-Spam-Status: No, score=-0.897 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=chxnhQkg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WCBvVyTM 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 k0pbM1b60rXL for ; Sun, 9 May 2021 01:36:04 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EFC93A217E for ; Sun, 9 May 2021 01:36:04 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 4F03F18FC for ; Sun, 9 May 2021 03:40:13 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Sun, 09 May 2021 03:40:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm2; bh=X0FNR4Rox08 4BLPytfDwToaJ0CZwkvEDKulmwYgFfg4=; b=chxnhQkg4ZEidfHDayU5fCJQwNR yoSD738Rhb7thRGns/0F+ys1D1xpeAm7W3klE95dfiaJ9O8Bk0o0QPHFM3hjLrJ5 irTAGgIXOF8EK4l6o+wq0VOUOCV4zP7FPiGvzTVWPkn7rwKKU48UAVa/BDbWGBk0 fhb8SGAEuv0YQ0ox2c3ebYXSbE414ydVxeWCl883yktUagVkW/PgKIho0KFN5Gpz /Q+G7TZ1wwqkV6RVoO8pGV/AhSMTA8y5+RHVaYcly4hEGWcU75KJCTd629dabmxq /HpjgdTE3XIS3sOfeAjAJRD8Mcks1L5IKzIHAFpcZYgh37nkl27qwgJxyxw== 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= fm2; bh=X0FNR4Rox084BLPytfDwToaJ0CZwkvEDKulmwYgFfg4=; b=WCBvVyTM 0oXuQrbVNX0h9APNOXyU7fuqyEMBsWujXBkVHHrE1HR1n13Rs3H4vHOVYe6E269x P5yU2RGM54SfX8bwE3ssFAvq/9AR+KajpMWdYjU3Ym1B6cjDcDS9Wjuvvp/kLmcM jwxceuZflTW6/h5Eluu9p+q3HuC8lXAE8RIIBgUnEsZremH6fZTrs+TB+dRT4CMW JDXZeIdP6r+wK4mz25PTO9GHoHGOaSB6KgfxOVz5WPBbOxf1380KXdAeD1KLdXwG 8/Ci3rLGaH1PzbTI+HfO0BIHb2QKQzD365q2uvbw0egrKEoSITymTlAHBgI9DpRR KoghyJM9mOwlRg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeghedguddvgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecupfhoucgurghtvgcufhhivghlugculdegledmne cujfgurheptggghffvufesrgdttdertddtjeenucfhrhhomheptfgvphhoshhithhorhih ucettghtihhvihhthicuufhumhhmrghrhicuuehothcuoeguohgpnhhothgprhgvphhlhi esmhhnohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeekfedvudetjedvfeekheeiveeu gfefhfetteevgeffkefffeetffdvleehudeiteenucffohhmrghinhepghhithhhuhgsrd gtohhmnecukfhppedvtddrudekhedrkeekrdduiedunecuvehluhhsthgvrhfuihiivgep udenucfrrghrrghmpehmrghilhhfrhhomhepughopghnohhtpghrvghplhihsehmnhhoth drnhgvth X-ME-Proxy: Received: from fv-az154-953.kzav01uq0i3u1f1hch3ggm0mbb.bx.internal.cloudapp.net (unknown [20.185.88.161]) by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 9 May 2021 03:40:12 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============4687598746054216668==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20210509083604.6EFC93A217E@ietfa.amsl.com> Date: Sun, 9 May 2021 01:36:04 -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, 09 May 2021 08:36:10 -0000 --===============4687598746054216668== 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 (+1/-0/=F0=9F=92=AC0) 1 issues created: - EBML ID 0x80 is marked invalid/reserved but it's used in Matroska (by r= obUx4) https://github.com/ietf-wg-cellar/ebml-specification/issues/407 [bug] [= errata-rfc8794]=20 * ietf-wg-cellar/matroska-specification (+2/-0/=F0=9F=92=AC5) 2 issues created: - add the control track elements in main Schema file (by robUx4) https://github.com/ietf-wg-cellar/matroska-specification/issues/509 [XM= L Schema] [build system]=20 - Add the bogus TagDefault value in the RFC (by robUx4) https://github.com/ietf-wg-cellar/matroska-specification/issues/508 [XM= L Schema] [format addition] [spec_main]=20 2 issues received 5 new comments: - #500 Add an EBML constraint about 0-length elements (2 by hubblec4, rob= Ux4) https://github.com/ietf-wg-cellar/matroska-specification/issues/500 [cl= arifications] [format addition] [spec_main]=20 - #478 fix ChapterTimeEnd section (3 by SpencerDawkins, robUx4) https://github.com/ietf-wg-cellar/matroska-specification/issues/478 [bu= g] [spec_main]=20 Pull requests ------------- * ietf-wg-cellar/ebml-specification (+1/-0/=F0=9F=92=AC0) 1 pull requests submitted: - allow 0x80 EBML ID since it's used in Matroska (by robUx4) https://github.com/ietf-wg-cellar/ebml-specification/pull/408 [bug] [er= rata-rfc8794]=20 * ietf-wg-cellar/matroska-specification (+4/-1/=F0=9F=92=AC1) 4 pull requests submitted: - tag TrackUID as preserved during stream copy using an extension (by rob= Ux4) https://github.com/ietf-wg-cellar/matroska-specification/pull/507 [XML = Schema] [build system] [clarifications] [spec_main]=20 - remove ebml_schema2clean.xsl which is unused (by robUx4) https://github.com/ietf-wg-cellar/matroska-specification/pull/506 [buil= d system]=20 - remove default values from chapter examples (by robUx4) https://github.com/ietf-wg-cellar/matroska-specification/pull/505 [clar= ifications] [spec_main]=20 - Clean chapterend section (by robUx4) https://github.com/ietf-wg-cellar/matroska-specification/pull/504 [bug]= [spec_main]=20 1 pull requests received 1 new comments: - #473 make ChapterTimeEnd mandatory for ordered chapters (1 by robUx4) https://github.com/ietf-wg-cellar/matroska-specification/pull/473 [clar= ifications] [spec_main]=20 1 pull requests merged: - remove ebml_schema2clean.xsl which is unused https://github.com/ietf-wg-cellar/matroska-specification/pull/506 [buil= d system]=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 --===============4687598746054216668== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

Sunday May 09, 2021

Events without label "editorial"

Issues

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

1 issues created:

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

2 issues created:

2 issues received 5 new comments:

Pull requests

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

1 pull requests submitted:

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

4 pull requests submitted:

1 pull requests received 1 new comments:

1 pull requests merged:

Repositories tracked by this digest:

--===============4687598746054216668==-- From nobody Mon May 10 07:16: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 366CA3A1E4C for ; Mon, 10 May 2021 07:16:26 -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 SRi6UYVCcO7s for ; Mon, 10 May 2021 07:16:21 -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 BEE543A1E4E for ; Mon, 10 May 2021 07:16:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 2832318575 for ; Mon, 10 May 2021 10:25:13 -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 MTzxHNRY6ksH for ; Mon, 10 May 2021 10:25:12 -0400 (EDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 00161180B1 for ; Mon, 10 May 2021 10:25:11 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5C7757B7 for ; Mon, 10 May 2021 10:16:18 -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/ebml-specification] EBML ID 0x80 is marked invalid/reserved but it's used in Matroska (#407) 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, 10 May 2021 14:16:26 -0000 --=-=-= Content-Type: text/plain Steve Lhomme wrote: > As pointed out by [Paul Foley](https://mailarchive.ietf.org/arch/msg/cellar/z_INjU-Vc9FOTDZs9AhdRRjrIig/), the 0x80 is EBML ID is said to be invalid in the [RFC text](https://datatracker.ietf.org/doc/html/rfc8794#section-5): >> The bits of the VINT_DATA component of the Element ID MUST NOT be all >> "0" values or all "1" values. > But in Matroska we use 0x80 for `ChapterDisplay`. > I think the all 0 rules should be removed. In particular because 0x80 > is the value that should be used when all VINT_DATA bits are 0, per > this rule: >> The VINT_DATA component of the Element ID MUST be encoded at the shortest valid length. > Changing this text means also editing the IANA registry which lists all > the variants of 0 bits as reserved. I'm not sure how to deal with this. It may be that we can put these IANA instructions into the Matroska document. Obviously, they would ideally go into an EBML-bis document, and that would be something we'd do if we were revising it now. IANA instructions are a bit weird in that they are in essence, edge-triggered, and once processed in a document, they change. ( https://en.wikipedia.org/wiki/Interrupt ) -- ] 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+93Q3WUFAmCZQDEACgkQgItw+93Q 3WVMlwgAhtwgC2Y8FhEb6ZULyjbcTi3iE4KbJsOXEs6p1rg5HD9uN/2DqRaoiZUQ NLTpWKhR9nzvMza5neuc+xLfOTzK9E0DcPHPutLLa0/1UYJBXPq4azsQmbMOU8Pt GVg/XkpBjYMEMEJAb5o+1Z04xEr3Gt+BKd8Gu+GlUJXxeK7S9prfqZa+JDRJj4vU bMSeL8Hdj5YjVVLbhnbUM/ECabe9vd/AR8NbZCaNjE4WEE05ERHPq8xS9uCv9KiD AnYNKHKuwTDIA6CZkZ9fKZWKG7hNaS3/4f5v2DjBrn+ZAh7IERk50V5Wl8KJAp00 afM8AZyzoMM0TZccWih47oI3a7uD9Q== =22YF -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon May 10 15:44:18 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 55DE13A2DBE for ; Mon, 10 May 2021 15:44:17 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 X4WUlhbl_QN9 for ; Mon, 10 May 2021 15:44:12 -0700 (PDT) Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (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 689F73A2DBD for ; Mon, 10 May 2021 15:44:12 -0700 (PDT) Received: by mail-yb1-xb31.google.com with SMTP id r8so23808680ybb.9 for ; Mon, 10 May 2021 15:44:12 -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=SYnmW+VFm1rgXSV6eOj2Hg9tRAMHMhlcAF/bIhlV+Ik=; b=X9rDe3DKAURlGvgy7ycCQRwrqRUVHJE9csXE8DM20Ug7o6hbi9+AaGz/d5rKMEZ6pI Ab++A035AxJxpkAD48mgJC2K2YamOg7OEjdN1xQfOwZN+Lw1wgc6EU192bRMGcItsu7B wsNvjV3r9LEYQLdAcytnie5CprQ5HsgnK8wTNMiZAGjrYK5Dy67Oz+U4lYtRpIecsroP ej+1H6j5xKJVKCc66Bu/TOEifvRoJ4atVaMUb1agtSZkPzOGXmyvGmi/PZGraOhp3ybA fKIaIog7v3h5SAGZ6VRzI4B4zAeAXSOw4ExxpALDYtVpENWEwZCreEPcDCXSvQwRmM4p PeKA== 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=SYnmW+VFm1rgXSV6eOj2Hg9tRAMHMhlcAF/bIhlV+Ik=; b=juXx1Fpe/Di9t0NrPCuDldDK2C/eKSWrW4e4uk3ew1k/ewLYCJFLcfl/N+z/mYoxwd i93g1kpm7eUA5pY61n8SnHayPkADaWgFG9G090z3iWT/S04Vz+k4/hEuhmEnbGCOf2Zt fwVd3ySEtWlgAYZ3B5GbmBjIeffRRw2GYdBWB87hiKvcASDKAkdo3bNJjIcgf2EUMzol gyp+8ZqPVrCpMvLjHulVHG6IgUHAPrmpPgwOZ82jeSvufEPD4qDojTXToxtlOeA6NMRb 7pw3VIewhulCu0gquU+KV8On8VCcopR9lrnEpnuyOVVKfRk9dIq8TXrQ9yi90/k61Y/7 R1Dw== X-Gm-Message-State: AOAM530fHEXghnNz5WcqMjciA7wyilWBIBqB143AU+uatp2vSH3N+36f JuCEyfPH4BueKsUWIkW+z0MUUxaavzlL0R/o6fEKVDXq/88= X-Google-Smtp-Source: ABdhPJw9aND4r9fRUAzcCqiePbzBqN4Vo+i4T/TP/G2HqIi3lF9trPDERYiurAheueIlCjMWRRvJHRq4b+ASWfpLmQ4= X-Received: by 2002:a25:1883:: with SMTP id 125mr34884921yby.465.1620686651077; Mon, 10 May 2021 15:44:11 -0700 (PDT) MIME-Version: 1.0 References: <21441.1620656178@localhost> In-Reply-To: <21441.1620656178@localhost> From: Spencer Dawkins at IETF Date: Mon, 10 May 2021 17:43:44 -0500 Message-ID: To: Michael Richardson Cc: Codec Encoding for LossLess Archiving and Realtime transmission , Murray Kucherawy Content-Type: multipart/alternative; boundary="00000000000021377f05c2018468" Archived-At: Subject: Re: [Cellar] [ietf-wg-cellar/ebml-specification] EBML ID 0x80 is marked invalid/reserved but it's used in Matroska (#407) 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, 10 May 2021 22:44:17 -0000 --00000000000021377f05c2018468 Content-Type: text/plain; charset="UTF-8" Adding our Loyal AD ... because I could be wrong, and he would know ... On Mon, May 10, 2021 at 9:16 AM Michael Richardson wrote: > > Steve Lhomme wrote: > > As pointed out by [Paul Foley]( > https://mailarchive.ietf.org/arch/msg/cellar/z_INjU-Vc9FOTDZs9AhdRRjrIig/), > the 0x80 is EBML ID is said to be invalid in the [RFC text]( > https://datatracker.ietf.org/doc/html/rfc8794#section-5): > > >> The bits of the VINT_DATA component of the Element ID MUST NOT be > all > >> "0" values or all "1" values. > > > But in Matroska we use 0x80 for `ChapterDisplay`. > > > I think the all 0 rules should be removed. In particular because 0x80 > > is the value that should be used when all VINT_DATA bits are 0, per > > this rule: > > >> The VINT_DATA component of the Element ID MUST be encoded at the > shortest valid length. > > > Changing this text means also editing the IANA registry which lists > all > > the variants of 0 bits as reserved. > > I'm not sure how to deal with this. > It may be that we can put these IANA instructions into the Matroska > document. > Obviously, they would ideally go into an EBML-bis document, and that would > be > something we'd do if we were revising it now. > That would be perfect (if we were doing an EBML-bis document, but I predict that the answer is - the EBML document is a Proposed Standard, so any Proposed Standard that (reasonably) updates the instructions to IANA should be OK. This update is relevant for Matroska, which is also targeting publication as a Proposed Standard, so that's a fine place to put the updated IANA instructions. The EBML RFC IANA instructions would be outdated, but the point of IANA registries is that the IANA registries are up to date, and you don't have to chase (in some cases) a few dozen RFCs to find all the rules. Murray, is that about right? Best, SPencer > IANA instructions are a bit weird in that they are in essence, > edge-triggered, and once processed in a document, they change. > > ( https://en.wikipedia.org/wiki/Interrupt ) > > -- > ] 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 [ > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --00000000000021377f05c2018468 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Adding our Loyal AD ... because I could be wrong, and= he would know ...=C2=A0

On Mon, May 10, 2021 at 9:16 AM Michael Richardson = <mcr@sandelman.ca> wrote:
=

Steve Lhomme <notifications@github.com> wrote:
=C2=A0 =C2=A0 > As pointed out by [Paul Foley](https://mailarchive.ietf.org/arch/msg/cellar/z_INjU-= Vc9FOTDZs9AhdRRjrIig/), the 0x80 is EBML ID is said to be invalid in th= e [RFC text](https://datatracker.ietf.org/doc= /html/rfc8794#section-5):

=C2=A0 =C2=A0 >> The bits of the VINT_DATA component of the Element I= D MUST NOT be all
=C2=A0 =C2=A0 >> "0" values or all "1" values.
=C2=A0 =C2=A0 > But in Matroska we use 0x80 for `ChapterDisplay`.

=C2=A0 =C2=A0 > I think the all 0 rules should be removed. In particular= because 0x80
=C2=A0 =C2=A0 > is the value that should be used when all VINT_DATA bits= are 0, per
=C2=A0 =C2=A0 > this rule:

=C2=A0 =C2=A0 >> The VINT_DATA component of the Element ID MUST be en= coded at the shortest valid length.

=C2=A0 =C2=A0 > Changing this text means also editing the IANA registry = which lists all
=C2=A0 =C2=A0 > the variants of 0 bits as reserved.

I'm not sure how to deal with this.
It may be that we can put these IANA instructions into the Matroska documen= t.
Obviously, they would ideally go into an EBML-bis document, and that would = be
something we'd do if we were revising it now.

=
That would be perfect (if we were doing an EBML-bis document, bu= t I predict that the answer is - the EBML document is a Proposed Standard, = so any Proposed Standard that (reasonably) updates the instructions to IANA= should be OK. This update is relevant for Matroska, which is also targetin= g publication as a Proposed Standard, so that's a fine place to put the= updated IANA instructions.=C2=A0

The EBML RFC IAN= A instructions would be outdated, but the point of IANA registries is that = the IANA registries are up to date, and you don't have to chase (in som= e cases) a few dozen RFCs to find all the rules.=C2=A0

=
Murray, is that about right?

Best,
=
SPencer
=C2=A0
IANA instructions are a bit weird in that they are in e= ssence,
edge-triggered, and once processed in a document, they change.

( https://en.wikipedia.org/wiki/Interrupt )

--
]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Never tell me the o= dds!=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| ipv6 me= sh networks [
]=C2=A0 =C2=A0Michael Richardson, Sandelman Software Works=C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 IoT architect=C2=A0 =C2=A0[
]=C2=A0 =C2=A0 =C2=A0= mcr@sandelman.ca=C2=A0 http://www.sandelman.ca/=C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0ruby on rails=C2=A0 =C2=A0 [

_______________________________________________
Cellar mailing list
Cellar@ietf.org https://www.ietf.org/mailman/listinfo/cellar
--00000000000021377f05c2018468-- From nobody Sun May 16 00:06: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 6C1B93A2FDA for ; Sun, 16 May 2021 00:06:02 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wkrMs1aSSj6 for ; Sun, 16 May 2021 00:05:57 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 80E713A2FD7 for ; Sun, 16 May 2021 00:05:57 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id v12so3105882wrq.6 for ; Sun, 16 May 2021 00:05:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=j3srnGbEEu457V+ss9zEtvM68s4SISEwoDLd3YfI8zk=; b=A7kFCV1Me+U4ATrTJPRMRtw1bd9HxKuhx7V1LCaqkX0NLL5COeaW5dtIydY4xk22+6 rMZ6JMixFpQGqIOpU4NEO3HM2qceKSXOVRh6sswOhewiHZvn4240vjNfBFDDTvDSdk7T sL4uivWVKOznblipioFdNocO6ZBrNPIDJNSl+9Nm8U/Q9+n1iZmn7rbqy56zbBK5Zm/s ZBBuZiP2H0vAUOKLyamitwRHzVFSW/8JMeQ5jbEXYjQA9cFKPgrpXFPsqCckjVO7indB 8lEIBdmFy7qNwodIkeM8SRxs2QQy9DzSSdW4zaaHSScT6ub1PH+AE1kWK86Q617CbBoj dptA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=j3srnGbEEu457V+ss9zEtvM68s4SISEwoDLd3YfI8zk=; b=e/bragst/v92pChx7agnRMZNtcPhFmDd6oEEDpE9nG2FszSMDdir+yLWDCtLfConf4 LYdKT3RBJdTzDlSfwHQSQBGSUK6BOCLvhUxppZjzpjv3Qsr/NFmIdYkSEp8TCpat6lfW pSN33w2Hv8CKcMHUkMMdj7cQc5HRZtQO1CDegY2nTxYhc0avm7GQOIHg0tfyiCdk9yTI e8NhXIS/ekDJxDRC5oXB8eXBIra4NLSB8ZOi4g0eBd6qWZmGV5gChjzPnmJcLAwgeJXG TyxgRj7/2LeFycuvPpiH0h73ABnVt5GPA98IErx3MhtmhGOMxJ2l1ReWQQ+1DBw7bIvR YIqg== X-Gm-Message-State: AOAM532nWt4UJil9N9O10O2sQy606+h8IYYAHc8Jdaimpu7AvK8ctxqy wS3ZHTRn0/BSRGDkIZp7fmBozm4NOZJFNA6A X-Google-Smtp-Source: ABdhPJwnV4vO+3UCIqKIcPXvcaMqbIEqLWVm3/GFJqNl3Ufai8NZCoa9qIs4uhJ7Y2YET+4Zs89lzg== X-Received: by 2002:a5d:6c6f:: with SMTP id r15mr13789014wrz.79.1621148754514; Sun, 16 May 2021 00:05:54 -0700 (PDT) Received: from ?IPv6:2a01:cb0c:20:e900:35b8:fd8e:d681:39f3? (2a01cb0c0020e90035b8fd8ed68139f3.ipv6.abo.wanadoo.fr. [2a01:cb0c:20:e900:35b8:fd8e:d681:39f3]) by smtp.gmail.com with ESMTPSA id g206sm440997wme.16.2021.05.16.00.05.53 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 16 May 2021 00:05:53 -0700 (PDT) To: Codec Encoding for LossLess Archiving and Realtime transmission From: Steve Lhomme Message-ID: <93ec0e00-ee55-006a-fd22-73c39a752a76@matroska.org> Date: Sun, 16 May 2021 09:05:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Cellar] Last Call for #495 content reordering of section in the Matroska spec 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, 16 May 2021 07:06:03 -0000 Hi, Since my previous post may have been lost in the replies, I'm posting a new plain one on the mailing list to make sure everyone is aware. I reordered a few sections of the Matroska spec so the information follow a more understandable flow, ie from the more general to the more detailed. I did not edit any content, just moved some around. As the changes look big and the result is not very readable as a PR, I uploaded the result the TXT and XML files before and after the change so you can compare at https://github.com/robUx4/matroska-specification/pull/1/files If you're OK with this, you can approve at https://github.com/ietf-wg-cellar/matroska-specification/pull/495 Otherwise just let me know. This is blocking other PRs as the modified text has moved. I prefer to do the move first as doing it later will still lead to the same problem and delay anything more important down the line. From nobody Sun May 16 06:42: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 DEB5C3A07CE for ; Sun, 16 May 2021 06:42:21 -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 BqxlzIqMJjGb for ; Sun, 16 May 2021 06:42:17 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C67033A07C3 for ; Sun, 16 May 2021 06:42:16 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id n2so3780911wrm.0 for ; Sun, 16 May 2021 06:42:16 -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=5x4PkdH/yuJH0b6mJoNY7zz+v+yIOYthW7E7IbxGoXE=; b=ABCn87BaekaakJpEez+zKHM+yFSLihqxmkF+TBc0cs292XbtnYU5B2I8MuM3cPYqzx 6B2xkIuAPmNvIGcfcuaZvNeAUgC3wSAQPTDmiNd2bfFNz8lVZHp8YJ/BfiEwC91sMaIv 24VzQG5Q3J73OOLrcfin33WmPQQBylHjQBhIIh2Skh1eI9S9mGN4NQZ1E8yn5e/R4oDo mvivSoJunF9J1b2NDWdTkcukXgwluWX4MVEDf9XmIZ+GTIHXxVzhQuvr5ypONNbFVMSk CpCF9U8eBbDvYtQLe65CYKIb9chRR1YQMp6jbwORM1QJIlJFzmh3NjevcO+1HjErv53D jCyQ== 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=5x4PkdH/yuJH0b6mJoNY7zz+v+yIOYthW7E7IbxGoXE=; b=P6JAv7U/d06Vjewub/juC/BHPPaCYXaqITThnkh7hjZZkzCju0JZP8PVm+oC5GsXAD zkrpYWzgUywhmjTLWgXTPXsWayqPbFuRNze1Z4XOK0ZpjA6pPCzQe5gXJGQlTlmMiQRk YJitzyIx/KNJmyxo/Df0YDz1SJTYDQ5FW1PH4KGRRaUxO/iGRVI937BiWAUbUOQbD2f0 YUeVx+M56Tk6scrnonl+GFCgPpU9Bp6MR3XXP1cK01VRK4mXOhsmr/3jemZPsz5o7XLS ezohQfRBTUAITZ+v5wanUvx5Ri9NfkRMgKD3spXYJ3Y6OxhGTgHD4sZFCRQAMQV8zvLg /nTQ== X-Gm-Message-State: AOAM530XS0e5m0SQ7eKlbj/MovLTuYtF2To62/bIJZJ3khJJZc9yVa2C HsaCor3eKG756e6hHlnZlWA82unpg8D6t+S+ X-Google-Smtp-Source: ABdhPJyiMA2NmLf9e83+BmbVqF9k4PGTCWxgDpXiww9khKzP2Ah26aewy461e5q931EtCw3Ukyp6hw== X-Received: by 2002:a05:6000:1ac7:: with SMTP id i7mr70184431wry.380.1621172534633; Sun, 16 May 2021 06:42:14 -0700 (PDT) Received: from ?IPv6:2a01:cb0c:20:e900:806c:e5a2:2564:1160? (2a01cb0c0020e900806ce5a225641160.ipv6.abo.wanadoo.fr. [2a01:cb0c:20:e900:806c:e5a2:2564:1160]) by smtp.gmail.com with ESMTPSA id f3sm12936304wrp.7.2021.05.16.06.42.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 16 May 2021 06:42:13 -0700 (PDT) To: cellar@ietf.org References: <21441.1620656178@localhost> From: Steve Lhomme Message-ID: <206103c0-9265-127b-6a5b-48da92fe3c9d@matroska.org> Date: Sun, 16 May 2021 15:42:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] [ietf-wg-cellar/ebml-specification] EBML ID 0x80 is marked invalid/reserved but it's used in Matroska (#407) 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, 16 May 2021 13:42:22 -0000 On 2021-05-11 0:43, Spencer Dawkins at IETF wrote: > Adding our Loyal AD ... because I could be wrong, and he would know ...= >=20 > On Mon, May 10, 2021 at 9:16 AM Michael Richardson > wrote: >=20 >=20 > Steve Lhomme > wrote: > =C2=A0 =C2=A0 > As pointed out by [Paul > Foley](https://mailarchive.ietf.org/arch/msg/cellar/z_INjU-Vc9FOTDZ= s9AhdRRjrIig/ > ), > the 0x80 is EBML ID is said to be invalid in the [RFC > text](https://datatracker.ietf.org/doc/html/rfc8794#section-5 > ): >=20 > =C2=A0 =C2=A0 >> The bits of the VINT_DATA component of the Elemen= t ID MUST > NOT be all > =C2=A0 =C2=A0 >> "0" values or all "1" values. >=20 > =C2=A0 =C2=A0 > But in Matroska we use 0x80 for `ChapterDisplay`. >=20 > =C2=A0 =C2=A0 > I think the all 0 rules should be removed. In part= icular > because 0x80 > =C2=A0 =C2=A0 > is the value that should be used when all VINT_DAT= A bits are > 0, per > =C2=A0 =C2=A0 > this rule: >=20 > =C2=A0 =C2=A0 >> The VINT_DATA component of the Element ID MUST be= encoded at > the shortest valid length. >=20 > =C2=A0 =C2=A0 > Changing this text means also editing the IANA reg= istry which > lists all > =C2=A0 =C2=A0 > the variants of 0 bits as reserved. >=20 > I'm not sure how to deal with this. > It may be that we can put these IANA instructions into the Matroska= > document. > Obviously, they would ideally go into an EBML-bis document, and tha= t > would be > something we'd do if we were revising it now. >=20 >=20 > That would be perfect (if we were doing an EBML-bis document, but I=20 What would be an EBML-bis document ? A revision to the RFC comparable to = the errata or something that would result in a new RFC ? > predict that the answer is - the EBML document is a Proposed Standard, = > so any Proposed Standard that (reasonably) updates the instructions to = > IANA should be OK. This update is relevant for Matroska, which is also = > targeting publication as a Proposed Standard, so that's a fine place to= =20 > put the updated IANA instructions. >=20 > The EBML RFC IANA instructions would be outdated, but the point of IANA= =20 > registries is that the IANA registries are up to date, and you don't=20 > have to chase (in some cases) a few dozen RFCs to find all the rules. >=20 > Murray, is that about right? >=20 > Best, >=20 > SPencer >=20 > IANA instructions are a bit weird in that they are in essence, > edge-triggered, and once processed in a document, they change. >=20 > ( https://en.wikipedia.org/wiki/Interrupt > ) >=20 > -- > ]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Never tell = me the odds!=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= | ipv6 mesh > networks [ > ]=C2=A0 =C2=A0Michael Richardson, Sandelman Software Works=C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 IoT > architect=C2=A0 =C2=A0[ > ] mcr@sandelman.ca > http://www.sandelman.ca/ =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0ruby > on rails=C2=A0 =C2=A0 [ >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > >=20 >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar >=20 From nobody Sun May 16 11:17:59 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 0559B3A1078 for ; Sun, 16 May 2021 11:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_BLOCKED=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 qUb8pUq8rVRh for ; Sun, 16 May 2021 11:17:52 -0700 (PDT) Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (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 A18A03A1075 for ; Sun, 16 May 2021 11:17:52 -0700 (PDT) Received: by mail-yb1-xb2a.google.com with SMTP id 82so5621329yby.7 for ; Sun, 16 May 2021 11:17:52 -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=kFPjFigM71fHiZIQPmP9/TkE5fXvTDrZkUWgjQ02nlc=; b=ACF6IkikD+uw5SB/syA4Vo9QiNYJ532GytxNThdZb0LOUADBVjpbCGpspijOSP8RYQ 0W3RWaLh0Luw11MDuWxEJM1kRAxW36G2zI0zUdaPhI5/OQN10igIkDDivGWT2RrnvsRN IKr4FyVMV+Ks6aX7gGAFwPHr0qXcVPAhR9fcjt801zr7DI7uQ8nH2oalyd3wGsEbndRY gPZeS+G9/jYfvB6SnJu7VBrVL5MESHQ52RHrdFUlUQC4jg/0Y+qNW7a1tmnuzQOzbt3k Tan7vVLOXlytm1BzPgvfkhHq5mVfeC7L0e72xCnQ8oYEzJA/qU9l/7vMQ1N+wgXbC9O8 5aeg== 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=kFPjFigM71fHiZIQPmP9/TkE5fXvTDrZkUWgjQ02nlc=; b=nolkScowtQqm2xBLy5X+wSm7bteWpRcNdu/vtwV3czWiV2R1GECCBHWhasNEUm2N7a j1JT8sHW+9w5T1D4C0JAxr3JpPnKmKUrZ6igcmQj+9BZApXr50v3v/GkGMPgoCtUiU1i kZUUgIfvJBhUIpPpg+NH8c5uXMRW98VsdRvGYxFIsg4O8NQJXI7nP8pR/1C47/6NC7+U p051pDT+0skhD6mOedGXoSIUEi3V6XHH4XV9rmCU2TO+/OL6zj3hqjXJDJd1PD+puQlf EqIXhN+Ey3svp76pVRf4/yLNs6ULs/p27/URWELix0LYnKPqKPM6izBd8199RGaO6gyL uDGQ== X-Gm-Message-State: AOAM533EMBcekhrbYKZxl6XROrqtvafxQ9ds5B3RrFSZ+HpnsJlh9S/e pxbVqegb484R/JRqE23EtuffR/9z/yG1y2PNrQJ8kt126Px9dg== X-Google-Smtp-Source: ABdhPJzWVX0h/5tojGAPwh2PSQrX1IQ+LMLACAqCWfFbdJy/uAarwJb0+0/SxFSEEE3vWnLCU1lTp2h8CcKHcIqsLN8= X-Received: by 2002:a25:dfc5:: with SMTP id w188mr2484836ybg.465.1621189071240; Sun, 16 May 2021 11:17:51 -0700 (PDT) MIME-Version: 1.0 References: <93ec0e00-ee55-006a-fd22-73c39a752a76@matroska.org> In-Reply-To: <93ec0e00-ee55-006a-fd22-73c39a752a76@matroska.org> From: Spencer Dawkins at IETF Date: Sun, 16 May 2021 13:17:24 -0500 Message-ID: To: Steve Lhomme Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="000000000000b4814705c2767e64" Archived-At: Subject: Re: [Cellar] Last Call for #495 content reordering of section in the Matroska spec 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, 16 May 2021 18:17:57 -0000 --000000000000b4814705c2767e64 Content-Type: text/plain; charset="UTF-8" Hi, Steve, On Sun, May 16, 2021 at 2:06 AM Steve Lhomme wrote: > Hi, > > Since my previous post may have been lost in the replies, I'm posting a > new plain one on the mailing list to make sure everyone is aware. > Thank you for taking this question to the mailing list. I see that Michael has already approved the PR in https://github.com/robUx4/matroska-specification/branches, but I did have one quick question, after a quick look through the table of contents. 9.1.4. Tracks Element . . . . . . . . . . . . . . . . . . . 36 9.1.5. Cues Element . . . . . . . . . . . . . . . . . . . . 102 So, there's a 66-page gap between 9.1.4 and 9.1.5. The specification has plenty of 9.1.4.n subsections, but they don't show up in the TOC, because the "tocDepth" attribute isn't specified in the XML, and defaults to "3", so they won't be easily spotted unless you know what to search for in the text. Perhaps you could consider adding "tocDepth=4" to ? While cross-checking the XML, I noticed that Matroska Media Container Format Specifications says that the specification is "informational", but the CELLAR charter at https://datatracker.ietf.org/wg/cellar/about/ says that the Matroska specifications would be Standards Track, so status="std". Best, Spencer > I reordered a few sections of the Matroska spec so the information > follow a more understandable flow, ie from the more general to the more > detailed. > > I did not edit any content, just moved some around. > > As the changes look big and the result is not very readable as a PR, I > uploaded the result the TXT and XML files before and after the change so > you can compare at > https://github.com/robUx4/matroska-specification/pull/1/files > > If you're OK with this, you can approve at > https://github.com/ietf-wg-cellar/matroska-specification/pull/495 > > Otherwise just let me know. > > This is blocking other PRs as the modified text has moved. I prefer to > do the move first as doing it later will still lead to the same problem > and delay anything more important down the line. > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --000000000000b4814705c2767e64 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Steve,=C2=A0

On Sun, May 16, 2021 at 2= :06 AM Steve Lhomme <slhomme@mat= roska.org> wrote:
Hi,

Since my previous post may have been lost in the replies, I'm posting a=
new plain one on the mailing list to make sure everyone is aware.

Thank you for taking this question to the mailin= g list.

I see that Michael has already approved th= e PR in=C2=A0https://github.com/robUx4/matroska-specification/branches, but = I did have one quick question, after a quick look through the table of cont= ents.=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A09.1.4.=C2= =A0 Tracks Element =C2=A0. . . . . . . . . . . . . . . . . . . =C2=A036
= =C2=A0 =C2=A0 =C2=A0 =C2=A09.1.5.=C2=A0 Cues Element =C2=A0. . . . . . . . = . . . . . . . . . . . . 102

So, there's a = 66-page gap between 9.1.4 and 9.1.5. The specification has plenty of 9.1.4.= n subsections, but they don't show up in the TOC, because the=C2=A0&quo= t;tocDepth" attribute isn't specified in the XML, and defaults to = "3", so they won't be easily spotted unless you know what to = search for in the text.=C2=A0

Perhaps you could co= nsider adding=C2=A0"tocDepth=3D4" to=C2=A0

<rfc version=3D"3" ipr=3D"trust200902= " docName=3D"draft-ietf-cellar-matroska-08" sortRefs=3D"= ;true" submissionType=3D"IETF" category=3D"info" x= ml:lang=3D"en" xmlns:xi=3D"http://www.w3.org/2001/XInclude" consensus=3D"true= ">

?

While cross-checking the XML, I noticed that

<= blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px">
<title abbrev=3D"Matroska Format">Mat= roska Media Container Format Specifications</title><seriesInfo val= ue=3D"draft-ietf-cellar-matroska-08" stream=3D"IETF" st= atus=3D"informational" name=3D"Internet-Draft"></= seriesInfo>

=
says that the specification is "informational", but th= e CELLAR charter at=C2=A0https://datatracker.ietf.org/wg/cellar/about/ says that the Mat= roska specifications would be Standards Track, so status=3D"std".=

Best,

Spencer
= =C2=A0
I reordered a= few sections of the Matroska spec so the information
follow a more understandable flow, ie from the more general to the more detailed.

I did not edit any content, just moved some around.

As the changes look big and the result is not very readable as a PR, I
uploaded the result the TXT and XML files before and after the change so you can compare at
https://github.com/robUx4/matroska-spec= ification/pull/1/files

If you're OK with this, you can approve at
https://github.com/ietf-wg-cellar/m= atroska-specification/pull/495

Otherwise just let me know.

This is blocking other PRs as the modified text has moved. I prefer to
do the move first as doing it later will still lead to the same problem and delay anything more important down the line.

_______________________________________________
Cellar mailing list
Cellar@ietf.org https://www.ietf.org/mailman/listinfo/cellar
--000000000000b4814705c2767e64-- From nobody Sun May 16 11:29:36 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 685473A1172 for ; Sun, 16 May 2021 11:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_BLOCKED=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 5pA3vbyEbvfy for ; Sun, 16 May 2021 11:29:30 -0700 (PDT) Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (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 9FC073A1165 for ; Sun, 16 May 2021 11:29:30 -0700 (PDT) Received: by mail-yb1-xb30.google.com with SMTP id e190so5622033ybb.10 for ; Sun, 16 May 2021 11:29: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=GWXStxGwT1njGFq1+sc+NRz9aaVwIjg0EeM8Pd4MosQ=; b=OUqp2kAaaHC4dC8Z+ofC8v9dnBeVvDdkoVe/6vPg9GEOKibHL/qLvWtViz/dlRtmwr wUeSjvuXLD9P9q7ICLVLfwW61AAaGMD7uEsD7Wd3yTToTszXbECFA18QHHBmFQYbONyT lzK2TJqn/nfWUsmeW85AsEv3RvRlapbtp+nkHbG+/Uc+zpp6gHJwqdlf8sXU3/dySt/L le5lKboWPPCI00BqT+KAX9wZbnaXqvpNEc7DhBbTvWknaKBQ5OECrpaW7AubDG2xyl3C 9d/C5tNYhiSWt3g4XJh/ibkDxk6TA8rFJJcu4I0ne1Y4Lx0OjjAF0GjebrlYrYQNZuXz igSA== 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=GWXStxGwT1njGFq1+sc+NRz9aaVwIjg0EeM8Pd4MosQ=; b=Kzm1zWRcOnbyDMnWnO9ISheYo1eRKq28xJwX6Pz3yS7qeLJteKydoq3kBIBjaE+eNq Y1kEQj1aV5AHLeNd2txmZxKcHtL5LW1Rmq+HCDKUT5qcKUWfK788HD5broEJAoqgoleB DWH6mAZipm0UiIZlCAv7FMf9vHdXogjYBKKR8pYcMIBVpkFgr2KDD+/SkZz0zZn+Navk 5M0XZInuzDlf50Mk5za7Fp48Voos17yg6EO4U5OrK/eKAFzxTS4u1LcpCvwpX+EgKQh6 hdpBb8lvvH8nPCx18RZ8vBZyPr2D9QoQ5yCOMPwmhwbbNTv0hBWsLGcTzpdJNJND2uP/ 0JcA== X-Gm-Message-State: AOAM531P4EKHaF/F48XI6gU0OE1KZg60myYL68fLbQjAztCS9PerD4Ty p6MIV5zB9j9NRmUyaMoXXLRcAi/RhDMIXWXkhCQ= X-Google-Smtp-Source: ABdhPJwvl1pi/qZUtKDEG9BBNPX8/iUQgWxClI4QN5eaxvfXmt2yUiKv6VheHQNXjdGXsfOo/Jzb9jF50zQrext1S5Y= X-Received: by 2002:a25:8e0e:: with SMTP id p14mr42606374ybl.84.1621189769179; Sun, 16 May 2021 11:29:29 -0700 (PDT) MIME-Version: 1.0 References: <21441.1620656178@localhost> <206103c0-9265-127b-6a5b-48da92fe3c9d@matroska.org> In-Reply-To: <206103c0-9265-127b-6a5b-48da92fe3c9d@matroska.org> From: Spencer Dawkins at IETF Date: Sun, 16 May 2021 13:29:02 -0500 Message-ID: To: Steve Lhomme Cc: Codec Encoding for LossLess Archiving and Realtime transmission , Murray Kucherawy Content-Type: multipart/alternative; boundary="0000000000004e348605c276a84c" Archived-At: Subject: Re: [Cellar] [ietf-wg-cellar/ebml-specification] EBML ID 0x80 is marked invalid/reserved but it's used in Matroska (#407) 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, 16 May 2021 18:29:36 -0000 --0000000000004e348605c276a84c Content-Type: text/plain; charset="UTF-8" Hi, Steve, (adding Murray to the CC list, because I'm invoking his wisdom on the question we're talking about) On Sun, May 16, 2021 at 8:42 AM Steve Lhomme wrote: > On 2021-05-11 0:43, Spencer Dawkins at IETF wrote: > > Adding our Loyal AD ... because I could be wrong, and he would know ... > > > > On Mon, May 10, 2021 at 9:16 AM Michael Richardson > > wrote: > > > > > > Steve Lhomme > > wrote: > > > As pointed out by [Paul > > Foley]( > https://mailarchive.ietf.org/arch/msg/cellar/z_INjU-Vc9FOTDZs9AhdRRjrIig/ > > < > https://mailarchive.ietf.org/arch/msg/cellar/z_INjU-Vc9FOTDZs9AhdRRjrIig/ > >), > > the 0x80 is EBML ID is said to be invalid in the [RFC > > text](https://datatracker.ietf.org/doc/html/rfc8794#section-5 > > ): > > > > >> The bits of the VINT_DATA component of the Element ID MUST > > NOT be all > > >> "0" values or all "1" values. > > > > > But in Matroska we use 0x80 for `ChapterDisplay`. > > > > > I think the all 0 rules should be removed. In particular > > because 0x80 > > > is the value that should be used when all VINT_DATA bits are > > 0, per > > > this rule: > > > > >> The VINT_DATA component of the Element ID MUST be encoded at > > the shortest valid length. > > > > > Changing this text means also editing the IANA registry which > > lists all > > > the variants of 0 bits as reserved. > > > > I'm not sure how to deal with this. > > It may be that we can put these IANA instructions into the Matroska > > document. > > Obviously, they would ideally go into an EBML-bis document, and that > > would be > > something we'd do if we were revising it now. > > > > > > That would be perfect (if we were doing an EBML-bis document, but I > > What would be an EBML-bis document ? A revision to the RFC comparable to > the errata or something that would result in a new RFC ? > This is always the question, when we have accepted Errata for a published RFC - does the working group publish - an RFC that only contains the sections that the fix for the Errata touches (so, the new RFC Updates the previous RFC), or - an RFC that contains all the sections of the original RFC, whether they contain fixes for the Errata or not (so, the new RFC Obsoletes the previous RFC) Guidance from the IESG about what is preferred has changed over time, so I wanted Murray to be aware that the question was coming up in CELLAR, in case he needed to tell us what the current answer is. Does that make sense? Best, Spencer > > predict that the answer is - the EBML document is a Proposed Standard, > > so any Proposed Standard that (reasonably) updates the instructions to > > IANA should be OK. This update is relevant for Matroska, which is also > > targeting publication as a Proposed Standard, so that's a fine place to > > put the updated IANA instructions. > > > > The EBML RFC IANA instructions would be outdated, but the point of IANA > > registries is that the IANA registries are up to date, and you don't > > have to chase (in some cases) a few dozen RFCs to find all the rules. > > > > Murray, is that about right? > > > > Best, > > > > SPencer > > > > IANA instructions are a bit weird in that they are in essence, > > edge-triggered, and once processed in a document, they change. > > > > ( https://en.wikipedia.org/wiki/Interrupt > > ) > > > > -- > > ] 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 [ > > > > _______________________________________________ > > Cellar mailing list > > Cellar@ietf.org > > https://www.ietf.org/mailman/listinfo/cellar > > > > > > > > _______________________________________________ > > Cellar mailing list > > Cellar@ietf.org > > https://www.ietf.org/mailman/listinfo/cellar > > > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --0000000000004e348605c276a84c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Steve,=C2=A0

(addi= ng Murray to the CC list, because I'm invoking his wisdom on the questi= on we're=C2=A0talking about)

=
On Sun, May 16, 2021 at 8:42 AM Steve= Lhomme <slhomme@matroska.org> wrote:
On = 2021-05-11 0:43, Spencer Dawkins at IETF wrote:
> Adding our Loyal AD ... because I could be wrong, and he would know ..= .
>
> On Mon, May 10, 2021 at 9:16 AM Michael Richardson <mcr@sandelman.ca
> <mailto:mcr@s= andelman.ca>> wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0Steve Lhomme <notifications@github.com
>=C2=A0 =C2=A0 =C2=A0<mailto:notifications@github.com>> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > As pointed out by [Paul
>=C2=A0 =C2=A0 =C2=A0Foley](https://mailarchive.ietf.org/arch/msg/cellar/z_INjU-Vc9FOTDZs9AhdRRjrIi= g/
>=C2=A0 =C2=A0 =C2=A0<https://mailarchive.ietf.org/arch/msg/cellar/z_INjU-Vc9FOTDZs9AhdRRjrIig/<= /a>>),
>=C2=A0 =C2=A0 =C2=A0the 0x80 is EBML ID is said to be invalid in the [R= FC
>=C2=A0 =C2=A0 =C2=A0text](https://datatra= cker.ietf.org/doc/html/rfc8794#section-5
>=C2=A0 =C2=A0 =C2=A0<https://datatrack= er.ietf.org/doc/html/rfc8794#section-5>):
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> The bits of the VINT_DATA c= omponent of the Element ID MUST
>=C2=A0 =C2=A0 =C2=A0NOT be all
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> "0" values or all= "1" values.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > But in Matroska we use 0x80 for= `ChapterDisplay`.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > I think the all 0 rules should = be removed. In particular
>=C2=A0 =C2=A0 =C2=A0because 0x80
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > is the value that should be use= d when all VINT_DATA bits are
>=C2=A0 =C2=A0 =C2=A00, per
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > this rule:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> The VINT_DATA component of = the Element ID MUST be encoded at
>=C2=A0 =C2=A0 =C2=A0the shortest valid length.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Changing this text means also e= diting the IANA registry which
>=C2=A0 =C2=A0 =C2=A0lists all
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > the variants of 0 bits as reser= ved.
>
>=C2=A0 =C2=A0 =C2=A0I'm not sure how to deal with this.
>=C2=A0 =C2=A0 =C2=A0It may be that we can put these IANA instructions i= nto the Matroska
>=C2=A0 =C2=A0 =C2=A0document.
>=C2=A0 =C2=A0 =C2=A0Obviously, they would ideally go into an EBML-bis d= ocument, and that
>=C2=A0 =C2=A0 =C2=A0would be
>=C2=A0 =C2=A0 =C2=A0something we'd do if we were revising it now. >
>
> That would be perfect (if we were doing an EBML-bis document, but I
What would be an EBML-bis document ? A revision to the RFC comparable to the errata or something that would result in a new RFC ?

This is always the question, when we have accepted Errata= for a published RFC - does the working group publish
  • an = RFC that only contains the sections that the fix for the Errata touches (so= , the new RFC Updates the previous RFC), or
  • an RFC that contains al= l the sections of the original RFC, whether they contain fixes for the Erra= ta or not (so, the new RFC Obsoletes the previous RFC)
Guidan= ce from the IESG about what is preferred has changed over time, so I wanted= Murray to be aware that the question was coming up in CELLAR, in case he n= eeded to tell us what the current answer is.=C2=A0=C2=A0
Does that make sense?

Best,

Spencer
=C2=A0
> predict that the answer is - the EBML document is= a Proposed Standard,
> so any Proposed Standard that (reasonably) updates the instructions to=
> IANA should be OK. This update is relevant for Matroska, which is also=
> targeting publication as a Proposed Standard, so that's a fine pla= ce to
> put the updated IANA instructions.
>
> The EBML RFC IANA instructions would be outdated, but the point of IAN= A
> registries is that the IANA registries are up to date, and you don'= ;t
> have to chase (in some cases) a few dozen RFCs to find all the rules.<= br> >
> Murray, is that about right?
>
> Best,
>
> SPencer
>
>=C2=A0 =C2=A0 =C2=A0IANA instructions are a bit weird in that they are = in essence,
>=C2=A0 =C2=A0 =C2=A0edge-triggered, and once processed in a document, t= hey change.
>
>=C2=A0 =C2=A0 =C2=A0( https://en.wikipedia.org/wiki/Inter= rupt
>=C2=A0 =C2=A0 =C2=A0<https://en.wikipedia.org/wiki/Int= errupt> )
>
>=C2=A0 =C2=A0 =C2=A0--
>=C2=A0 =C2=A0 =C2=A0]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Never tell me the odds!=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| ipv6 mesh
>=C2=A0 =C2=A0 =C2=A0networks [
>=C2=A0 =C2=A0 =C2=A0]=C2=A0 =C2=A0Michael Richardson, Sandelman Softwar= e Works=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 IoT
>=C2=A0 =C2=A0 =C2=A0architect=C2=A0 =C2=A0[
>=C2=A0 =C2=A0 =C2=A0] mcr@sandelman.ca <mailto:mcr@sandelman.ca>
>=C2=A0 =C2=A0 =C2=A0http://www.sandelman.ca/ <http://www.sandelman= .ca/>=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0ruby
>=C2=A0 =C2=A0 =C2=A0on rails=C2=A0 =C2=A0 [
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0Cellar mailing list
>=C2=A0 =C2=A0 =C2=A0Cellar@ietf.org <mailto:Cellar@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/lis= tinfo/cellar
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman= /listinfo/cellar>
>
>
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar >


_______________________________________________
Cellar mailing list
Cellar@ietf.org https://www.ietf.org/mailman/listinfo/cellar
--0000000000004e348605c276a84c-- From nobody Sun May 16 15:56:05 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 8ED033A1C48 for ; Sun, 16 May 2021 15:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 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_DNSWL_LOW=-0.7, 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=tMHO1NH3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SQsknmJS 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 3THXw1pjDlGP for ; Sun, 16 May 2021 15:55:58 -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 D91663A1C4F for ; Sun, 16 May 2021 15:55:58 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 7FC8D5C01D9 for ; Sun, 16 May 2021 18:19:50 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 16 May 2021 18:19:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm2; bh=gK1M5X+dO5e C+gcJvuni3LyB9o1kqkbhjYnG4WOgBoo=; b=tMHO1NH35eVLMxdTBOIRtDlFZ5Y rB8nUxaz5h4WP3X+jihLEWJyn7mYtOTui2KkTm3Qw8T4SmPg3HzQOgO1n9J2L9Km pkP5eYiQxuMdXvUPbcPRR1pJ5ERysLFY3y3ZyHY0O8nE7rRjrrLlYpOIbWPOq/mA PFvq5JTi9gkyK4PAiY+t/Np8nwyP7e1giKYv/qAoJtAZ016JWSiX+vR/P053R2s4 xOtZbV/+RKU9dKCa/FulKI4ThnVbP4h4CCP7eHadasPxnuUr1rbbHnKeMYmoHaI5 GNfY+r+tEqBO4pg/PHdfPqaybfrlBRya2bUvAymOFHeaaKxt0Ua2RMNMRQA== 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= fm2; bh=gK1M5X+dO5eC+gcJvuni3LyB9o1kqkbhjYnG4WOgBoo=; b=SQsknmJS sSGhSE5HpzVb5a1ImFJHVI0PzptasLV6mmSh+6XFNPtc2UnVNPWTfAEeYWHnU6fu 8bG1HkE4cbwwjZqyzPS9AXjjziH24coAMO2CN+DY4aNnnetc7M7Y8FkLxPbsjkyK 6yHI5psYfrRI8KM7bymalGnanHFalag1Y6DK9VkpR8z4pgc/NGQ++0CWWhzlXVHm daz4WMRb39Gq0jvEOpQI24tSl/VoIC3evoNEgkmSr1bLQcfqngiRPf/2uqUowMa2 CtQ5YXzdghvDWt82SC5HhoraUybGOiBNOjQz3yJDI6ujnZLPUO6g2xggNCDLr0BL TW/ud5RKfz78Nw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeigedgtdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucfpohcuuggrthgvuchfihgvlhguucdlgeelmdenuc fjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpeftvghpohhsihhtohhrhicu tegtthhivhhithihucfuuhhmmhgrrhihuceuohhtuceoughopghnohhtpghrvghplhihse hmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeefvdduteejvdefkeehieevuefg fefhteetveegffekffefteffvdelheduieetnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucfkphepuddtgedrvddugedrfeekrddvvdenucevlhhushhtvghrufhiiigvpedu necurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprhgvphhlhiesmhhnohhtrd hnvght X-ME-Proxy: Received: from fv-az290-521.z45yk40qnouupoc55gb0v1wkoc.jx.internal.cloudapp.net (unknown [104.214.38.22]) by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 16 May 2021 18:19:50 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============0210501998407251130==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20210516225558.D91663A1C4F@ietfa.amsl.com> Date: Sun, 16 May 2021 15:55:58 -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, 16 May 2021 22:56:04 -0000 --===============0210501998407251130== 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/matroska-specification (+0/-0/=F0=9F=92=AC2) 1 issues received 2 new comments: - #508 Add the bogus TagDefault value in the RFC (2 by robUx4) https://github.com/ietf-wg-cellar/matroska-specification/issues/508 [XM= L Schema] [format addition] [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 --===============0210501998407251130== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

Sunday May 16, 2021

Events without label "editorial"

Issues

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

1 issues received 2 new comments:

Repositories tracked by this digest:

--===============0210501998407251130==-- From nobody Tue May 18 10:41:26 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 DF43A3A1ABB for ; Tue, 18 May 2021 10:41:24 -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 DHdCPj-5b8CN for ; Tue, 18 May 2021 10:41:23 -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 1A6163A1ABA for ; Tue, 18 May 2021 10:41:22 -0700 (PDT) Received: by mail-vs1-xe35.google.com with SMTP id j13so5376688vsf.2 for ; Tue, 18 May 2021 10:41:22 -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=ptbmYyoKAg579sA5s5fLADKmUEBaVuJEguYNee0yHOw=; b=uXHYSPDTFbK9GWOhJ5y3GM3DDN2MzFCROvVe0kQpFJa+Ggol4vH0awygOAUbOapn/Z +ZkqHxr5DxPdLiC7NnAx6T/Bjpv+jXhV/cCr9f2TeVkShwuZNS2fk9O6KFXDvmn2ZgoX MhBtRpzID5j9y1Ol1KwHnCDXYdSATC6CeztlT7b6hLDJVNYJTETAHYvX6ehrCQ6u4gj3 iWAUF08kIFeVejVlDx5jPjWloHdPA4m1HXgZ6qlN0oXZ13GIorGBBGZZKZ76YWC55qw2 jlkJFjei+DJC2arykyEJeVnoX6nFfF2FIXg9pz/Gu1Wtdr8GbvYXPsq4kdYrOyA1rxGD Y1mA== 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=ptbmYyoKAg579sA5s5fLADKmUEBaVuJEguYNee0yHOw=; b=Z/08KbxnVUE9kCTDBzqKv7l5B67CZxJhTnw9zkL/rC1dRxjD0zzSJlTPJ94n3XBGBA WCnW2umF6FcX+YH0hv0PKMgCGZT+7YSona87uggrnplrzUN8/fvcYP1R/PbABZg1PrJw 4yF/zUxMYzJcFkuO0siSl9WlBJcSqxnDrk+N7ejU7QX/6bm/imohDv06Z/wcjAkGk67w LssdMnA6CIiQ921x+RMNT4p+QY1gBwTJMht8SdRxhyZDsQb+XfYhkcEUlSN3up5Qo0xP qLLuYU6p/LSkhU94aGbu/zS6YZZZW3PfFittGhljGaGtfYnnES7nv4l1dLig3bucxgWg n9xA== X-Gm-Message-State: AOAM530KWNkb5f/PYD78nvtu7mjVY/WqhTox0LWY6IzOxNzmFxilG1Gb oGMXODot6jmLbjRDpWyP/G68mJtiIHcF4cje5sU= X-Google-Smtp-Source: ABdhPJx405H7d0hwoKREzSZ2yn4LLuTNl7fakafCtxhEQoZB+Vrk8AdNRJLpxc2IwqFBEMr2V5otfzpGZc30R64Q1yM= X-Received: by 2002:a67:ebd7:: with SMTP id y23mr4461445vso.54.1621359680940; Tue, 18 May 2021 10:41:20 -0700 (PDT) MIME-Version: 1.0 References: <21441.1620656178@localhost> In-Reply-To: From: "Murray S. Kucherawy" Date: Tue, 18 May 2021 10:41:09 -0700 Message-ID: To: Spencer Dawkins at IETF Cc: Michael Richardson , Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="000000000000d5eea705c29e37ee" Archived-At: Subject: Re: [Cellar] [ietf-wg-cellar/ebml-specification] EBML ID 0x80 is marked invalid/reserved but it's used in Matroska (#407) 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, 18 May 2021 17:41:25 -0000 --000000000000d5eea705c29e37ee Content-Type: text/plain; charset="UTF-8" Sorry for the delay replying here. On Mon, May 10, 2021 at 3:44 PM Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Adding our Loyal AD ... because I could be wrong, and he would know ... > > I'm not sure how to deal with this. >> It may be that we can put these IANA instructions into the Matroska >> document. >> Obviously, they would ideally go into an EBML-bis document, and that >> would be >> something we'd do if we were revising it now. >> > > That would be perfect (if we were doing an EBML-bis document, but I > predict that the answer is - the EBML document is a Proposed Standard, so > any Proposed Standard that (reasonably) updates the instructions to IANA > should be OK. This update is relevant for Matroska, which is also targeting > publication as a Proposed Standard, so that's a fine place to put the > updated IANA instructions. > > The EBML RFC IANA instructions would be outdated, but the point of IANA > registries is that the IANA registries are up to date, and you don't have > to chase (in some cases) a few dozen RFCs to find all the rules. > > Murray, is that about right? > It's possible I don't have all the context I need here, in which case this answer will be nonsense and I'll need ask for more details, but running with what I've got: I think you could do an "updates" document to EBML that just makes IANA registry/policy amendments if you want to do that. Smaller documents tend to result in faster processing by the IESG. The cases where this tends not to work is where the number of "updates" documents gets large enough that teasing out reality becomes difficult; at that point it becomes better to just issue a complete "bis" document. If you put EBML-specific IANA actions in the Matroska document, and they are not clearly related, you might encounter some resistance of the form "What the heck is this doing here?" from the IESG or other reviewers. If that's not a helpful answer, let me know and I'll get Spencer to give me more context. -MSK --000000000000d5eea705c29e37ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry for the delay replying here.

On = Mon, May 10, 2021 at 3:44 PM Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:=
Adding our Loyal AD ... because I could be wrong, and he would know = ...=C2=A0

I'm not sure how to deal with this.
It may be that we can put these IANA instructions into the Matroska documen= t.
Obviously, they would ideally go into an EBML-bis document, and that would = be
something we'd do if we were revising it now.

=
That would be perfect (if we were doing an EBML-bis document, bu= t I predict that the answer is - the EBML document is a Proposed Standard, = so any Proposed Standard that (reasonably) updates the instructions to IANA= should be OK. This update is relevant for Matroska, which is also targetin= g publication as a Proposed Standard, so that's a fine place to put the= updated IANA instructions.=C2=A0

The EBML RFC IAN= A instructions would be outdated, but the point of IANA registries is that = the IANA registries are up to date, and you don't have to chase (in som= e cases) a few dozen RFCs to find all the rules.=C2=A0

=
Murray, is that about right?

It's possible I don't have all the context I need here, in= which case this answer will be nonsense and I'll need ask for more det= ails, but running with what I've got:

I th= ink you could do an "updates" document to EBML that just makes IA= NA registry/policy amendments if you want to do that.=C2=A0 Smaller documen= ts tend to result in faster processing by the IESG.=C2=A0 The cases where t= his tends not to work is where the number of "updates" documents = gets large enough that teasing out reality becomes difficult; at that point= it becomes better to just issue a complete "bis" document.
=

If you put EBML-specific IANA actions in the Matroska d= ocument, and they are not clearly related, you might encounter some resista= nce of the form "What the heck is this doing here?" from the IESG= or other reviewers.

If that's not a help= ful answer, let me know and I'll get Spencer to give me more context.

-MSK
--000000000000d5eea705c29e37ee-- From nobody Tue May 18 10:51:36 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 803393A1AF9 for ; Tue, 18 May 2021 10:51:23 -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 XlS3zu4_rZl5 for ; Tue, 18 May 2021 10:51:18 -0700 (PDT) Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (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 9A5773A1AFF for ; Tue, 18 May 2021 10:51:18 -0700 (PDT) Received: by mail-ua1-x92d.google.com with SMTP id f1so3495147uaj.10 for ; Tue, 18 May 2021 10:51:18 -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=g1jiuVFhMCsDKXIe1BlHg5XN0ofAUj58MqXALQOz4bA=; b=l/C4Sct2EerM+m3cAHgLze/ZyZct1McK5o18sU8YFf8bFql5s6X18gJPKad7JoCX7O isxYGqP+zkoifkxrvGpak4PYciK7tXV/5JFe8b3Cs6iSaqgJ1yQLmNFo9unIDc6ePWOA mZyDDmcnEGlY3UulXnj97YDbEvArTMoFdmVF8mzX+G4rAAcvQoUxfNGZsD1jKPvdRs4V Rvnzv8uk1YwL3Hp9mHLkbu1qCBOqwYsDeJSCljz8e3kuDcoffT0TpgOaqGsApNz1BAUD lud89vZbm//pAj0fNOpcZFMBVW/ObvSfbca9o8KZPo6+q7vHKHcCnvhYHPVIFLq36u96 RO6w== 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=g1jiuVFhMCsDKXIe1BlHg5XN0ofAUj58MqXALQOz4bA=; b=k7Mmd39QVtIc9lo1gTauDpBONzVmUEbgR48Obl0/uvL1GcoH/eiUio4+CfusUuTr82 W+7DzVrAldhSvFSJGJqQJlNa7VKQKxadw/p02sfP7pcPfA2wK7ZzPDHWvYqyBd0pgYRE PIuwTgaYIGPRF5qzEH93otEsntdBdMm6WIrZN4ntMv0FfcDOhQQvq7kzOuvQKnx3Lp95 6X9JCg6EBOzLHqGk2b4NqnFhNO8cnTzuMpD6AyFw3hC8tl+w+46Mp7+XvCe6NiWKmi44 Xj5rYPEstrtsA77VV9cg1p/nmIWpqq72NPzIXdZeJ9wc22pjWqzbsvw69D67/rIDeQno CV3w== X-Gm-Message-State: AOAM533CafYZl1PSlMFSfJMZcbb0BqV8NodzRNitkT/o4NSXGhLmHVTX GDgLTdbYKUXnWa+kwFh+TbAp7w1L0t5T5qaXV10= X-Google-Smtp-Source: ABdhPJx0GV0x2ZQdc8lF8iAE32F7vyP9D4cwIM8FmX1RnwgzHzs6VTI+rfayvv4KgFCLn+JEdTFsTnYtZkwtxq9MYf0= X-Received: by 2002:ab0:42a7:: with SMTP id j36mr7999065uaj.87.1621360276823; Tue, 18 May 2021 10:51:16 -0700 (PDT) MIME-Version: 1.0 References: <21441.1620656178@localhost> <206103c0-9265-127b-6a5b-48da92fe3c9d@matroska.org> In-Reply-To: From: "Murray S. Kucherawy" Date: Tue, 18 May 2021 10:51:05 -0700 Message-ID: To: Spencer Dawkins at IETF Cc: Steve Lhomme , Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="0000000000005a60ad05c29e5bb1" Archived-At: Subject: Re: [Cellar] [ietf-wg-cellar/ebml-specification] EBML ID 0x80 is marked invalid/reserved but it's used in Matroska (#407) 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, 18 May 2021 17:51:34 -0000 --0000000000005a60ad05c29e5bb1 Content-Type: text/plain; charset="UTF-8" On Sun, May 16, 2021 at 11:29 AM Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Hi, Steve, > > (adding Murray to the CC list, because I'm invoking his wisdom on the > question we're talking about) > > On Sun, May 16, 2021 at 8:42 AM Steve Lhomme wrote: > >> What would be an EBML-bis document ? A revision to the RFC comparable to >> the errata or something that would result in a new RFC ? >> > > This is always the question, when we have accepted Errata for a published > RFC - does the working group publish > > - an RFC that only contains the sections that the fix for the Errata > touches (so, the new RFC Updates the previous RFC), or > - an RFC that contains all the sections of the original RFC, whether > they contain fixes for the Errata or not (so, the new RFC Obsoletes the > previous RFC) > > Guidance from the IESG about what is preferred has changed over time, so I > wanted Murray to be aware that the question was coming up in CELLAR, in > case he needed to tell us what the current answer is. > > Does that make sense? > An "updates" or "bis" document just to resolve one or two errata might raise some eyebrows. How many do you want to handle? Is there any pending update you could fold into such a document? Or to put it another way, what's wrong with leaving it as a small number of errata for now? Whether you do a full "bis" document or an "updates" depends on how big the aggregate change(s) you have in mind are. I'm happy to be an advocate for either; just depends on how big the final "diff" to the existing document would be. -MSK --0000000000005a60ad05c29e5bb1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, May 16, 2021 at 11:29 AM Spencer = Dawkins at IETF <spence= rdawkins.ietf@gmail.com> wrote:
=
Hi, Steve,=C2=A0

(adding Murray to the CC list,= because I'm invoking his wisdom on the question we're=C2=A0talking= about)

On Sun, May 16, 2021 at 8:42 AM Steve Lhomme <slhomme@matroska.org> w= rote:
What would= be an EBML-bis document ? A revision to the RFC comparable to
the errata or something that would result in a new RFC ?

This is always the question, when we have accepted Errata= for a published RFC - does the working group publish
  • an = RFC that only contains the sections that the fix for the Errata touches (so= , the new RFC Updates the previous RFC), or
  • an RFC that contains al= l the sections of the original RFC, whether they contain fixes for the Erra= ta or not (so, the new RFC Obsoletes the previous RFC)
Guidan= ce from the IESG about what is preferred has changed over time, so I wanted= Murray to be aware that the question was coming up in CELLAR, in case he n= eeded to tell us what the current answer is.=C2=A0=C2=A0
Does that make sense?

<= /div>
An "updates" or "bis" document just to resolv= e one or two errata might raise some eyebrows.=C2=A0 How many do you want t= o handle?=C2=A0 Is there any pending update you could fold into such a docu= ment?=C2=A0 Or to put it another way, what's wrong with leaving it as a= small number of errata for now?

Whether you do a = full "bis" document or an "updates" depends on how big = the aggregate change(s) you have in mind are.=C2=A0 I'm happy to be an = advocate for either; just depends on how big the final "diff" to = the existing document would be.

-MSK
--0000000000005a60ad05c29e5bb1-- From nobody Tue May 18 10:59:48 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 C4DD53A1B14 for ; Tue, 18 May 2021 10:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_BLOCKED=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 RKXnVbIOFYYR for ; Tue, 18 May 2021 10:59:31 -0700 (PDT) Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (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 D9BE93A1B83 for ; Tue, 18 May 2021 10:59:30 -0700 (PDT) Received: by mail-yb1-xb2d.google.com with SMTP id i4so14515038ybe.2 for ; Tue, 18 May 2021 10:59: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=37m9+Ys9zYiN5nOkc+V0xpZmIgBGDrKmjhb9Oav2TyY=; b=lzcSxYos7fs1wawtWw+qg/QyZ1KSInEBHeWEILkFbOW5u+0vRXsITO5h+OH2UMXN/y b/gvsqtK4RuOxEoUSBZZa/GsRrlVue4iTGe5HkOOXtyLIUUhxXRriKahYNlictdFOLFs AJVhE0BW3518zFcGe0O29WLw2LaDNY7FSSOm14x1T7/jXj8F9TXybJPQVLbuDbZ8x2Hv 7bBATnOVikK3HQTu2Kd4MRbTCbXdBenGHO334wkaWvKwk5XsUczVLGcEggw0zj+YBbcE pr2IKE/Sl6D1Ddf+GsUY4me+zW2G2aYOh30sPiJ/TuT45U7GSgVPtoMObhZChA7ZojQd FXcA== 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=37m9+Ys9zYiN5nOkc+V0xpZmIgBGDrKmjhb9Oav2TyY=; b=o/4vEZ5Mp7YYrFza+xb0CUHjUNYAJ4/fjkguOji5IKf7KEBHMMhpAoHNnbJXCjJBer fi2VOjgkBJe/LPKagwjwjzf8gbyok1dWAlW5AdwV7oYSZdOWm/TCFyO6poLMXCyfo+Lx SMGXB7K9j4o5ng62zBO77PISoORSEt4SPwFK2lE1kZfHRcYO7wk42cbUCO1IpkHLPJ3R j4Auk7iUGsj30kOFAkIzwTD2L78wcfzsUPeAZYJV3PQv8mPQgoIh5Tfw5kkHznFI3xbe ZhbWRCSNmLQxPjbePKAvPh+78p8BUr527fne2/bOtqd2rxVePmbQzvZNYFuXFPFOkNFT NTvw== X-Gm-Message-State: AOAM533DgXrDW032CvOqjDU+Ws/+J7isk3yqoyePi+ezQB17egq5+2xd fywV/jdaI5o7lh3daykz0eIIaZpselFYDwLIfLw= X-Google-Smtp-Source: ABdhPJyZQNg2VU6soYL3PZlXKv/uM0j9DAbAEIN/jmS2FzuU5SWLiDker0imETCbyGDaKWEYD5n5WpZ72VhjCbzvn9Y= X-Received: by 2002:a25:5d0b:: with SMTP id r11mr9100027ybb.380.1621360769021; Tue, 18 May 2021 10:59:29 -0700 (PDT) MIME-Version: 1.0 References: <21441.1620656178@localhost> <206103c0-9265-127b-6a5b-48da92fe3c9d@matroska.org> In-Reply-To: From: Spencer Dawkins at IETF Date: Tue, 18 May 2021 12:59:02 -0500 Message-ID: To: "Murray S. Kucherawy" Cc: Steve Lhomme , Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="000000000000b0bc8a05c29e782e" Archived-At: Subject: Re: [Cellar] [ietf-wg-cellar/ebml-specification] EBML ID 0x80 is marked invalid/reserved but it's used in Matroska (#407) 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, 18 May 2021 17:59:47 -0000 --000000000000b0bc8a05c29e782e Content-Type: text/plain; charset="UTF-8" Hi, Murray, (replying here - I think this email is more relevant) On Tue, May 18, 2021 at 12:51 PM Murray S. Kucherawy wrote: > On Sun, May 16, 2021 at 11:29 AM Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > >> Hi, Steve, >> >> (adding Murray to the CC list, because I'm invoking his wisdom on the >> question we're talking about) >> >> On Sun, May 16, 2021 at 8:42 AM Steve Lhomme >> wrote: >> >>> What would be an EBML-bis document ? A revision to the RFC comparable to >>> the errata or something that would result in a new RFC ? >>> >> >> This is always the question, when we have accepted Errata for a published >> RFC - does the working group publish >> >> - an RFC that only contains the sections that the fix for the Errata >> touches (so, the new RFC Updates the previous RFC), or >> - an RFC that contains all the sections of the original RFC, whether >> they contain fixes for the Errata or not (so, the new RFC Obsoletes the >> previous RFC) >> >> Guidance from the IESG about what is preferred has changed over time, so >> I wanted Murray to be aware that the question was coming up in CELLAR, in >> case he needed to tell us what the current answer is. >> >> Does that make sense? >> > > An "updates" or "bis" document just to resolve one or two errata might > raise some eyebrows. How many do you want to handle? Is there any pending > update you could fold into such a document? Or to put it another way, > what's wrong with leaving it as a small number of errata for now? > > Whether you do a full "bis" document or an "updates" depends on how big > the aggregate change(s) you have in mind are. I'm happy to be an advocate > for either; just depends on how big the final "diff" to the existing > document would be. > This is helpful. What we're looking at in this thread is a small number of errors for EBML (that haven't been entered as errata for the RFC yet), and a change to the IANA instructions for one of the registries in . https://www.iana.org/assignments/ebml/ebml.xhtml. Does that sound OK as an Updates RFC to you? (depending on the final "diff", of course!) Best, Spencer > -MSK > --000000000000b0bc8a05c29e782e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Murray,=C2=A0
<= br>
(replying here - I think this email is more relevant)
On Tue, = May 18, 2021 at 12:51 PM Murray S. Kucherawy <superuser@gmail.com> wrote:
On Sun, = May 16, 2021 at 11:29 AM Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com<= /a>> wrote:
On Sun, M= ay 16, 2021 at 8:42 AM Steve Lhomme <slhomme@matroska.org> wrote:
What would be an EBML-bis docume= nt ? A revision to the RFC comparable to
the errata or something that would result in a new RFC ?

This is always the question, when we have accepted Errata= for a published RFC - does the working group publish
  • an = RFC that only contains the sections that the fix for the Errata touches (so= , the new RFC Updates the previous RFC), or
  • an RFC that contains al= l the sections of the original RFC, whether they contain fixes for the Erra= ta or not (so, the new RFC Obsoletes the previous RFC)
Guidan= ce from the IESG about what is preferred has changed over time, so I wanted= Murray to be aware that the question was coming up in CELLAR, in case he n= eeded to tell us what the current answer is.=C2=A0=C2=A0
Does that make sense?

<= /div>
An "updates" or "bis" document just to resolv= e one or two errata might raise some eyebrows.=C2=A0 How many do you want t= o handle?=C2=A0 Is there any pending update you could fold into such a docu= ment?=C2=A0 Or to put it another way, what's wrong with leaving it as a= small number of errata for now?

Whether you do a = full "bis" document or an "updates" depends on how big = the aggregate change(s) you have in mind are.=C2=A0 I'm happy to be an = advocate for either; just depends on how big the final "diff" to = the existing document would be.

This is helpful.=C2=A0

What we're looki= ng at in this thread is a small number of errors for=C2=A0EBML (that haven&= #39;t been entered as errata for the RFC yet), and a change to the IANA ins= tructions for one of the registries in .https://www.iana.org/assignments/ebml/ebml.xhtml<= /a>.




--000000000000b0bc8a05c29e782e-- From nobody Tue May 18 11:29: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 A02C93A1C8B for ; Tue, 18 May 2021 11:29:34 -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 3ckOGSHrRTDb for ; Tue, 18 May 2021 11:29:30 -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 0E9D63A1C82 for ; Tue, 18 May 2021 11:29:29 -0700 (PDT) Received: by mail-ua1-x92e.google.com with SMTP id p17so2006188uaw.4 for ; Tue, 18 May 2021 11:29:29 -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=bxAKpH1cDc9gDcOOLuWwGyVQHd6UsQ5ZX0ud3B8VqMI=; b=cF3Sj5LHReTFhWvSXcje89ajIHDx3Q9i1GiyPW0dvqYvZ+p1fmidd2uOdnw3Ced8bM geTqvMyAxBuEoZDYP1KmNxhgaaZ8xTMOdxlqsvJOOIuMOWHmcV4yxBb1rkJp8k4Eka1K Dof+y5BQuoQ/nUfUahDR3FkrkuW01V/LyEgqAFM8pVqt7tzVhdoEW0RCRb0krm64K5LV yf/d0JQ9HrpkJ8vEzfQuOX0rPGLwNj+TWZhhyHTi2yGpIKFG0HHbqb3F5udsj53nTYmG MT28ncVtVU1tS40X+TFH+QkgjYsiERyJjTSA7QOpRDX1afhVNLpcUIuUd0i2lVCAzv3Z hlwQ== 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=bxAKpH1cDc9gDcOOLuWwGyVQHd6UsQ5ZX0ud3B8VqMI=; b=pmDtVrcFXWu3gmbs6pWLFjVVUYDOsvoCW7NeCFFfKA8yDC0XtRc9MtUOY1vIrhsxGZ ZYcxWczbYfBZd/VfikCuzJ1yUsghxpwkPaKOEmzAEoQGaPr1oM6W1cMycPWJilk5ria5 8RnGpqcCPAZRf07qs5b+60jZhWPOzPHkXvFEK28Gxwy4yzrWqtrBgnSsW3dpHNewv4rQ PoSUmP9d9hY2NE0Jzavs0KzZKRDncKR6EArywCnx6TlqY8kthCYAd4hGL1+8neSipLGZ Kgc7MIYDc3nmKu6fkLJMa2iG5zFyit2qHMhUTa4cQjhgUn+Hy+lGV3PjNOqQL99tdH3j P4Xw== X-Gm-Message-State: AOAM532M0g3t7QGlQ9raFUmCl0EbYpg1IXBrbEmEdTKCLpoH4wIeLQWQ D7O19NDPZdP3C/JRu2atUz/BrBPXO3R1sngNBQQ= X-Google-Smtp-Source: ABdhPJxtjqcsnB+aTY+hISlJlCVkrXkZI0Z17bPIs74UQToTFirIYzRgG6bvh8Q1UccGznkxMZxrH1tA4BFfEgBWCEA= X-Received: by 2002:ab0:44a6:: with SMTP id n35mr8194518uan.101.1621362567649; Tue, 18 May 2021 11:29:27 -0700 (PDT) MIME-Version: 1.0 References: <21441.1620656178@localhost> <206103c0-9265-127b-6a5b-48da92fe3c9d@matroska.org> In-Reply-To: From: "Murray S. Kucherawy" Date: Tue, 18 May 2021 11:29:16 -0700 Message-ID: To: Spencer Dawkins at IETF Cc: Steve Lhomme , Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="000000000000e59e1005c29ee331" Archived-At: Subject: Re: [Cellar] [ietf-wg-cellar/ebml-specification] EBML ID 0x80 is marked invalid/reserved but it's used in Matroska (#407) 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, 18 May 2021 18:29:35 -0000 --000000000000e59e1005c29ee331 Content-Type: text/plain; charset="UTF-8" On Tue, May 18, 2021 at 10:59 AM Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > > An "updates" or "bis" document just to resolve one or two errata might >> raise some eyebrows. How many do you want to handle? Is there any pending >> update you could fold into such a document? Or to put it another way, >> what's wrong with leaving it as a small number of errata for now? >> >> Whether you do a full "bis" document or an "updates" depends on how big >> the aggregate change(s) you have in mind are. I'm happy to be an advocate >> for either; just depends on how big the final "diff" to the existing >> document would be. >> > > This is helpful. > > What we're looking at in this thread is a small number of errors for EBML > (that haven't been entered as errata for the RFC yet), and a change to the > IANA instructions for one of the registries in . > https://www.iana.org/assignments/ebml/ebml.xhtml. > > Does that sound OK as an Updates RFC to you? > > (depending on the final "diff", of course!) > I'd have to see it to say for sure, but I would start this by writing an "updates" RFC. If it starts to become bigger than the kind of thing you would be comfortable patching into some source code, you might consider just doing a whole "bis" document that includes all of your corrections. I would surmise that the inflection point between the two choices is when the size of the "updates" document exceeds the size that the diff of the "bis" document would be. When you cross that boundary, consider switching to the latter. Since you can always get the final XML back from the RFC Editor, doing a "bis" document isn't as much of a burden as you might think. The datatracker certainly does make it easy for someone to just review the diff to the previous RFC, and the IESG loves it when you make things easy on them. ;-) I can anticipate, however, some resistance just on the basis that we're already talking about a "bis" document for an RFC that's not even a year old, so we should be prepared to talk about why this is necessary. -MSK --000000000000e59e1005c29ee331 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=

An "updates" or &q= uot;bis" document just to resolve one or two errata might raise some e= yebrows.=C2=A0 How many do you want to handle?=C2=A0 Is there any pending u= pdate you could fold into such a document?=C2=A0 Or to put it another way, = what's wrong with leaving it as a small number of errata for now?
=

Whether you do a full "bis" document or an &q= uot;updates" depends on how big the aggregate change(s) you have in mi= nd are.=C2=A0 I'm happy to be an advocate for either; just depends on h= ow big the final "diff" to the existing document would be.
<= /div>

This is helpful.=C2=A0

What we're looking at in this thread is a small number= of errors for=C2=A0EBML (that haven't been entered as errata for the R= FC yet), and a change to the IANA instructions for one of the registries in= .https://www.iana.org/assignments/ebml/ebml.xhtml.

<= /div>
Does that sound OK as an Updates RFC to you?=C2=A0

=
(depending on the final "diff", of course!)

I'd have to see it to say for s= ure, but I would start this by writing an "updates" RFC.=C2=A0 If= it starts to become bigger than the kind of thing you would be comfortable= patching into some source code, you might consider just doing a whole &quo= t;bis" document that includes all of your corrections.=C2=A0 I would s= urmise that the inflection point between the two choices is when the size o= f the "updates" document exceeds the size that the diff of the &q= uot;bis" document would be.=C2=A0 When you cross that boundary, consid= er switching to the latter.

Since you can always g= et the final XML back from the RFC Editor, doing a "bis" document= isn't as much of a burden as you might think.=C2=A0 The datatracker ce= rtainly does make it easy for someone to just review the diff to the previo= us RFC, and the IESG loves it when you make things easy on them.=C2=A0 ;-)<= /div>

I can anticipate, however, some resistance just on= the basis that we're already talking about a "bis" document = for an RFC that's not even a year old, so we should be prepared to talk= about why this is necessary.

-MSK
--000000000000e59e1005c29ee331-- From nobody Thu May 20 05:40: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 5ED423A158A for ; Thu, 20 May 2021 05:40: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlAoxCJbXH9D for ; Thu, 20 May 2021 05:40:12 -0700 (PDT) Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) (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 259C73A1584 for ; Thu, 20 May 2021 05:40:12 -0700 (PDT) Received: by mail-yb1-xb33.google.com with SMTP id d14so14648706ybe.3 for ; Thu, 20 May 2021 05:40:12 -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=yWtjeLKZQxXMVn1BqaXeWkuOwe9AhOPtgbc7ow+3lc0=; b=pa/5CEuxipYi1xO10ubyfS1y3nvMIqh/GtyeQD64pWq9ld3dpyfIBVw4Y81p2V0ZDd h+/+EyV0T7wxWvG58P4R/DKxpni6V/iC7gREq4492gcmGotTh0jj58HDs9Qm6fGCi7Dw gdGts19/+OFBTxAPgQfzlA0+osmeQuWZ9lcsdc3RoDmU79GmnSd0n0egZGlBrsv6aDPB LV0bryqcmZNT+3fMpfu5ZvxhOaD6Kcwpi30PJVRevTLxVAOEaMyg3jVGFye5fcnkSzL6 0c1ByHEo7ILdg4iwnJADpe4nJfvZD+sOWJEt1XyK0HBQ4bpPpxbGKcs1eSdKhvFLGE4j 5iKA== 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=yWtjeLKZQxXMVn1BqaXeWkuOwe9AhOPtgbc7ow+3lc0=; b=dmYmCUp83cPud3uxIJWQjBqdA/IuG6rFfzeZGK2bBkP69g3L7Ks8ClM80KA5abc2Kn oKe9rqKebJ52mKk4uAejg5LBgxWYNDOfX5OSh2ESuS3fXv8Bu/D0tO3ddbkPHnsSzEcp d4eF+7jTFOHdQERbPc1q0C+R1wHEU9vJO4nCVMHJrJizCRXP2Gs5W3NoUPFelL3XhY2q XjrVoAMP1ND77LYvdfJGHq3kQ5E3KQN8LzuSGuvemlfqjg1ChbBcKRuii5r1dLDsD3Vb 1e1GBhZimEDduyFUZuaeereCVn4HHvdGaI276yFSJ5O5AFlKs2N8JAZcKpPdXniWlXVc LTNg== X-Gm-Message-State: AOAM533ZNxxck9nASYM7EQe+iHYiMZoyxzwlgSqO3PBbOeEPPrXdVdgC R8OldCpehT30PUweK8uXlhR7oRxXHa31VvQEHBGJ4cxJ20U= X-Google-Smtp-Source: ABdhPJzC2CK+Xy+nMk5hwyVhSM114rkFfzRd8pFV6mpSRmlol91R+mSSfn6pOYcgG+NL0xKzkjqO7f2EztmywBfdX08= X-Received: by 2002:a25:1983:: with SMTP id 125mr3720346ybz.84.1621514410834; Thu, 20 May 2021 05:40:10 -0700 (PDT) MIME-Version: 1.0 From: Spencer Dawkins at IETF Date: Thu, 20 May 2021 07:39:44 -0500 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="00000000000074bd6805c2c23e14" Archived-At: Subject: [Cellar] Wakeup call and call for special topics for our next meeting on 25 May 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, 20 May 2021 12:40:14 -0000 --00000000000074bd6805c2c23e14 Content-Type: text/plain; charset="UTF-8" Dear Callar, We will be having our next meeting this coming Tuesday. I know that we need to finish discussions about EBML errata and IANA registry instructions, and our way forward. . What else should we have as special topics, before working our way through the issues? Best, Spencer p.s. Michael may not be able to join this coming meeting, depending on his schedule. Please be patient with me :-) --00000000000074bd6805c2c23e14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Callar,=C2=A0

We will be having ou= r next meeting this coming Tuesday.=C2=A0

I know t= hat we need to finish discussions about EBML errata and IANA registry instr= uctions,=C2=A0and our way forward. .=C2=A0

What el= se should we have as special topics, before working our=C2=A0way through th= e issues?

Best,

Spencer

p.s. Michael may not be able to join this coming me= eting, depending on his schedule. Please be patient with me :-)
--00000000000074bd6805c2c23e14-- From nobody Fri May 21 11:20: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 62E9F3A1A4B for ; Fri, 21 May 2021 11:19:59 -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, RCVD_IN_DNSWL_BLOCKED=0.001, 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 O7X_FuWsxjL7 for ; Fri, 21 May 2021 11:19:55 -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 0D51B3A1A4A for ; Fri, 21 May 2021 11:19:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 13AE138D47; Fri, 21 May 2021 14:29:28 -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 LJR78OaTX5Oo; Fri, 21 May 2021 14:29:27 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 6EDEB38D3F; Fri, 21 May 2021 14:29:27 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C995F9AF; Fri, 21 May 2021 14:19:51 -0400 (EDT) From: Michael Richardson To: "Murray S. Kucherawy" , Spencer Dawkins at IETF , Codec Encoding for LossLess Archiving and Realtime transmission In-Reply-To: References: <21441.1620656178@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] [ietf-wg-cellar/ebml-specification] EBML ID 0x80 is marked invalid/reserved but it's used in Matroska (#407) 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, 21 May 2021 18:19:59 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Murray S. Kucherawy wrote: > It's possible I don't have all the context I need here, in which case > this answer will be nonsense and I'll need ask for more details, but > running with what I've got: I think you got it right. > I think you could do an "updates" document to EBML that just makes IA= NA > registry/policy amendments if you want to do that. Smaller documents > tend to result in faster processing by the IESG. The cases where this > tends not to work is where the number of "updates" documents gets lar= ge > enough that teasing out reality becomes difficult; at that point it > becomes better to just issue a complete "bis" document. I think we are still in the updates space. > If you put EBML-specific IANA actions in the Matroska document, and > they are not clearly related, you might encounter some resistance of > the form "What the heck is this doing here?" from the IESG or other > reviewers. I think we have slightly bit more than than the IANA action changes. I think that we should do this updates document, but not rush it, aiming to get it to IESG by the end of the summer. I think it will be about four pages long. =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+93Q3WUFAmCn+ccACgkQgItw+93Q 3WV63Qf7B1Xfx3B1H4UkjMEksKPznxSyXnuNF89sdiHEqYGoSqTzog7wjEH9NtxJ nJrZQqt8c9GdshGqr/Re+77HDHz/qvhqdmpR/2TA1fcg6djr9+LGaODJrT3KoaFp XJuXynl4dxOdo3XHIBZxym+sMVmqNGquCZGyaGI9ZT66NzY1gUZ4F4bOh+gmjlAy /yH1sATxqpEMv5QweFy7bpmSKyPCJSeX+ivtuH4ys0yqEu1WU74eOQfwne6hp1WC J/s0Ua61PObEFs4GI0apqLtsXkNsuv9VRiKtp8KxTwYVE7rmJ+G1Db64g5EyZ+3+ WMmmEAgHpe0n983YH6x80DSSn4n36A== =BCPp -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri May 21 13:33:21 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 E1A903A1FA1 for ; Fri, 21 May 2021 13:33:17 -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 YSmBfi45AWWn for ; Fri, 21 May 2021 13:33:13 -0700 (PDT) Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (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 B48903A1F9F for ; Fri, 21 May 2021 13:33:12 -0700 (PDT) Received: by mail-yb1-xb36.google.com with SMTP id b13so27762110ybk.4 for ; Fri, 21 May 2021 13:33:12 -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=SEEnOPxBrNdlWNEUq1epUHDiYvawERk+SWPKtx+a8bg=; b=RJGoRF+VzrQMe8AIbbbD9njV+rPfux3sw2Y+GpSC1uzOCx9OtkKMMVV/V+/F6iWno+ 9SYIL7yAb9E0gpGWmZo+Xct3QaCcumTWF4PELV58J3s0r4QMWtKsXQR0EckLyRpK+Qgc D4lrE7TQsUcIY3KUdK3e6gxVGs/90zeTDycoLed0zahdVyeqTxjaSde+Frdc9d+41r+y ySyJZkuUy+Wn6MG9uMXSf3wOWNvdEwH8/tV/6aNpOgZfpC0EsOvWLm5ahDEtEJv3oJjW rIou/HAHVrPOxzHE39Fv5f/iyu8jGgqJDXbSOuNrXAw3II+Ux3M5AYC6DnQxMSbEjkaS +1Gg== 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=SEEnOPxBrNdlWNEUq1epUHDiYvawERk+SWPKtx+a8bg=; b=bO4YxFHY8FU02hZIx5/+EsaXo7EPwLErE2sRzceYIcQ/ucHYd5c6/KioARpysmRld+ CDH58As4XYadWoM8azOVuKhOqKwMnB9S5f97OZwg1wyxkzK1wRySwlQC61HGPhrkKO85 JOWG2IGY7ghBIMS6o0uZqFHTSLLBaJrox5CwZ8pbTSDxgBCcY0Cnn8lp942/rYyXA8fo KX+BSphl9MNRHpHq9uJDP6vS0utOTRcUh6racyl6xBeqmy6NDz4dcxYC3Lg13NhIa3r5 hUggPSoupz7oR++wC/d4T+jiHPbDGVgl/NrNRxgU5YVNhV0gK8BD3966Ncc9DiL3+wGm dbCA== X-Gm-Message-State: AOAM530g4flb9bNYEM5Q+SJX3a9Yjcs3ptuZ+qQ/DuzNuUXp/mE2CA2x lSBhSKdss4AaXgpPYlpnvLaM4E+1iJEJKGw8DuNqVFAfIrL2og== X-Google-Smtp-Source: ABdhPJyI3RY93cq9HFFxn3gaP+aKQTFu46O/WrXsHHktOqH4H7bCypZ5yR6LYSLjsCFvNOWejxptve0dgBXw4drqijE= X-Received: by 2002:a25:5d0b:: with SMTP id r11mr16742243ybb.380.1621629190593; Fri, 21 May 2021 13:33:10 -0700 (PDT) MIME-Version: 1.0 From: Spencer Dawkins at IETF Date: Fri, 21 May 2021 15:32:44 -0500 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="000000000000dce05705c2dcf7bc" Archived-At: Subject: [Cellar] Draft Agenda for metting on 25 May, 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: Fri, 21 May 2021 20:33:18 -0000 --000000000000dce05705c2dcf7bc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear All, Please let me know if we need to make any changes. Best. Spencer CELLAR =E2=80=93 DRAFT AGENDA for Virtual Interim Meeting May 25, 2021 21:00 Amsterdam *** 20:00 UTC 16:00 NYC 13:00 San Francisco (*** Time is anchored to Amsterdam) INFO: https://github.com/ietf-wg-cellar/chair-notes/tree/master/interim-2021-05 (*** Note that we=E2=80=99re now pointing to the Github repo for chair note= s here***) 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.) Attendees - Spencer Dawkins Regrets - (possibly) Michael Richardson 1. Note Well. https://www.ietf.org/about/note-well/ 2. Accept draft minutes from previous meeting (attached below) objections asked for, and none received 3. Logistics for Meeting. 3a) 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. 3b) APPEAR.IN is now called =E2=80=9Cwhereby.com=E2=80= =9D https://whereby.com/cellar-interim 3c) Roll call 1. 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 - draft-ietf-cellar-ffv1-v4-16 was posted 2020-12-01, in ID Exists - draft-ietf-cellar-flac-01 was posted 2021-04-27, in ID Exists (thank you, Dave, for submitting this) - 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 1. Milestone review: - Matroska maybe at the end of Summer 2021? It=E2=80=99s closer than we = thought Action: we=E2=80=99re making a lot of progress on this - we just need to fi= gure out where we are - 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. Dave is working on https://github.com/ietf-wg-cellar/Cellar-FLAC/pull/92= , making changes for XML2RFCv3 and making sure we have valid authors (not organizations) with email addresses (by working group last call) - FFV1-v4 requires more research, and it is unclear when we will know what a realistic goal date is. 1. 2021 virtual interim meeting dates - Please note our 2021 dates listed at https://datatracker.ietf.org/wg/cellar/meetings/ - IETF 111 in July will definitely be virtual (announced last week). - 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. 1. From the mailing list: From Steve, on EBML errata - Spencer thought we submitted errata last time, but https://www.rfc-editor.org/errata_search.php?rfc=3D8794&rec_status=3D15&= presentation=3Dtable doesn=E2=80=99t show any errata of any status - did this happen? - We have 2 merged changes and 2 pending changes in Github - In mailing list discussion, we think we have about four pages of text, with the identified errata, and the change to IANA instructions - Murray said that=E2=80=99s likely fine as an Updates RFC, rather than = a much bigger RFC that replaces RFC 8794 - Are we OK with producing a short RFC that would update the EBML RFC, probably around end-of-summer? 1. From the mailing list: From Steve, on Matroska #495 section reorderin= g - Steve rebuilt the txt/html files and sent before/after to the mailing list - Are we all happy with this? - Do we need to do anything else? 1. FFV1 v4 issues - Last month, we said we need some working group time to brainstorm on v4 - we can do this as a meeting, on the mailing list, or more broadly - What would a good plan look like? Can we schedule that time now? - Jerome said he would start work on the Introduction (added as an issue= ) - 1. Matroska issues - 1. FLAC issues - AOB? NEXT MEETING June 22, 2021. Notes from previous meeting for approval CELLAR =E2=80=93 DRAFT AGENDA for Virtual Interim Meeting April 27, 2021 21:00 Amsterdam *** 20:00 UTC 16:00 NYC 13:00 San Francisco (*** Time is anchored to Amsterdam) INFO: https://github.com/ietf-wg-cellar/chair-notes/tree/master/interim-2021-04 (*** Note that we=E2=80=99re now pointing to the Github repo for chair note= s here***) 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.) Attendees - Spencer Dawkins - Michael Richardson - J=C3=A9r=C3=B4me Martinez - Michael Niedermeyer - Dave Rice - Martin Below Regrets - (possibly) Mortiz Bunkus 1. Note Well. https://www.ietf.org/about/note-well/ 2. Accept draft minutes from previous meeting (attached below) objections asked for, and none received 3. Logistics for Meeting. 3a) 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. 3b) APPEAR.IN is now called =E2=80=9Cwhereby.com=E2=80= =9D https://whereby.com/cellar-interim 3c) Roll call 1. 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 - draft-ietf-cellar-ffv1-v4-16 was posted 2020-12-01, 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 - draft-ietf-cellar-flac-00 was posted 2019-07-30, has Expired (and we still don=E2=80=99t have an editor, correct?) 1. Milestone review: - Michael has requested that the RFC Editor move the FFv1 normative reference to Matroska informative, and this has happened. Do we also nee= d to move two other normative references in FFv1 to informative? Action: Michael will send email to AD and RFC-Editor requesting this, so we won=E2=80=99t have to talk about this in AUTH48 DONE. - Matroska maybe at the end of Summer 2021? It=E2=80=99s closer than we = thought Action: we=E2=80=99re making a lot of progress on this - we just need to fi= gure out where we are - =E2=80=9CMatroska=E2=80=9D includes -codec and -tags, correct? Spencer h= as updated this in the datatracker. - FLAC just needs an editor to complete the work. Michael still hasn=E2=80= =99t heard from Florin, so the working group has a decision to make about FLA= C. Action: Dave will submit an update on this. We need to chase Florin down and get an answer. Dave is working on https://github.com/ietf-wg-cellar/Cellar-FLAC/pull/92, making changes for XML2RFCv3 and making sure we have valid authors (not organizations) with email addresses (by working group last call) - FFV1-v4 requires more research, and it is unclear when we will know what a realistic goal date is. 1. 2021 virtual interim meeting dates - Please note our 2021 dates listed at https://datatracker.ietf.org/wg/cellar/meetings/ - IETF 111 in July will definitely be virtual (announced last week). - 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. 1. From the mailing list: From Steve, on EBML errata - we have 2 merged changes and 2 pending changes in Github - What needs to happen next? - https://www.rfc-editor.org/errata.php#reportnew - On the call - we=E2=80=99re submitting the pending changes in the erra= ta system 1. From the mailing list: From Steve, on Matroska #495 section reorderin= g - Steve volunteered to rebuild the txt/html files and send before/after to the mailing list - Do we need to do anything else? - No other action needed - Action: Steve, please proceed as you suggested! 1. FFV1 v4 issues * No work on FFV4 to report this month * Status: somewhat stalled at the moment. We=E2=80=99ve mostly collected information for v4 while working on the v1-v3 document, and need some brainstorming time. * We think getting the v1-v3 document will help gather critical mass in the working group. * We do need some working group time to brainstorm on v4 - we can do this as a meeting, on the mailing list, or more broadly. * What are the goals for v4? Compressed frames that expand are already in v4. We=E2=80=99ve identified some bugs, and we have some ideas in Git= hub. We have a requirement for another color scheme (two greens) * Starting to focus on the Introduction would also be useful (added as an issue) - Jerome will start work on this * We can put ideas in the Introduction first, and then either add them to the spec or remove them from the Introduction as work proceeds. 2. Matroska issues - 1. FLAC issues - Michael has reached out to Florin to see about his interest in helping with this document, but we don=E2=80=99t have an answer from him. - no response to email April 27. ACTION: Dave will repost flac document with new version number. DONE during the meeting. AOB? --000000000000dce05705c2dcf7bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,

Please let me know if we need= to make=C2=A0any changes.

Best.

Spencer

CELLAR =E2=80=93 DRAFT AGENDA for Virtual Interim Meeting
May 25, 2021 21:00 Amsterdam ***
20:00 UTC
16:00 NY= C
13:00 San Francisco
(*** Time is anchored to Amsterdam)

INFO:
ht= tps://github.com/ietf-wg-cellar/chair-notes/tree/master/interim-2021-05=
(*** Note that we=E2=80=99re now pointi= ng to the Github repo for chair notes here***)

WEB CONFERENCE:

https://whereby.com/cella= r-interim

THERE IS NO T= ELEPHONE DIALIN (You can try connecting to the=C2=A0whereby.com=C2=A0link at any time.)

Attendees

  • Spencer Dawkins

Regrets

  • (poss= ibly) Michael Richardson

  1. Note Well.= =C2=A0https://www.ietf.org/abou= t/note-well/

  2. Acc= ept draft minutes from previous meeting (attached below)
    objections asked for, and none received

  3. Logistics for Meeting.
    3a) Shared COMIMD for notetaking:
    https://c= odimd.ietf.org/notes-cellar-virtual

    • Note that if you log in to the IETF datatra= cker, you=E2=80=99ll
      be able to edit the= se notes, add your name to attendee
      list= s, etc. *

    Pleas= e ask Spencer if you have questions.

3b)=C2=A0APPEAR.IN=C2=A0is = now called =E2=80=9Cwhereby.com=E2=80=9D

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

3c) Roll call

=
  1. WG statu= s update
  • dr= aft-ietf-cellar-codec-06 was posted 2021-04-12, in ID Exists
  • draft-ietf-ce= llar-ffv1-20 was posted 2021-02-23, is now in RFC Editor Queue
  • draft-ietf-c= ellar-ffv1-v4-16 was posted 2020-12-01, in ID Exists
  • draft-ietf-cellar-flac= -01 was posted 2021-04-27, in ID Exists (thank you, Dave, for submitting th= is)
  • draft-ietf-cellar-matroska-07 was posted 2021-04-12, in ID Exists
    • <= li class=3D"gmail-" style=3D"box-sizing:border-box;margin-top:0.25em">draft= -ietf-cellar-tags-06 was posted 2021-04-12, in ID Exists
  1. Milestone review:=
  • Matroska m= aybe at the end of Summer 2021? It=E2=80=99s closer than we thought

    • Action: we=E2=80=99re making= a lot of progress on this - we just need to figure out where we are

    <= li class=3D"gmail-" style=3D"box-sizing:border-box">

    FLAC still needs an editor to complete the work= . Michael did hear back from Florin, and he=E2=80=99s unable to serve as ed= itor, so the working group has a decision to make about FLAC.
    Dave is working on=C2=A0https://github.com/ietf-wg-cellar/Cellar-FLA= C/pull/92, making changes for XML2RFCv3 and making sure we have valid a= uthors (not organizations) with email addresses (by working group last call= )

  • FFV1-v4 requires m= ore research, and it is unclear when we will know what a realistic goal dat= e is.

  1. 2021 virtual interim meeting dates
  • Please note our 2021 dates listed at=C2= =A0https://datatrack= er.ietf.org/wg/cellar/meetings/
  • IETF 111 in July will definitely be vir= tual (announced last week).
  • Sometime around 2021-09-28, we=E2=80=99ll see i= f we want to meet at IETF 112 on November 6-12, 2021, in person in Madrid.<= /li>
  1. From the mailing list: From Steve, on EBML errata
  • Spencer thought we submitted errata= last time, but=C2=A0https://www.rfc-editor= .org/errata_search.php?rfc=3D8794&rec_status=3D15&presentation=3Dta= ble=C2=A0doesn=E2=80=99t show any errata of any status - did this happe= n?
  • We have 2 merged changes and 2 pending changes in Github
  • In mailing li= st discussion, we think we have about four pages of text, with the identifi= ed errata, and the change to IANA instructions
  • Murray said that=E2=80=99s l= ikely fine as an Updates RFC, rather than a much bigger RFC that replaces R= FC 8794
  • Are we OK with producing a short RFC that would update the EBML RFC= , probably around end-of-summer?
  1. From the mailing list: From Steve, on Mat= roska #495 section reordering
  • Steve rebuilt the txt/html files and sent before/after t= o the mailing list
  • Are we all happy with this?
  • Do we need to do anything el= se?
  1. FFV1 v4 issues
  • Last month, we said we need some working group time to brainstorm = on v4 - we can do this as a meeting, on the mailing list, or more broadly
  • W= hat would a good plan look like? Can we schedule that time now?
  • Jerome said= he would start work on the Introduction (added as an issue)
  • Matroska is= sues
    • <= /ul>
      1. FLA= C issues

      AOB?

      Notes from previo=
us meeting for approval
      CEL=
LAR =E2=80=93 DRAFT AGENDA for Virtual Interim Meeting
      April 27, 2021 21:00 Amsterdam ***
      20:00 UTC
      16:00 NYC
      13:00 San Francisco
      (*** Time is anchored to Amsterdam)
      INFO:
      https://gith=
ub.com/ietf-wg-cellar/chair-notes/tree/master/interim-2021-04
      (*** Note that we=E2=80=99re 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=C2=A0whereb=
y.com=C2=A0link at any time.)
      Attendees
      • =
Spencer Dawkins
      • Michael Richardson
      • J=C3=A9r=C3=B4me Martinez
      • Michael Niede=
rmeyer
      • Dave Rice
      • Martin Below
      Regrets
      • =
(possibly) Mortiz Bunkus
      1. Note Well.=
=C2=A0https://www.ietf.org/abou=
t/note-well/
      2. Acc=
ept draft minutes from previous meeting (attached below)
        objections asked for, and none received
      3. Logistics for Meeting.
        3a) Shared COMIMD for notetaking:
        https://c=
odimd.ietf.org/notes-cellar-virtual
        • Note that if you log in to the IETF datatra=
cker, you=E2=80=99ll
          be able to edit the=
se notes, add your name to attendee
          list=
s, etc. *
        Pleas=
e ask Spencer if you have questions.
      3b)=C2=A0APPEAR.IN=C2=A0is =
now called =E2=80=9Cwhereby.com=E2=80=9D
         https://=
whereby.com/cellar-interim

      3c) Roll call
      =

      1. WG statu=
s update
      • dr=
aft-ietf-cellar-codec-06 was posted 2021-04-12, in ID Exists
      • draft-ietf-ce=
llar-ffv1-20 was posted 2021-02-23, is now in RFC Editor Queue
      • draft-ietf-c=
ellar-ffv1-v4-16 was posted 2020-12-01, in ID Exists
      • draft-ietf-cellar-matr=
oska-07 was posted 2021-04-12, in ID Exists
      • draft-ietf-cellar-tags-06 was =
posted 2021-04-12, in ID Exists
      • draft-ietf-cellar-flac-00 was posted 2019-0=
7-30, has Expired (and we still don=E2=80=99t have an editor, correct?)
      1. Mi=
lestone review:
      • Michael has requested that the RFC Editor move the FFv1 normative refe=
rence to Matroska informative, and this has happened. Do we also need to mo=
ve two other normative references in FFv1 to informative?
      Action: Michael will send email to AD =
and RFC-Editor requesting this, so we won=E2=80=99t have to talk about this=
 in AUTH48
      DONE.
      • Matroska maybe at the end of Summer 2021=
? It=E2=80=99s closer than we thought
      Action: we=E2=80=99re making a lot of progress on this - w=
e just need to figure out where we are
      • =
=E2=80=9CMatroska=E2=80=9D includes -codec and -tags, correct? Spencer has =
updated this in the datatracker.
      • FLAC just needs an editor to complete the work. Michael still =
hasn=E2=80=99t heard from Florin, so the working group has a decision to ma=
ke about FLAC.
      Ac=
tion: Dave will submit an update on this.
      We need to chase Florin down and get an answer.
      Dave is working on=C2=A0https://github.com/ietf-wg-cellar/Cellar-FLAC/pull/92, making changes for XML2RFCv3 and making sure we have valid authors (not =
organizations) with email addresses (by working group last call)
      1. 20=
21 virtual interim meeting dates
      1. From the mail=
ing list: From Steve, on EBML errata
      1. Fr=
om the mailing list: From Steve, on Matroska #495 section reordering
        • Steve volunteered=
 to rebuild the txt/html files and send before/after to the mailing list
        • Do=
 we need to do anything else?
        • No other action needed -
          Action: Steve, please proceed as you suggested!
      2. FFV1 v4 issues
        * No work on FFV4 to report this month
        * Status: somewhat stalled at the moment. We=E2=80=99ve mostl=
y collected information for v4 while working on the v1-v3 document, and nee=
d some brainstorming time.
        * We think ge=
tting the v1-v3 document will help gather critical mass in the working grou=
p.
        * We do need some working group time =
to brainstorm on v4 - we can do this as a meeting, on the mailing list, or =
more broadly.
        * What are the goals for v=
4? Compressed frames that expand are already in v4. We=E2=80=99ve identifie=
d some bugs, and we have some ideas in Github. We have a requirement for an=
other color scheme (two greens)
        * Starti=
ng to focus on the Introduction would also be useful (added as an issue) - =
Jerome will start work on this
        * We can =
put ideas in the Introduction first, and then either add them to the spec o=
r remove them from the Introduction as work proceeds.
      3. Matroska issues
      1. FLAC issues
      • Michael has reached out to =
Florin to see about his interest in helping with this document, but we don=
=E2=80=99t have an answer from him.
        • no response to email April 27.
      <=
p class=3D"gmail-part" style=3D"box-sizing:border-box;margin:0px 0px 16px;c=
olor:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,"Segoe=
 UI",Roboto,"Helvetica Neue",Helvetica,Arial,sans-serif,&quo=
t;Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol&=
quot;;font-size:16px;letter-spacing:0.35px">ACTION: Dave will repost flac d=
ocument with new version number.
      DONE du=
ring the meeting.
      AOB?
    --000000000000dce05705c2dcf7bc-- From nobody Sat May 22 04:29:26 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 698A23A2156 for ; Sat, 22 May 2021 04:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.395 X-Spam-Level: X-Spam-Status: No, score=0.395 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, FROM_SUSPICIOUS_NTLD=0.498, PDS_OTHER_BAD_TLD=1.997, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bunkus.online 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 GOsEXSZ8N-TC for ; Sat, 22 May 2021 04:29:16 -0700 (PDT) Received: from liselle.bunkus.org (liselle.bunkus.org [144.76.140.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC8C13A2153 for ; Sat, 22 May 2021 04:29:13 -0700 (PDT) Received: from sweet-chili.int.bunkus.org (sweet-chili.int.bunkus.org [192.168.191.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) (Authenticated sender: email-relay) by liselle.bunkus.org (Postfix) with ESMTPSA id 7F83D110DA49 for ; Sat, 22 May 2021 13:29:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bunkus.online; s=dkim; t=1621682946; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=7vroVyzexkeG/uwpnp7d3nqlpCoUBDHDpSYzM3fVOqA=; b=bNQGjeuuxldNm3V4P7dbNJfYHG94+SV0OH3W1qHcjHlV0Fs7P/z9jKU4fwCZdZUkNgm8MT fXMlCfPuNqzGxQ9UQebAy6V3Cs97IwstFo3fFXxPODMH66BHtq1c+QA6E9Nc1pmv7pht8L /ahgqz21sQfRK/34KzrtSAphjUR3ncU= Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.int.bunkus.org (Postfix) with ESMTP id 277E05D6D7AE for ; Sat, 22 May 2021 13:29:06 +0200 (CEST) References: User-agent: mu4e 1.4.15; emacs 27.1 From: Moritz Bunkus To: cellar@ietf.org In-reply-to: Message-ID: <87sg2f6m7y.fsf@bunkus.online> Date: Sat, 22 May 2021 13:29:06 +0200 MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Cellar] Draft Agenda for metting on 25 May, 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: Sat, 22 May 2021 11:29:25 -0000 Hey, I'd like to add one minor topic for discussion: a possible move for our IRC channel from the Freenode IRC network to another one, preferably libera.chat. There's been a pretty rough shakeup on Freenode this week that has led many Open Source projects to jump ship. I've opened an issue on our infrastructure repo with more details here: https://github.com/Matroska-Org/infrastructure/issues/9 IRC isn't the most important thing, but it is one of our official ways of communication, hence it warrants a group discussion. If anyone wants to learn more about it, please see the following: https://ariadne.space/2021/05/20/the-whole-freenode-kerfluffle/ https://gist.github.com/jesopo/45a3e9cdbe517dc55e6058eb43b00ed9 m. From nobody Sat May 22 05:35:30 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 BD6923A237A for ; Sat, 22 May 2021 05:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.395 X-Spam-Level: X-Spam-Status: No, score=0.395 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, FROM_SUSPICIOUS_NTLD=0.498, PDS_OTHER_BAD_TLD=1.997, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bunkus.online 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 jF2trAh7uaKO for ; Sat, 22 May 2021 05:35:24 -0700 (PDT) Received: from liselle.bunkus.org (liselle.bunkus.org [144.76.140.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8C213A2378 for ; Sat, 22 May 2021 05:35:21 -0700 (PDT) Received: from sweet-chili.int.bunkus.org (sweet-chili.int.bunkus.org [192.168.191.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) (Authenticated sender: email-relay) by liselle.bunkus.org (Postfix) with ESMTPSA id 6BFC1110E472 for ; Sat, 22 May 2021 14:35:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bunkus.online; s=dkim; t=1621686916; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=B+5yuvhcDPCCjQh3sH/tqoTPV2Vdpt2fZUORGXpd+Vs=; b=rdj90J4Cnv/9vnqZtd8ICaxTBNIRnvjPACAhIdb3xCj3eVS3OnDTbl9VzhpGyBc9zdIYPF RY867dxTwhtQg/ycXx79Nu14feNWbpInNYOw7BeN/ylyawf5AL1lkVgiuUdU8NAaySiHtT yFW97L/7y1cGKKg2WBo2yNwo8MyGZbI= Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.int.bunkus.org (Postfix) with ESMTP id 1A6CE5D6F0C2 for ; Sat, 22 May 2021 14:35:16 +0200 (CEST) References: <87sg2f6m7y.fsf@bunkus.online> User-agent: mu4e 1.4.15; emacs 27.1 From: Moritz Bunkus To: cellar@ietf.org In-reply-to: <87sg2f6m7y.fsf@bunkus.online> Message-ID: <87mtsn6j5o.fsf@bunkus.online> Date: Sat, 22 May 2021 14:35:16 +0200 MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Cellar] Draft Agenda for metting on 25 May, 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: Sat, 22 May 2021 12:35:29 -0000 Hey, what I meant to say was: I know this doesn't have anything to do with the specs process, but as we'll be hanging out together anyway this would be a good opportunity to spend a couple of minutes on it if we don't have anything more pressing to discuss. m. From nobody Sat May 22 18:29: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 06EDC3A275E for ; Sat, 22 May 2021 18:29:45 -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, RCVD_IN_DNSWL_BLOCKED=0.001, 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 e0pEAhRwIX_D for ; Sat, 22 May 2021 18:29:40 -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 5E45A3A275D for ; Sat, 22 May 2021 18:29:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 1D22E38B73; Sat, 22 May 2021 21:39:18 -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 HwevygHCawy1; Sat, 22 May 2021 21:39:17 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7BAD938B4A; Sat, 22 May 2021 21:39:17 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0A45367E; Sat, 22 May 2021 21:29:37 -0400 (EDT) From: Michael Richardson To: Moritz Bunkus cc: cellar@ietf.org In-Reply-To: <87sg2f6m7y.fsf@bunkus.online> References: <87sg2f6m7y.fsf@bunkus.online> 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] Draft Agenda for metting on 25 May, 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: Sun, 23 May 2021 01:29:45 -0000 --=-=-= Content-Type: text/plain Moritz Bunkus wrote: > I'd like to add one minor topic for discussion: a possible move for our > IRC channel from the Freenode IRC network to another one, preferably > libera.chat. There's been a pretty rough shakeup on Freenode this week It seems like a good idea. > IRC isn't the most important thing, but it is one of our official ways > of communication, hence it warrants a group discussion. Just to mention that there is also cellar@jabber.ietf.org, available via XMPP, and I think there is still a Matrix and Zulip bridge into it. -- ] 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+93Q3WUFAmCpsAAACgkQgItw+93Q 3WWlKQgAp4Ix5qRIsFxKwNxpWwFWRtD1KZ53MN2hhl8iAhiKpoh7z27xjV94DmX2 LOLrwI/7+bAFZSmdylJxbnVgKF5Egivzni2Bh6g10Or6TqJo64muTfVTaFMlgQHY GUXk5VAPcddnP05ELp6ON5q56qxcnuT93mHdgSIAYdDD6Ew+ht4RmsFbHxb9XEFX +LfoDiBIj19Fgnpsga7NioE0izE3UxczUmUMMc4xq7lSJcfk24+KCeeIffKK5tPe jjIP/8Uc/sRaivCBITrBQYxqpT8z61Kukdm4mTuegKdR0UrwdbILtybB0GyFkmgU cIxeJYcJEzY2anGD7dlT1EZzva+PYg== =JSP3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun May 23 01:06: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 213653A005D for ; Sun, 23 May 2021 01:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 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_DNSWL_LOW=-0.7, 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=fR6sRaXg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GKkanVaW 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 mohsE57R_Okq for ; Sun, 23 May 2021 01:06:07 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A6043A005C for ; Sun, 23 May 2021 01:06:07 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 7FE64FDE for ; Sun, 23 May 2021 03:46:18 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sun, 23 May 2021 03:46:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm2; bh=cLA9YDyvMpn rtHVwvBvWdXaWQzSISzfXA07F0hW6vbY=; b=fR6sRaXgzIWtBtdHFlvF7fFDuaH JurRuz5BzSj42kokxrsihKPhZakAINzWo9hy+AsGWiFrb9O1R2dXjsamvl+0jCQf ihYuW1dK8yA493uyf8KJ0uS9+1i7L1VJqPR+S9SbdJpn2EduF5c5teZTYOxWAlmi Lr0KtQvfs9TByCQXqNqSOYXlVh0iX653XKRt21/yeNGglwmbqG6lNnK5Wflt50hd z2x8Tc3FaVR27fRjei90GbETT2YjF6RGHX+KaXIVSEi2PL/1qPEJBlmGm76vXTpS fNbTtvwoUfHQ8GA2SpHfxGyaaXdmKaSlxOJaEf5x8wzUYI1RtiLS9BKXSIQ== 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= fm2; bh=cLA9YDyvMpnrtHVwvBvWdXaWQzSISzfXA07F0hW6vbY=; b=GKkanVaW qzA/keo+KqcDRcH8r4NcRD7RY3YpgquoHoVCcmzMhvQOGLHjUbWAm2RakiFfK0lt H9vuWz79SZeUc4BRrg6zaBtF+l+0yn4aBhazwMa4x2vMRlICySEjDwQ8JbYThaWK nYYe6PebRh9jf1FZpn2OYxuE2sz0jaD10eszo8vGjhuDUzfDoYYjes/WgC7f/kQw 9WbixyhfFbpUExIoj24vCZuXk794OWEXmKcnC9aiWMwGtmckCLF6Xob7K97hW2ip pa9ArfDfBfK7Gs9e4ck+N7mM8Id8R1VeOFOK4+fMRf7bB19kM0U25Z//APOUVWuR y5MSh+rsj2lKtw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdejiedguddvgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecupfhoucgurghtvgcufhhivghlugculdegledmne cujfgurheptggghffvufesrgdttdertddtjeenucfhrhhomheptfgvphhoshhithhorhih ucettghtihhvihhthicuufhumhhmrghrhicuuehothcuoeguohgpnhhothgprhgvphhlhi esmhhnohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeekfedvudetjedvfeekheeiveeu gfefhfetteevgeffkefffeetffdvleehudeiteenucffohhmrghinhepghhithhhuhgsrd gtohhmnecukfhppedvfedruddtvddrudekiedrudehheenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprhgvphhlhiesmhhnoh htrdhnvght X-ME-Proxy: Received: from fv-az290-665.z45yk40qnouupoc55gb0v1wkoc.jx.internal.cloudapp.net (unknown [23.102.186.155]) by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 23 May 2021 03:46:16 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============7650351312781332060==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20210523080607.5A6043A005C@ietfa.amsl.com> Date: Sun, 23 May 2021 01:06:07 -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, 23 May 2021 08:06:12 -0000 --===============7650351312781332060== 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/matroska-specification (+0/-0/=F0=9F=92=AC2) 1 issues received 2 new comments: - #422 Consider providing a facility for integer-fraction timescales (2 b= y Xaymar, mkver) https://github.com/ietf-wg-cellar/matroska-specification/issues/422 [cl= arifications] [format addition] [spec_main] [spec_tags]=20 Pull requests ------------- * ietf-wg-cellar/matroska-specification (+2/-0/=F0=9F=92=AC4) 2 pull requests submitted: - Expand the tocdepth to 4 (by robUx4) https://github.com/ietf-wg-cellar/matroska-specification/pull/513 [form= atting]=20 - mark the markdown/xml/output as IETF standards (by robUx4) https://github.com/ietf-wg-cellar/matroska-specification/pull/512 [buil= d system] [clarifications]=20 1 pull requests received 4 new comments: - #495 Reorder/Reparent sections in the Matroska RFC (4 by SpencerDawkins= , robUx4) https://github.com/ietf-wg-cellar/matroska-specification/pull/495 [form= atting] [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 --===============7650351312781332060== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

    Sunday May 23, 2021

    Events without label "editorial"

    Issues

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

    1 issues received 2 new comments:

    Pull requests

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

    2 pull requests submitted:

    1 pull requests received 4 new comments:

    Repositories tracked by this digest:

    --===============7650351312781332060==-- From nobody Sun May 23 15:50:32 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 1C2383A292A for ; Sun, 23 May 2021 15:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 fwwYDIv-riBy for ; Sun, 23 May 2021 15:50:25 -0700 (PDT) Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) (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 748623A292B for ; Sun, 23 May 2021 15:50:25 -0700 (PDT) Received: by mail-yb1-xb35.google.com with SMTP id r7so13421555ybs.10 for ; Sun, 23 May 2021 15:50:25 -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=lATvRoB+vk+LexYiXFMEfNUcwyRJL8TnUES20tG72Sw=; b=llGCex8To4XInuJyjxXx5KdoH8piVoJxH251YbymA+dgX4KjUni5qCVXQ1wTGoIAdf b2klesI7wVKPVXRfunVqwfbspcjetYVVRd7rW3p6ACzuIimz47QOn0Yk/g5exa1gH2a/ wjyrsJWnAnzbDrGaFYrWsTOQOzHI+r1x8TN3f0UyyvXSU4nm9Sl2mXlzxbfVOFaF/aAA avVsGdCGbtjyVjt9C867m61FTHdJ1JQhYr2UZdoS1guaAzdVgiZaBfB3vfQp0vwogn/I UhMjFfoc57+mYJlA6B55FhSMiH3MHApmm5XXQJ628vVJaIP9h5SHst7jOeI5rb2F/Kdz bI9g== 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=lATvRoB+vk+LexYiXFMEfNUcwyRJL8TnUES20tG72Sw=; b=YY0ymMIiQ5Pk/M54r5xLCNM5wIj4W64ps0iUM0QluKmTMVwkoiNS2+DD+reujHTBYh NCxYMWFBBu4Ep0oIpY2cQCz2zanfoAdgnYbPQlA/Uf70clycXfT/rCGYMF5bVzVbQrdV hR1b5IrGkAcTkJOj4VnYUc+J5LLP9de7lhyNIYdl7RAX23Q6wR6Aa+dSYmGPKjQd5IcI i87hOVnNlxTY55ElbcqGd5EddSPpBnZt3rV8F+rIKcE50aJRHEVasJR/r9vKX0XUXWXH CBNbeTxxktyIYVDB7CVh0CYrX9oQMJtkwCV1yKrdrwozFufXes+wWF4aiqOzQsWtcsAy 15qQ== X-Gm-Message-State: AOAM531KPqnPtyM9EvA950nuXv9EAtEUMH/Rio+rPLr8KR+ZIYQGyxDG 7UlO2FzPESo1Pn1V4lLIBkklkaK2eg6fhZdUhDhowP78FXf1fg== X-Google-Smtp-Source: ABdhPJz+c+RIBs32z+rcnRecLKfrtq9taiv2/+qpyEDJLbPPdgCfhKIMgdhCRNpKV6hxgD+ezBffIyiCj57gffsRIsQ= X-Received: by 2002:a05:6902:54c:: with SMTP id z12mr30753725ybs.389.1621810223819; Sun, 23 May 2021 15:50:23 -0700 (PDT) MIME-Version: 1.0 References: <87sg2f6m7y.fsf@bunkus.online> <1743.1621733377@localhost> In-Reply-To: <1743.1621733377@localhost> From: Spencer Dawkins at IETF Date: Sun, 23 May 2021 17:49:57 -0500 Message-ID: To: Michael Richardson Cc: Moritz Bunkus , Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="00000000000048ade905c3071e58" Archived-At: Subject: Re: [Cellar] Draft Agenda for metting on 25 May, 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: Sun, 23 May 2021 22:50:30 -0000 --00000000000048ade905c3071e58 Content-Type: text/plain; charset="UTF-8" Moritz/Michael, On Sat, May 22, 2021 at 8:29 PM Michael Richardson wrote: > > Moritz Bunkus wrote: > > I'd like to add one minor topic for discussion: a possible move for > our > > IRC channel from the Freenode IRC network to another one, preferably > > libera.chat. There's been a pretty rough shakeup on Freenode this > week > > It seems like a good idea. > > > IRC isn't the most important thing, but it is one of our official > ways > > of communication, hence it warrants a group discussion. > > Just to mention that there is also cellar@jabber.ietf.org, available via > XMPP, and I think there is still a Matrix and Zulip bridge into it. > I added this as a one-time 3d) in the agenda: "Changes to logistics (IRC, Jabber, Whereby, Meetecho ...)" Michael and I are told that the IETF will be providing Meetecho as a conferencing system for virtual interim meetings. We wanted to talk to the group about switching from Whereby, so this will also be a good place to chat about that for a moment. Best, Spencer --00000000000048ade905c3071e58 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Moritz/Michael,=C2=A0

    On Sat, May 22, 2021= at 8:29 PM Michael Richardson <mcr@= sandelman.ca> wrote:

    Moritz Bunkus <mo=3D40bunkus.online@dmarc.ietf.org> wrote:
    =C2=A0 =C2=A0 > I'd like to add one minor topic for discussion: a po= ssible move for our
    =C2=A0 =C2=A0 > IRC channel from the Freenode IRC network to another one= , preferably
    =C2=A0 =C2=A0 > libera.chat. There's been a pretty rough shakeup on = Freenode this week

    It seems like a good idea.

    =C2=A0 =C2=A0 > IRC isn't the most important thing, but it is one of= our official ways
    =C2=A0 =C2=A0 > of communication, hence it warrants a group discussion.<= br>
    Just to mention that there is also cellar@jabber.ietf.org, available via
    XMPP, and I think there is still a Matrix and Zulip bridge into it.

    I added this as a one-time 3d) in the agenda: = "Changes to logistics (IRC, Jabber, Whereby, Meetecho ...)"
    =

    Michael and I are told that the IETF will be providing = Meetecho as a conferencing system for virtual interim meetings. We wanted t= o talk to the group about switching from Whereby, so this will also be a go= od place to chat about that for a moment.=C2=A0

    Be= st,

    Spencer
    --00000000000048ade905c3071e58-- From nobody Tue May 25 12:04:50 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 26CCD3A19B7 for ; Tue, 25 May 2021 12:04:49 -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 qGJCCofZagi1 for ; Tue, 25 May 2021 12:04:43 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 41C8A3A19AB for ; Tue, 25 May 2021 12:04:43 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id n17-20020a7bc5d10000b0290169edfadac9so4289125wmk.1 for ; Tue, 25 May 2021 12:04:43 -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=yYdPgRm81hMLxUJk5s+KBmp1/u5OQ2NahLJvx23KJhM=; b=G4oZx4S6oEO4SQr5RgnIoaMUbnsmrHoxeU0PR5cISUTDyEuzPDTV7AlXcPh5/jZYVk Qpc8ICKgO1XBoxFhite1LdiU/bb1UccHPM4qWoGgvlf2acJNTjr8ieBFUWOv2O+LwoQX nibnqt0Vy44lP8VaElex0kqztcON0GpweHqBuV8KBSDXQ6irFQb/lec07Kh6pS9KHyC5 6pjWkaOfvx79EAN+gW3w8NhNae12IW33KTCYb4YmzlWO5HT7jQy9l0Jq/x1KyIqIKujK BHuR6Z2uV0L4lZH1f/y0DmcKrxj2Of+GqaN+Aqi3l4cBwB3XYKRhTrCHvUO7QZkax+uA ti7Q== 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=yYdPgRm81hMLxUJk5s+KBmp1/u5OQ2NahLJvx23KJhM=; b=sZQ2ftAiVNJVPSiZtooJpXsQdVCCXai/TFrYEG8dA9BKof4xB/n+6DGwYJurUvTo1o Hm2WHkxqoXDVRwqcwfy6cmQaA8WrWQMXQoJhotBZNtlPwxIqD80LvGxVqBtAzmYYsZtt I5Al1v7Yh0WvaAsTq+ATxCbiuG6AQNwL5qfcIe07sLVMEpFszmbFoGOW9b8FezztjETL TV9pFdIdbX4acN4GOe6TLFqHoPTtEt1k+tfBBG2YBwz3pNTsgIE96lizA2XWXPW4j26C 7fiDwfs7j3bJ+2cYmJ9MFftvzqUYH5uGWE/FtrdeU3SbP8QRypH0QXG8Gkr6ENFajCKr RVUg== X-Gm-Message-State: AOAM530GtAwB86LQ2Ny2EtaVY7AEBHeFTrS6bZ3GqrUElV6qLiyWJsWw f3AgqTBq9E7wdQTB5c1flBZKefSdmSM3GjC1 X-Google-Smtp-Source: ABdhPJzGGU+ztPwz8ne0WkbLqW9aB8YDZvNdDxnbu6pbkeaOTRs9uW4CTIqCkjD3SKScwZsMqvqVxA== X-Received: by 2002:a05:600c:21c3:: with SMTP id x3mr24731575wmj.131.1621969480894; Tue, 25 May 2021 12:04:40 -0700 (PDT) Received: from ?IPv6:2a01:cb0c:20:e900:f83d:c9d:b02e:cc4e? (2a01cb0c0020e900f83d0c9db02ecc4e.ipv6.abo.wanadoo.fr. [2a01:cb0c:20:e900:f83d:c9d:b02e:cc4e]) by smtp.gmail.com with ESMTPSA id z17sm19763327wrt.81.2021.05.25.12.04.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 25 May 2021 12:04:40 -0700 (PDT) To: cellar@ietf.org References: From: Steve Lhomme Message-ID: <98610292-5c64-3519-479c-439efafe2c6d@matroska.org> Date: Tue, 25 May 2021 21:04:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] Draft Agenda for metting on 25 May, 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, 25 May 2021 19:04:49 -0000 This time I got the time AND date right. It's is on. On 2021-05-21 22:32, Spencer Dawkins at IETF wrote: > Dear All, >=20 > Please let me know if we need to make=C2=A0any changes. >=20 > Best. >=20 > Spencer >=20 > CELLAR =E2=80=93 DRAFT AGENDA for Virtual Interim Meeting > May 25, 2021 21:00 Amsterdam *** > 20:00 UTC > 16:00 NYC > 13:00 San Francisco > (*** Time is anchored to Amsterdam) >=20 > INFO: > https://github.com/ietf-wg-cellar/chair-notes/tree/master/interim-2021-= 05 > (*** Note that we=E2=80=99re now pointing to the Github repo for chair = notes=20 > here***) >=20 > WEB CONFERENCE: >=20 > https://whereby.com/cellar-interim = >=20 > THERE IS NO TELEPHONE DIALIN (You can try connecting to the whereby.com= =20 > =C2=A0link at any time.) >=20 > Attendees >=20 > * Spencer Dawkins >=20 > Regrets >=20 > * (possibly) Michael Richardson >=20 > 1. >=20 > Note Well. https://www.ietf.org/about/note-well/ > >=20 > 2. >=20 > Accept draft minutes from previous meeting (attached below) > objections asked for, and none received >=20 > 3. >=20 > Logistics for Meeting. > 3a) Shared COMIMD for notetaking: > https://codimd.ietf.org/notes-cellar-virtual > >=20 > * 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. * >=20 > Please ask Spencer if you have questions. >=20 > 3b) APPEAR.IN =C2=A0is now called =E2=80=9Cwhereby.c= om=20 > =E2=80=9D >=20 > |https://whereby.com/cellar-interim | >=20 > 3c) Roll call >=20 > 4. WG status update >=20 > * 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 > * draft-ietf-cellar-ffv1-v4-16 was posted 2020-12-01, in ID Exists > * draft-ietf-cellar-flac-01 was posted 2021-04-27, in ID Exists (than= k > you, Dave, for submitting this) > * 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 >=20 > 5. Milestone review: >=20 > * Matroska maybe at the end of Summer 2021? It=E2=80=99s closer than = we thought >=20 > Action: we=E2=80=99re making a lot of progress on this - we just need t= o figure=20 > out where we are >=20 > * >=20 > 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 th= e working > group has a decision to make about FLAC. > Dave is working on > https://github.com/ietf-wg-cellar/Cellar-FLAC/pull/92 > , making > changes for XML2RFCv3 and making sure we have valid authors (not > organizations) with email addresses (by working group last call) >=20 > * >=20 > FFV1-v4 requires more research, and it is unclear when we will know= > what a realistic goal date is. >=20 > 5. 2021 virtual interim meeting dates >=20 > * Please note our 2021 dates listed at > https://datatracker.ietf.org/wg/cellar/meetings/ > > * IETF 111 in July will definitely be virtual (announced last week). > * 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. >=20 > 6. From the mailing list: From Steve, on EBML errata >=20 > * Spencer thought we submitted errata last time, but > https://www.rfc-editor.org/errata_search.php?rfc=3D8794&rec_status=3D= 15&presentation=3Dtable > =C2=A0doesn=E2=80=99t > show any errata of any status - did this happen? > * We have 2 merged changes and 2 pending changes in Github > * In mailing list discussion, we think we have about four pages of > text, with the identified errata, and the change to IANA instructio= ns > * Murray said that=E2=80=99s likely fine as an Updates RFC, rather th= an a much > bigger RFC that replaces RFC 8794 > * Are we OK with producing a short RFC that would update the EBML RFC= , > probably around end-of-summer? >=20 > 7. From the mailing list: From Steve, on Matroska #495 section reorde= ring >=20 > * Steve rebuilt the txt/html files and sent before/after to the > mailing list > * Are we all happy with this? > * Do we need to do anything else? >=20 > 8. FFV1 v4 issues >=20 > * Last month, we said we need some working group time to brainstorm o= n > v4 - we can do this as a meeting, on the mailing list, or more broa= dly > * What would a good plan look like? Can we schedule that time now? > * Jerome said he would start work on the Introduction (added as an is= sue) > * >=20 > 9. Matroska issues >=20 > * >=20 > 10. FLAC issues >=20 > * >=20 > AOB? >=20 > |NEXT MEETING June 22, 2021. | >=20 > Notes from previous meeting for approval >=20 > CELLAR =E2=80=93 DRAFT AGENDA for Virtual Interim Meeting > April 27, 2021 21:00 Amsterdam *** > 20:00 UTC > 16:00 NYC > 13:00 San Francisco > (*** Time is anchored to Amsterdam) >=20 > INFO: > https://github.com/ietf-wg-cellar/chair-notes/tree/master/interim-2021-= 04 > (*** Note that we=E2=80=99re now pointing to the Github repo for chair = notes=20 > here***) >=20 > WEB CONFERENCE: >=20 > https://whereby.com/cellar-interim = >=20 > THERE IS NO TELEPHONE DIALIN (You can try connecting to the whereby.com= =20 > =C2=A0link at any time.) >=20 > Attendees >=20 > * Spencer Dawkins > * Michael Richardson > * J=C3=A9r=C3=B4me Martinez > * Michael Niedermeyer > * Dave Rice > * Martin Below >=20 > Regrets >=20 > * (possibly) Mortiz Bunkus >=20 > 1. >=20 > Note Well. https://www.ietf.org/about/note-well/ > >=20 > 2. >=20 > Accept draft minutes from previous meeting (attached below) > objections asked for, and none received >=20 > 3. >=20 > Logistics for Meeting. > 3a) Shared COMIMD for notetaking: > https://codimd.ietf.org/notes-cellar-virtual > >=20 > * 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. * >=20 > Please ask Spencer if you have questions. >=20 > 3b) APPEAR.IN =C2=A0is now called =E2=80=9Cwhereby.c= om=20 > =E2=80=9D >=20 > |https://whereby.com/cellar-interim | >=20 > 3c) Roll call >=20 > 4. WG status update >=20 > * 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 > * draft-ietf-cellar-ffv1-v4-16 was posted 2020-12-01, 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 > * draft-ietf-cellar-flac-00 was posted 2019-07-30, has Expired (and w= e > still don=E2=80=99t have an editor, correct?) >=20 > 5. Milestone review: >=20 > * Michael has requested that the RFC Editor move the FFv1 normative > reference to Matroska informative, and this has happened. Do we als= o > need to move two other normative references in FFv1 to informative?= >=20 > Action: Michael will send email to AD and RFC-Editor requesting this, s= o=20 > we won=E2=80=99t have to talk about this in AUTH48 > DONE. >=20 > * Matroska maybe at the end of Summer 2021? It=E2=80=99s closer than = we thought >=20 > Action: we=E2=80=99re making a lot of progress on this - we just need t= o figure=20 > out where we are >=20 > * >=20 > =E2=80=9CMatroska=E2=80=9D includes -codec and -tags, correct? Spen= cer has updated > this in the datatracker. >=20 > * >=20 > FLAC just needs an editor to complete the work. Michael still hasn=E2= =80=99t > heard from Florin, so the working group has a decision to make abou= t > FLAC. >=20 > Action: Dave will submit an update on this. > We need to chase Florin down and get an answer. > Dave is working on https://github.com/ietf-wg-cellar/Cellar-FLAC/pull/9= 2=20 > , making changes= =20 > for XML2RFCv3 and making sure we have valid authors (not organizations)= =20 > with email addresses (by working group last call) >=20 > * FFV1-v4 requires more research, and it is unclear when we will know= > what a realistic goal date is. >=20 > 5. 2021 virtual interim meeting dates >=20 > * Please note our 2021 dates listed at > https://datatracker.ietf.org/wg/cellar/meetings/ > > * IETF 111 in July will definitely be virtual (announced last week). > * 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. >=20 > 6. From the mailing list: From Steve, on EBML errata >=20 > * we have 2 merged changes and 2 pending changes in Github > * What needs to happen next? > * https://www.rfc-editor.org/errata.php#reportnew > > * On the call - we=E2=80=99re submitting the pending changes in the e= rrata system >=20 > 7. From the mailing list: From Steve, on Matroska #495 section reorde= ring >=20 > * Steve volunteered to rebuild the txt/html files and send > before/after to the mailing list > * Do we need to do anything else? > * No other action needed - > Action: Steve, please proceed as you suggested! >=20 > 8. >=20 > FFV1 v4 issues > * No work on FFV4 to report this month > * Status: somewhat stalled at the moment. We=E2=80=99ve mostly coll= ected > information for v4 while working on the v1-v3 document, and need > some brainstorming time. > * We think getting the v1-v3 document will help gather critical mas= s > in the working group. > * We do need some working group time to brainstorm on v4 - we can d= o > this as a meeting, on the mailing list, or more broadly. > * What are the goals for v4? Compressed frames that expand are > already in v4. We=E2=80=99ve identified some bugs, and we have some= ideas in > Github. We have a requirement for another color scheme (two greens)= > * Starting to focus on the Introduction would also be useful (added= > as an issue) - Jerome will start work on this > * We can put ideas in the Introduction first, and then either add > them to the spec or remove them from the Introduction as work proce= eds. >=20 > 9. >=20 > Matroska issues >=20 > * >=20 > 10. FLAC issues >=20 > * Michael has reached out to Florin to see about his interest in > helping with this document, but we don=E2=80=99t have an answer fro= m him. > o no response to email April 27. >=20 > ACTION: Dave will repost flac document with new version number. > DONE during the meeting. >=20 > AOB? >=20 >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar >=20 From nobody Tue May 25 12:52:55 2021 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C4F3A1B57; Tue, 25 May 2021 12:52:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <162197236867.27123.2460011049044161394@ietfa.amsl.com> Date: Tue, 25 May 2021 12:52:48 -0700 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-ffv1-v4-17.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2021 19:52:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Codec Encoding for LossLess Archiving and Realtime transmission WG of the IETF. Title : FFV1 Video Coding Format Version 4 Authors : Michael Niedermayer Dave Rice Jerome Martinez Filename : draft-ietf-cellar-ffv1-v4-17.txt Pages : 58 Date : 2021-05-25 Abstract: This document defines FFV1, a lossless intra-frame video encoding format. FFV1 is designed to efficiently compress video data in a variety of pixel formats. Compared to uncompressed video, FFV1 offers storage compression, frame fixity, and self-description, which makes FFV1 useful as a preservation or intermediate video format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1-v4/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-cellar-ffv1-v4-17.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ffv1-v4-17 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 27 12:38:41 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 1F3A03A0AD0 for ; Thu, 27 May 2021 12:38:39 -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 weVT1f0KdNJ6 for ; Thu, 27 May 2021 12:38:34 -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 709053A0AC8 for ; Thu, 27 May 2021 12:38:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id BA8C238A3C for ; Thu, 27 May 2021 15:48: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 xZX8AR4gKeWf for ; Thu, 27 May 2021 15:48:31 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 1E11E1805B for ; Thu, 27 May 2021 08:39:09 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E8046440 for ; Thu, 27 May 2021 08:29:11 -0400 (EDT) From: Michael Richardson To: cellar@ietf.org X-Attribution: mcr 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: [Cellar] NomCom 2021-2022 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, 27 May 2021 19:38:39 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Please note that the NomCom 2021-2022 Call for Volunteers started today. Changes to the eligibility conditions in 2020 mean that anyone who has published two (or more) RFC in the last five years is eligible. While CELLAR has only one RFC (8794), it is possible that the three authors have worked on other documents so I mention it now. > The IETF NomCom appoints people to fill the open slots on the IETF LLC, > IETF Trust, the IAB, and the IESG. > Ten voting members for the NomCom are selected in a verifiably random > way from a pool of volunteers. The more volunteers, the better chance we > have of choosing a random yet representative cross section of the IETF > population. The call's duration is 4 weeks and ends before 23:59 UTC on Wednesday June 23, 2021. Further details can be found in BCP 10 (RFC 8713) and of course t= he announcement email: > https://mailarchive.ietf.org/arch/msg/ietf-announce/T_WVH96pH-5QVTRqd0yTT= 1TaPaU/ Path 3: The person has been a listed author or editor (on the front page) of at least two IETF Stream RFCs within the last 5 years prior to the day the call for NomCom volunteers is sent to the community. An Internet-Draft that has been approved by the IESG and is in the RFC Editor queue counts the same as a published RFC, with the relevant date be= ing the date the draft was added to the RFC Editor queue. =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+93Q3WUFAmCvkJcACgkQgItw+93Q 3WXbZAgAtwo2bwiY6e0Xpdhs+FdIFxZfLouvzXzTFuNWuY6wDKh8OO0AzvJ9XrrC aB5eMl8IEINQX+NbQlZAs94798yNlufucMeGEdjXFoFQ/UNa6h2tK3JpLlYRxwWl K7T8hVAmRg//PXmEBqFMMaRApQeVMH4GFbf1iDAFijVxvThQTtPMT/9sZJa3LwY9 UXUN6mIgTBnnTbS6Gc5CQpN9RHEw+BDfIvFsRDzgCaDYA6gmwnGqmranP7x2mq+1 cwOpjlAHJv9epTY+/rHeCkqMk7tdn33Ou25TARAPweTEhgc523u1AV8bf2zvFk1F J2juXDWje6ze6IlI1xil0y/mXK7RJA== =R29e -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri May 28 03:09: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 21EBB3A231B for ; Fri, 28 May 2021 03:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.392 X-Spam-Level: ** X-Spam-Status: No, score=2.392 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, FROM_SUSPICIOUS_NTLD=0.498, FROM_SUSPICIOUS_NTLD_FP=1.997, PDS_OTHER_BAD_TLD=1.997, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bunkus.online 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 zOL-sxz6BxIf for ; Fri, 28 May 2021 03:09:29 -0700 (PDT) Received: from liselle.bunkus.org (liselle.bunkus.org [144.76.140.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E50143A2318 for ; Fri, 28 May 2021 03:09:26 -0700 (PDT) Received: from sweet-chili.int.bunkus.org (sweet-chili.int.bunkus.org [192.168.191.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) (Authenticated sender: email-relay) by liselle.bunkus.org (Postfix) with ESMTPSA id AB774115B06A for ; Fri, 28 May 2021 12:09:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bunkus.online; s=dkim; t=1622196558; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=S+wTM1YEQyzGN1fhHH8otrBCCGyrEniA5yOnxEUqWj4=; b=n5PREMATTttj3+Dc+TmouIGxp+4J3dn7IYNfz3PenqpKhxgUZGNyVvsq41G4uNmbG8zXHw xNgT/o5pEBHFvO0NOWJAKJN+r09qrddwgWIk52TGupzn6tnXKNOHie2vzmBj+mq7Hrlx8Z +xOEqzZB+y94GArBV0I4ZVCNvl5MuBg= Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.int.bunkus.org (Postfix) with ESMTP id 59FD05FA66AB for ; Fri, 28 May 2021 12:09:18 +0200 (CEST) User-agent: mu4e 1.4.15; emacs 27.2 From: Moritz Bunkus To: Cellar list Message-ID: <87tumnrwz6.fsf@bunkus.online> Date: Fri, 28 May 2021 12:09:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Cellar] IRC channel again 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, 28 May 2021 10:09:34 -0000 Hey, yeah, we talked about the IRC channel on Tuesday and decided to postpone the decision (or not to do anything at that point). Mostly people didn't have a strong opinion one way or the other. Over the last couple of days Freenode has cracked down on several hundred channels, simply due to them having "libera.chat" in the topic. Not just on channels that actually planned to move, but also on channels that were simply thinking about moving or that did NOT in fact wanted to move and told their users via their topic. Cracking down means that a Freenode bot came in, renamed the channel, removed rights from existing ops, changed the topic and basically archived the channel. They're seizing control of channels they have nothing to do with. Here are a couple of examples: https://www.gentoo.org/news/2021/05/26/gentoo-freenode-channels-hijacked.ht= ml https://mastodon.sdf.org/@kline/106299403921451814 https://fridge.ubuntu.com/2021/05/26/announcing-ubuntus-move-to-libera-chat/ I find all of this highly offensive to a community of free/open source projects. Therefore I do have a strong opinion now: let's move our IRC to libera.chat, please. As all of you didn't have a strong opinion on Tuesday, I'll assume you're OK with that move. Unless someone objects by Sunday, I'll implement the move on Monday (closing the channel on Freenode, updating our web page). Switching to other chat tools (XMPP/Jabber, Matrix=E2=80=A6) is a totally d= ifferent topic I'm not trying to tackle at this point; moving IRC is easy enough to implement and somewhat time sensitive due to recent events. m. From nobody Fri May 28 03:21:36 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 54D9E3A236E for ; Fri, 28 May 2021 03:21:34 -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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idhOvgM_nFl3 for ; Fri, 28 May 2021 03:21:32 -0700 (PDT) Received: from 2.mo2.mail-out.ovh.net (2.mo2.mail-out.ovh.net [188.165.53.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E1F33A236C for ; Fri, 28 May 2021 03:21:31 -0700 (PDT) Received: from player796.ha.ovh.net (unknown [10.108.20.200]) by mo2.mail-out.ovh.net (Postfix) with ESMTP id DF0EB20A5D2 for ; Fri, 28 May 2021 12:21:28 +0200 (CEST) Received: from mediaarea.net (p548f9e2a.dip0.t-ipconnect.de [84.143.158.42]) (Authenticated sender: jerome@mediaarea.net) by player796.ha.ovh.net (Postfix) with ESMTPSA id 2CD561E84CC41 for ; Fri, 28 May 2021 10:21:25 +0000 (UTC) Authentication-Results: garm.ovh; auth=pass (GARM-95G001247ab7ff-4f85-4409-a91f-88a09d9db9b9, 55BE88294E42C4AF53A0A358BBC109F7927DBBAA) smtp.auth=jerome@mediaarea.net X-OVh-ClientIp: 84.143.158.42 To: cellar@ietf.org References: <87tumnrwz6.fsf@bunkus.online> From: Jerome Martinez Message-ID: <43c85997-93e0-b5cf-98da-e8ffae3d83a6@mediaarea.net> Date: Fri, 28 May 2021 12:21:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: <87tumnrwz6.fsf@bunkus.online> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Ovh-Tracer-Id: 14134547430771724433 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduledrvdekjedgvdekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtkeertddtfeejnecuhfhrohhmpeflvghrohhmvgcuofgrrhhtihhnvgiiuceojhgvrhhomhgvsehmvgguihgrrghrvggrrdhnvghtqeenucggtffrrghtthgvrhhnpefhledukedviefhuefgledutdeffeefheffjeetteegveegteekhedtffevhfehieenucfkpheptddrtddrtddrtddpkeegrddugeefrdduheekrdegvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdqohhuthdphhgvlhhopehplhgrhigvrhejleeirdhhrgdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomhepjhgvrhhomhgvsehmvgguihgrrghrvggrrdhnvghtpdhrtghpthhtoheptggvlhhlrghrsehivghtfhdrohhrgh Archived-At: Subject: Re: [Cellar] IRC channel again 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, 28 May 2021 10:21:34 -0000 On 28/05/2021 12:09, Moritz Bunkus wrote: > [...] but also on channels that were > simply thinking about moving or that did NOT in fact wanted to move and > told their users via their topic. Fun of basic automation :). > Therefore I do have a strong opinion now: let's move our IRC to > libera.chat, please. I see no issue with that move, so +1. Topic on freenode will have to be selected for not being caught by the stupid bot :). Jérôme From nobody Fri May 28 04:19: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 54DC03A252C for ; Fri, 28 May 2021 04:19:14 -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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 (1024-bit key) header.d=reto.ch 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 Sq9eMsIDzuGd for ; Fri, 28 May 2021 04:19:09 -0700 (PDT) Received: from smtp-190b.mail.infomaniak.ch (smtp-190b.mail.infomaniak.ch [185.125.25.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90E653A2529 for ; Fri, 28 May 2021 04:19:09 -0700 (PDT) Received: from smtp-2-0001.mail.infomaniak.ch (unknown [10.5.36.108]) by smtp-2-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4Fs2J945SqzMqK9M for ; Fri, 28 May 2021 13:19:05 +0200 (CEST) Received: from Castor (unknown [8.39.215.30]) by smtp-2-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 4Fs2J90Wxfzlh8j1 for ; Fri, 28 May 2021 13:19:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=reto.ch; s=20191114; t=1622200745; bh=Ci1jzAcFILdp6+I0zesJihGHMoK55WQQRHKZ4jFERvI=; h=Date:From:Subject:To:In-Reply-To:From; b=e4ENQU2lUb2Lt0gcnwtE+Y4xuCtCyJq4NIGym7F2C3ItaxvjB02T+eioRA6GmA7d3 EKjs4ezrtHaQrAdLhYEQSLFa0zzQVzg7cpRFncpIHyVLMkMd1AsrKaGIH7GbXjxyqx g+Yut+jidFH475/S+IE7G1xEAeqltLjTubjVPonI= Date: Fri, 28 May 2021 13:19:05 +0200 From: Reto Kromer To: cellar@ietf.org X-Priority: 3 In-Reply-To: <43c85997-93e0-b5cf-98da-e8ffae3d83a6@mediaarea.net> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4.3 (480) Archived-At: Subject: Re: [Cellar] IRC channel again 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, 28 May 2021 11:19:14 -0000 Jerome Martinez wrote: >> Therefore I do have a strong opinion now: let's move our IRC to >> libera.chat, please. > >I see no issue with that move, so +1. +1 Best regards, Reto From nobody Sat May 29 23:42:20 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 6C6FA3A312F for ; Sat, 29 May 2021 23:42:18 -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 sgUZHcmbdm6p for ; Sat, 29 May 2021 23:42:13 -0700 (PDT) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 E53B83A312E for ; Sat, 29 May 2021 23:42:12 -0700 (PDT) Received: by mail-wm1-x331.google.com with SMTP id f17so2943464wmf.2 for ; Sat, 29 May 2021 23:42:12 -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=2ztiNcHUGQbiIf8Y8hLBD4qjC2SorCmTAW9MveWd2RQ=; b=nwuK1zx8xO1HlH/Ge6vKKUSUnMjwwu477rFEeGO9I1+RUBxelEf6e5W087/p9GzGlp zGjaPgt0Srqe3e3SG1DHqvjj1UP+wD2xQZDSb+V8wxU8Oee6xrQv8GwK/YJMmgRLp4Ji sXLxQYa/uRenw09DIwjr2Qv/zv5uqWSYKw4gTtQ+pZME5yOCfFHi44jklnBTWNPVUBVt lMhAMNVTD++V3FMnGpyCYWt5kz9nR6kAHCffw5lqugxkNAP7ZwL97OrWIi3x/z19FsOT 4EMiEPdgQ4/kK7w60CWYZTz7Z0jP2/Nar9kte3vBkmco78JW463u5D9thl5t+Cguny/M f3sQ== 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=2ztiNcHUGQbiIf8Y8hLBD4qjC2SorCmTAW9MveWd2RQ=; b=tSQFotFMt3GR7DtdG1Rp2S895lljckOwGkpHO5l5uKbQd9BuHnjsEe00cmXSYewDzX flsw5V/d65oFdc74xITaw0ytevzFOd2DSbeTC4EsKNxnjJBL0YuWQ556TL4C7n9ZVAu1 ZMlSlg3W+mAci4iodVYL5OTo4vd5zrRrpOzg+43YaCYss4uvl4I2p3TaiwMSuEM6ycGj vYIxAEVWCiGUV/bJ3VE/GY+EQ01QtIG+lu9591QUvmh4AObtaCLvO9DO6LdSbHAKhhc5 2pfU6hztzx5AtPxfSIFWtxC1tnTh2N8WDUMTZE9f38fhlp+WroNXFB/j+NWD8Jb7D8oz PnYw== X-Gm-Message-State: AOAM5303q5m7cfLVhQVRPSXCsvX1BO6vO/dPaHLrpwPAQO4GYqBZk8zS NnBdAoMZ13NlVJWNgbngmKxc3mPlXNrww7cy X-Google-Smtp-Source: ABdhPJzHQ5809bk3MoLQZnWbPTdu4PlDxsXv/VeiDNbZ6H3sqMEU+OQxG47sOVePg4CwHVmaMYUWGQ== X-Received: by 2002:a1c:7f86:: with SMTP id a128mr15369823wmd.20.1622356930767; Sat, 29 May 2021 23:42:10 -0700 (PDT) Received: from ?IPv6:2a01:cb0c:20:e900:49c6:4a24:e540:ae61? (2a01cb0c0020e90049c64a24e540ae61.ipv6.abo.wanadoo.fr. [2a01:cb0c:20:e900:49c6:4a24:e540:ae61]) by smtp.gmail.com with ESMTPSA id h15sm11339230wmq.1.2021.05.29.23.42.10 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 29 May 2021 23:42:10 -0700 (PDT) To: cellar@ietf.org References: <87tumnrwz6.fsf@bunkus.online> From: Steve Lhomme Message-ID: Date: Sun, 30 May 2021 08:42:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: <87tumnrwz6.fsf@bunkus.online> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] IRC channel again 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, 30 May 2021 06:42:19 -0000 On 2021-05-28 12:09, Moritz Bunkus wrote: > Hey, >=20 > yeah, we talked about the IRC channel on Tuesday and decided to postpon= e > the decision (or not to do anything at that point). Mostly people didn'= t > have a strong opinion one way or the other. >=20 > Over the last couple of days Freenode has cracked down on several hundr= ed > channels, simply due to them having "libera.chat" in the topic. Not jus= t on > channels that actually planned to move, but also on channels that were > simply thinking about moving or that did NOT in fact wanted to move and= > told their users via their topic. >=20 > Cracking down means that a Freenode bot came in, renamed the channel, > removed rights from existing ops, changed the topic and basically archi= ved > the channel. They're seizing control of channels they have nothing to d= o > with. >=20 > Here are a couple of examples: >=20 > https://www.gentoo.org/news/2021/05/26/gentoo-freenode-channels-hijacke= d.html > https://mastodon.sdf.org/@kline/106299403921451814 > https://fridge.ubuntu.com/2021/05/26/announcing-ubuntus-move-to-libera-= chat/ >=20 > I find all of this highly offensive to a community of free/open source > projects. >=20 > Therefore I do have a strong opinion now: let's move our IRC to > libera.chat, please. >=20 > As all of you didn't have a strong opinion on Tuesday, I'll assume you'= re > OK with that move. Unless someone objects by Sunday, I'll implement the= > move on Monday (closing the channel on Freenode, updating our web page)= =2E I support the move. This has become ridiculous. AFAIK Videolan is also=20 moving there. > Switching to other chat tools (XMPP/Jabber, Matrix=E2=80=A6) is a total= ly different > topic I'm not trying to tackle at this point; moving IRC is easy enough= to > implement and somewhat time sensitive due to recent events. >=20 > m. >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar >=20 From nobody Sun May 30 01:36: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 943963A3469 for ; Sun, 30 May 2021 01:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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_DNSWL_BLOCKED=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=LiR50SDK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JHvnYSZY 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 3Rm-_vo5GfCT for ; Sun, 30 May 2021 01:36:05 -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 B3E523A346D for ; Sun, 30 May 2021 01:36:05 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 7D53EE0A for ; Sun, 30 May 2021 04:26:43 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Sun, 30 May 2021 04:26:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm2; bh=uw4BbmGzdUS XqV1l3oaltlydUmncGX3bnTo3vHFl7qs=; b=LiR50SDK8RpPLs65Sq9xq6Zvj3a zSU2VbPhlRgdOUKdURQd44KGc0vTIP5SBULxHb+ImYSqkzXRYiR1DJrudX/fOavA ts+BbpE27JFndrsggxgAIiKUP/C8LrHD/OxRHypeobxi3ZdyYeZUCOEUytIsZfGq cfR2Hi4Q3xtjenuyu8TflgueD8DXVQa0ZIF/l9nKBGujCWuBLp42bjVy2vcXuJdf NcThF/ME+Doxv4YX2HcqKOngZ0VrL+i+6tH7U9Vn7nhw6DazCu+lP72lsjCbcTiS tyVYbIbWvmz/6eTIAU+1jpNbHS/3dkflizMzVMczj5zsYU15iSoQO8cNdZQ== 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= fm2; bh=uw4BbmGzdUSXqV1l3oaltlydUmncGX3bnTo3vHFl7qs=; b=JHvnYSZY CjigUTrE/8KZtr0tttxuSfJloBdxCAZm83L/9EytCChd9MlucWIeo2vlebjHoN2g UTXWlraki/J9SVwNlV/7EezVHNCLx5jO04ormtRnWiYcyYoXA8R5e3bkoZ4S05Qq ONX7bPeIeFS4P8bRLK1/so+FjIDN9RAzqU6VNr8zdiuma7eVkxF/b4/iDt31uI65 5ht/RgwYQniwwH3bfs+kMYV/hlRJEcp6up2CE7qhRHynC3w93mYZ2NoJuXYpsPeP 2QhfSKXogAc1t9VgG0xAQLppHFhOU0GndFCslb1bS1WhuWidHA3PVuHB5F8iQ9HN 5xnHcQgXS5mERw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeluddgtdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucfpohcuuggrthgvuchfihgvlhguucdlgeelmdenuc fjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpeftvghpohhsihhtohhrhicu tegtthhivhhithihucfuuhhmmhgrrhihuceuohhtuceoughopghnohhtpghrvghplhihse hmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeefvdduteejvdefkeehieevuefg fefhteetveegffekffefteffvdelheduieetnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucfkphepudefrdekvddrkeefrddvvdeknecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomhepughopghnohhtpghrvghplhihsehmnhhothdrnh gvth X-ME-Proxy: Received: from fv-az201-811.ett4tu3jvdse5ovc2mkgjqcs5a.bx.internal.cloudapp.net (unknown [13.82.83.228]) by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 30 May 2021 04:26:42 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============6956949156652418941==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20210530083605.B3E523A346D@ietfa.amsl.com> Date: Sun, 30 May 2021 01:36:05 -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, 30 May 2021 08:36:11 -0000 --===============6956949156652418941== 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 (+2/-0/=F0=9F=92=AC2) 2 issues created: - range attribute vs restriction element (by robUx4) https://github.com/ietf-wg-cellar/ebml-specification/issues/410 [bug] [= errata-rfc8794]=20 - Writing elements with a default value if the element can be multiple (b= y hubblec4) https://github.com/ietf-wg-cellar/ebml-specification/issues/409=20 1 issues received 2 new comments: - #409 Writing elements with a default value if the element can be multip= le (2 by robUx4) https://github.com/ietf-wg-cellar/ebml-specification/issues/409 [clarif= ications] [errata-rfc8794]=20 * ietf-wg-cellar/matroska-specification (+0/-2/=F0=9F=92=AC1) 1 issues received 1 new comments: - #422 Consider providing a facility for integer-fraction timescales (1 b= y robUx4) https://github.com/ietf-wg-cellar/matroska-specification/issues/422 [cl= arifications] [format addition] [spec_main] [spec_tags]=20 2 issues closed: - add the control track elements in main Schema file https://github.com/i= etf-wg-cellar/matroska-specification/issues/509 [XML Schema] [build system]= =20 - ChapterSegmentEditionUID https://github.com/ietf-wg-cellar/matroska-spe= cification/issues/267 [clarifications] [spec_main]=20 Pull requests ------------- * ietf-wg-cellar/matroska-specification (+2/-6/=F0=9F=92=AC7) 2 pull requests submitted: - Remove range attribute from element with a (large) restriction section = (by robUx4) https://github.com/ietf-wg-cellar/matroska-specification/pull/515 [clar= ifications] [enhancement] [spec_main]=20 - make ChapterDisplay use only one language at a time (by robUx4) https://github.com/ietf-wg-cellar/matroska-specification/pull/514 [bug]= [clarifications] [spec_main]=20 6 pull requests received 7 new comments: - #514 make ChapterDisplay use only one language at a time (1 by robUx4) https://github.com/ietf-wg-cellar/matroska-specification/pull/514 [bug]= [clarifications] [spec_main]=20 - #513 Expand the tocdepth to 4 (1 by robUx4) https://github.com/ietf-wg-cellar/matroska-specification/pull/513 [form= atting]=20 - #512 mark the markdown/xml/output as IETF standards (1 by SpencerDawkin= s) https://github.com/ietf-wg-cellar/matroska-specification/pull/512 [buil= d system] [clarifications]=20 - #511 move back the control track IDs in the main schema file (1 by robU= x4) https://github.com/ietf-wg-cellar/matroska-specification/pull/511 [XML = Schema] [build system]=20 - #495 Reorder/Reparent sections in the Matroska RFC (2 by SpencerDawkins) https://github.com/ietf-wg-cellar/matroska-specification/pull/495 [form= atting] [spec_main]=20 - #487 Move the deprecated elements at the end of the specs (1 by robUx4) https://github.com/ietf-wg-cellar/matroska-specification/pull/487 [form= atting] [spec_main]=20 6 pull requests merged: - move back the control track IDs in the main schema file https://github.com/ietf-wg-cellar/matroska-specification/pull/511 [XML = Schema] [build system]=20 - make BlockGroup\Slices max version 1 https://github.com/ietf-wg-cellar/matroska-specification/pull/475 [clar= ifications] [spec_main]=20 - reorder attributes to have a consistent order between elements https://github.com/ietf-wg-cellar/matroska-specification/pull/498 [XML = Schema] [formatting] [spec_main]=20 - Move the ChapterSegmentUID section into the Medium Linking section https://github.com/ietf-wg-cellar/matroska-specification/pull/489 [form= atting]=20 - mark the markdown/xml/output as IETF standards https://github.com/ietf-wg-cellar/matroska-specification/pull/512 [buil= d system] [clarifications]=20 - Reorder/Reparent sections in the Matroska RFC https://github.com/ietf-wg-cellar/matroska-specification/pull/495 [form= atting] [spec_main]=20 * FFmpeg/FFV1 (+1/-0/=F0=9F=92=AC2) 1 pull requests submitted: - bump to ffv1 v4 18 (by dericed) https://github.com/FFmpeg/FFV1/pull/263=20 1 pull requests received 2 new comments: - #263 bump to ffv1 v4 18 (2 by dericed) https://github.com/FFmpeg/FFV1/pull/263=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 --===============6956949156652418941== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

    Sunday May 30, 2021

    Events without label "editorial"

    Issues

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

    2 issues created:

    1 issues received 2 new comments:

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

    1 issues received 1 new comments:

    2 issues closed:

    Pull requests

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

    2 pull requests submitted:

    6 pull requests received 7 new comments:

    6 pull requests merged:

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

    1 pull requests submitted:

    1 pull requests received 2 new comments:

    Repositories tracked by this digest:

    --===============6956949156652418941==--