Joshua MacDonald

> We now have open issues in the spec to handle this in the API/SDK. Please link any spec issues, for the readers following this issue?

I will elevate this topic again in the next Specification SIG meeting. Recently I observed the following interaction. A Rust SDK emitted a string-valued attribute containing invalid utf8. This passed...

I do see the connection with #3950, which appears equally unresolved. I am surprised to hear about vendors that accept OTLP data and are not prepared to accept byte slice...

To help focus this conversation, the specification does have language to avoid API users entering raw byte -value attributes. https://github.com/open-telemetry/opentelemetry-specification/tree/main/specification/common#attribute I believe that (a) we should require strings to be...

@pellared The document you is restricted to attribute values, and my issue here is about all the other strings too. Sure, other language runtimes have an expectation of UTF-16 --...

My expectation is that when a bound instrument is used, the map lookup step described above is bypassed. I expect there is an initial step to construct the attribute set,...

@cijothomas I apologize for the delay. I wanted to be sure that we evaluate all the issues connected with this topic. I definitely support adding bound instruments to the Metric...

@jsvd I've read the proposal and I understand the motivation to propose an extension interface for looking up mappings from various sources. I began to work on a style-guide for...

I discussed prerequisites with @lquerel. As a primary blocker, we need to integrate and rationalize the layout of our `otap-dataflow` crates. The `otel-arrow-rust` sibling crate will have to move in...

I believe we should close this in favor of #399. I also believe that the Arrow IPC file format makes a reasonable intermediate representation, I would include this under the...