Why is Sentry using baggage header instead of tracestate?

[mugli]

From Sentry doc:

We chose baggage as the propagation mechanism for DSC. (w3c baggage spec) Baggage is a standard HTTP header with URI encoded key-value pairs.

But baggage is not the only standard HTTP header for propagation. There is also tracestate.

And to quote from the W3C spec:

The main purpose of the tracestate HTTP header is to provide additional vendor-specific trace identification information across different distributed tracing systems and is a companion header for the traceparent field.
...
The tracestate HTTP header MUST NOT be used for any properties that are not defined by a tracing system. [BAGGAGE] MAY be used for defining and propagating such application level properties.

It seems to me Sentry should be using the tracestate header to propagate vendor-specific tracing context and leave the baggage header for application level data.

What was the reason behind choosing baggage over tracestate?

[lforst]

IIRC baggage was easier to work with in combination with other vendors (merging, adding, and so on). Our initial implementation used tracestate but we settled for baggage.

Was that a good decision? Idk. So far we didn't have too many issues. Some voices say we should have used our own proprietary header. But I think this is where we are now and we're likely gonna stick with baggage for a long time.

[mugli]

Thank you for explaining. I see some onging projects related to Sentry + OTel. Will that going to have any effect on this decision of using baggage header instead of tracestate? Or does that matter, in terms of following Otel spec?