Issue with "-" in extension names

[duglin]

See:

• Mapping rules for attributes/headers #255 (comment)
• Mapping rules for attributes/headers #255 (comment)

In #255 we introduced the notion of using "-" to denote stepping into a nested object but we do not ban the use of "-" in a property name. This makes it ambiguous as to whether "-" is part of a name or not. We should either use some other mechanism or ban the use of "-" in names.

ping @clemensv

[cneijenhuis]

I think the issue is a bit broader actually. We have the attribute naming conventions, but they're neither normative, nor do they limit the encoding in any way. E.g. in JSON, UTF-8 fieldnames are allowed, but wouldn't work with HTTP headers.

ban the use of "-" in names

A simple way to prevent a lot of (similar) issues is to limit attribute names to alphanumeric characters.

We could allow % to be used for encoding non-alphanumeric characters, similar to url-encoding. But I'm not sure if that isn't overkill already.

@duglin If it's ok, I'd like to take over and create a PR that:

• allows alphanumeric characters only in attribute naming conventions
• states that extensions names MUST follow the attribute naming conventions

[deissnerk]

@cneijenhuis What about case-sensitivity? E.g. an event router that receives an event in HTTP binary content mode, is not able to convert an extension attribute back to camel casing.

[cneijenhuis]

@deissnerk There is another issue for that: #177

I agree they are related. Once it is clearly defined which characters are supported in attribute names, it becomes easier to fix the issue in HTTP headers.

E.g. if the outcome is that only allow alphanumeric characters are allowed, we have many more ASCII characters that can be used (e.g. convert camelCase to snake_case).
However, if the outcome is that all UTF-8 characters are allowed (as in JSON), then base64 encoding (see #177 (comment)) seems like a good idea.

[duglin]

I believe that we can close this one now that we've agreed to adopt #321. Please speak up if you think otherwise.

[duglin]

on the call today we agreed to close this issue - we can reopen if new info comes up.