7 ms·

Disclaimer: I wrote and maintain a MessagePack implementation. Hey that's me! Yeah they fixed that, but there's other parts of the spec that are basically unw

Disclaimer: I wrote and maintain a MessagePack implementation. Hey that's me! Yeah they fixed that, but there's other parts of the spec that are basically unworkable like indefinite length values, "canonicalization", and tags, making it essentially MP (MP does have extension types, I should say, the virtue of tossing out CBOR's tags is you then don't have to implement things like datetimes/timezones, bignums, etc), and indeed at least FIDO tosses this all out: https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html#ctap2-canonical-cbor-encoding-form https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-cl... Beyond that, CBOR is MessagePack. The story is that Carsten Bormann wanted to create an IETF standardized MP version, the creators asked him not to (after he acted in pretty bad faith), he forked off a version, added the aforementioned ill-advised tweaks, named it after himself, and submitted it anyway. All this design by committee stuff is mostly wrong--though IETF has modified it by committee since. There's no reason an MP implementation has to be slower than a CBOR implementation. If a given library wanted to be very fast it could be. If anything, the fact that CBOR more or less requires you to allocate should put a ceiling on how fast it can really be. Or, put another way, benchmarks of dynamic language implementations of a serialization format aren't a high signal indication of its speed ceiling. If you use a dynamic language and speed is a concern to this degree, you'd write an adapter yourself, probably building on one of the low level implementations. That said, people are usually disappointed by MP's speed over JSON. A lot of engineering hours have gone into making JSON fast, to the point where I don't think it ever made sense to choose MP over it for speed reasons (there are other good reasons). Other posters here have pointed out that your metrics are usually dominated by something else. But finally, CBOR is fine! The implementations are good and it's widely used. Users of CBOR and MP alike will probably have very similar experiences unless you have a niche use case (on an embedded device that can't allocate, you really need bignums, etc).

magicalhippo 2y ago
> Yeah they fixed that, but there's other parts of the spec that are basically unworkable Yeah it just made me chuckle cause it was such an obvious oversight and a fun way of pointing it out. That said I totally get that writing specs are hard, so not dissing the authors as such. > There's no reason an MP implementation has to be slower than a CBOR implementation. Yeah that also struck me. Like ok that CBOR library might be faster than that MP library, but could be either is just missing some optimizations. And it didn't look like there were orders-of-magnitude differences in either case. Anyway I've only looked at CBOR and MessagePack when I dabbled with some microcontroller projects. I found both to be too big, ie couldn't find a library suitably small, either compiled size or memory requirements or both. So I ended up with JSON for those due to that. Using a SAX-like parser I could avoid dynamic allocations entirely (or close enough).
- camgunz 2y ago
  > That said I totally get that writing specs are hard, so not dissing the authors as such. Oh definitely. Yeah maybe I come off as anti-spec or something, but in this case I just think MP was really well thought out, and then Bormann hung a bunch of stuff on it that really wasn't, and I'm salty haha. > Anyway I've only looked at CBOR and MessagePack when I dabbled with some microcontroller projects. I found both to be too big, ie couldn't find a library suitably small, either compiled size or memory requirements or both. So I ended up with JSON for those due to that. Using a SAX-like parser I could avoid dynamic allocations entirely (or close enough). Whaa? I wrote an MP implementation specifically for this use case: https://github.com/camgunz/cmp https://github.com/camgunz/cmp. JSON parsing terrifies me; there was some table of tons of JSON (de)serializers with all their weirdo bugs that I never would've thought of. There are probably pretty good test suites now though? I've never looked.
  - magicalhippo 2y ago
    > I wrote an MP implementation specifically for this use case Perhaps I missed that, can't recall. Will definitely try (again) tho, looks very promising. As for parsing JSON, the upside is that's its trivial to debug over serial, both viewing and sending, and in my case I could assume limited shenanigans and fail hard if there were issues.
    - camgunz 2y ago
      > As for parsing JSON, the upside is that's its trivial to debug over serial, both viewing and sending, and in my case I could assume limited shenanigans and fail hard if there were issues. Totally yeah, text formats are way easier to work with. This is a very undersold benefit of JSON.
