Encode values for the Jaeger propagator

[carlosalberto]

As a follow-up of #1549 we may need to support encoded Baggage values too.

As Jaeger has support for both URL-encoded and non-encoded values, how should this be implemented? Should we have two Jaeger propagators, i.e. JaegerPropagator.getEncodedInstance() and JaegerPropagator.getInstance()?

(Also, we may need to add a value for OTEL_PROPAGATORS to support this dual case)

@yurishkuro would you mind advising how to proceed here?

[yurishkuro]

What is OTEL's plan for propagators that can be used with transports that do not have HTTP restrictions on the headers?

If the plan is to continue using HTTP propagator (at least for now), then you only need one Jaeger propagator that applies url-encoding to header values. But there will be danger that the serialized format will be incompatible with native Jaeger SDKs for non-HTTP cases.

[jkwatson]

@carlosalberto is there a spec for this?

[yurishkuro]

@jkwatson no spec, just reference implementations in Jaeger SDK. TL;DR; - "encoded" means the values are url-encoded/decoded, which is what is used for OpenTracing.HTTP_HEADERS propagator, and unencoded for OpenTracing.TEXT_MAP propagator.

[jkwatson]

@jkwatson no spec, just reference implementations in Jaeger SDK. TL;DR; - "encoded" means the values are url-encoded/decoded, which is what is used for OpenTracing.HTTP_HEADERS propagator, and unencoded for OpenTracing.TEXT_MAP propagator.

I was more referring to what SDKs are required to implement wrt. to this functionality, rather than the exact details of the functionality. IIRC, what SDKs are supposed to do for Jaeger exporters is woefully underspecified currently.

[yurishkuro]

That sounds like a different issue from this ticket, which is specifically about url-encoding of in-band trace context

[jkwatson]

That sounds like a different issue from this ticket, which is specifically about url-encoding of in-band trace context

sorry...mis-typed there. I meant the jaeger propagator specification, which is completely missing from the otel specs.

[yurishkuro]

https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/context/api-propagators.md#propagators-distribution links to Jaeger Propagation Spec (https://www.jaegertracing.io/docs/1.21/client-libraries/#propagation-format). Please open additional tickets if you find something missing.

[jkwatson]

I think that simply linking to another document is not an acceptable "specification". For example, the Jaeger spec has things in it like "We’re considering a new feature that allows downstream services to upsample if they find their tracing level is too low". What should OTel do with that? How will OTel implementors know when/if that needs to be added?

[carlosalberto]

I think we need to add some of features that we expect to support in Jaeger (handy if we don't plan to support all). We did this for B3 Propagation, and it's worth spending a few cycles for this, adding also an Encoded values in the Spec Matrix under Jaeger Propagation.