Are not there any satisfiable codecs?
-@table @asis
-@item @url{https://wiki.theory.org/BitTorrentSpecification#Bencoding, Bencode}
- Is very simple and deterministic. But it has a few data types, even
- lacking human-readable strings.
-@item @url{https://www.ietf.org/archive/id/draft-rivest-sexp-08.html, Canonical S-Expressions}
- Is another interesting candidate with relatively simple encoding,
- but without enough data types.
-@item @url{https://bsonspec.org/, BSON}
- Is pretty simple too, having enough data types. But it is not able
- to transfer strings and lists longer than their 32-bit length. Also
- that encoding is not compact.
-@item @url{https://msgpack.org/, MessagePack}
- Is another good candidate with rather simple encoding. But it still
- can not transfer large (>4GiB) strings. And it does not have
- deterministic encoding rules.
-@item @url{https://datatracker.ietf.org/doc/html/rfc8949, CBOR}
- Looked like the promising one, having nearly the same aims as we
- did, even with Deterministic Encoded CBOR version description and
- being pretty compact in binary form.
-
- But it is the @strong{most} complicated from all the codecs
- mentioned above, failing their main claim of being simple. Streaming
- encoding can reduce both the code size and memory usage of your
- application, but deterministic CBOR encoding prohibits it.
-
- Moreover hardly you will find CBOR libraries supporting strict
- validation of deterministically encoded CBOR structures.
-@end table
+@multitable @columnfractions .30 .10 .10 .10 .10 .10 .10 .10
+
+@headitem name @tab
+ Schemaless @tab
+ Simple @tab
+ Deterministic @tab
+ Streamable @tab
+ Compact @tab
+ Large strings @tab
+ Many types
+
+@item ASN.1 DER @tab N @tab @strong{N} @tab Y @tab N @tab ~ @tab Y @tab ~
+@item ASN.1 CER @tab N @tab @strong{N} @tab Y @tab Y @tab ~ @tab Y @tab ~
+@item @url{https://protobuf.dev/, Protocol Buffers}
+ @tab N @tab ~ @tab N @tab N @tab Y @tab N @tab Y
+@item @url{https://flatbuffers.dev/, FlatBuffers}
+ @tab Y @tab N @tab N @tab N @tab N @tab Y @tab Y
+@item @url{https://bsonspec.org/, BSON} @tab
+ Y @tab Y @tab N @tab N @tab N @tab N @tab Y
+@item @url{https://msgpack.org/, MessagePack} @tab
+ Y @tab Y @tab N @tab N @tab N @tab N @tab Y
+@item @url{https://datatracker.ietf.org/doc/html/rfc8949, CBOR} @tab
+ Y @tab N @tab N @tab Y @tab Y @tab Y @tab Y
+@item Deterministic Encoded CBOR @tab
+ Y @tab N @tab Y @tab N @tab Y @tab Y @tab Y
+@item @url{http://cr.yp.to/proto/netstrings.txt, Netstring} @tab
+ Y @tab Y @tab Y @tab N @tab N @tab Y @tab N
+@item @url{https://wiki.theory.org/BitTorrentSpecification#Bencoding, Bencode} @tab
+ Y @tab Y @tab Y @tab Y @tab N @tab Y @tab N
+@item @url{https://en.wikipedia.org/wiki/Canonical_S-expressions, Canonical S-expression}
+ @tab Y @tab Y @tab Y @tab Y @tab N @tab Y @tab N
+@item YAC @tab
+ Y @tab Y @tab Y @tab Y @tab Y @tab Y @tab Y
+
+@end multitable
+
+@itemize
+@item Schemaless formats are easier to deal with in heterogeneous
+ environments, with wide range of software. But with the price of
+ bigger size and harder validation as a rule.
+@item Streamable formats allow you to send a part of the data
+ immediately, for example element of the list or map. Simplifying
+ encoder and requiring less memory usage. All formats who needs to
+ know the size of maps/lists are not streamable.
+@item Compactness means small amount of bytes overhead for the given
+ data. For example any codec with ASCII decimal lengths of the
+ strings or integers representation is not compact.
+@item "Large strings" is a strings bigger than 4GiB. Some codecs allow
+ you to send only even 2GiB of data in a single chunk. That will
+ force you code and structures be more complex when dealing with big
+ data transfer
+@item "Many types" is a subjective thing of course. If codec can encode
+ everything JSON can, then it is enough types. ASN.1 codecs support
+ many various types, but they can not represent arbitrary map.
+@item Hardly you will find CBOR libraries supporting strict validation
+ of deterministically encoded CBOR structures.
+@end itemize
YAC deals with those problems by using only streaming deterministic
-encoding. YAC Ain't a CBOR. Its other important differences:
+encoding. Its other important differences:
@itemize
@item It lacks any kind of tagging support, making the whole codec