Subject: [Cellar] EBML Draft TODOs

From: Dave Rice <[email-masked]>
Date: Tue, 29 Dec 2015 17:39:36 -0500

Hi all,

I'm replying to Tim's email <https://mailarchive.ietf.org/arch/msg/cellar/dAXWjowxNZ7uUVIBKIzxPT0SN7Y> as a new thread, specifically about EBML Draft to-dos. I propose that the EBML specification, currently at stored in a GitHub repo <https://github.com/Matroska-Org/ebml-specification/blob/master/specification.markdown> be considered as a working group draft. The document is largely complete and well discussed.

For remaining TODOs, I suggest this. Please add others if needed.

- Refine the definition of EBML Schema
	The current documentation of EBML Schema is based upon Matroska's specdata.xml file. However there is much agreement that the EBML Schema definition be expanded for greater machine-readability and expression of restrictions (adopting many ideas from the spec for XML Schema). This effort would ideally benefits Matroska-format validators in both the Matroska and webM communities as well as any other usage of the EBML format.

- Clarity on the use of custom data types
	The EBML spec defines a short list of data types but doesn't state if the data types are restricted to the list or if an EBML Element may be defined to a custom data type (as is permitted in XML).

- Custom elements in EBML Header
	There is some open debate on whether or not a valid EBML Document may contain elements within the EBML Header that are not defined in the EBML specification. 

- Clarity on CRC Definition
	There are several competing specs on the EBML CRC Element as discussed on GitHub <https://github.com/Matroska-Org/ebml-specification/issues/38>. The work here should resolve the confusion there.

- EBML Header does not self-define
	There was some discussion that led to an understanding that the EBML Header defines qualities about the corresponding EBML Body but not the EBML Header itself. Thus a MaxIDLength could be 2 even though the EBML Header has uses IDLengths of 4. The outcome of this discussion needs to be incorporated into the EBML Draft.

- Security Considerations
	RFC docs seem to require a section on security. Moritz began to list issues here <https://github.com/Matroska-Org/ebml-specification/issues/6#issuecomment-99937237> but there is nothing drafted for the spec yet.

I think that's about it for to do's. Please/edit/comment add if I'm missing anything.

Dave Rice

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Tue, 29 Dec 2015 15:01:38 -0800

> I think that's about it for to do's. Please/edit/comment add if I'm

Well, the big one (for me as chair) would be the submission of an 
individual I-D to the datatracker to adopt. Since you're starting from 
Markdown, pandoc2rfc might be suitable (see RFC 7328), but I've never 
used it personally.

---

From: Dave Rice <[email-masked]>
Date: Tue, 29 Dec 2015 18:46:39 -0500

Hi,

> On Dec 29, 2015, at 5:39 PM, Dave Rice <[email-masked]> wrote:

[…]

> 	The current documentation of EBML Schema is based upon Matroska's specdata.xml file. However there is much agreement that the EBML Schema definition be expanded for greater machine-readability and…

I’ll send patches on this in a separate thread over the next week.

> 	The EBML spec defines a short list of data types but doesn't state if the data types are restricted to the list or if an EBML Element may be defined to a custom data type (as is permitted in XML).

AFAIK webM and Matroska only use the data types as already defined in the EBML specification. With the addition of restrictions in element definitions (as planned in work on EBML Schema) the need for custom data types is reduced. I propose to limit the spec to the current data types and in the EBML Element Types <https://github.com/Matroska-Org/ebml-specification/blob/master/specification.markdown#ebml-element-types> section to change:

"Each defined EBML Element MUST have a declared Element Type.”

to

"Each defined EBML Element MUST declared one of the following Element Types.”

There also needs to be some clean-up on whether to use the term “Element Type” or “Data Type”. Any preference?

> 	There is some open debate on whether or not a valid EBML Document may contain elements within the EBML Header that are not defined in the EBML specification. 

Actually this point seems to have already been settled and the section on the EBML Header <https://github.com/Matroska-Org/ebml-specification/blob/master/specification.markdown#ebml-header> states that the "EBML Header MUST ONLY contain EBML Elements that are defined as part of the EBML Specification”.

> 	There are several competing specs on the EBML CRC Element as discussed on GitHub <https://github.com/Matroska-Org/ebml-specification/issues/38>. The work here should resolve the confusion there.

This issue is complex so I’ll start a new thread.

> 	There was some discussion that led to an understanding that the EBML Header defines qualities about the corresponding EBML Body but not the EBML Header itself. Thus a MaxIDLength could be 2 even t…

This issue is also resolved as the definitions of EBMLMaxIDLength and EBMLMaxSizeLength already clarify that they define the elements of the EBML Body. Since the Header doesn’t self-define size and id limits, the spec now clarifies them as "All EBML Elements within the EBML Header MUST NOT utilize any Element ID with a length greater than 4 octets. All EBML Elements within the EBML Header MUST NOT utilize any Element Data Size with a length greater than 4 octets."

> 	RFC docs seem to require a section on security. Moritz began to list issues here <https://github.com/Matroska-Org/ebml-specification/issues/6#issuecomment-99937237> but there is nothing drafted fo…

Tim, is a “Security” section required?

Dave Rice

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Tue, 29 Dec 2015 16:48:12 -0800

> Tim, is a “Security” section required?

Yes. This requirement is spelled out in RFC 7332. See RFC 3552 for some 
guidelines on writing these sections, or RFC 6716 for an example of such 
a section for a codec and draft-ietf-codec-oggopus for an example of 
such a section for a container.

---

From: Reto Kromer <[email-masked]>
Date: Wed, 30 Dec 2015 08:09:39 +0100

>Tim, is a “Security” section required?

I'm not Tim, but yes, this is explicitly required. See
RFC 7332:

  https://tools.ietf.org/html/rfc7332

Best regards, Reto

AV Preservation by reto.ch
chemin du Suchet 5 | 1024 Ecublens | Switzerland
Web: http://reto.ch | Twitter: @retoch