Christian Neumüller

Was closing it even intentional? I can't remember any final decision in this issue. At least it's not documented here?

I guess closing this via a commit into some personal repository (tigrannajaryan/exp-otelproto@1507a2f) was accidental? It's surprising to me that GitHub allows this (I would even be tempted to call that...

Currently only homogeneous, single-dimensional arrays of primitives are allowed. This issue is about relaxing that. EDIT: Discussion is happening mostly on https://github.com/open-telemetry/opentelemetry-specification/pull/596 recently.

I maintain we should not relax the criteria, but see #596. This has also been discussed in a few SIG Spec meetings.

>> If we allow adding nested structures/maps to Attributes, what type should the attribute key represent? Also Attributes? E.g. in Java AttributeKey attributesKey(String key) would be the factory method >...

> No changes are needed in the Collector, it is already fully supported. How does the collector handle exporting a nested map to Jaeger / Zipkin? Does it already JSON-encode?

This removal was fully intentional, it used to be there before the very recent https://github.com/open-telemetry/opentelemetry-specification/pull/2469 @lmolkova re-designed the HTTP semantic conventions with the goal to remove redundant ways of reporting...

Indeed all the FaaS resource attributes also caused problems at Dynatrace, to the point where we patched our SDKs to allow adding resource attributes until before the first span is...

CC @thisthat @discostu105

I would say we keep it as resource but add a note in the markdown that they may also be sent as span attributes. We may later want to add...