There are not many modern app-level protocols and much fewer messaging protocols that don't allow for any end-to-end message metadata; at a minimum declaring what the payload content of a message is, when the message was generated, and an end-to-end ID. Content-type could be a mere byte the client sends to the app and where 0x01 spells "JSON". CONNECT shows how you can have a bitfield that can control the presence of headers. You can control the presence of 4 subsequent optional headers with 4 shape options in one byte. That's as simple as what happens in CONNECT and just as compact.
There are also not many modern app-level protocols that constrain their opcode-set to 4 bits quasi forever, so extensibility also means to have runway for future extension.
The Silverlight developer community has been up in arms for 2+ years claiming the exact opposite, i.e. that they got completely abandoned in favor of HTML5. Part of that is motivated exactly by the Windows OS group having been pushing HTML5+JS as the primary programming model for apps much harder than they have pushed XAML/WPF/Silverlight ever since Windows 8's new app model got first presented. In server/cloud it's all about HTML5/JS and open standards to the point that Azure Mobile Services only now (yesterday, actually) added .NET support after being exclusively Javascript/Node.js only for well over a year. Recent (<18 months) evidence of Microsoft pushing SL over HTML5 would be greatly appreciated.
There are also not many modern app-level protocols that constrain their opcode-set to 4 bits quasi forever, so extensibility also means to have runway for future extension.