[Cellar] IANA Considerations for EBML

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 07 June 2018 01:54 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 633A113107D for <cellar@ietfa.amsl.com>; Wed, 6 Jun 2018 18:54:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id au3_HaJUrys8 for <cellar@ietfa.amsl.com>; Wed, 6 Jun 2018 18:54:31 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DD2F130E16 for <cellar@ietf.org>; Wed, 6 Jun 2018 18:54:31 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9C0E120090 for <cellar@ietf.org>; Wed, 6 Jun 2018 22:07:58 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id A3A1925C3; Wed, 6 Jun 2018 21:53:54 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A13D574 for <cellar@ietf.org>; Wed, 6 Jun 2018 21:53:54 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: cellar@ietf.org
X-Attribution: mcr
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: Wed, 06 Jun 2018 21:53:54 -0400
Message-ID: <15361.1528336434@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/k-77-POOqdQRv0TUGe_TusfwG2o>
Subject: [Cellar] IANA Considerations for EBML
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.26
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: Thu, 07 Jun 2018 01:54:35 -0000

I've made a pull request, https://github.com/Matroska-Org/ebml-specification/pull/179
but I include the text here so that we can discuss it on the list.
I havne't gotten the references done correctly for mmark, so don't worry
about that for now.

Note: "Specification Required" does not imply IETF specification.
It could be any SDO, and many other entities that might publish things.
First Come/First Served requires no document at all... just ask IANA.
RFC Required does not imply standards track.

see https://tools.ietf.org/html/rfc8126


# IANA Considerations

This document creates a new IANA Registry called
"CELLAR EBML Element ID Registry".

Element IDs are described in section {{#element-id}}.  Element IDs are
encoded using the VINT mechanism described in
section {{#variable-sized-integer}} can be between one and five bytes
long. Five byte long Element IDs are possible only if declared in the header.

One byte Element IDs are numbers between 1 and 126. These items are valuable
because they short, and need to be used for commonly repeated elements.
Values from 1 to 126 are to be allocated according to RFC Required.

Two byte Element IDs are numbers between 127 and 16382.
Numbers may be allocated within this range according to Specification
Required.

Three byte Element IDs are numbers between 16383 and 2097150.
Numbers may be allocated within this range according to First Come First
Served.

Four byte Element IDs are numbers between 2097151 and 268435456.
Four byte Element IDs are somewhat special in that they are useful for
resynchronizing to major structures in the event of data corruption or
loss.  As such four byte Element IDs are split into two categories.
Four byte Element IDs whose lower three bytes (as encoded) would make
printable 7-bit ASCII values may be allocated only Specification Required.
Sequential allocation of values is not required: specifications SHOULD
include a specific request, and are encouraged to do early allocations.

To be clear about the above category: Four Byte Element IDs always start
with hex 0x10 to 0x1F,  and that byte may be chosen so that the entire number
has some desirable property, such as a specific CRC.  The other three bytes,
when ALL having values between 33 (ASCII !) and 126 (ASCII ~), fall into
this catgory.

Other Four Byte Element IDs may be allocated by First Come First Served.

Five Byte Element IDs (values from 268435457 upwards) are reserved for
Experimental use.


-- 
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-