Clarify how tracestate can or cannot be used by application developers

[gfraiteur]

I'm writing as the author of logging framework for .NET application developers which supports distributed logging including per-request logging, sampled logging, and pluggable correlation protocols (see https://doc.postsharp.net/6.8/distributed-logging and https://doc.postsharp.net/6.8/log-enabling#sampled).

Our logging framework allows application developers to define logging properties, and properties marked as "baggage" are transferred to remote services (in the spirit of OpenTracing and the .NET Activity class). Properties in this framework are name-value pairs where the values are arbitrary objects and eventually rendered into arbitrary strings. It's important to note that these properties are defined by application developers, not by infrastructure/framework vendors. A typical piece of baggage could be a user name, for instance.

My questions related to this use case are:

• Should every application property map to a tracestate member? Your language seems to indicate that this facility is designed for infrastructure, not for application code.
• If yes, how can a framework know if the member is in "raw" format or in Base64, so that it can deserialize it properly for use by the application developer?
• If no, is it recommendable to serialize all application properties into a single tracestate member?
• How are vendors supposed to react to application properties?
• Are there more recommendations for application developers and framework developers?

Thank you.

[yurishkuro]

None of this should be mapped into tracestate, what you need is https://github.com/w3c/baggage

[gfraiteur]

Thank you for your quick answer. I would suggest to add a section with related recommendations.