tracestate response header proposal about trace-context HOT 4 OPEN

It is worth pointing out that Jonathan Mace's "baggage" paper advocated for implementing the merge semantics (or option 2). However, it does feel like a higher burden on implementers (many implementations propagate the context forward as immutable). I like option 1. Maybe in the future we could introduce different levels where both options are possible but option 2 is not required.

from trace-context.

it wouldn't be too hard to write the spec such that we do proposal 1 for now but leave proposal 2 open for the future. For example we could specify it as a comma separated list but ignore all entries after the first in version 1

from trace-context.

I would like to revive this proposal for level 3. Specifically, I believe proposal 2 to be the more useful. I agree with Yuri that it does complicate implementation, but I believe the usefulness outweighs the benefits. Option 2 is required if there is any middleman like a proxy, or routing service, or other the header will be lost.

from trace-context.

The MAY semantic on back propagation sounds like a good plan. A few thoughts:

1. I wonder if backpropagation opens door for any new information exposure problems. With forward propagation one can inject a cleanup filter on incoming request that will ensure that tracestate is cleaned up before any outgoing calls. With back propagation it is unclear at what stage this clean up filer must be set. Do all frameworks support this type of callback to clean up the whole tracestate on response?
2. What to do with async calls? If a request initiates some background actions, does framework needs to collect all tracestates, even though neither of them will ever be used? With forward propagation it is a constant set of headers that will be stored and sent to background tasks forewer. With back propagation the tracestate potentially will grow with no use.

from trace-context.