Re: [Cellar] Call for adoption of three new WG items

Michael Richardson <> Thu, 31 May 2018 19:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2880312EAF7 for <>; Thu, 31 May 2018 12:16:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DnXy6UpqK3xm for <>; Thu, 31 May 2018 12:16:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D60C41315B3 for <>; Thu, 31 May 2018 12:16:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5733620093; Thu, 31 May 2018 15:29:51 -0400 (EDT)
Received: by (Postfix, from userid 179) id 0789D2DA9; Thu, 31 May 2018 15:16:13 -0400 (EDT)
Received: from (localhost []) by (Postfix) with ESMTP id 045672DA1; Thu, 31 May 2018 15:16:13 -0400 (EDT)
From: Michael Richardson <>
cc: Dave Rice <>, hubblec4 <>
In-Reply-To: <>
References: <> <> <> <>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Thu, 31 May 2018 15:16:12 -0400
Message-ID: <28452.1527794172@localhost>
Archived-At: <>
Subject: Re: [Cellar] Call for adoption of three new WG items
X-Mailman-Version: 2.1.22
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, 31 May 2018 19:16:48 -0000

Dave Rice <> wrote:
    > - the tags and codec specs sections may need more frequent adjustments
    > as new codecs and tags are needed, whereas the rest of the matroska
    > specification should be relatively stable

Assuming that the IANA Considerations requires an IETF Standards Action to
allocate, then new tags and new codecs can be added with a specification that
simply updates this document: we don't have to repeat the entire process.

If bigcompany.example publishes some super-magic codec, available only by
using their CPU, and want a codec code for it, and the IANA Considerations
includes an "Expert Review" or "First Come First Served" section, then they
simply ask for it, no specification required even.
If the ITU publishes some codec, and wants a code, and it's "Specification
Required" (vs IETF Standards Action), then the existence of their document
is enough to get a code.

    > Moving the tags section to a separate document wasn’t because of its
    > complexity but because it would likely need more frequent revision as
    > new metadata values are added. So the chapters descriptions are still
    > in draft-lhomme-cellar-matroska-04, see

Will the new tags materially affect processing of the old tags?

]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]        |   ruby on rails    [