Extension names become case insensitive in binary encoding

Extensions are not defined to have case-insensitive names, but the binary encoding puts the extension name in a header. Since header names are case insensitive, their case may be changed by middleware. This makes extensions fairly fragile.

I suggest we either:

1. Define extensions to be case insensitive in spec.md
2. Change the way extensions are encoded in HTTP binary encoding.

I personally prefer (2). I’d recommend

CE-X: <key>: <value>

[timbray]

Does the spec say (don’t recall seeing this) that properties (built-in or extensions) be English words? If not, the base64 idea is worth serious consideration, specifically for HTTP headers, which are a lossy encoding. Case-folding is a can of worms, and should be avoided wherever possible in the interests of sanity and diversity. E.g., if ASCII case-folding rules are applied mechanically, they are apt to break anyone who uses a Turkish word to name a property. Case has no place in Internet protocols.

[deissnerk]

I think it should be a requirement that the different transport bindings can be chained. If I get an event via webhook in binary format and need to publish it on an MQTT 3.1 topic (-> JSON representation), I have no way to determine the case of the extension attributes. SDKs should decide how to represent extensions, but this representation should not lose information.