Re: [Cellar] [IANA #1161138] Protocol Action: 'Extensible Binary Meta Language' to Proposed Standard (draft-ietf-cellar-ebml-17.txt)

Dave Rice <dave@dericed.com> Fri, 31 January 2020 15:06 UTC

Return-Path: <dave@dericed.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 EB95A12083E for <cellar@ietfa.amsl.com>; Fri, 31 Jan 2020 07:06:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.018
X-Spam-Level:
X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, TRACKER_ID=0.1, URIBL_BLOCKED=0.001] autolearn=no 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 eAuX3xL3s8Pf for <cellar@ietfa.amsl.com>; Fri, 31 Jan 2020 07:06:31 -0800 (PST)
Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (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 23085120839 for <cellar@ietf.org>; Fri, 31 Jan 2020 07:06:31 -0800 (PST)
Received: from [146.96.19.240] (port=53442 helo=[10.10.201.20]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <dave@dericed.com>) id 1ixXsG-001xGK-WD; Fri, 31 Jan 2020 10:06:29 -0500
From: Dave Rice <dave@dericed.com>
Message-Id: <2F73B0E2-D56F-4E8D-AA2D-FD4458CDDCCB@dericed.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_07DA342E-2BDF-4FA8-A9A1-D5982F6B6E6F"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 31 Jan 2020 10:06:22 -0500
In-Reply-To: <rt-4.4.3-1805-1580433383-1725.1161138-9-0@icann.org>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, spencerdawkins.ietf@gmail.com, alexey.melnikov@isode.com, Barry Leiba <barryleiba@computer.org>, Adam Roach <adam@nostrum.com>, Alexey Melnikov <aamelnikov@fastmail.fm>, Steven Villereal <villereal@gmail.com>, Codec Encoding for LossLess Archiving and Realtime transmission <cellar@ietf.org>
To: drafts-approval-comment@iana.org
References: <RT-Ticket-1161138@icann.org> <158030678874.2791.1756674491139811730.idtracker@ietfa.amsl.com> <rt-4.4.3-1805-1580433383-1725.1161138-9-0@icann.org>
X-Mailer: Apple Mail (2.3445.104.11)
X-OutGoing-Spam-Status: No, score=-0.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server172.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - dericed.com
X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com
X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/eqyLhX4JMZq9FGsDPoL1oXQdDOk>
Subject: Re: [Cellar] [IANA #1161138] Protocol Action: 'Extensible Binary Meta Language' to Proposed Standard (draft-ietf-cellar-ebml-17.txt)
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: Fri, 31 Jan 2020 15:06:33 -0000

Hi Amanda,

> On Jan 30, 2020, at 8:16 PM, Amanda Baber via RT <drafts-approval-comment@iana.org> wrote:
> 
> Dear Authors/Chairs,
> 
> Before we upload the new EBML registries, we have a question about values that aren't mentioned in the document.
> 
> Most one-, two-, three-, four-, and five-octet values have their meaning specified in the IANA Considerations section: assigned, available for assignment (described as "Unassigned" in the registry), Reserved, or "Not valid for use as an Element ID." However, we don't know how to describe these values in the registry:

Most of these values are "Not valid for use as an Element ID”. In https://www.ietf.org/id/draft-ietf-cellar-ebml-17.html#section-5 <https://www.ietf.org/id/draft-ietf-cellar-ebml-17.html#section-5> is a rule for Element IDs that says "The VINT_DATA component of the Element ID MUST be encoded at the shortest valid length” but there are other reasons within these ranges so I’m noting the reason for each value.

> 0x4001-0x407E

The range 0x4001-0x407E is invalid as Element ID as they can be written more succinctly as 0x81-0xFE.

> 0x200001-0x203FFE

0x200001-0x203FFE is invalid as Element ID as they can be written more succinctly as 0x81-0xFE and 0x40FF-0x7FFE.

> 0x10000001-0x101FFFFE

0x10000001-0x101FFFFE is invalid as Element ID as they can be written more succinctly as 0x81-0xFE and 0x40FF-0x7FFE and 0x207FFF-0x3FFFFE.

> 0x0000000000-0x080FFFFFFE

The range of 0x0000000000-0x080FFFFFFE is more complex.
- 0x0000000000 is invalid for other reasons as there is no VINT Marker. It’s not an Element ID at all.
- 0x0000000001-0x7FFFFFFFF are invalid as the VINT_WIDTH indicates a width greater than the 5 byte width of the value range.
- 0x0800000000 is invalid as the VINT_DATA of an Element ID can not be all zero
- 0x0800000001-0x80FFFFFFE are not valid as they can be written more succinctly as 0x81-0xFE and 0x40FF-0x7FFE and 0x207FFF-0x3FFFFE and 0x103FFFFF-0x1FFFFFFE

> 0x0FFFFFFFFF-0xFFFFFFFFFF

The 0x0FFFFFFFFF-0xFFFFFFFFFF is easier but different :)
- 0x0FFFFFFFFF is invalid since "The bits of the VINT_DATA component of the Element ID MUST NOT be all 0 values or all 1 values.” (section 5)
- 0x1000000000-0xFFFFFFFFFF are invalid since the length of these values is 5 bytes, but the VINT_WIDTH is not equal to 4 null bits.

> How should we fill in the "Element Name" field for these values? I'm attaching a PDF version of our first draft of the registry so that you can see them in context. 


[…]

I hope this helps. :)
Kind Regards and thanks for your attention on this,

Dave Rice