Joker_vD 2y 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.
- camgunz 2y ago
  No in practice people just ignore the spec, but that's not really what you're hoping for when writing one.
  - Joker_vD 2y ago
    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?
    - camgunz 2y ago
      > 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 https://datatracker.ietf.org/doc/html/rfc8949#section-5.1 [1]: https://datatracker.ietf.org/doc/html/rfc8949#name-indefinite-lengths-for-some https://datatracker.ietf.org/doc/html/rfc8949#name-indefinit... [2]: https://datatracker.ietf.org/doc/html/rfc8949#name-indefinite-length-byte-stri https://datatracker.ietf.org/doc/html/rfc8949#name-indefinit...
lifthrasiir 2y ago
> there's other parts of the spec that are basically unworkable like indefinite length values, "canonicalization", and tags, making it essentially MP [...]. I'm not sure but your wording suggests that CBOR is equally unworkable as MP because they implement the same feature set...? But anyway, those features are not always required but useful from time to time and any complete serialization format ought to include them in some way. Canonicalization for example is an absolute requirement for cryptographic applications; you know JWT got so cursed due to JSON's lack of this property. Tag facilities are well thought out in my opinion, while specific tags are less so but implementations can choose to ignore them anyway---thankfully after the aforementioned revisions. > The story is that Carsten Bormann wanted to create an IETF standardized MP version, the creators asked him not to (after he acted in pretty bad faith), he forked off a version, added the aforementioned ill-advised tweaks, named it after himself, and submitted it anyway. To me it looks more like Markdown vs. CommonMark disputes; John Gruber repeatedly refused to standardize Markdown or even any subset in spite of huge needs because he somehow believes that standardization ruins simplicity. I don't really agree---simple but correct standard is possible, albeit with efforts. So people did their own standardization including CommonMark, which subtly differ from each other, but any further efforts would be inadvently blocked by Gruber. MessagePack seems no different to me.
- elcritch 2y ago
  > To me it looks more like Markdown vs. CommonMark disputes; John Gruber repeatedly refused to standardize Markdown or even any subset in spite of huge needs because he somehow believes that standardization ruins simplicity. I don't really agree---simple but correct standard is possible, albeit with efforts. Right, that was my take after reading about it for a while. The way MessagePack and CBOR frame the problem is fairly different, with CBOR intentionally opting for an open tagging system. Plus it feels a bit childish brining up the circumstances of the fork (correct or not) when they've clearly diverged bit in purpose and scope. The Markdown vs CommonMark is an apt comparison. I've used both and both work very well. They're both stable, and be parsed into native objects at a speed nearing that of memory copy with the right implementations.
  - 2y ago
eqvinox 2y ago
> The story is that Carsten Bormann wanted to create an IETF standardized MP version, the creators asked him not to (after he acted in pretty bad faith), he forked off a version, added the aforementioned ill-advised tweaks, named it after himself, and submitted it anyway. All this design by committee stuff is mostly wrong--though IETF has modified it by committee since. The IETF does not have a committee process. The CBOR RFC has 2 authors, Carsten Bormann and Paul Hoffman. Authors bring documents into the IETF, and the process is basically that everyone bashes¹ on it (the doc, not the people, please) until either there's a reasonable amount of agreement or they give up. And everyone here means everyone. You could've sent a mail to the mailing list to bash on CBOR. Other MessagePack people could've sent a mail to the mailing list. You could've had comments relayed on the microphone for IETF meetings. Did that happen? One of very few things that won't fly there is that standardization in general is bad, because the IETF doesn't believe that. But that's only the general argument — "standardizing this particular thing is bad" can and has gone through before. From some sibling comments I see this may have been a major point of contention, but I don't know it was the only one. *If* it is, it's in poor faith to drag this personal dispute into the discussion (I don't know what other disagreements and bad faith there were.) ¹ bashing here means pointing out flaws. It's up to the authors to make text changes to address them.
- camgunz 2y ago
  Aren't there a bunch of emails and what-not about it? I think that's what people are referring to. EDIT: > Other MessagePack people could've sent a mail to the mailing list. You could've had comments relayed on the microphone for IETF meetings. Did that happen? Yes
  - eqvinox 2y ago
    > Aren't there a bunch of emails and what-not about it? I think that's what people are referring to. Sorry, what "it"/"that" is this? I'm failing to process due to unclear references. > > Other MessagePack people could've sent a mail to the mailing list. You could've had comments relayed on the microphone for IETF meetings. Did that happen? > Yes Can you point to anything? Best I can find is https://mailarchive.ietf.org/arch/msg/apps-discuss/iZM_ZqA9ix8PU91MlgrOuLueyhQ/ https://mailarchive.ietf.org/arch/msg/apps-discuss/iZM_ZqA9i... but that's not particularly useful. Boils down to questioning the utility of standards...

