Name and version were added in #2767 based on #2719 which does not contain any context - was probably raised to align RPC with HTTP.

Since that we've started to consider RPC conventions to record logical call (HTTP/etc would be physical) and then network.protocol.name|version become less relevant:

1. protocol details are not really accessible at the instrumentation point (gRPC, ConnectRPC) - this makes sense since RPC frameworks frequently support pluggable transports and are, to a certain extent, transport-agnostic
2. protocol details are usually not that interesting (protocol is usually HTTP, versions could be different in some cases)
3. Transport is usually TCP (could be unix, pipe, or UDP in edge cases) and is not an essential characteristic of generic RPC call.

The most important part is that network-level details are primarily important on the physical / protocol calls and are less accessible/interesting on logical layer.

What could be important - the flavor of the RPC protocol:

• content-type:
  • gRPC: application/grpc(+proto), application/grpc+json (application/grpc[+{subtype}])
  • ConnectRPC: application/grpc[+{subtype}], application/grpc-web[+{subtype}], application/connect+proto | json. This allows to differentiate if client used pure HTTP
  • dubbo: application/{Message-Codec} (json, grpc+proto and more)
• framework/protocol-specific:
  • dubbo: TRI-Protocol-Version header
  • json-rpc: protocol version ("2.0")

So the proposal here:

• remove network.protocol.name|version and network.transport from generic RPC spans, system-specific conventions can still reference them when they are important. This is similar to DB conventions - these attributes are not included
• system-specific conventions should add attributes to describe protocol flavors/versions important for them

Also: should we consider promoting content-type on metrics?