Discuss using http.request.* and http.response.*

[danielkhan]

For HTTP we often have to distinguish between request and response which leads to long field names like http.requestheaders and http.responseheaders.

So instead of using http.requestheaders it could be http.request.headers, http.response.headers.

This might be also applicable to other protocols.

ECS does something similar https://github.com/elastic/ecs/blob/master/schemas/http.yml

[Oberon00]

For HTTP we often have to distinguish between request and response

This is done via the Span Kind, not the attribute names.

Headers cannot really be transported with the current restriction that attributes must be scalars (unless you use a convention like htpp.response.header.<HEADERNAME>). It is a bit unclear what this issue is about: Introduce semantic conventions for headers?

[jmacd]

Closing this as there are no semantic conventions for request and response headers. Please reopen if you think we should have semantic conventions for request and response headers at this time, or submit a PR to the spec.