W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2023

RE: [EXTERNAL] Re: W3C Trace Context Level 2 & Baggage specifications

From: J. Kalyana Sundaram <kalyanaj@microsoft.com>
Date: Tue, 14 Feb 2023 19:01:28 +0000
To: Mark Nottingham <mnot@mnot.net>
CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, Sergey Kanzhelev <skanzhelev@google.com>, Philippe Le Hégaret <plh@w3.org>
Message-ID: <BN6PR21MB04662802DB24306E6AAAE85EDAA29@BN6PR21MB0466.namprd21.prod.outlook.com>
Hi Mark,

Thanks a lot for your response, and my apologies on the delay in getting back to you.

A few initial comments:

1. Registration with IANA: I believe this is already done per https://github.com/w3c/trace-context/issues/120#issuecomment-1082266813 

2. Changing HTTP RFC: I filed an issue for this based on your feedback below: https://github.com/w3c/trace-context/issues/519

3. For the rest of the comments, Trace Context 1 is already in Recommendation status for the last couple of years, we are now looking to get feedback on the Level 2 of the spec which adds a new trace flag and improves considerations for traceid/spanid generation. It doesn't add any new headers.



-----Original Message-----
From: Mark Nottingham <mnot@mnot.net> 
Sent: Wednesday, February 1, 2023 7:39 PM
To: J. Kalyana Sundaram <kalyanaj@microsoft.com>
Cc: ietf-http-wg@w3.org; Sergey Kanzhelev <skanzhelev@google.com>; Philippe Le Hégaret <plh@w3.org>
Subject: [EXTERNAL] Re: W3C Trace Context Level 2 & Baggage specifications

[You don't often get email from mnot@mnot.net. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

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:

* 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhttpwg.org%2Fspecs%2Frfc9110.html%23considerations.for.new.fields&data=05%7C01%7Ckalyanaj%40microsoft.com%7Ce38728e9c4f241b4b92f08db04cf1ba0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638109059804919053%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ijtFP3aD0e3%2BgKOzZcSft3BwCZ%2BdeNJfs9Ljk0%2B4zfs%3D&reserved=0> and make sure you have addressed the points there.

See also <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhttpwg.org%2Fadmin%2Feditors%2Fstyle-guide&data=05%7C01%7Ckalyanaj%40microsoft.com%7Ce38728e9c4f241b4b92f08db04cf1ba0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638109059804919053%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=YdPGFHIt9ejNbQSjWP7G3Fd%2BvRG7JL0g%2FKEP6fRN0RU%3D&reserved=0> for the preferred editorial style for HTTP-related documents.

Finally, make sure you register the fields with IANA; see:

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


> On 1 Feb 2023, at 1:29 pm, J. Kalyana Sundaram <kalyanaj@microsoft.com> wrote:
>  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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mnot.net%2F&data=05%7C01%7Ckalyanaj%40microsoft.com%7Ce38728e9c4f241b4b92f08db04cf1ba0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638109059804919053%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5mzIc7qxEAHV2MQPJlZ8gwW%2F4FJj4aWV6IKPsSkGK6I%3D&reserved=0
Received on Tuesday, 14 February 2023 19:01:45 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 14 February 2023 19:01:46 UTC