>
I suspect we may end up having to support multiple formats in our
implementations inevitably due to the need to interop with other
libraries that didn't coordinate on this mailing list.
That makes sense, I agree.
>
Do you know why the spec for HTTP header encoding chose hex instead of base64?
I do not. Poking around their github there isn't a discussion of base64, but they have talked about removing the fixed length binary requirement on some fields all together (in favor of any old string).
Side note, I have the same question about UUID. Although I'm not sure if the same readability arguments apply.
>
Someone sitting on the bridge between JSON-RPC and HTTP will have to
convert between these two formats as opposed to just copying the strings
over.
That's a good point. I want to say that it's trivial to convert
00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01 to something like { version: 0, trace-id: "4bf92f3577b34da6a3ce929d0e0e4736", parent-id: "00f067aa0ba902b7", trace-flags: 1}, but experience tells that even doing something trivial can seem burdensome compared to doing nothing.
Also, just typing that out I had the compulsion to convert the 'version' and 'trace-flags' to numbers because a) that would be the natural json type and b) it's smaller on the wire. But that's another degree of ambiguity that we would need to specify.
>
Is there precedent for other encoding besides the single-string one
presented by the HTTP header spec? If there is, such that breaking the
values up is common, I'll be less concerned. But if folks tend to just
reuse that single-string encoding across many protocols, I think we
should follow that.
Yes, there are drafts of a binary format and a format for MQTT. The binary format breaks the fields up, converts the hex to binary, and re-combines the fields with field delimiters and length prefixes and such. The MQTT format only specifies for v5, but makes a recommendation for v3. v5 uses headers, so it uses the same formats as HTTP (
00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
). v3 is just a recommendation, but suggests that if the body is json, to use simple strings in the outermost object. I doubt we will see implementations of the v3 recommendation in libraries, and the spec is just a draft, but I do think it might be a bit reckless for them to recommend injecting a field with a name like 'tracestate' into json payloads whose format they know nothing about. On one hand it would be compatible with a simple string implementation of json-rpc over mqtt, but on the other it might overwrite a pre-existing value that we had put there already.
>
we might end up supporting 2+1 instead of 1+1 formats
I think this is persuasive. I don't think that we would end up with 2+1 if we write for W3C, but the object format might take longer to get consensus on.
It seems like if we have one format for a first version and an inevitable additional format in a second version, and one of those formats is going to be the simple string, then it's sensical to have the simple string as the first version. It also makes for a pretty short first version of the spec.