Re: [Cellar] [Matroska-Org/ebml-specification] IANA considerations for Element ID allocation (#179)

Michael Richardson <> Thu, 07 June 2018 17:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D88A8130FD7 for <>; Thu, 7 Jun 2018 10:09:25 -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 S8A5snxFs4Lr for <>; Thu, 7 Jun 2018 10:09:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 56788130F6F for <>; Thu, 7 Jun 2018 10:09:22 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 2B45620090; Thu, 7 Jun 2018 13:22:52 -0400 (EDT)
Received: by (Postfix, from userid 179) id 8C5F63033; Thu, 7 Jun 2018 13:08:45 -0400 (EDT)
Received: from (localhost []) by (Postfix) with ESMTP id 8A1543032; Thu, 7 Jun 2018 13:08:45 -0400 (EDT)
From: Michael Richardson <>
To: Matroska-Org/ebml-specification <>
In-Reply-To: <Matroska-Org/ebml-specification/pull/179/review/>
References: <Matroska-Org/ebml-specification/pull/> <Matroska-Org/ebml-specification/pull/179/review/>
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, 07 Jun 2018 13:08:45 -0400
Message-ID: <5086.1528391325@localhost>
Archived-At: <>
Subject: Re: [Cellar] [Matroska-Org/ebml-specification] IANA considerations for Element ID allocation (#179)
X-Mailman-Version: 2.1.26
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, 07 Jun 2018 17:09:26 -0000

I am responding to comments in github by Dave Rice.

I have fixed the backtick for references and the , for thousands.
If you want to merge the paragraphs, I will do that once I'm finished
editing, because I find it annoying to edit that way (and it makes for
less understable diffs).

I have fixed the off-by-one on 268,435,456.

> Also perhaps these min/max values should be integrated into the table in
> the {{#element-id}} section

That's a good idea.

> Should define the ascii range specifically here. For instance the lower
> three bytes of the EBML Element are 0x45DFA3 which is extended ascii for
> Eߣ (~'ebml')

If we permit other than 7-bit US-ASCII to be reserved, then the discussion
will then be latin-1,latin-2,windows-XXXX, or UTF-8.  If you want 0x45DFA3,
then it's also available by First Come First Served, it's just not reserved.

> perhaps this paragraph and the prior could be merged

my opinion is that it more understandable this way.

> +Other Four Byte Element IDs may be allocated by First Come First Served.
> how?

Please see

>+Five Byte Element IDs (values from 268435457 upwards) are reserved for
>+Experimental use.
>that only leaves two available non-experimental five byte element ids.

I don't think it leaves any: it's all experimental.
Do we really need that any Five Byte Element IDs in specifications?

Michael Richardson <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-