Make initial traceparent optional

[codefromthecrypt]

There are a number of reasons why initial headers sent should allow tracestate without traceparent.

• format or vendor-specific sampling hints. ex b3=1
• passing in a format or vendor-specific way only the trace ID
• vendors who are only using tracestate for non-trace data such as appId
• special, vendor-specific instructions. ex return back a synthetic parent ID
• mechanical conversion of existing headers by a proxy
  • ex stashing the b3 header as a b3 entry, as a save point, but without having to convert it to traceparent format which has a squishy notion of the sampling flag.

Most importantly, this can help reduce the pressure to add vendor-specific features to the traceparent or response variants.

[codefromthecrypt]

The "initial" part is important. The state model impact is once, there is a traceparent header you must always continue to send that with the existing rules on state management. This is to cover the case where it doesn't already exist.

[danielkhan]

This is a valid scenario. Right now, the normative section is not really clear on that.
At the same time, the version is contained in traceparent and this might break parsing in later versions.
In our working group meeting, we leaned towards allowing that in level-2.

[SergeyKanzhelev]

@Kanwaldeep I believe IOT in MS may be using specification this way. Do you want to propose the change for the spec in level-2? I think it is a good improvement for the spec

[kalyanaj]

We need to understand the use cases that absolutely need this support.

[SergeyKanzhelev]

To reiterate conversation we just had, the scenario is understood, but there are workarounds. Response header support in future may make it even easier to work around. Allowing this in spec may lead to abuse when tracestate is used as a general purpose baggage which is not desireable.