SpanContext and Link spec/proto are not clear

[dyladan]

From SpanContext spec https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#spancontext:

SpanContext contains traceId, spanId, TraceFlags, and TraceState.

From Link specification https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#specifying-links:

A Link contains a SpanContext and zero or more Attributes.

From proto definition of Link https://github.com/open-telemetry/opentelemetry-proto/blob/a17f202fdae65e828ac29fb663b5bc5b64b13290/opentelemetry/proto/trace/v1/trace.proto#L197:

Link contains trace_id, span_id, and trace_state, but does not contain TraceFlags.

Thus, if a user wants to create a Link they must first create or get a SpanContext which has a valid TraceFlags. TraceFlags are not included in the Link proto so it might be confusing to the user to have to specify flags for the link which have no effect.

I would suggest that the Link spec is modified to specifically state that only the fields included in the proto are required for a link.

This issue was originally brought to my attention by follow up from an issue @carlosalberto filed on the JS API suggesting we use SpanContext in our Link type instead of the LinkContext type we had created specifically for this purpose.

[Oberon00]

Or maybe the trace flags should be included in the protocol? It might be interesting to know whether the parent had the sampled flag set or not.

[dyladan]

As I see it, the options are:

1. include traceflags in the protocol
2. specify that links only contain traceid, spanid, and tracestate (and attributes of course)
3. close this issue and leave SIG maintainers to resolve the discrepancy by either creating a new type or just using spancontext and dropping the unnecessary field in the otlp exporter

[reyang]

traceflags might be useful for certain backends to optimize indexing.

Discussed during the spec SIG meeting, we haven't seen a strong case that traceflags are needed in the protocol.

One thinking is that it might be easier/consistent to have the OTLP covering the entire SpanContext (which flows across RPC boundaries), which makes the spec simpler, and also makes it easier to add new stuff in the future in case W3C TraceContext has introduced new optional things.