Consider renaming the header from Correlation-Context to correlationcontext about baggage HOT 17 CLOSED

A few thoughts.
From a consistency standpoint, it’s strange to both see lower cased, non-hyphenated headers like traceparent and the exact opposite in the same umbrella of specs.

I can understand that sticking with the current proposal would be easier for some. But this is in a draft state so everyone relying on the current version should anticipate backwards incompatible changes.

Backwards compatibility in drafts should not weight over compatibility with technologies like JMS and consistency with the rest of the spec.

The earlier this change is made, the less painful it will be.

from baggage.

As was discussed during the call - the decision on name must balance between prior art - what was implemented in .NET based on Editor Draft of this spec and the benefits of different name. Prior art and implementations that are already live will speed up adoption of a spec. While better name can make support of some protocols like JMS better.

I'd suggest to keep the current name for the faster adoption. As I mentioned in PR #14 it's not just .NET, we see people using this specification already in other places and scenarios.

from baggage.

Opentelemetry is beginning work on this in earnest now. We should probably talk about this issue during tomorrow's call.

from baggage.

The current header is incompatible with JMS, not MQTT as I thought yesterday. I updated the description of the issue with an example.

from baggage.

I am indifferent towards the name that we choose

from baggage.

Please see this document for more context: https://docs.google.com/document/d/1Crnp9XguH3BY5b1hcAV2QNiHZV0SKyIuC3moZgdpgiE/edit#

from baggage.

If you choose to make this Correlation-Context zipkin will make a different header that can be used in JMS. your call

from baggage.

PS @SergeyKanzhelev please don't use google docs, they aren't visible in some countries due to blocking of google.

from baggage.

FWIW we've discussed b3ext a long time ago, but punted on it due to this spec. This is likely the default name if the spec here becomes unusable.

from baggage.

also renaming isn't a choice of just downcasing. for example, in trace-context iirc NR suggested different names hence traceparent and tracestate (no one I recall felt strongly enough to debate those choices, which is amazing)

ex simply correlation could also work

from baggage.

There's a separate issue tracking another potential name here #17

from baggage.

@adriancole we discussed the name correlation in the meeting but decided that it had too many other meanings, particularly a few of the tracing vendors use the term internally for their process of linking spans together, and we didn't want to explode the naming choices and make the decision drag on for too long of a time.

from baggage.

[felixbarny] From a consistency standpoint, it’s strange to both see lower cased, non-hyphenated headers like traceparent and the exact opposite in the same umbrella of specs.

Agreed.

[felixbarny] Backwards compatibility in drafts should not weight over compatibility with technologies like JMS and consistency with the rest of the spec.

Agreed. And it's not just JMS - I'd be surprised if there weren't other things out there that would choke on Correlation-Context, either now or in the future. Picking something with a maximum likelihood of compatibility in as many situations as possible feels like something this spec should shoot for.

[felixbarny] The earlier this change is made, the less painful it will be.

Agreed.

[SergeyKanzhelev] I'd suggest to keep the current name for the faster adoption.

The problem is once this is finalized, it can't realistically be changed. Sticking with Correlation-Context feels like a short term win but a long-term loss.

I do sympathize with wanting to disrupt existing stuff as little as possible. It's a valid concern and it almost swayed me. But taken as a whole I'd vote for changing it to correlationcontext or another similar name that's consistent with traceparent and tracestate, and maximizes the likelihood of compatibility with other non-HTTP techs/protocols/etc.

from baggage.

@nicmunroe thank you for the comment. One thing disappoints me with the traceparent and tracestate that I mentioned in the document:

As a note here, the promise of Trace Context specification doesn’t hold. Using header names tracestate and traceparent as a single word causes many issues like syntax error highlighting in IDEs. So in many places they are already treated as two words in variables naming and protocols.

So renaming to correlationcontext, tempting to keep consistent with the tracestate, may not be used the way we anticipate and recommend. So end users and protocol owners will start inserting delimiters anyway.

Renaming to baggage doesn't have this problem.

from baggage.

The header will be renamed to baggage.

from baggage.

Should this be closed since we have #17 ?

from baggage.

+1 to close

from baggage.