w3c/trace-context

Release trace context level-1

dyladan opened this issue · 9 comments

dyladan commented

Since the most recent level-1 publish, there has been an erratum raised and fixed.

It might be good to wait for #465 to merge first so this only needs to be done once.

plehegar commented
  1. All changes to the BNF are just about fixing the notation #432
  2. #465 removes some confusing vendor/tenant wording
  3. #428 fixes a contradiction between the mutation. In effect, it changes a MUST to a SHOULD on how keys are ordered if there is a mutation.

All of the changes do not affect implementations

swickr commented

Re: #428 -- How likely is it that some implementation relied on moving modified keys to the left? How many implementations consistently moved a modified key?

basti1302 commented

@swickr

How likely is it that some implementation relied on moving modified keys to the left?

Let me rephrase this question slightly: How likely is it that an implementation B relied on an implementation A (where A is upstream of B in that particular transaction) to move the key that A modifies to the left. That would be the only situation in which the change from MUST to SHOULD could be considered a breaking change and I assume that is the intent behind your question, correct?

IMO that would be an extremely unlikely scenario, I would even say impossible. The tracestate header field value is a set of vendor specific key value pairs. Each vendor is supposed to only care about the key value pairs which it adds to tracestate itself. Everything else in there is to be treated as a list of opaque key value pairs. Thus, an implementation is not supposed to derive any information from key value pairs from other vendors. In my understanding, this also implies that an implementation is not supposed to analyze the relative positions of key value pairs that belong to other implementations.

How many implementations consistently moved a modified key?

I do not understand the motivation for this question. If a hypothetical implementation existed that does not consistently move they key value pair to the left when updating it, it would be in violation of the spec now and technically, it would no longer violate the spec after this update.

FWIW, to the best of my knowledge, there is no such implementation. All implementations I know of that modify tracestate work like this:

  1. Check if their own key is present in tracestate.
  2. If it is already present, update it and move it to the left-most position when propagating tracestate downsteam.
  3. If it is not present, simply prepend their own key value pair as the left-most position when propagating tracestate downsteam.
  • 👍2
plehegar commented

In section 3.5 Mutating the tracestate Field (level-1 branch), I read:

  • "Modified keys MUST be moved to the beginning (left) of the list." (first paragraph)
  • Update an existing value. [...]. "Modified keys SHOULD be moved to the beginning (left) of the list."

So, I would conclude that the change from MUST to SHOULD in the second paragraph did not affect the fact that implementations are still expected to move the modified key to the beginning (left) of the list. Shouldn't we modify the first sentence as well?

dyladan commented

IMO that would be an extremely unlikely scenario, I would even say impossible. The tracestate header field value is a set of vendor specific key value pairs. Each vendor is supposed to only care about the key value pairs which it adds to tracestate itself. Everything else in there is to be treated as a list of opaque key value pairs. Thus, an implementation is not supposed to derive any information from key value pairs from other vendors. In my understanding, this also implies that an implementation is not supposed to analyze the relative positions of key value pairs that belong to other implementations.

I agree except on one point. It is important that entries are moved left if the header ever grows too long and needs to be truncated. This ensures the most recently updated keys are the ones which are kept after truncation.

plehegar commented

Publication of the updated Rec has been requested for November 23.

  • 🎉1