I'll just note, once again, how verbose, unattractive & difficult to parse JSON is compared to S-expressions. Here are several of the examples in the spec in both formats, in order (I've rearranged the field so that required fields come first & optional fields come later).

2.1:

{
"mid": "ef5a7369-f0b9-4143-a49d-2b9c7ee51117",
"rmid": "66c61afc-037b-4229-ace4-5ec4d788903e",
"to": "uid:123",
"from": "uid:56",
"type": "dm",
"version": "UMF/1.4.3",
"priority": "10",
"timestamp": "2013-09-29T10:40Z",
"body": {
"message": "How is it going?"
}
}

(message
ef5a7369-f0b9-4143-a49d-2b9c7ee51117
(to uid:123)
(from uid:56)
(version SMF/1.4.3)
(timestamp 2013-09-29T10:40Z)
(rmid 66c61afc-037b-4229-ace4-5ec4d788903e)
(type dm)
(priority 10)
(body
(message "How is it going?")))

2.2.11:

{
"mid": "ef5a7369-f0b9-4143-a49d-2b9c7ee51117",
"to": "uid:56",
"from": "game:store",
"version": "UMF/1.3",
"timestamp": "2013-09-29T10:40Z",
"body": {
"type": "store:purchase",
"itemID": "5x:winnings:multiplier",
"expiration": "2014-02-10T10:40Z"
}
}

(message
ef5a7369-f0b9-4143-a49d-2b9c7ee51117
(to uid:56)
(from game:store)
(version UMF/1.3)
(timestamp 2013-09-29T10:40Z)
(body (type store:purchase)
(itemID "5x:winnings:multiplier")
(expiration 2014-02-10T10:40Z)))

2.2.11.2

Note how JSON has to rely on metadata to indicate that a Base64 sequence, whereas it's natively supported by canonical S-expressions. Note also how the S-expression format natively supports types ('display hints') for its values.

{
"mid": "ef5a7369-f0b9-4143-a49d-2b9c7ee51117",
"to": "uid:134",
"from": "uid:56",
"version": "UMF/1.3",
"timestamp": "2013-09-29T10:40Z",
"body": {
"type": "private:message",
"contentType": "text/plain",
"base64": "SSBzZWUgeW91IHRvb2sgdGhlIHRyb3VibGUgdG8gZGVjb2RlIHRoaXMgbWVzc2FnZS4="
}
}

(message
ef5a7369-f0b9-4143-a49d-2b9c7ee51117
(to uid:134)
(from uid:56)
(version SMF/1.3)
(timestamp 2013-09-29T10:40Z)
(body
(type private:message)
[text/plain]|SSBzZWUgeW91IHRvb2sgdGhlIHRyb3VibGUgdG8gZGVjb2RlIHRoaXMgbWVzc2FnZS4=|))

2.2.11.3

One might expect that S-expressions might shine when it comes to sending multiple items, and of course one would be correct.

Also note how the parallel structure of the message & message/body/message objects raises the question of whether the message/body/message schema should also be UMF.

{
"mid": "ef5a7369-f0b9-4143-a49d-2b9c7ee51117",
"to": "uid:134",
"from": "chat:room:14",
"version": "UMF/1.3",
"timestamp": "2013-09-29T10:40Z",
"body": {
"type": "chat:messages",
"messages": [
{
"from": "moderator",
"text": "Susan welcome to chat Nation NYC",
"ts": "2013-09-29T10:34Z"
},
{
"from": "uid:16",
"text": "Rex, you are one lucky SOB!",
"ts": "2013-09-29T10:30Z"
},
{
"from": "uid:133",
"text": "Rex you're going down this next round",
"ts": "2013-09-29T10:31Z"
}
]
}
}

(message
ef5a7369-f0b9-4143-a49d-2b9c7ee51117
(to uid:134)
(from chat:room:14)
(version SMF/1.3)
(timestamp 2013-09-29T10:40Z)
(body
(type chat:messages)
(messages
(message
(from moderator)
(text "Susan welcome to chat Nation NYC")
(ts 2013-09-29T10:34Z))
(message
(from uid:16)
(text "Rex, you are one lucky SOB!")
(ts 2013-09-29T10:30Z))
(message
(from uid:133)
(text "Rex you're going down this next round")
(ts 2013-09-29T10:31Z)))))

2.2.17

Note that there is a complex canonicalisation procedure for the JSON object, and that the sender must mutate the signed object; by contrast, the S-expression format is properly layered and doesn't mutate signed objects (which implies that it's possible to chain signatures cleanly).

{
"mid": "ef5a7369-f0b9-4143-a49d-2b9c7ee51117",
"to": "uid:123",
"from": "uid:56",
"version": "UMF/1.4.6",
"signature": "c0fa1bc00531bd78ef38c628449c5102aeabd49b5dc3a2a516ea6ea959d6658e",
"body": {}
}

(signature
(message
ef5a7369-f0b9-4143-a49d-2b9c7ee51117
(to uid:123)
(from uid:56)
(version SMF/1.4.6)
(body))
|c0fa1bc00531bd78ef38c628449c5102aeabd49b5dc3a2a516ea6ea959d6658e|)

It's not to late to switch away from JSON, it really isn't.