FYI on w3c correlation context

[Adrian Cole]

Some of you know that the w3c trace context header was made
specifically to avoid encoding issues on messaging transports. Mainly
by restricting it to lower-alpha, similar to our 'b3' header.

This resulted in headers named 'traceparent' and 'tracestate' which
are compatible without having to do non-portable header renaming such
as what Apache Camel does when it encounters special characters. Some
may recall how very incompatible different libraries addressed this
concern. Basically if you didn't control both ends.. good luck.

Currently, Microsoft are pushing to not dodge hyphens on correlation
context header name because they use it in their SDKs prior to the
spec, and since they are leading the spec anyway it is fair to suggest
this.

https://github.com/w3c/correlation-context/issues/13

However, it is still a terrible idea, to add a hyphen. It is also
commonly the case that "extra fields" are tunneled over messaging
transports. When we've had people with issues pushing their fields,
one suggestion was to tunnel them through a safe field. At one point
we discussed 'b3ext' to push properties through for this very reason.
As the w3c header would work just as fine in theory, personally I
delayed creating this.

If the group in W3C decide collectively to follow microsoft's prior
name, we'll be in the same boat again. Please voice or vote your
opinion on the w3c issue above even if you don't agree with mine. I
understand many people don't care about compatibility between legacy
java messaging systems, but do empathize that this is real.

Over to you!
-A

[Adrian Cole]

PS here's the rationale we used for b3 which is exactly the same point

https://github.com/openzipkin/b3-propagation/blob/master/RATIONALE.md#relationship-to-jms-java-message-service