3 ms·

The bittorrent protocol uses a very simple binary data representation system: bencoding. It can be described in a single paragraph: https://www.bittorrent.org/

The bittorrent protocol uses a very simple binary data representation system: bencoding. It can be described in a single paragraph: https://www.bittorrent.org/beps/bep_0003.html#bencoding https://www.bittorrent.org/beps/bep_0003.html#bencoding Although it supports only dictionaries, lists, ints and strings, it may be enough for your use case and is easily extendable. Edit: also ASN.1 does not solve futute-extending out-of-the-box. In JSON/bencoding/XML, it's trivial to add another key/element to a dictionary/array/element and allow applications to use it if they can and ignore it otherwise. Okay, TLV looks like it could handle that, but there's nothing about it in the description language itself.

XAMPPRocky 5y ago
> also ASN.1 does not solve futute-extending out-of-the-box. In JSON/bencoding/XML, it's trivial to add another key/element to a dictionary/array/element and allow applications to use it if they can and ignore it otherwise. Okay, TLV looks like it could handle that, but there's nothing about it in the description language itself. This is wrong. ASN.1 has always had support for "extensibility" out of the box. See section 52 of X.680[0] for complete details but I've included a couple of examples below. Also ASN.1 unlike other IDLs allows encodings to optionally take advantage of whether a type is considered in extensible. For example in PER, a type is a smaller encoding when it is not extensible. A ::= INTEGER (0..10, ..., 12) -- A is 0 to 10, or 12. -- V1 of B contains `a, b`, V2 contains `a, b, c` B ::= SEQUENCE { a INTEGER, b BOOLEAN, ... c OCTET STRING, } [0]: https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.680-202102-I!!PDF-E&type=items https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.68...
- jesprenj 5y ago
  Thanks for the information! I forgot to mention the only "research" of ASN.1 I ever did is the linked post (:

XAMPPRocky 5y ago

> also ASN.1 does not solve futute-extending out-of-the-box. In JSON/bencoding/XML, it's trivial to add another key/element to a dictionary/array/element and allow applications to use it if they can and ignore it otherwise. Okay, TLV looks like it could handle that, but there's nothing about it in the description language itself. This is wrong. ASN.1 has always had support for "extensibility" out of the box. See section 52 of X.680[0] for complete details but I've included a couple of examples below. Also ASN.1 unlike other IDLs allows encodings to optionally take advantage of whether a type is considered in extensible. For example in PER, a type is a smaller encoding when it is not extensible. A ::= INTEGER (0..10, ..., 12) -- A is 0 to 10, or 12. -- V1 of B contains `a, b`, V2 contains `a, b, c` B ::= SEQUENCE { a INTEGER, b BOOLEAN, ... c OCTET STRING, } [0]: https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.680-202102-I!!PDF-E&type=items https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.68...

jesprenj 5y ago
Thanks for the information! I forgot to mention the only "research" of ASN.1 I ever did is the linked post (: