Subject: [Cellar] VINT_DATA of all ontes

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

ebml says in section 7:

     Additionally,
     an "Element ID" with binary encoding of "1111 1111" is invalid since
     the "VINT_DATA" section is set to all one values, whereas an "Element
     ID" with binary encoding of "0100 0000 0111 1111" stores a
     semantically equal "VINT_DATA" and is the shortest possible
     "VINT" encoding.

It seems that there is a prohibition on VINT_DATA that is all ones.
I can't find a place in section 6 that says this.  Is this a restriction on
all VINT_DATA, or just ones used for Element ID?

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Dave Rice <[email-masked]>
Date: Thu, 7 Jun 2018 10:50:21 -0400

> On Jun 6, 2018, at 9:49 PM, Michael Richardson <[email-masked]> wrote:
> 
> 
> ebml says in section 7:
> 
>     Additionally,
> I can't find a place in section 6 that says this.

Just before your quote, I see:

"The VINT_DATA component of the Element ID MUST NOT be either defined or written as either all zero values or all one values.”

> Is this a restriction on

This is specific to the Element ID. An all-one VINT_DATA in Element Data Size (also a VINT) means that the size is unknown. See:

   An "Element Data Size" with all "VINT_DATA" bits set to one is
   reserved as an indicator that the size of the "EBML Element" is
   unknown.  The only reserved value for the "VINT_DATA" of "Element
   Data Size" is all bits set to one.

Dave

---

From: Michael Richardson <[email-masked]>
Date: Thu, 07 Jun 2018 12:57:59 -0400

> "The VINT_DATA component of the Element ID MUST NOT be either defined
    > or written as either all zero values or all one values.”

Ah, my eyes missed that.

Could we split this into three paragraphs, and can we add some explanation of
why all zeros and all ones is forbidden?

    >> all VINT_DATA, or just ones used for Element ID?

Would the WG like to simply skip allocation of Element IDs values which
would be all ones in the appropriate encoding?  Clearly, one can go to the
next bigger VINT size and express it, but it seems like skipping that value
is simpler.  I believe that my suggested IANA Considerations text on
this value does that.

---

From: Steve Lhomme <[email-masked]>
Date: Sun, 17 Jun 2018 17:05:40 +0200

> why all zeros and all ones is forbidden?

In general do why want to explain why this or that technical choice
was made ? It doesn't seem to be the case in the RFCs I know and might
add considerable work.

If it's just for this particular case it can be done.

> is simpler.  I believe that my suggested IANA Considerations text on

Should the IANA part restate the rules on how the IDs should be
understood and what is/isn't allowed ? Or maybe we can just put a
reference to the section about EBML IDs ?

> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar
>

-- 
Steve Lhomme
Matroska association Chairman