[otlp] Decide if original and lowerCamelCase JSON keys should be supported

[tigrannajaryan]

The decision that we need to make is whether both the original proto field name and the camelCase version of the field name should be acceptable. It is acceptable by Prototobuf JSON definition. Do we see any need to deviate from this?

[tigrannajaryan]

It is not entirely clear what the definition of JSON-friendliness is. They keys used by OTLP are valid in JSON.

Perhaps one decision that we need to make is whether both the original proto field name and the camelCase version of the field name should be acceptable. It is acceptable by Prototobuf JSON definition. Do we see any need to deviate from this?

[tigrannajaryan]

cc @mwear @dyladan @bogdandrutu @jmacd @Aneurysm9 in case you have any thoughts about this.

[dyladan]

I think the default behavior of the protobuf client is to change keys to lowerCamelCase and is likely what the JS exporter is currently doing. I don't see any reason not to accept both though since it is default proto behavior.

[tigrannajaryan]

I agree with @dyladan that we should just keep the default Protobuf behavior for exporters and also keep the ability for receivers to accept both.

@open-telemetry/specs-approvers any opinions on this?

[dyladan]

I don't see any reason to restrict the exporters to this behavior. I would just say receivers should expect both and let exporters do what makes sense for their users expectations.

[tigrannajaryan]

I don't see any reason to restrict the exporters to this behavior. I would just say receivers should expect both and let exporters do what makes sense for their users expectations.

Yes, that's essentially what will happen if we say receivers must accept both.