Define the charter more precisely

[yurishkuro]

https://github.com/TraceContext/tracecontext-spec/blob/master/HTTP_HEADER_FORMAT.md#trace-context-http-header-format says

A trace context header is used to pass trace context information across systems for a HTTP request. Our goal is to share this with the community so that various tracing and diagnostics products can operate together, and so that services can pass context through them, even if they're not being traced (useful for load balancers, etc.)

• what does "operate together" mean? If we have two applications A and B instrumented by two different tracing systems with different backends, what is the behavior we're expecting?
• "services can pass context through them, even if they're not being traced (useful for load balancers, etc.)" - this goal does not require any specification of the format, just the standard header name

[codefromthecrypt]

simultaneously copied historical context in #18

[mtwo]

Yuri, to answer your first question, I can think of a few scenarios where having an expected context format is beneficial:

1. At minimum, load balancers, proxies, etc. can forward the header (as mentioned in your second comment, this doesn't require a format specification, just a name)
2. PaaS services (Azure App Service, Elastic Beanstalk, etc.) or platforms that automatically handle tracing for the developer (via sidecars, etc.) can interact with context, even if the context was set by a service using a different tracing backend. In the case of a PaaS that sends traces to a single backend (X-Ray for Elastic Beanstalk, etc.), spans could be joined later to create a full trace by pulling data from the PaaS provider's trace API.
3. You achieve a level of independence between instrumentation packages and tracing backends. A developer could link the instrumentation libraries / agents for Zipkin or Jaeger or Stackdriver, etc. and use them with a different tracing backend via a collector proxy (Stackdriver has one for Zipkin) or a compatible API.
4. API owners can match traces on their end with customer traces. This is particularly useful for large providers like Amazon, Microsoft, Google, etc., but one can imagine it becoming common for API owners of any size

There's likely other benefits that I've missed, but does what I've outlined above make sense?

[yurishkuro]

Hi Morgan,

These are fine goals, but they are too high level imo to be able to draw a spec from. I.e. it's not useful to discuss what the values in the header mean without taking about that the receiving systems are expected to do with it. So far the specs only talks about the first part.

Let's take just the trace-id first. Assume my service is tracing-aware (not an LB/proxy). I can do two things with the trace-id:

1. record it as correlation id and start my own trace-id
2. use the inbound trace-id as my own

I think we're taking about the second option here, but it's not stated explicitly and various comments on various threads implied other interpretations. Agreeing on a second option has certain implications already, like if we allow variable-length trace-ids, many Dapper-like systems won't be able to accommodate that without extending their internal data models and storage formats.

Then to continue, let's assume we handled the inbound trace-id one way or another, and we're making an outbound call. Again, several options:

1. outbound trace-id can be different from inbound
2. outbound trace-id is expected to be the same as the inbound one
   • note that this does not imply option-2 from above, because it's possible that the instrumentation will send two headers, one Trace-Context with the received trace-id and another (e.g. B3) with its own internal id

For this part, I think we're talking about option 2 as well, but it's not stated explicitly.

[mtwo]

Ahh, understood!

In my mind we're talking about the second option to each of the choices that you presented, as this enables pass-through scenarios, and the re-used instrumentation code scenario. Like you pointed out, there may also be scenarios where multiple headers are passed for compatibility purposes, though ideally this becomes less necessary more and more projects would adopt Trace-Context.

@adriancole since you already have #18 open, do you want to add this there (assuming that you agree, which I think that you do)?

[codefromthecrypt]

I agree with how yuri stated this. I think the very least 2 is defined (or a required goal to define). Tacitly we discuss 1, which is real life problem. Imho we need to explain 1 eventually and bear in mind always. It is important context (forgive the term) to relay transitional brown field suggestions. MS in their spec outline some guidance around this type of thing and we can too. Iotw yes? What should we put down? I can spike a PR..

[AloisReitbauer]

This one was created before we defined the W3C charter and is obsolete now