Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Element range attribute excludes the Binary type #423

Open
hubblec4 opened this issue Feb 27, 2023 · 3 comments
Open

Element range attribute excludes the Binary type #423

hubblec4 opened this issue Feb 27, 2023 · 3 comments
Labels
bug enhancement Add more content to the document, explaning more things errata-rfc8794 Errors found in RFC 8794

Comments

@hubblec4
Copy link

Currently the range attribute is allowed only for numerical element types,
but Matroska has two Binary elements with a definde range.

ietf-wg-cellar/matroska-specification#730

@robUx4 robUx4 added bug enhancement Add more content to the document, explaning more things errata-rfc8794 Errors found in RFC 8794 labels Mar 5, 2023
@robUx4
Copy link
Contributor

robUx4 commented Mar 5, 2023

Indeed, either we don't use the range field or we change the rules here. The text is pretty clear that it's only for "number" values: https://www.rfc-editor.org/rfc/rfc8794.html#expression-of-range

I think the idea of the range field, rather than just being rules written in the text, is that they are machine readable and parseable, to generate code accordingly. It becomes tricky to describe with that field for complex binary blobs, which EBML or Matroska are not supposed to interpret on their own.

So in the spirit of the separation of parsing levels, I would not put binary ranges inside the range field but in the text or in the usage notes.

@hubblec4
Copy link
Author

hubblec4 commented Mar 5, 2023

I would not put binary ranges inside the range field but in the text or in the usage notes.

OK. Sounds logical and I think usage notes could be enough for the moment.

Would a new range-attribute makes sense, -> range_binary ?

@robUx4
Copy link
Contributor

robUx4 commented Mar 5, 2023

It would not be machine readable. Binary data are not meant to be interpreted at the EBML level. And you can't easily say bit 4 must be set if bit 19-20 are going to be used. It's just impractical a the EBML and Matroska levels.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug enhancement Add more content to the document, explaning more things errata-rfc8794 Errors found in RFC 8794
Projects
None yet
Development

No branches or pull requests

2 participants