From fb94c02a3e73799b4fe30f0edc2e4ba7c2f6f30c Mon Sep 17 00:00:00 2001 From: James Thompson Date: Wed, 1 Oct 2025 00:01:07 +1000 Subject: [PATCH 01/10] First Draft at guidance --- docs/rpc/README.md | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/docs/rpc/README.md b/docs/rpc/README.md index 8a4afa2455..8a55af9938 100644 --- a/docs/rpc/README.md +++ b/docs/rpc/README.md @@ -49,4 +49,37 @@ Specifications defined by maintainers of RPC systems: * [gRPC](https://github.com/grpc/proposal/blob/master/A66-otel-stats.md): Semantic Conventions for *gRPC*. +## RPC Service vs RPC Framework + +### What is a RPC Protocol? + +A RPC protocol describes the manner in which a message is transported from one service to another. +This protocol may have the same value as the network protocol ie http or it may differ when, +a implementation of the network protocol is used ie gRPC. + +These implementation's will usually only expose a subset of functionality of the network protocol +and may only be compatible with newer versions of the network protocol ie grpc will not work over http v1. + +Some pre-defined protocols are: + +* [gRPC](#) +* [http](#) +* [triple](#) +* [soap](#) + +### What is a RPC Framework? + +A RPC Framework describes the api's made available to applications wanting to implement RPC Communications +in a protocol agnostic manner. This is why protocol and framework is not a one-to-one relationship but rather one-to-many. + +The framework in adddition to providing the api can define properties which are sent along with the message +to provide additional context. For instance a framework might require a message id to be sent with the message. +The framework doesn't care how it is transported across the network. + +Some pre-defined frameworks are: + +* [Apache Dubbo](#) +* [Dapr](#) +* [Connect RPC](#) + [DocumentStatus]: https://opentelemetry.io/docs/specs/otel/document-status From 4effed54ac8552a9fc20f479777752dac046026f Mon Sep 17 00:00:00 2001 From: James Thompson Date: Thu, 2 Oct 2025 00:48:28 +1000 Subject: [PATCH 02/10] Further refinement of guidance --- docs/rpc/README.md | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/docs/rpc/README.md b/docs/rpc/README.md index 8a55af9938..667330554e 100644 --- a/docs/rpc/README.md +++ b/docs/rpc/README.md @@ -55,7 +55,7 @@ Specifications defined by maintainers of RPC systems: A RPC protocol describes the manner in which a message is transported from one service to another. This protocol may have the same value as the network protocol ie http or it may differ when, -a implementation of the network protocol is used ie gRPC. +an implementation of the network protocol is used ie gRPC. These implementation's will usually only expose a subset of functionality of the network protocol and may only be compatible with newer versions of the network protocol ie grpc will not work over http v1. @@ -66,6 +66,10 @@ Some pre-defined protocols are: * [http](#) * [triple](#) * [soap](#) +* [Connect RPC](#) + +It is expected that these protocols will define protocol specific attributes, for instance gRPC would contain a status attribute. +As such the usage of these attribute/s should be documented via a dedicated protocol page providing complete definitions. ### What is a RPC Framework? @@ -81,5 +85,13 @@ Some pre-defined frameworks are: * [Apache Dubbo](#) * [Dapr](#) * [Connect RPC](#) +* [JSON-RPC](#) + +These frameworks can provide additional attributes for capturing the properties mentioned earlier. +It is expected that these attributes are added where appropriate to the corresponding signals defined for the network protocol, +with a general "if applicable for the rpc framework" condition placed on the requirement level. + +A framework may have its own page when the framework defines its own signals which require the inclusion of framework specific +attributes for the signal to have value & meaning. [DocumentStatus]: https://opentelemetry.io/docs/specs/otel/document-status From df66ee5a6e258dbc27fc708c522b2bcce93edce6 Mon Sep 17 00:00:00 2001 From: James Thompson Date: Thu, 2 Oct 2025 09:59:50 +1000 Subject: [PATCH 03/10] Review feedback --- docs/rpc/README.md | 35 ++++++++++++++++++++++------------- 1 file changed, 22 insertions(+), 13 deletions(-) diff --git a/docs/rpc/README.md b/docs/rpc/README.md index 667330554e..362db2bd92 100644 --- a/docs/rpc/README.md +++ b/docs/rpc/README.md @@ -49,24 +49,28 @@ Specifications defined by maintainers of RPC systems: * [gRPC](https://github.com/grpc/proposal/blob/master/A66-otel-stats.md): Semantic Conventions for *gRPC*. -## RPC Service vs RPC Framework +## RPC Protocol vs RPC Framework ### What is a RPC Protocol? A RPC protocol describes the manner in which a message is transported from one service to another. This protocol may have the same value as the network protocol ie http or it may differ when, -an implementation of the network protocol is used ie gRPC. +an implementation of the network protocol is used e.g. gRPC. -These implementation's will usually only expose a subset of functionality of the network protocol +These implementations will usually only expose a subset of functionality of the network protocol and may only be compatible with newer versions of the network protocol ie grpc will not work over http v1. Some pre-defined protocols are: -* [gRPC](#) -* [http](#) -* [triple](#) -* [soap](#) -* [Connect RPC](#) +* [gRPC](grpc.md) + +* [HTTP](/docs/http/README.md) + +* Triple + +* SOAP + +* [Connect RPC](connect-rpc.md) It is expected that these protocols will define protocol specific attributes, for instance gRPC would contain a status attribute. As such the usage of these attribute/s should be documented via a dedicated protocol page providing complete definitions. @@ -76,16 +80,21 @@ As such the usage of these attribute/s should be documented via a dedicated prot A RPC Framework describes the api's made available to applications wanting to implement RPC Communications in a protocol agnostic manner. This is why protocol and framework is not a one-to-one relationship but rather one-to-many. -The framework in adddition to providing the api can define properties which are sent along with the message +The framework in addition to providing the api can define properties which are sent along with the message to provide additional context. For instance a framework might require a message id to be sent with the message. The framework doesn't care how it is transported across the network. Some pre-defined frameworks are: -* [Apache Dubbo](#) -* [Dapr](#) -* [Connect RPC](#) -* [JSON-RPC](#) +* Apache Dubbo + +* Dapr + +* [Connect RPC](connect-rpc.md) + +* [JSON-RPC](json-rpc.md) + +* WCF These frameworks can provide additional attributes for capturing the properties mentioned earlier. It is expected that these attributes are added where appropriate to the corresponding signals defined for the network protocol, From bf512e67be7f9af0eec04a93119e5e4316881e69 Mon Sep 17 00:00:00 2001 From: James Thompson Date: Thu, 2 Oct 2025 13:26:53 +1000 Subject: [PATCH 04/10] Document correction --- docs/rpc/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/rpc/README.md b/docs/rpc/README.md index 362db2bd92..8d6cd081b0 100644 --- a/docs/rpc/README.md +++ b/docs/rpc/README.md @@ -97,7 +97,7 @@ Some pre-defined frameworks are: * WCF These frameworks can provide additional attributes for capturing the properties mentioned earlier. -It is expected that these attributes are added where appropriate to the corresponding signals defined for the network protocol, +It is expected that these attributes are added where appropriate to the corresponding signals defined for the rpc protocol, with a general "if applicable for the rpc framework" condition placed on the requirement level. A framework may have its own page when the framework defines its own signals which require the inclusion of framework specific From 9399d0638bd7654de0fddd3c310f7875097fe2d0 Mon Sep 17 00:00:00 2001 From: James Thompson Date: Mon, 6 Oct 2025 01:29:53 +1100 Subject: [PATCH 05/10] More improvements to guide --- docs/rpc/README.md | 51 +++++++++++++++++++++++++++------------------- 1 file changed, 30 insertions(+), 21 deletions(-) diff --git a/docs/rpc/README.md b/docs/rpc/README.md index 8d6cd081b0..d76f4ad1b1 100644 --- a/docs/rpc/README.md +++ b/docs/rpc/README.md @@ -7,7 +7,7 @@ linkTitle: RPC **Status**: [Development][DocumentStatus] This document defines semantic conventions for remote procedure calls (RPC) -, also called "remote method invocations" (RMI). +, sometimes called "remote method invocations" (RMI). > [!IMPORTANT] > Existing RPC instrumentations that are using @@ -34,42 +34,49 @@ This document defines semantic conventions for remote procedure calls (RPC) > * MAY drop the environment variable in their next major version and emit only > the stable RPC conventions. -Semantic conventions for RPC are defined for the following signals: +The RPC Semantic conventions are designed to cover the logical operation of invoking an operation (function) to run in a remote process. +This remote process call will often travel across the network to reach it's destination. + +The details of this invocation can be captured using the following signals: * [RPC Spans](rpc-spans.md): Semantic Conventions for RPC client and server *spans*. * [RPC Metrics](rpc-metrics.md): Semantic Conventions for RPC *metrics*. -Technology specific semantic conventions are defined for the following RPC systems: +These generic conventions can be extended based on the protocol/framework being used. +This is described in more detail in the [RPC Transport Protocol vs RPC Framework](#rpc-ransport-protocol-vs-rpc-framework) section. -* [Connect](connect-rpc.md): Semantic Conventions for *Connect RPC*. -* [gRPC](grpc.md): Semantic Conventions for *gRPC*. -* [JSON-RPC](json-rpc.md): Semantic Conventions for *JSON-RPC*. +However should the process being invoked be a member of a more specific domain such as those below, +the corresponding conventions should be followed: -Specifications defined by maintainers of RPC systems: +* [Database](/docs/database/README.md) +* [Generative AI](/docs/gen-ai/README.md) +* [Messaging](/docs/messaging/README.md) -* [gRPC](https://github.com/grpc/proposal/blob/master/A66-otel-stats.md): Semantic Conventions for *gRPC*. +If your focus is on the network layer calls rather than the logical calls being made, +the RPC documents are not for you but instead what you are after is described via the below conventions: -## RPC Protocol vs RPC Framework +* [Http](#) -### What is a RPC Protocol? +## RPC Transport Protocol vs RPC Framework -A RPC protocol describes the manner in which a message is transported from one service to another. +### What is a RPC Transport Protocol? + +A RPC transport protocol describes the manner in which a message is transported from one service to another. This protocol may have the same value as the network protocol ie http or it may differ when, an implementation of the network protocol is used e.g. gRPC. These implementations will usually only expose a subset of functionality of the network protocol and may only be compatible with newer versions of the network protocol ie grpc will not work over http v1. -Some pre-defined protocols are: +Another aspect of how the network.protocol.* differs to rpc.transport.protocol.* is that, +the transport protocol can implement additional client side functionality such as retry, caching, cancellation etc. -* [gRPC](grpc.md) - -* [HTTP](/docs/http/README.md) +Some pre-defined transport protocols are: +* [gRPC](grpc.md) +* [Http](/docs/http/README.md) * Triple - * SOAP - * [Connect RPC](connect-rpc.md) It is expected that these protocols will define protocol specific attributes, for instance gRPC would contain a status attribute. @@ -87,13 +94,9 @@ The framework doesn't care how it is transported across the network. Some pre-defined frameworks are: * Apache Dubbo - * Dapr - * [Connect RPC](connect-rpc.md) - * [JSON-RPC](json-rpc.md) - * WCF These frameworks can provide additional attributes for capturing the properties mentioned earlier. @@ -103,4 +106,10 @@ with a general "if applicable for the rpc framework" condition placed on the req A framework may have its own page when the framework defines its own signals which require the inclusion of framework specific attributes for the signal to have value & meaning. +## Supplementry Documents + +Specifications defined by maintainers of RPC systems: + +* [gRPC](https://github.com/grpc/proposal/blob/master/A66-otel-stats.md): Semantic Conventions for *gRPC*. + [DocumentStatus]: https://opentelemetry.io/docs/specs/otel/document-status From 6ce562155353bd2aefc6f69024d2135630b31c10 Mon Sep 17 00:00:00 2001 From: James Thompson Date: Mon, 6 Oct 2025 13:42:49 +1100 Subject: [PATCH 06/10] Doc Fixes --- docs/rpc/README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/rpc/README.md b/docs/rpc/README.md index d76f4ad1b1..d113ea124e 100644 --- a/docs/rpc/README.md +++ b/docs/rpc/README.md @@ -43,7 +43,7 @@ The details of this invocation can be captured using the following signals: * [RPC Metrics](rpc-metrics.md): Semantic Conventions for RPC *metrics*. These generic conventions can be extended based on the protocol/framework being used. -This is described in more detail in the [RPC Transport Protocol vs RPC Framework](#rpc-ransport-protocol-vs-rpc-framework) section. +This is described in more detail in the [RPC Transport Protocol vs RPC Framework](#rpc-transport-protocol-vs-rpc-framework) section. However should the process being invoked be a member of a more specific domain such as those below, the corresponding conventions should be followed: @@ -55,7 +55,7 @@ the corresponding conventions should be followed: If your focus is on the network layer calls rather than the logical calls being made, the RPC documents are not for you but instead what you are after is described via the below conventions: -* [Http](#) +* Http ## RPC Transport Protocol vs RPC Framework @@ -68,7 +68,7 @@ an implementation of the network protocol is used e.g. gRPC. These implementations will usually only expose a subset of functionality of the network protocol and may only be compatible with newer versions of the network protocol ie grpc will not work over http v1. -Another aspect of how the network.protocol.* differs to rpc.transport.protocol.* is that, +Another aspect of how the `network.protocol.*` differs to `rpc.transport.protocol.*` is that, the transport protocol can implement additional client side functionality such as retry, caching, cancellation etc. Some pre-defined transport protocols are: @@ -106,7 +106,7 @@ with a general "if applicable for the rpc framework" condition placed on the req A framework may have its own page when the framework defines its own signals which require the inclusion of framework specific attributes for the signal to have value & meaning. -## Supplementry Documents +## Supplementary Documents Specifications defined by maintainers of RPC systems: From 1531a111a480a1a85c2260fcb2f62864d03977dd Mon Sep 17 00:00:00 2001 From: James Thompson Date: Wed, 8 Oct 2025 01:19:03 +1100 Subject: [PATCH 07/10] Update README.md --- docs/rpc/README.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/docs/rpc/README.md b/docs/rpc/README.md index d113ea124e..2f93170e90 100644 --- a/docs/rpc/README.md +++ b/docs/rpc/README.md @@ -42,7 +42,7 @@ The details of this invocation can be captured using the following signals: * [RPC Spans](rpc-spans.md): Semantic Conventions for RPC client and server *spans*. * [RPC Metrics](rpc-metrics.md): Semantic Conventions for RPC *metrics*. -These generic conventions can be extended based on the protocol/framework being used. +These generic conventions can be extended based on the transport protocol/framework being used. This is described in more detail in the [RPC Transport Protocol vs RPC Framework](#rpc-transport-protocol-vs-rpc-framework) section. However should the process being invoked be a member of a more specific domain such as those below, @@ -96,11 +96,10 @@ Some pre-defined frameworks are: * Apache Dubbo * Dapr * [Connect RPC](connect-rpc.md) -* [JSON-RPC](json-rpc.md) * WCF These frameworks can provide additional attributes for capturing the properties mentioned earlier. -It is expected that these attributes are added where appropriate to the corresponding signals defined for the rpc protocol, +It is expected that these attributes are added where appropriate to the corresponding signals defined for the rpc transport protocol, with a general "if applicable for the rpc framework" condition placed on the requirement level. A framework may have its own page when the framework defines its own signals which require the inclusion of framework specific From 9c476fdb8ce73ede674f57ee21ecae11764c1b71 Mon Sep 17 00:00:00 2001 From: James Thompson Date: Thu, 9 Oct 2025 12:59:44 +1100 Subject: [PATCH 08/10] Review feedback --- docs/rpc/README.md | 39 +++++++++++++++++---------------------- 1 file changed, 17 insertions(+), 22 deletions(-) diff --git a/docs/rpc/README.md b/docs/rpc/README.md index 2f93170e90..d46d802f07 100644 --- a/docs/rpc/README.md +++ b/docs/rpc/README.md @@ -6,8 +6,7 @@ linkTitle: RPC **Status**: [Development][DocumentStatus] -This document defines semantic conventions for remote procedure calls (RPC) -, sometimes called "remote method invocations" (RMI). +This document defines semantic conventions for remote procedure calls (RPC). > [!IMPORTANT] > Existing RPC instrumentations that are using @@ -42,8 +41,20 @@ The details of this invocation can be captured using the following signals: * [RPC Spans](rpc-spans.md): Semantic Conventions for RPC client and server *spans*. * [RPC Metrics](rpc-metrics.md): Semantic Conventions for RPC *metrics*. -These generic conventions can be extended based on the transport protocol/framework being used. -This is described in more detail in the [RPC Transport Protocol vs RPC Framework](#rpc-transport-protocol-vs-rpc-framework) section. +These generic conventions can be extended based on the [RPC Transport Protocol](#what-is-a-rpc-transport-protocol) being used with the following protocols defined: + +* [gRPC](grpc.md) +* [Http](/docs/http/README.md) +* Triple +* SOAP +* [Connect RPC](connect-rpc.md) + +They can also be extended based on the [RPC Framework](#what-is-a-rpc-framework) being used with the following frameworks defined: + +* Apache Dubbo +* Dapr +* [Connect RPC](connect-rpc.md) +* WCF However should the process being invoked be a member of a more specific domain such as those below, the corresponding conventions should be followed: @@ -53,7 +64,7 @@ the corresponding conventions should be followed: * [Messaging](/docs/messaging/README.md) If your focus is on the network layer calls rather than the logical calls being made, -the RPC documents are not for you but instead what you are after is described via the below conventions: +these RPC documents are not for you but instead what you are after is described via the below conventions: * Http @@ -71,34 +82,18 @@ and may only be compatible with newer versions of the network protocol ie grpc w Another aspect of how the `network.protocol.*` differs to `rpc.transport.protocol.*` is that, the transport protocol can implement additional client side functionality such as retry, caching, cancellation etc. -Some pre-defined transport protocols are: - -* [gRPC](grpc.md) -* [Http](/docs/http/README.md) -* Triple -* SOAP -* [Connect RPC](connect-rpc.md) - It is expected that these protocols will define protocol specific attributes, for instance gRPC would contain a status attribute. As such the usage of these attribute/s should be documented via a dedicated protocol page providing complete definitions. ### What is a RPC Framework? A RPC Framework describes the api's made available to applications wanting to implement RPC Communications -in a protocol agnostic manner. This is why protocol and framework is not a one-to-one relationship but rather one-to-many. +in a protocol agnostic manner. This is why protocol and framework is not a one-to-one relationship but rather many-to-many. The framework in addition to providing the api can define properties which are sent along with the message to provide additional context. For instance a framework might require a message id to be sent with the message. The framework doesn't care how it is transported across the network. -Some pre-defined frameworks are: - -* Apache Dubbo -* Dapr -* [Connect RPC](connect-rpc.md) -* WCF - -These frameworks can provide additional attributes for capturing the properties mentioned earlier. It is expected that these attributes are added where appropriate to the corresponding signals defined for the rpc transport protocol, with a general "if applicable for the rpc framework" condition placed on the requirement level. From a532f2891ab4b0a34733efd0cf395ac99ae9a858 Mon Sep 17 00:00:00 2001 From: James Thompson Date: Thu, 23 Oct 2025 10:58:41 +1100 Subject: [PATCH 09/10] Update README.md --- docs/rpc/README.md | 63 +++++++++++++++++++++++----------------------- 1 file changed, 32 insertions(+), 31 deletions(-) diff --git a/docs/rpc/README.md b/docs/rpc/README.md index d46d802f07..83a8554765 100644 --- a/docs/rpc/README.md +++ b/docs/rpc/README.md @@ -13,24 +13,24 @@ This document defines semantic conventions for remote procedure calls (RPC). > [v1.37.0 of this document](https://github.com/open-telemetry/semantic-conventions/blob/v1.37.0/docs/rpc/README.md) > (or prior): > -> * SHOULD NOT change the version of the RPC conventions that they emit by +> - SHOULD NOT change the version of the RPC conventions that they emit by > default in their existing major version. Conventions include (but are not > limited to) attributes, metric and span names, and unit of measure. -> * SHOULD introduce an environment variable `OTEL_SEMCONV_STABILITY_OPT_IN` +> - SHOULD introduce an environment variable `OTEL_SEMCONV_STABILITY_OPT_IN` > in their existing major version as a comma-separated list of category-specific values > (e.g., http, databases, rpc). The list of values includes: -> * `rpc` - emit the stable RPC conventions, and stop emitting +> - `rpc` - emit the stable RPC conventions, and stop emitting > the experimental RPC conventions that the instrumentation emitted > previously. -> * `rpc/dup` - emit both the experimental and stable RPC conventions, +> - `rpc/dup` - emit both the experimental and stable RPC conventions, > allowing for a phased rollout of the stable semantic conventions. -> * The default behavior (in the absence of one of these values) is to continue +> - The default behavior (in the absence of one of these values) is to continue > emitting whatever version of the old experimental RPC conventions > the instrumentation was emitting previously. -> * Note: `rpc/dup` has higher precedence than `rpc` in case both values are present -> * SHOULD maintain (security patching at a minimum) their existing major version +> - Note: `rpc/dup` has higher precedence than `rpc` in case both values are present +> - SHOULD maintain (security patching at a minimum) their existing major version > for at least six months after it starts emitting both sets of conventions. -> * MAY drop the environment variable in their next major version and emit only +> - MAY drop the environment variable in their next major version and emit only > the stable RPC conventions. The RPC Semantic conventions are designed to cover the logical operation of invoking an operation (function) to run in a remote process. @@ -38,49 +38,50 @@ This remote process call will often travel across the network to reach it's dest The details of this invocation can be captured using the following signals: -* [RPC Spans](rpc-spans.md): Semantic Conventions for RPC client and server *spans*. -* [RPC Metrics](rpc-metrics.md): Semantic Conventions for RPC *metrics*. +- [RPC Spans](rpc-spans.md): Semantic Conventions for RPC client and server *spans*. +- [RPC Metrics](rpc-metrics.md): Semantic Conventions for RPC *metrics*. -These generic conventions can be extended based on the [RPC Transport Protocol](#what-is-a-rpc-transport-protocol) being used with the following protocols defined: +These generic conventions can be extended based on the [RPC Protocol](#what-is-a-rpc-protocol) being used with the following protocols defined: -* [gRPC](grpc.md) -* [Http](/docs/http/README.md) -* Triple -* SOAP -* [Connect RPC](connect-rpc.md) +- [gRPC](grpc.md) +- [Http](/docs/http/README.md) +- Triple +- Twirp +- SOAP +- [Connect RPC](connect-rpc.md) They can also be extended based on the [RPC Framework](#what-is-a-rpc-framework) being used with the following frameworks defined: -* Apache Dubbo -* Dapr -* [Connect RPC](connect-rpc.md) -* WCF +- Apache Dubbo +- Dapr +- [Connect RPC](connect-rpc.md) +- WCF However should the process being invoked be a member of a more specific domain such as those below, the corresponding conventions should be followed: -* [Database](/docs/database/README.md) -* [Generative AI](/docs/gen-ai/README.md) -* [Messaging](/docs/messaging/README.md) +- [Database](/docs/database/README.md) +- [Generative AI](/docs/gen-ai/README.md) +- [Messaging](/docs/messaging/README.md) If your focus is on the network layer calls rather than the logical calls being made, these RPC documents are not for you but instead what you are after is described via the below conventions: -* Http +- Http -## RPC Transport Protocol vs RPC Framework +## RPC Protocol vs RPC Framework -### What is a RPC Transport Protocol? +### What is a RPC Protocol? -A RPC transport protocol describes the manner in which a message is transported from one service to another. +A RPC protocol describes the manner in which a message is transported from one service to another. This protocol may have the same value as the network protocol ie http or it may differ when, an implementation of the network protocol is used e.g. gRPC. These implementations will usually only expose a subset of functionality of the network protocol and may only be compatible with newer versions of the network protocol ie grpc will not work over http v1. -Another aspect of how the `network.protocol.*` differs to `rpc.transport.protocol.*` is that, -the transport protocol can implement additional client side functionality such as retry, caching, cancellation etc. +Another aspect of how the `network.protocol.*` differs to `rpc.protocol.*` is that, +the protocol can implement additional client side (application level) functionality such as retry, caching, cancellation etc. It is expected that these protocols will define protocol specific attributes, for instance gRPC would contain a status attribute. As such the usage of these attribute/s should be documented via a dedicated protocol page providing complete definitions. @@ -94,7 +95,7 @@ The framework in addition to providing the api can define properties which are s to provide additional context. For instance a framework might require a message id to be sent with the message. The framework doesn't care how it is transported across the network. -It is expected that these attributes are added where appropriate to the corresponding signals defined for the rpc transport protocol, +It is expected that these attributes are added where appropriate to the corresponding signals defined for the rpc protocol, with a general "if applicable for the rpc framework" condition placed on the requirement level. A framework may have its own page when the framework defines its own signals which require the inclusion of framework specific @@ -104,6 +105,6 @@ attributes for the signal to have value & meaning. Specifications defined by maintainers of RPC systems: -* [gRPC](https://github.com/grpc/proposal/blob/master/A66-otel-stats.md): Semantic Conventions for *gRPC*. +- [gRPC](https://github.com/grpc/proposal/blob/master/A66-otel-stats.md): Semantic Conventions for *gRPC*. [DocumentStatus]: https://opentelemetry.io/docs/specs/otel/document-status From e3bb4b9b751d8c95a7b4d51366963e07872e6ca2 Mon Sep 17 00:00:00 2001 From: James Thompson Date: Thu, 13 Nov 2025 13:23:31 +1100 Subject: [PATCH 10/10] Update README.md --- docs/rpc/README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/rpc/README.md b/docs/rpc/README.md index 83a8554765..cbd153c76a 100644 --- a/docs/rpc/README.md +++ b/docs/rpc/README.md @@ -44,6 +44,7 @@ The details of this invocation can be captured using the following signals: These generic conventions can be extended based on the [RPC Protocol](#what-is-a-rpc-protocol) being used with the following protocols defined: - [gRPC](grpc.md) +- GWT - [Http](/docs/http/README.md) - Triple - Twirp