Clarify handling of duplicate keys in tracestate

[tsloughter]

Discussing on gitter last week it was not clear from the spec how to handle duplicate keys in a received tracestate.

The tests require the tracestate is dropped in such a case:

trace-context/test/test.py

Line 536 in 98f210e

def test_tracestate_duplicated_keys(self):

The example in the spec about going through a system twice is also a bit confusing, https://w3c.github.io/trace-context/#combined-header-value

I think it would make more sense, even though it is an example of what shouldn't be used, to say it shouldn't be congo=congosSecondPosition,rojo=rojosFirstPosition,congo=congosFirstPosition simply because the newer entries should come first.

[danielkhan]

If a system follows the spec, duplicate keys can not occur. As such a header with duplicate keys is considered to be invalid.

I think it's questionable if the suggested example would be more correct as it would mean flipping congosSecondPosition and congosFirstPosition but I will bring it up at the next meeting.

[danielkhan]

The tests are too rigid and test non-normative rules and we should modify them.

[danielkhan]

@reyang do you have time to look into this?

[reyang]

@danielkhan it is unclear to me what's the expectation for the test cases:

1. Do we expect the Test Service to take tracestate that has duplicated keys, instead of drop it on the floor? - I guess the answer is YES.
2. Do we expect the Test Service to send the tracestate without de-dupe, or it should de-dupe the keys before sending it out? - I guess the answer is YES.

[danielkhan]

Sorry for the long wait. Let's go for 1.)
For 2. just forward without de-dupe.

[dyladan]

@reyang sorry to ping you on this after so long but did you ever get around to this?