Re: W3C Trace Context Level 2 & Baggage specifications

[Mark Nottingham <[e-mail]>]

Hi Kalyan,

Thanks for the heads-up. Just a few observations from a quick read through --

* 3.2.1 Header Name (and 3.3.2)

> In order to increase interoperability across multiple protocols and encourage successful integration, tracing systems SHOULD encode the header name as ASCII lowercase.

It's a bit unusual to specify this; HTTP header names are widely implemented as case-insensitive. Why is it felt necessary to say this? Same question for the preceding paragraph.

* 3.2.3 Examples of HTTP traceparent Headers

~~~
Valid traceparent when caller sampled this request:
Value = 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
base16(version) = 00
base16(trace-id) = 4bf92f3577b34da6a3ce929d0e0e4736
base16(parent-id) = 00f067aa0ba902b7
base16(trace-flags) = 01 // sampled
~~~

This is confusing, because it doesn't actually include the header field. It'd be more clear if it were an entire request header section, followed by information about it; e.g.,

~~~
GET /foo HTTP/1.1
Host: example.com
TraceParent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01

The above request has the following traceparent values:

* base16(version) = 00
* base16(trace-id) = 4bf92f3577b34da6a3ce929d0e0e4736
* base16(parent-id) = 00f067aa0ba902b7
* base16(trace-flags) = 01 // sampled
~~~

* 3.2.4 Versioning of traceparent

Generally, we don't recommend versioning HTTP fields; it's better to just define a new field name for the new, incompatible semantics or syntax. Are you using a version flag here because you expect this structure to appear outside of HTTP headers?

* Syntax

These headers are somewhat unusual; e.g., tracestate doesn't allow commas, when it could have just used a quoted value; trace parent has a very specific encoding rather than using more typical key/value pairs or lists. Why was this approach taken?

We're encouraging new fields to be defined as Structured Fields, rather than using ABNF; see:
  https://httpwg.org/specs/rfc8941.html

* Other

The defining document for HTTP is now RFC9110, not RFC7230/1; please update your references accordingly.

Please see the list of considerations for new fields at <https://httpwg.org/specs/rfc9110.html#considerations.for.new.fields> and make sure you have addressed the points there.

See also <https://httpwg.org/admin/editors/style-guide> for the preferred editorial style for HTTP-related documents.

Finally, make sure you register the fields with IANA; see:
  https://github.com/protocol-registries/http-fields/

(it's good practice to put the registration template in your specification, but not required)

Cheers,


> On 1 Feb 2023, at 1:29 pm, J. Kalyana Sundaram <[e-mail]> wrote:
> 
> Hello IETF HTTP WG:
>  Sergey and I are the co-chairs for the W3C Distributed Tracing Working Group.  We are currently in the Wide Review process for the following two specifications:  
>  
>     • Trace Context Level 2 specification: Trace Context Level 2 (w3.org) Latest Editor’s Draft: Trace Context Level 2 (w3c.github.io)
>     • Baggage specification: Propagation format for distributed context: Baggage (w3.org) Latest Editor’s Draft: Propagation format for distributed context: Baggage (w3c.github.io)
>  As part of this wide review process, we wanted to notify you about the above two specifications and get your approval. Please let us know if you have any feedback / questions, or if you need any additional information.
>  Thanks,
>  Kalyan


--
Mark Nottingham   https://www.mnot.net/