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

From: Michael Richardson <[email-masked]>
Date: Thu, 07 Jun 2018 13:08:45 -0400

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 https://tools.ietf.org/html/rfc8126#section-4.4

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

---

From: Dave Rice <[email-masked]>
Date: Wed, 13 Jun 2018 10:16:23 -0400

> On Jun 7, 2018, at 1:08 PM, Michael Richardson <[email-masked]> wrote:
> 

Keeping it to the 7-bit ascii range is fine with me. Nudging Steve for comment as he’s the one that originated use of element id easter eggs outside of the 0x20 to 0x7E range.

> Please see https://tools.ietf.org/html/rfc8126#section-4.4

I suggest including an "[@!RFC8126]” at the end of this sentence to create a normative reference to RFC8126.

> I don't think it leaves any: it's all experimental.

This may be related to the off by one issue. If "Five Byte Element IDs (values from 268435457 upwards) are reserved for Experimental use.”
Both 268435456 and 268435457 require a five element id, so in my first reading it seems like this sentence was saying that:

268435456, reservation status unknown
268435457, reservation status unknown
>268435457, reserved

> Do we really need that any Five Byte Element IDs in specifications?

I don’t need five byte element IDs in this specification, but a user defining an EBML Document Type should be able to read this document and understand if and how they can create their own identifiers at any length.

Dave

---

From: Michael Richardson <[email-masked]>
Date: Wed, 13 Jun 2018 11:23:18 -0400

> This may be related to the off by one issue. If "Five Byte Element IDs
    > (values from 268435457 upwards) are reserved for Experimental use.”
    > Both 268435456 and 268435457 require a five element id, so in my first
    > reading it seems like this sentence was saying that:

    > 268435457, reservation status unknown

I would mark them as simply RESERVED, that way nobody can get the encoding
wrong.

    > I don’t need five byte element IDs in this specification, but a user
    > defining an EBML Document Type should be able to read this document and
    > understand if and how they can create their own identifiers at any
    > length.

The First Come First Served space is usually easiest.

If you feel that the text needs to be friendly, or explain things better to
non-IETF types, that's completely reasonable.
My goal is to write text that *IANA* will understand, and that represents the
rough consensus of the group.
So, again, are there any objections to the essential plan?

---

From: Dave Rice <[email-masked]>
Date: Wed, 13 Jun 2018 13:47:52 -0400

> On Jun 13, 2018, at 11:23 AM, Michael Richardson <[email-masked]> wrote:
> 
> 

The essential plan sounds fine with me. Looking forward to reviewing an updated pull request.
Dave

---

From: Jerome Martinez <[email-masked]>
Date: Wed, 13 Jun 2018 21:20:52 +0200

> So, again, are there any objections to the essential plan?

It is fine for me, thanks for taking care of it.