Bastian Krol

Related: https://github.com/open-telemetry/opentelemetry-specification/issues/3811

> Also, I am looking to understand better: the use cases where browser support is needed for traceresponse header, and... Another use case is a customer support scenario. When a...

I feel there is a tradeoff between: (a) choosing metric names that makes the most sense for what the metric represents and (b) names that make it easy to mentally...

I don't see any possibility to make this change in a backwards compatible way. Yes, maybe not disallowing the `=` character in tracestate values would have been better. But this...

I think this spec should not mandate one or the other. This decision should be made by the service responding with HTTP 304. I think you laid out the two...

> > In that case, yes, if no new traceresponse header is added to the response > > You mean, if new traceresponse header ARE added to the response, the...

I like that! And I agree, including this would improve the spec. I would rephrase it slightly. Mostly using singular form (there is only one traceresponse header per response, not...

> Not really just the body, it is also combined with all other headers for that cached response. Right. > Sure. Do you have a suggestion where to add it...

Ping @happylynx :) Would you mind taking a look?

@ericyliu The fix is available in PR #8 since early January but @happylynx seems to be gone. Maybe I should publish my fixed fork to npm.