Define the intended implementer

[danielkhan]

See https://lists.w3.org/Archives/Public/public-trace-context/2020Feb/0004.html

This spec is intended for vendors who operate distributed tracing systems (or operate distributed systems and want to use or connect to distributed tracing systems) and this protocol doesn’t rely on any changes from web browsers, although it’s possible that client-side JavaScript could use these headers as part of a distributed tracing system. The motivation is to encourage interop among several vendors in this space that are using HTTP and Web technologies, although it’s also noted that this could apply beyond HTTP.

Reviewing specs of this kind is a little less common for PING, since we’re most often looking at APIs or protocols that involve web site and web browser behaviors. The WG notes in their README that their intention is to ask for exceptions to CORS limitations on these headers, which would rely on web browsers treating these trace headers differently from other headers when making cross-origin requests, but that isn’t mentioned in this specification.

[mtwo]

Responding here inline @npdoty :

1. Who is the intended implementer and does this need to be a W3C web standard?
As you point out, this header won't be used in web browsers in the near-term, but is needed for other components like clients, servers, and browser JS libraries that communicate via HTTP. We're also looking for some parts of this spec to be given exceptions to CORS, though this isn't yet in the spec as we're still defining this functionality.

2. What information may be revealed in these standardized identifier headers and who will have access to that information?
I think that you answered this question in your response, but let me know if I need to address this directly

3. Privacy considerations
Can the intelligence-free nature of these identifiers be confirmed or audited by external parties?
Identifier randomness is up to implementations, with OpenTelemetry likely being the most prolific of these. OpenTelemetry is fully open source and auditable.

Note that these privacy concerns of the traceparent field are theoretical rather than practical.
We'll remove this

Vendors extremely sensitive to personal information exposure MAY implement selective removal of values corresponding to the unknown keys. Vendors SHOULD NOT mutate the tracestate field, as it defeats the purpose of allowing multiple tracing systems to collaborate.
I agree that the phrasing here is awkward and unclear. We'll rewrite the section.

Vendors should ensure that they include only these response headers when responding to systems that participated in the trace.
As you suggested, we'll replace this with "Vendors should ensure that they include these response headers only when responding to systems that participated in the trace."

“requeest” should be “request”
This has since been fixed.

@npdoty do my responses address your concerns? Let us know and we can continue discussing and create PRs.

[dyladan]

As you suggested, we'll replace this with "Vendors should ensure that they include these response headers only when responding to systems that participated in the trace."

I am concerned by this wording because one of the main use-cases is the supportability use-case where a cloud service returns their internal trace id when they are called so that if something goes wrong, you can include that trace id in your support request. This use-case not only doesn't guarantee the caller is a participant, but almost guarantees they are not.

[kalyanaj]

This is something we will consider for Level 2 cleanup. We can add information about various implementations. Examples of categories could be: tracing vendors/systems, cloud vendors, library authors, language authors (e.g., .NET), browsers (for the future - e.g. even before the initial page load they could generate a traceID).