Move OTLP specification to github.com/open-telemetry/opentelemetry-proto

Resolves #3415

CHANGELOG.md

@@ -7,6 +7,11 @@ release.
 
 ## Unreleased
 
+### Protocol
+
+- Move OTLP specification to github.com/open-telemetry/opentelemetry-proto.
+  ([#](https://github.com/open-telemetry/opentelemetry-specification/pull/))
+
 ### Context
 
 ### Traces

specification/protocol/README.md

@@ -1,8 +1,7 @@
 # OpenTelemetry Protocol
 
-This is the specification of new OpenTelemetry protocol (OTLP).
+The OpenTelemetry protocol (OTLP) specification has moved to
+[github.com/open-telemetry/opentelemetry-proto/docs/README.md](https://github.com/open-telemetry/opentelemetry-proto/blob/main/docs/README.md).
 
-- [Design Goals](design-goals.md).
-- [Requirements](requirements.md).
-- [Specification](otlp.md).
-- [SDK Exporter](exporter.md).
+For additional OTLP implementation requirements in the OpenTelemetry SDKs, see
+[SDK Exporter](exporter.md).

specification/protocol/design-goals.md

@@ -1,19 +1,4 @@
 # Design Goals for OpenTelemetry Wire Protocol
 
-We want to design a telemetry data exchange protocol that has the following characteristics:
-
-- Be suitable for use between all of the following node types: instrumented applications, telemetry backends, local agents, stand-alone collectors/forwarders.
-
-- Have high reliability of data delivery and clear visibility when the data cannot be delivered.
-
-- Have low CPU usage for serialization and deserialization.
-
-- Impose minimal pressure on memory manager, including pass-through scenarios, where deserialized data is short-lived and must be serialized as-is shortly after and where such short-lived data is created and discarded at high frequency (think telemetry data forwarders).
-
-- Support ability to efficiently modify deserialized data and serialize again to pass further. This is related but slightly different from the previous requirement.
-
-- Ensure high throughput (within the available bandwidth) in high latency networks (e.g. scenarios where telemetry source and the backend are separated by high latency network).
-
-- Allow backpressure signalling.
-
-- Be load-balancer friendly (do not hinder re-balancing).
+This page has moved to
+[github.com/open-telemetry/opentelemetry-proto/docs/design-goals.md](https://github.com/open-telemetry/opentelemetry-proto/blob/main/docs/design-goals.md).

specification/protocol/exporter.md

@@ -158,7 +158,7 @@ The `OTEL_EXPORTER_OTLP_HEADERS`, `OTEL_EXPORTER_OTLP_TRACES_HEADERS`, `OTEL_EXP
 
 Transient errors MUST be handled with a retry strategy. This retry strategy MUST implement an exponential back-off with jitter to avoid overwhelming the destination until the network is restored or the destination has recovered.
 
-For OTLP/HTTP, the errors `408 (Request Timeout)` and `5xx (Server Errors)` are defined as transient, detailed information about errors can be found in the [HTTP failures section](otlp.md#failures). For the OTLP/gRPC, the full list of the gRPC retryable status codes can be found in the [gRPC response section](otlp.md#otlpgrpc-response).
+For OTLP/HTTP, the errors `408 (Request Timeout)` and `5xx (Server Errors)` are defined as transient, detailed information about errors can be found in the [HTTP failures section](https://github.com/open-telemetry/opentelemetry-proto/blob/main/docs/specification.md#failures). For the OTLP/gRPC, the full list of the gRPC retryable status codes can be found in the [gRPC response section](https://github.com/open-telemetry/opentelemetry-proto/blob/main/docs/specification.md#otlpgrpc-response).
 
 ## User Agent
 
@@ -171,5 +171,5 @@ OTel-OTLP-Exporter-Python/1.2.3
 The format of the header SHOULD follow [RFC 7231][rfc-7231]. The conventions used for specifying the OpenTelemetry SDK language and version are available in the [Resource semantic conventions][resource-semconv].
 
 [resource-semconv]: ../resource/semantic_conventions/README.md#telemetry-sdk
-[otlphttp-req]: otlp.md#otlphttp-request
+[otlphttp-req]: https://github.com/open-telemetry/opentelemetry-proto/blob/main/docs/specification.md#otlphttp-request
 [rfc-7231]: https://datatracker.ietf.org/doc/html/rfc7231#section-5.5.3

specification/protocol/file-exporter.md

@@ -42,7 +42,7 @@ There is no guarantee in particular that timestamps will be monotonically increa
 This defines the first version of the serialization scheme.
 
 The data must be encoded according to the format specified in the
-[OTLP JSON Encoding](../../specification/protocol/otlp.md#json-protobuf-encoding).
+[OTLP JSON Encoding](https://github.com/open-telemetry/opentelemetry-proto/blob/main/docs/specification.md#json-protobuf-encoding).
 
 Only top-level objects, `ExportTraceServiceRequest`, `ExportMetricsServiceRequest`, and `ExportLogsServiceRequest` are supported.