Remove distributed tracing extension

[slinkydeveloper]

This PR removes the distributed tracing extension spec. Below just some answers to the questions you're probably gonna ask to me:

Why?

The reason to remove the distributed tracing extension is very simple: from the user perspective, this spec that leads users to think to it as a replacement for w3c trace context.

Why people are confused?

We receive a lot of times questions, both in spec community channels and in sdks, about how to use the distributed tracing as medium to transport trace informations. And it's often hard to get people to understand that the goal of the extension is to carry the historic traceparent, and MUST not be used as a replacement for w3c trace context and friends.

I believe that if a spec contains an unclear feature like that, then it should be removed, because such feature leads to bad implementations which doesn't interact properly between themselves. Also, I think it's important to be clear that we're not trying to overlap with other tracing specs already widely adopted outside CloudEvents.

But we just changed recently, right?

Yes, we recently approved some changes to make more clear its use case #607. This still doesn't help and lead people to confusion, probably because of the name and the extension keys that still resembles the w3c trace context.

I don't want to remove this, because I'm using this extension as replacement to w3c trace context.

You're using it wrong, change your code.

I don't want to remove this, because I'm using this extension to carry historic trace informations.

Just continue to use it, removing an extension from this repository doesn't mean that nobody can use it anymore.
If we really feel that this extension spec should be "sponsored" by the Serverless WG because we have a lot of "correct" use cases for that, then I propose to rename both the spec name and the extension fields to a name that clearly disambiguates from w3c trace context. For example, something like that might work:

• Distributed Tracing Extension -> Historic Trace Extension
• traceparent -> initialtraceparent
• tracestate -> initialtracestate

Signed-off-by: Francesco Guardiani francescoguard@gmail.com

[duglin]

On the 1/14 call @clemensv agreed to take a stab at adding some clarifying text

[slinkydeveloper]

Recent discussions about Distributed Tracing Extension "unclear role":

• https://cloud-native.slack.com/archives/CCXF3CBL1/p1606776741094000
• Add support for Distributed Tracing extension sdk-javascript#355

[duglin]

@clemensv I believe this one is waiting on some suggested text from you, right?

[jskeet]

Do we have any progress on this? I'm mostly asking because I'm not sure whether to remove the representation in the C# SDK before we go to V2.

[duglin]

Poke your partner in crime 🤣. @clemensv

[jskeet]

@clemensv: Any updates on this? Getting close to a V2 release of the C# SDK...

[slinkydeveloper]

@jskeet from a SDK mantainer POV, maybe it's a better bet to remove it for the v2 release and eventually re-add it later?

[jskeet]

@slinkydeveloper: That's my plan unless we get anything definitive soon, yes.

[slinkydeveloper]

Can we go ahead and merge this?

[slinkydeveloper]

@duglin

[duglin]

@clemensv any update on this?

[grant]

(Viewing CNCF SWG meeting minutes)

Are we removing the documented CloudEvent extension, supporting traceparent and tracestate CloudEvent attributes? With events receivers, I can imagine it would be useful to consume a trace, store it, and/or input the trace into a different API for telemetry (Cloud Trace in Google's case).

Currently, different SDKs handle this attribute differently (some accepting CE-traceparent, others traceparent, making it difficult to integrate on our side. The spec example seems to have an example of both headers. (We'd like to send apps JSON CEs with a traceparent/tracestate attribute).

Either way, clarity on the spec and if this PR is going through would help.

CC @matthewrobertson @anniefu

[clemensv]

We are closing this issue without action.

This extension will be kept as the OpenTelemetry WG for Messaging Sementics is interested in using and potentially updating it to aligned with the outcome of their work. Chair of that effort is @pyohannes.

The gist of the state of discussion in OTel is that there is a need for end-to-end tracing at the level of CloudEvents as well as for tracing at the level of the transport mechanisms, and while those may root in the same base activity, the resulting trace paths and the motivations are different.