What to do about CE extension specs

[duglin]

Grant asked if there was any expectation for SDKs to add support for extensions to the CE spec - in particular the tracing extension. Today our extensions do not have any official standing and we state that they could change at any time. This could be a barrier to SDK adoption if they change often, or run the risk of being removed entirely.

This issue is being created to gather thoughts on what to do about this situation.

Some ideas mentioned during the Nov 4th call:

• move extensions into a "working-drafts" type of folder and then moved them into "extensions" once they cross some minimum bar
• move extensions that have crossed some bar to be "optional" in the main spec, but then there's an open question as to whether we can add OPTIONAL attributes w/o a major version bump

/cc @jskeet

[grant]

Thanks Dug! Adding on to this issue.

We also have notes in the CNCF Serverless WG Meeting Minutes doc about this.

In particular, we (Google Cloud libraries) would like to allow developers to use the traceparent value attached to their CloudEvent via a documented CloudEvent extension attribute. I.e. cloudevent.traceparent or some other language-idiomatic accessor.

It is expected that a CloudEvent receiver can parse a HTTP request in the form of a CloudEvent following the HTTP protocol binding that has the HTTP header:

• traceparent – The W3C Recommendation HTTP standard header for https://www.w3.org/TR/trace-context/
• ce-traceparent - The alternative mapping of the CloudEvent extension per 3.1.3.1. HTTP Header Names.

In our case, we have services that produce the W3 standard traceparent HTTP header.

Current Status

1. It looks like we are currently waiting on: Clarify usage of Distributed Tracing Extension by OpenTelemetry #912
   • We talked about this during today, 12.02 on the CE SWG call. Waiting for review.
2. The CloudEvent SDKs do not uniformly have functionality for receiving tracing information. I believe it would help to finalize the details in the spec's extension page, including the appropriate HTTP mapping (ce- and/or not).

/cc @anniefu @matthewrobertson

[grant]

Here is the Golang SDK issue for reference:

cloudevents/sdk-go#729

[joaopgrassi]

Hi all, just chiming in this discussion. I replied @grant in cloudevents/sdk-go#729, but will leave some comments here.

The traceparent header is what OpenTelemetry heavily uses to propagate context. This is header contains the "current" or most recent context of what's happening. Say you send an HTTP request, this header will contain the context for it. Upon receiving the request, the server reads that traceparent (now the remote context) and can continue the trace. This has "nothing" to do with CloudEvents. It's a cross-cutting concern.

Now, I have been working on with OpenTelemetry to try to spec out how the Distributed Tracing Extension will be used by OTel. In a nutshell, we will use this to carry the initial creation context of the event. Once this context is set on the extension, it will never change. This will give the possibility to "link" all operations that happened because of the creation of this event. I encourage interested people to read the OTel spec to know what it is about: open-telemetry/opentelemetry-specification#1978.

When systems are receiving the event, it might be impractical to have to deserialize the whole payload to read the Distributed Tracing Extension, so the ce-traceparent header might be a "way out" and can be used in many protocols, such as HTTP or maybe any other messaging protocol. We still are discussing how to do context propagation in messaging systems in OTel and this overlaps greatly with CloudEvents. But for me, this is something that should be "hidden" from people using the CloudEvents SDKs. It shouldn't matter for people using the SDKs that there's the ce-traceparent and the standard traceparent. You configure the SDK and it all works. It only matter for the involved in developing the SDKs.

[duglin]

Going to propose we close this on tomorrow's call... if anyone has any concerns please speak up.

[grant]

SGTM

[duglin]

Agreed to close on 6/16 call