4 ms·

An interesting project! Regarding some of the ASN.1 comparison characteristics, I'm not quite sure if I understand--there's a lot to read here, and it's likely

An interesting project! Regarding some of the ASN.1 comparison characteristics, I'm not quite sure if I understand--there's a lot to read here, and it's likely I've missed something by a lack of acquaintance with your documents/specifications. But a couple comments: - Cyclic data: ASN.1 supports recursive data structures.[0] - Time zones: ASN.1 supports ISO 8601 time types, including specification of local or UTC time.[1] I'm not sure how else you might manage this, but perhaps it's not what you mean? - Bin + txt: Again, I'm unclear on what you mean here, but ASN.1 has both binary and text-based encodings (X.693 for XML encoding rules[2], X.697 for JSON[3], and an RFC for generic string encoding rules[4]; compilers support input and output). - Versioned: Also a little unclear to me--it seems like the intent is to capture the version of data sent across the wire relative to the schema used in its creation or else that it ties the encoding to the notation/encoding specification. ASN.1 supports extensibility (the ellipsis marker, ...[5]) and versioning,[6] but AFAIK there's nothing that forces a DER-encoded document to describe whether it's from the first release or the newest. Relative to security, it also supports various canonical encodings. [0]: https://www.obj-sys.com/asn1tutorial/node19.html https://www.obj-sys.com/asn1tutorial/node19.html and X.680 3.8.61. [1]: https://www.itu.int/rec/T-REC-X.680-X.693-202102-I/en https://www.itu.int/rec/T-REC-X.680-X.693-202102-I/en (see X.680 §38 and Annex J.2.11) [2]: https://www.itu.int/rec/T-REC-X.693/en https://www.itu.int/rec/T-REC-X.693/en -- X.694 governs interoperability between XSD and ASN.1 schema. [3]: https://www.itu.int/rec/T-REC-X.697/en https://www.itu.int/rec/T-REC-X.697/en [4]: https://datatracker.ietf.org/doc/rfc3641/ https://datatracker.ietf.org/doc/rfc3641/ [5]: See X.680 3.8.41 [6]: See X.680 §3.8.95

kstenerud 5y ago
> - Cyclic data: ASN.1 supports recursive data structures. Not sure if I missed something, but the link was talking about self-referential types, not self-referential data. For example (in CTE): &a:{ "recursive link" = $a } In the above example, `&a:` means mark the next object and give it symbolic identifier "a". `$a` means look up the reference to symbolic identifier "a". So this is a map whose "recusive link" key is a pointer to the map itself. How this data is represented internally by the receiver of such a document (a table, a dictionary, a struct, etc) is up to the implementation, but the intent is for a structure whose data points to itself. > - Time zones: ASN.1 supports ISO 8601 time types, including specification of local or UTC time. Yes, this is the major failing of ISO 8601: They don't have true time zones. It only uses UTC offsets, which are a bad idea for so many reasons. https://github.com/kstenerud/concise-encoding/blob/master/ce-structure.md#how-to-record-time https://github.com/kstenerud/concise-encoding/blob/master/ce... > - Bin + txt: Again, I'm unclear on what you mean here, but ASN.1 has both binary and text-based encodings Ah cool, didn't know about those. > - Versioned: Also a little unclear to me The intent is to specify the exact document formatting that the decoder can expect. For example we could in theory decide to make CBE version 2 a bit-oriented format instead of byte-oriented in order to save space at the cost of processing time. It would be completely unreadable to a CBE 1 decoder, but since the document starts with 0x83 0x02 instead of 0x83 0x01, a CBE 1 decoder would say "I can't decode this" and a CBE 2 decoder would say "I can decode this". With documents versioned to the spec, we can change even the fundamental structure of the format to deal with ANYTHING that might come up in future. Maybe a new security flaw in CBE 1 is discovered. Maybe a new data type becomes so popular that it would be crazy not to include it, etc. This avoids polluting the simpler encodings with deprecated types (see BSON) and bloating the format.

kstenerud 5y ago

> - Cyclic data: ASN.1 supports recursive data structures. Not sure if I missed something, but the link was talking about self-referential types, not self-referential data. For example (in CTE): &a:{ "recursive link" = $a } In the above example, `&a:` means mark the next object and give it symbolic identifier "a". `$a` means look up the reference to symbolic identifier "a". So this is a map whose "recusive link" key is a pointer to the map itself. How this data is represented internally by the receiver of such a document (a table, a dictionary, a struct, etc) is up to the implementation, but the intent is for a structure whose data points to itself. > - Time zones: ASN.1 supports ISO 8601 time types, including specification of local or UTC time. Yes, this is the major failing of ISO 8601: They don't have true time zones. It only uses UTC offsets, which are a bad idea for so many reasons. https://github.com/kstenerud/concise-encoding/blob/master/ce-structure.md#how-to-record-time https://github.com/kstenerud/concise-encoding/blob/master/ce... > - Bin + txt: Again, I'm unclear on what you mean here, but ASN.1 has both binary and text-based encodings Ah cool, didn't know about those. > - Versioned: Also a little unclear to me The intent is to specify the exact document formatting that the decoder can expect. For example we could in theory decide to make CBE version 2 a bit-oriented format instead of byte-oriented in order to save space at the cost of processing time. It would be completely unreadable to a CBE 1 decoder, but since the document starts with 0x83 0x02 instead of 0x83 0x01, a CBE 1 decoder would say "I can't decode this" and a CBE 2 decoder would say "I can decode this". With documents versioned to the spec, we can change even the fundamental structure of the format to deal with ANYTHING that might come up in future. Maybe a new security flaw in CBE 1 is discovered. Maybe a new data type becomes so popular that it would be crazy not to include it, etc. This avoids polluting the simpler encodings with deprecated types (see BSON) and bloating the format.