Header limits are obsolete and should be removed

[danielkhan]

In https://github.com/w3c/trace-context/blame/cr--edit-processing-model/spec/20-HTTP_HEADER_FORMAT.md#L387 we describe the limits which still reflects the 512 character limit we agreed on before coming up with the 5 entry limit.
This is now described in https://github.com/w3c/trace-context/blame/cr--edit-processing-model/spec/20-HTTP_HEADER_FORMAT.md#L375
Should we remove the limits paragraph entirely?

[SergeyKanzhelev]

Is it possible to close on this item separately from the big CR PR? Few considerations:

• Rationale doc should be updated with the discussions and reasoning
• There are two items that we need to make sure to address Action on tracestate header larger than 512 is confusing #175 and Explain/remove 512 limit of tracestate in spec #109
• My understanding that the MUST propagate 5 thing is still too aggressive of a requirement (Maybe even more aggressive than limiting to 512 characters if there are abuse. At least this is what we discussed in Amazon office during the KubeCon and should re-hash in rationale doc again.). Discussion was that SaaS/platform vendor may have its own limit published, which will make an incentive for tracing vendors to limit tracestate entries they require. Basically follow the @yurishkuro suggestion in Explain/remove 512 limit of tracestate in spec #109

[danielkhan]

ok - let's discuss that independently of the PR.

[AloisReitbauer]

We cannot move to PR if we do not reach a decision on this topic. I propose we add the trimming procedure to the PR and add a note that size requirements are still under discussion. What is currently in the spec does not reflect the latest discussions, so it at least needs to be removed.

[SergeyKanzhelev]

Let's clean up duplicates:

• Can a tracer/application only carry trace-parent and drop trace-state?
• Explain/remove 512 limit of tracestate in spec
• Action on tracestate header larger than 512 is confusing

Basically, we need to update rationale document with the logic of
decision and discussions we had. Suggest truncation strategies and
advice on the limits.

I'll close issues above. I'll sent a proposed update for this limit.

[danielkhan]

Let's continue discussion in #248

[SergeyKanzhelev]

@danielkhan can we keep the issue open as it's easier to discover issues left for CR than find a PR with the issue that wasn't closed.

[SergeyKanzhelev]

closed via #248