Comment by Joker_vD

5 months ago

> parts of the spec that are basically unworkable like indefinite length values,

Is this really a problem in practice? Say, an HTTP/1.1 message also may have the body of indefinite length, and it usually works just fine.

No in practice people just ignore the spec, but that's not really what you're hoping for when writing one.

  • Is it? Take JSON: its spec states that JSON numbers are theoretically infinite precision rationals, but implementations are free to impose their own restrictions. And they do: Python, for instance, is perfectly happy with both serializing and deserializing e.g. 2*7000 while many other implementations (e.g. Golang's) would balk at such values. Still, it works out mostly fine in practice. Is CBOR really worse than JSON?

    • > Is it? Take JSON: its spec states that JSON numbers are theoretically infinite precision rationals, but implementations are free to impose their own restrictions.

      Well like you say JSON gives you an out: "An implementation may set limits on the range and precision of numbers"; CBOR doesn't. I'm not really making a claim about CBOR vs. JSON (or HTTP). My TL;DR on this is: the nice thing about MP is that it asks very little of implementations, and that gives them a lot of freedom. CBOR asks way more of implementations--which by itself isn't bad--but it reckons with the tradeoffs not at all. A good example is "indefinite-length encodings"; this paragraph is still in the spec:

      ---

      Note that some applications and protocols will not want to use indefinite-length encoding. Using indefinite-length encoding allows an encoder to not need to marshal all the data for counting, but it requires a decoder to allocate increasing amounts of memory while waiting for the end of the item. This might be fine for some applications but not others.

      ---

      You might think, "well that's not so bad, maybe I don't have to implement this, after all it is in the seemingly optional 'Creating CBOR-Based Protocols' section", but unfortunately it's a core part of CBOR [1].

      Confusingly, CBOR seems to care about this kind of thing: "The design does not allow nesting indefinite-length strings as chunks into indefinite-length strings. If it were allowed, it would require decoder implementations to keep a stack, or at least a count, of nesting levels." [2]. But what's the difference between having to keep a stack of nesting levels and having to allocate as much as your network peer tells you to?

      The fact is you can't reasonably implement streaming in a data representation format. It's protocol-level functionality, which is why HTTP/1.1's description of it is way more useful. Including it is pretty indicative of the whole "let's just throw some features into the spec and see what happens" attitude.

      [0]: https://datatracker.ietf.org/doc/html/rfc8949#section-5.1

      [1]: https://datatracker.ietf.org/doc/html/rfc8949#name-indefinit...

      [2]: https://datatracker.ietf.org/doc/html/rfc8949#name-indefinit...

      2 replies →