Re: [Cellar] IANA Considerations for EBML

[Dave Rice <[e-mail]>]

Hi Michael, Steve,

I might be mistaken here, but from the draft the process of registering an Element ID via IANA only seems interested in the Element ID itself. For a curious onlooker of the IANA registrations it might be helpful to see what the associated DocType is so that the context and semantics could be understood, otherwise the registration only seems to indicate that somewhere someone registered it via first-come first-serve.

Additionally I think I’d prefer (except for the IDs used by EBML itself) that the combination of DocType and ElementID be required as unique rather than only the ElementID itself. This seems analogous to how the same node name is allowed in various XML Schemas but don’t necessarily have any relation to one another in semantics.

Is it acceptable to extend the IANA Considerations section to clarify the required information for registrations? From the discussion in the pull request these scenarios seem to be:

option a
- the VINT_DATA of the Element ID

option b
- the VINT_DATA of the Element ID
- the associated DocType

option c
- the VINT_DATA of the Element ID
- the associated DocType
- the full Element Definition as described at https://tools.ietf.org/html/draft-ietf-cellar-ebml-04#section-14.1.3 <https://tools.ietf.org/html/draft-ietf-cellar-ebml-04#section-14.1.3>

Dave

Would it be possible to an interest

> On Jun 17, 2018, at 10:57 AM, Steve Lhomme <[e-mail]> wrote:
> 
> 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 <[e-mail]>:
>> 
>> 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 <[e-mail]>, Sandelman Software Works
>> -= IPv6 IoT consulting =-
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Cellar mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/cellar
>> 
> 
> 
> 
> -- 
> Steve Lhomme
> Matroska association Chairman
> 
> _______________________________________________
> Cellar mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cellar