Request for a HTTP semantic conventions workgroup

[denisivan0v]

Semantic conventions for HTTP communications are available, but they remain in an experimental state. Related to the general semantic conventions workgroup requested in #803, we would like to request an additional workgroup that exclusively focuses on bringing semantic conventions for HTTP into a stable state.

We plan to discuss the following areas and the results in an OTEP:

• Status codes and errors
• Url/components attribute sets
• Attributes, optional attributes
• Request/Response body capture
• Retries, redirects and hedging policies
• Context propagation
• WebSockets/Long-polling and streaming

The proposed times for this workgroup are Monday 8 AM PST, Tuesday 9 AM PST or Wednesday 9 AM PST.

For reference please see request for an Instrumentation SIG in #802, the request for a Semantic Convention workgroup in #803, and the request for Messaging Semantic Convention workgroup in #805.

cc: @productml-ai @alolita @lmolkova @pyohannes @tedsuo

[Oberon00]

• Retries, redirects and hedging policies
• Context propagation

Note that retries + context propagation when sending a message were also a topic in the messaging WG kick-off meeting (see open-telemetry/oteps#173 (comment)). I think we should be careful when spinning up so many separate WGs that we do not come up with needlessly inconsistent solutions to very similar problems.

[lmolkova]

@Oberon00
I don't think we'll end up with inconsistent solutions. Messaging spec should talk about messaging specifics and HTTP describes transport (which can be used for messaging among other things).
Concepts like redirects and some context propagation aspects (headers, chance of requests being reused) are HTTP-specific and need to be explained in HTTP spec.
If there are common parts, we can separate them to general spec, but they are worth discussing with different groups of experts.

[tigrannajaryan]

@iNikem I think you had some questions about HTTP semantic conventions, if I remember correctly, so you may be interested in this.

[SergeyKanzhelev]

Perhaps this can be solved as a set of PRs to specs repo instead of a WG? We got a feedback that the big number of WGs is harmful and hard to not-full-time contributors to follow and participate.

[pyohannes]

Perhaps this can be solved as a set of PRs to specs repo instead of a WG? We got a feedback that the big number of WGs is harmful and hard to not-full-time contributors to follow and participate.

The reasons why we opted for introducing a WG for messaging (and HTTP):

1. It seemed we needed a focused group to work on a semantic conventions area, because a previous model with offline collaboration only resulted in a very slow progress.
2. We want (and need) SME inputs for the various semantic conventions, and distinct workgroups make it easy for SMEs to participate in discussions. A messaging architect wont sit through a 60 minute meeting to participate in a 15 minute discussions about messaging.
3. Those WGs should work towards bringing semantic conventions for a certain area to a stable state. Once that's achieved, the WG will be dissolved and we can discuss further changes in PRs and in meetings of the general instrumentation SIG.

However, I'm open to any other model that allows for focused in-person discussions. I'm not sure in how far the model is harmful, as all WGs are supposed to work on either OTEPs or spec PRs, which allow for offline collaboration and feedback without attending all meetings.

[lmolkova]

Perhaps this can be solved as a set of PRs to specs repo instead of a WG? We got a feedback that the big number of WGs is harmful and hard to not-full-time contributors to follow and participate.

I think we need both: less controversial problems can be easily solved with PR and offline discussion. Probably we can get really far with that on HTTP.
It would be nice to have group discussions for a path to stability and controversial things. Can we fit it into general semantic conventions meetings focused on certain issues and invite SMEs/architects there?

[denisivan0v]

Can we fit it into general semantic conventions meetings focused on certain issues and invite SMEs/architects there?

I would suggest us to start with a separate WGs for now, so we can build groups of people around semantic conventions topics and agree on scopes. The way I see it, the next would be to resolve controversial problems within WGs, and once we reached that point it would be easier to address individual items and eventually bring the existing semantic conventions to an initial stable state.

Also, we still need to select time. Don't you mind to quickly vote by clicking on the corresponding reaction?

Monday 8 AM PST - 🎉
Tuesday 9 AM PST - ❤️
Wednesday 9 AM PST - 🚀

[tedsuo]

@denisivan0v can you make it to the Tuesday 4pm Pacific meeting?

I agree with @lmolkova's proposal. Reviewing the HTTP semconv OTEP, very little of it is actually HTTP-specific. Almost all of it relates to general issues we have with instrumentation. As a result, we are already discussing these issues at that meeting. We can use HTTP as the focus for those discussions, so that SMEs can participate.

[tedsuo]

Following up on this issue, for now we've decided to stick to two meetings per week:

• Tuesday 4pm Pacific
• Thursday 8am Pacific

We can add an additional meeting if these meetings are not sufficient. Also, please join the #otel-instrumentation slack channel to get alerted to new issues/PRs and have async discussions.