With the proliferation of 128-bit UUIDs (IPv6, ext4/btrfs, MS COM objects, etc, etc), I could argue that it makes sense to include a dedicated UINT128 type. While it could be handled with prefix 0xB0 (16-byte FixRaw), the format loses the type specifications that makes it otherwise so nice, forcing the application to understand the low-lying transport mechanism (a bad thing). Because 128-bit numbers are used so often as identifiers (I'm having trouble thinking of numerical applications needing 128-bit integers), I would tentatively propose using 0xC1 as "128-bit UUID", packing to 17 bytes, while retaining type information. 

Is there a place for this, or a reason against it?

I am missing a way to easily detect if the string is msgpack serrialized.  Other formats, ie. PHPs serialize, you can easily detect if its PHP serialized by looking at the second char (: or ;). 

I can receive a string in my code that might be serialized in PHP, igbinay, or msgpack.  Furthermore, msgpack_unserialize() extension for PHP does not return false or error on arbitrary strings.  

Any suggestion without performing the unserialize?  apart from checking other formats first?

I'm missing an extension point. That is, a way to encode the usage of more complex abstract types built from the basic ones. What I'd like is something like

(type, value)

where both type and value can be values of any msgpack type. The interpretation above parsing those values individually would be outside of the scope of msgpack, and other specifications may define an interpretation for value given a certain type. Parsers would by default decode / encode this to / from an object of a specific type with two properties, "type" and "value", but could allow registration of encoding/decoding functions in whatever fashion makes sense in the implementation language / framework.

Implementation would be very much like FixArray, but the length is always exactly two. I propose using 11000001 followed by exactly two objects.

Note: It generally makes very little sense for the type to be anything but a string, array or map. I can however not see any good gains by artificially restricting this.

Example usages (outside of the scope of the msgpack specification):

• A msgpack date specification could define ("date", [2011,12,01]) to be interpreted as the date 1st of december, 2011.
• A msgpack crypto specification could define ("signed-pgp", [signature, value]) to be interpreted as a value and the digital signature on the msgpack representation of that value.
• A msgpack object orientation specification could define (["object", package_and_classname], { member:value,... }) to be interpreted as the instantiation of the specified class, with the specified members (maybe allowing classes to declare if they can be deserialized in this fashion).

I'm missing an optional CRC tag for basic security and data corruption. If pack provides a crc checksum, unpack should check the result against the given crc and report an error otherwise. The crc tag must be the last tag in the buffer. The crc checksum does not include itself and its type tag.

There are several reserved bytes free for this. For example 0xc6 is similar to 0xce, only one bit apart.

0xc6 crc with uint32 (optional)

I implemented this for c and perl here:

https://github.com/msgpack/msgpack/pull/114

https://github.com/msgpack/msgpack-perl/pull/7

Our main advantage to use the optional CRC  is to be sure that the writer has already finished writing by checking the fifth-last byte to be 0xc6. Omit parsing and unpacking then. Some writers buffer its output, and the reader optimisticly tries to parse whenever the ctime changes.

MsgPack is great, and I completely agree about strings.

But could we get this wiki into GitHub? This site was down recently, and that's a major problem. I cannot find the spec anywhere else on the web.

I've copied the bare minimum here: https://github.com/cdunn2001/msgpack-spec

That's only a README. With GitHub, the wiki attached to a repo is itself available via git. That would be prefect.

See wiki:

https://github.com/cdunn2001/msgpack-spec/wiki/Spec

and README:

https://github.com/cdunn2001/msgpack-spec/blob/master/README.md

The wiki looks a little better because of the surprising syntax-highlighting. Feel free to clone.