magicalhippo 2y ago

> Yeah they fixed that, but there's other parts of the spec that are basically unworkable Yeah it just made me chuckle cause it was such an obvious oversight and a fun way of pointing it out. That said I totally get that writing specs are hard, so not dissing the authors as such. > There's no reason an MP implementation has to be slower than a CBOR implementation. Yeah that also struck me. Like ok that CBOR library might be faster than that MP library, but could be either is just missing some optimizations. And it didn't look like there were orders-of-magnitude differences in either case. Anyway I've only looked at CBOR and MessagePack when I dabbled with some microcontroller projects. I found both to be too big, ie couldn't find a library suitably small, either compiled size or memory requirements or both. So I ended up with JSON for those due to that. Using a SAX-like parser I could avoid dynamic allocations entirely (or close enough).

camgunz 2y ago
> That said I totally get that writing specs are hard, so not dissing the authors as such. Oh definitely. Yeah maybe I come off as anti-spec or something, but in this case I just think MP was really well thought out, and then Bormann hung a bunch of stuff on it that really wasn't, and I'm salty haha. > Anyway I've only looked at CBOR and MessagePack when I dabbled with some microcontroller projects. I found both to be too big, ie couldn't find a library suitably small, either compiled size or memory requirements or both. So I ended up with JSON for those due to that. Using a SAX-like parser I could avoid dynamic allocations entirely (or close enough). Whaa? I wrote an MP implementation specifically for this use case: https://github.com/camgunz/cmp https://github.com/camgunz/cmp. JSON parsing terrifies me; there was some table of tons of JSON (de)serializers with all their weirdo bugs that I never would've thought of. There are probably pretty good test suites now though? I've never looked.
- magicalhippo 2y ago
  > I wrote an MP implementation specifically for this use case Perhaps I missed that, can't recall. Will definitely try (again) tho, looks very promising. As for parsing JSON, the upside is that's its trivial to debug over serial, both viewing and sending, and in my case I could assume limited shenanigans and fail hard if there were issues.
  - camgunz 2y ago
    > As for parsing JSON, the upside is that's its trivial to debug over serial, both viewing and sending, and in my case I could assume limited shenanigans and fail hard if there were issues. Totally yeah, text formats are way easier to work with. This is a very undersold benefit of JSON.

Joker_vD 2y 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.

camgunz 2y ago
No in practice people just ignore the spec, but that's not really what you're hoping for when writing one.
- Joker_vD 2y ago
  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?
  - camgunz 2y ago
    > 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 https://datatracker.ietf.org/doc/html/rfc8949#section-5.1 [1]: https://datatracker.ietf.org/doc/html/rfc8949#name-indefinite-lengths-for-some https://datatracker.ietf.org/doc/html/rfc8949#name-indefinit... [2]: https://datatracker.ietf.org/doc/html/rfc8949#name-indefinite-length-byte-stri https://datatracker.ietf.org/doc/html/rfc8949#name-indefinit...

lifthrasiir 2y ago

