Subject: [Cellar] IANA Considerations for EBML

From: Michael Richardson <[email-masked]>
Date: Wed, 06 Jun 2018 21:53:54 -0400

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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Steve Lhomme <[email-masked]>
Date: Sun, 17 Jun 2018 16:57:48 +0200

I think in general it would be better to use hexadecimal values for
the ranges. It's friendlier to know why these values when reading then
in "binary". Also they are coded as VINT but in the end are not
intrepreted as the integer values they represent but really the whole
ID as one. So the integer values are not what people will use/see.

2018-06-07 3:53 GMT+02:00 Michael Richardson <[email-masked]>:
> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar
>

-- 
Steve Lhomme
Matroska association Chairman