IETF Logo Mail Archive

Re: [Cellar] [Technical Errata Reported] RFC8794 (7185)

Steve Lhomme <slhomme@matroska.org> Sun, 30 October 2022 08:17 UTC

Return-Path: <slhomme@matroska.org>
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 4D572C14F6EB for <cellar@ietfa.amsl.com>; Sun, 30 Oct 2022 01:17:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Level:
X-Spam-Status: No, score=-6.906 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20210112.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEzbToQscHoM for <cellar@ietfa.amsl.com>; Sun, 30 Oct 2022 01:17:06 -0700 (PDT)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E003C14CF05 for <cellar@ietf.org>; Sun, 30 Oct 2022 01:17:06 -0700 (PDT)
Received: by mail-wm1-x332.google.com with SMTP id v130-20020a1cac88000000b003bcde03bd44so9022525wme.5 for <cellar@ietf.org>; Sun, 30 Oct 2022 01:17:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=jHuLJGiWCuaoDyYXUtuPOg10bxzFreoD0M2g9v1ZUHY=; b=GYQq2xgEc8G2o9LvXuU0a8OrrwE9T1/OlO/ctpKW5cpT5bECypI/JMk5Rk9rLGIoDF /5Epcv9sgiw2KroHz2jsPxGj1O5HBJay9cq9Nla6t3Z8IEwOmHgTPA9nlnNSvGNmSuDo aKP0F1wtFDF03UQ+Sy+zXAs4ZduMoJIKQBx67wgNM5txsJKsRWSnSOI0J+COeuOIGvz/ dh7CHRlDjDBI7hQzMFUb+SC/+AWRWVxZvgWhcW0sHI5RBTUojwfRD73WxD6P4kMfb0A8 En6qkuiEPqLw2vN7rzKfpmbwX4byCl/fr4eWXErTqksm3VnV8OMXgf/MEmD5EEpMz5Sq 5zSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jHuLJGiWCuaoDyYXUtuPOg10bxzFreoD0M2g9v1ZUHY=; b=yxSlD857jTMQrXWQWTQqJsLquNCFYE/mYrzx/GiX6PnL3jt0rW2wpilFk7Hy9lpqSD yRAiY/G1YZ3uYYY61jzjqEbUwBdLphLaWzPZR1yfgX622UOONaQ22/MtV7qjh3Z6LQzJ JtubKHa5KyJuBYf+QdBvpyjw3ljJiTYnFvagL/C2y8m62GjDSPlS50sOhlfgQy/w7O91 ru88yHvAg0VVOM1MBRbiZ0kguUReCirqaHH9oUTMwaqi6Xa5v6GxrYFmDpWo7Dvn6g08 SwWqmpfxzY4H6cfQTvli2HZroDrqN+66MJOt3yoRxZG543Lp7dDUSCjSnrNMkokuim2a uNIw==
X-Gm-Message-State: ACrzQf01TS5pZlg5ns3eaknnrWZyOei/bn9SXeNOpQQm4kKFWuYTCmzQ LQIgoiZjI7jhpW97qIiPN308iQ==
X-Google-Smtp-Source: AMsMyM6HKGSDi/gkZFdFC0GEaxPROSyIfIGayu+PJsY+yUv4xX6nfIs5/jElSDpkNZSb7c/ywVzz2w==
X-Received: by 2002:a05:600c:3585:b0:3c7:9f:5f87 with SMTP id p5-20020a05600c358500b003c7009f5f87mr15095830wmq.76.1667117825055; Sun, 30 Oct 2022 01:17:05 -0700 (PDT)
Received: from ?IPV6:2a01:cb0c:20:e900:8f:ffcb:6ea9:3c28? (2a01cb0c0020e900008fffcb6ea93c28.ipv6.abo.wanadoo.fr. [2a01:cb0c:20:e900:8f:ffcb:6ea9:3c28]) by smtp.gmail.com with ESMTPSA id h9-20020a05600c414900b003b49ab8ff53sm3804239wmm.8.2022.10.30.01.17.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 30 Oct 2022 01:17:04 -0700 (PDT)
Message-ID: <c0d72ec0-1604-43eb-2e76-4dba886467a8@matroska.org>
Date: Sun, 30 Oct 2022 09:17:01 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0
Content-Language: en-US
From: Steve Lhomme <slhomme@matroska.org>
To: Michael Richardson <mcr+ietf@sandelman.ca>, RFC Errata System <rfc-editor@rfc-editor.org>
Cc: dave@dericed.com, moritz@bunkus.org, superuser@gmail.com, francesca.palombini@ericsson.com, spencerdawkins.ietf@gmail.com, cellar@ietf.org
References: <20221030073602.966E8F650@rfcpa.amsl.com> <279165.1667116872@dyas> <d1f5d7a6-0b59-b001-7866-4593b7b48d51@matroska.org>
In-Reply-To: <d1f5d7a6-0b59-b001-7866-4593b7b48d51@matroska.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/sIKf2CD96dTZZfcpNZ_SsoPJcsQ>
Subject: Re: [Cellar] [Technical Errata Reported] RFC8794 (7185)
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.39
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: Sun, 30 Oct 2022 08:17:10 -0000

On 2022-10-30 9:11, Steve Lhomme wrote:
> On 2022-10-30 9:01, Michael Richardson wrote:
>>
>> RFC Errata System <rfc-editor@rfc-editor.org> wrote:
>>      > The following errata report has been submitted for RFC8794, 
>> "Extensible
>>      > Binary Meta Language".
>>
>>      > Original Text
>>
>> Hi, I think you've posted the diff in terms of the source XML for the 
>> element, I
>> think, not the resulting XML that is rendered by the RFC-editor?
> 
> Hi Michael,
> 
> This particular part is actually XML data inside the text. So the diff 
> is also XML data. I created the diff between the text version of the RFC 
> and the text version of the modified (rendered) RFC.
> 
>>      > Notes
>>      > -----
>>      > maxOccurs doesn't have a defined default value and has no upper 
>> bound.
>>
>>      > See 
>> https://github.com/ietf-wg-cellar/ebml-specification/issues/395
>>
>> Francesca, we discussed this errata, and they should all be correct, 
>> once we
>> get the format right.

Other than that, given the amount of errata and how awkward it is to 
read some of them, should we start making a new document that would 
update RFC8794 as Spencer suggested [1] ? Or even a new document that 
would update/obsolete the old one ?

We have a change that involved modifying the rule for EBML ID's in the 
IANA registry, so this should be made very visible.


https://mailarchive.ietf.org/arch/msg/cellar/sB3_kx2ccVrxJoaLJBcqNzgyOKo/

v2.23.0 | Report a Bug | By Email