Consider using byte arrays for trace and span IDs

[iredelmeier]

See open-telemetry/opentelemetry-go#183 for a similar issue.

[jtescher]

Could be nice to see a before / after here to evaluate ergonomics and conversion (e.g. uuid)

Looks like currently to/from would be something like:

let trace_id: u128 = 0x4bf9_2f35_77b3_4da6_a3ce_929d_0e0e_4736;

// From str
assert_eq!(u128::from_str_radix("4bf92f3577b34da6a3ce929d0e0e4736", 16), Ok(trace_id));

// To str
assert_eq!(format!("{:032x}", trace_id).as_str(), "4bf92f3577b34da6a3ce929d0e0e4736");

// From / to uuid
assert_eq!(uuid::Uuid::from_u128(trace_id).as_u128(), trace_id);

[MikeGoldsmith]

It's worth mentioning that B3 headers support 128 bit trace IDs where most other propagators are limited to 64 bits. The full trace ID needs to be preserved if received and then propagated via B3 headers but can be truncated to 64 bits (lower significant bits) for other propagators.

Some implementations use a byte array (like Go) to manage a single 64 or 128 bit id, others maintain the original trace ID as a string and a uint64 for the truncated 64 bit part (eg .NET).

[jtescher]

@MikeGoldsmith great point, is there a list of propagators that otel impls should support? Seems 64 bit traces are typically older versions?

[MikeGoldsmith]

I think B3 should be good enough for now. Vendor specific propagators can come later, and as long as we have both 128 and 64 bit IDs, we should be good 👍

[jtescher]

Hm well we currently support b3 the same way that the go impl does, and it looks like they require 128 bits? could be 0 padded but that works with u128 just the same? https://github.com/open-telemetry/opentelemetry-go/blob/a9756528bada550d81d668a2536a4e0788faa5c4/api/core/span_context.go#L88-L90

[iredelmeier]

B3 and W3C Trace-Context, which is 128-bit and should be the default.

[jtescher]

Closing this for now, can re-open if there is renewed interest.