> there's other parts of the spec that are basically unworkable like indefinite length values, "canonicalization", and tags, making it essentially MP [...]. I'm not sure but your wording suggests that CBOR is equally unworkable as MP because they implement the same feature set...? But anyway, those features are not always required but useful from time to time and any complete serialization format ought to include them in some way. Canonicalization for example is an absolute requirement for cryptographic applications; you know JWT got so cursed due to JSON's lack of this property. Tag facilities are well thought out in my opinion, while specific tags are less so but implementations can choose to ignore them anyway---thankfully after the aforementioned revisions. > The story is that Carsten Bormann wanted to create an IETF standardized MP version, the creators asked him not to (after he acted in pretty bad faith), he forked off a version, added the aforementioned ill-advised tweaks, named it after himself, and submitted it anyway. To me it looks more like Markdown vs. CommonMark disputes; John Gruber repeatedly refused to standardize Markdown or even any subset in spite of huge needs because he somehow believes that standardization ruins simplicity. I don't really agree---simple but correct standard is possible, albeit with efforts. So people did their own standardization including CommonMark, which subtly differ from each other, but any further efforts would be inadvently blocked by Gruber. MessagePack seems no different to me.

elcritch 2y ago
> To me it looks more like Markdown vs. CommonMark disputes; John Gruber repeatedly refused to standardize Markdown or even any subset in spite of huge needs because he somehow believes that standardization ruins simplicity. I don't really agree---simple but correct standard is possible, albeit with efforts. Right, that was my take after reading about it for a while. The way MessagePack and CBOR frame the problem is fairly different, with CBOR intentionally opting for an open tagging system. Plus it feels a bit childish brining up the circumstances of the fork (correct or not) when they've clearly diverged bit in purpose and scope. The Markdown vs CommonMark is an apt comparison. I've used both and both work very well. They're both stable, and be parsed into native objects at a speed nearing that of memory copy with the right implementations.
- 2y ago

eqvinox 2y ago

> The story is that Carsten Bormann wanted to create an IETF standardized MP version, the creators asked him not to (after he acted in pretty bad faith), he forked off a version, added the aforementioned ill-advised tweaks, named it after himself, and submitted it anyway. All this design by committee stuff is mostly wrong--though IETF has modified it by committee since. The IETF does not have a committee process. The CBOR RFC has 2 authors, Carsten Bormann and Paul Hoffman. Authors bring documents into the IETF, and the process is basically that everyone bashes¹ on it (the doc, not the people, please) until either there's a reasonable amount of agreement or they give up. And everyone here means everyone. You could've sent a mail to the mailing list to bash on CBOR. Other MessagePack people could've sent a mail to the mailing list. You could've had comments relayed on the microphone for IETF meetings. Did that happen? One of very few things that won't fly there is that standardization in general is bad, because the IETF doesn't believe that. But that's only the general argument — "standardizing this particular thing is bad" can and has gone through before. From some sibling comments I see this may have been a major point of contention, but I don't know it was the only one. *If* it is, it's in poor faith to drag this personal dispute into the discussion (I don't know what other disagreements and bad faith there were.) ¹ bashing here means pointing out flaws. It's up to the authors to make text changes to address them.

camgunz 2y ago
Aren't there a bunch of emails and what-not about it? I think that's what people are referring to. EDIT: > Other MessagePack people could've sent a mail to the mailing list. You could've had comments relayed on the microphone for IETF meetings. Did that happen? Yes
- eqvinox 2y ago
  > Aren't there a bunch of emails and what-not about it? I think that's what people are referring to. Sorry, what "it"/"that" is this? I'm failing to process due to unclear references. > > Other MessagePack people could've sent a mail to the mailing list. You could've had comments relayed on the microphone for IETF meetings. Did that happen? > Yes Can you point to anything? Best I can find is https://mailarchive.ietf.org/arch/msg/apps-discuss/iZM_ZqA9ix8PU91MlgrOuLueyhQ/ https://mailarchive.ietf.org/arch/msg/apps-discuss/iZM_ZqA9i... but that's not particularly useful. Boils down to questioning the utility of standards...