I wouldn't want fractions or the proposed big integers to be part of the MessagePack spec. The spec should be as minimalistic as possible—and saying that certain extensions are optional is not enough. MessagePack libraries should be expected to support all of the spec.

The one extension I'd support adding to the spec would be for a UUID type: either a 128-bit unsigned integer, or a 16-byte binary array.

@gappleto97 Why did you close this?

Because #249 superceded it. A lot of my spec is in there (though not credited via git), so I closed this until I am told otherwise.

I thought they were a maintainer of this. It appears I was mistaken. Should I reopen?

I suggest that you keep it open so it is shown as an alternative.

@dchenk The UUID is a less general type of data vs. big integer yet you are suggesting it to be implemented over the latter.

@konsolebox I'm not actually suggesting to add a UUID type. (The only reason I'd downplay the importance of "generality" here would be because UUIDs are probably much more commonly used than 128-bit integers.)

@dchenk 128-bit is not big integer. You're making a wrong comparison.

Also, maybe we can have conceptual problems in the main issue, and keep the PRs to technical issues. there's not much I can add to "should we support it", since im not really a maintainer. I can do something about implementational issues.

This proposal does not specify the binary format of the payload: two's compliment, signed magnitude, or one's compliment. Most arbitrary-precision integer libraries use signed magnitude. If signed magnitude were to be used, then the sign must appear somewhere in the message frame.