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

Hi Mark,

Also, here is the pull request (thanks Bastian!) to address the issue for "The defining document for HTTP is now RFC9110, not RFC7230/1; please update your references accordingly." in case you are interested in reviewing it: 

https://github.com/w3c/trace-context/pull/521

Thanks,

Kalyan


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

Hi Mark,

I want to add one thing to my earlier responses below to your comments on the trace context specification:

We also have the Baggage specification (the second spec in my original e-mail below) https://w3c.github.io/baggage/ that is in wide review status. If you have any feedback on it, please let us know (or you can file issues at https://github.com/w3c/baggage/issues).

Thank you,

Kalyan

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

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.

Thanks,

Kalyan

-----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:
  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhttpwg.org%2Fspecs%2Frfc8941.html&data=05%7C01%7Ckalyanaj%40microsoft.com%7Ce38728e9c4f241b4b92f08db04cf1ba0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638109059804919053%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=60QOahrt3JwaV93%2Bz9ZgAe6yxMFYXJP4i5KSLOhPRls%3D&reserved=0

* 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:
  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fprotocol-registries%2Fhttp-fields%2F&data=05%7C01%7Ckalyanaj%40microsoft.com%7Ce38728e9c4f241b4b92f08db04cf1ba0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638109059804919053%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7pSLuuVnAOuVgSYlj83QWRy%2FwL6IZR9CwxvWA4%2BP%2Fgw%3D&reserved=0

(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 <kalyanaj@microsoft.com> 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://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 Monday, 27 February 2023 16:32:34 UTC