-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider renaming the header from Correlation-Context to correlationcontext #13
Comments
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. |
Opentelemetry is beginning work on this in earnest now. We should probably talk about this issue during tomorrow's call. |
The current header is incompatible with JMS, not MQTT as I thought yesterday. I updated the description of the issue with an example. |
I am indifferent towards the name that we choose |
Please see this document for more context: https://docs.google.com/document/d/1Crnp9XguH3BY5b1hcAV2QNiHZV0SKyIuC3moZgdpgiE/edit# |
If you choose to make this Correlation-Context zipkin will make a different header that can be used in JMS. your call |
PS @SergeyKanzhelev please don't use google docs, they aren't visible in some countries due to blocking of google. |
FWIW we've discussed |
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 |
There's a separate issue tracking another potential name here #17 |
A few thoughts. 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. |
@adriancole we discussed the name |
Agreed.
Agreed. And it's not just JMS - I'd be surprised if there weren't other things out there that would choke on
Agreed.
The problem is once this is finalized, it can't realistically be changed. Sticking with 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 |
@nicmunroe thank you for the comment. One thing disappoints me with the
So renaming to Renaming to |
The header will be renamed to |
Should this be closed since we have #17 ? |
+1 to close |
Proposal
For trace-context we decided to use to use all lowercase alphabetic characters to make the header usable in non HTTP scenarios. Message queues such as JMS are more restrictive than HTTP in regards to header names. If we expect to propagate Correlation Context over protocols other than HTTP, we should consider using the same naming conventions as used for trace-context and name this header
correlationcontext
.The rationale for this change is the same as the rationale for Trace Context headers. See: https://github.com/w3c/trace-context/blob/master/http_header_format_rationale.md#lowercase-concatenated-header-names
Some benefits of having an alphabetic lowercase header name:
Known Issues
Incompatible as a JMS Header
Correlation-Context
is incompatible as a JMS header due to the-
character.Section 3.8.1.1 (Message Selector Syntax) of the JMS Specification states:
Example:
Output:
The text was updated successfully, but these errors were encountered: