IETF Logo Mail Archive

Re: [Cellar] [ietf-wg-cellar/ebml-specification] EBML ID 0x80 is marked invalid/reserved but it's used in Matroska (#407)

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Tue, 18 May 2021 17:59 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
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 <cellar@ietfa.amsl.com>; 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 <cellar@ietfa.amsl.com>; 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 <cellar@ietf.org>; Tue, 18 May 2021 10:59:30 -0700 (PDT)
Received: by mail-yb1-xb2d.google.com with SMTP id i4so14515038ybe.2 for <cellar@ietf.org>; 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: <ietf-wg-cellar/ebml-specification/issues/407@github.com> <21441.1620656178@localhost> <CAKKJt-e5PtTZM=j=Cn_YBPW87ag+oui7mGx=wuxt0JU1KY3SLQ@mail.gmail.com> <206103c0-9265-127b-6a5b-48da92fe3c9d@matroska.org> <CAKKJt-fnetcjQzvxhp9MjASujBNGAKwdf39bUhSqSL=4h2vy9Q@mail.gmail.com> <CAL0qLwagXdHdrssJtUBAVXY=ZJrVxkvnc-fyW-7jaoocd9391g@mail.gmail.com>
In-Reply-To: <CAL0qLwagXdHdrssJtUBAVXY=ZJrVxkvnc-fyW-7jaoocd9391g@mail.gmail.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Tue, 18 May 2021 12:59:02 -0500
Message-ID: <CAKKJt-cC0LzKWvwBNFvbujeu81Qsbn0yW4X7DrCzC8ny8G0dmg@mail.gmail.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Cc: Steve Lhomme <slhomme@matroska.org>, Codec Encoding for LossLess Archiving and Realtime transmission <cellar@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b0bc8a05c29e782e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/6Q_XWSqBPKOEhkDorgBcj6vmaYw>
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 <cellar.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cellar>, <mailto:cellar-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cellar/>
List-Post: <mailto:cellar@ietf.org>
List-Help: <mailto:cellar-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cellar>, <mailto:cellar-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 May 2021 17:59:47 -0000

Hi, Murray,

(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> 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 <slhomme@matroska.org>
>> 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
>

v2.23.0 | Report a Bug | By Email