|
|
|
|
|
|
by XAMPPRocky
1635 days 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.68... |
|
|