docs: add request size limitation

CHANGELOG.md

@@ -6,6 +6,7 @@ The full list of changes can be found in the compare view for the respective rel
 
 ### Added
 
+- docs: add request size limitation for HTTP body and gRPC messages. [#782](https://github.com/open-telemetry/opentelemetry-proto/pull/782)
 - docs: add response size limitation for HTTP body and gRPC messages. [#781](https://github.com/open-telemetry/opentelemetry-proto/pull/781)
 
 ### Changed

docs/specification.md

@@ -32,6 +32,7 @@ nodes such as collectors and telemetry backends.
 
 - [Protocol Details](#protocol-details)
   * [OTLP/gRPC](#otlpgrpc)
+    + [OTLP/gRPC Request](#otlpgrpc-request)
     + [OTLP/gRPC Concurrent Requests](#otlpgrpc-concurrent-requests)
     + [OTLP/gRPC Response](#otlpgrpc-response)
       - [Full Success](#full-success)
@@ -113,6 +114,22 @@ acknowledgements described in this protocol happen between a single
 client/server pair and do not span intermediary nodes in multi-hop delivery
 paths._
 
+#### OTLP/gRPC Request
+
+The server MUST enforce a message size limit when receiving the request,
+including after decompression, to mitigate possible excessive memory usage
+caused by a misconfigured or malicious client sending an oversized request.
+The server implementations typically enforce a default incoming message size
+limit of 4 MiB. However, it is RECOMMENDED to use 32 MiB as the default limit.
+Implementations MAY allow this limit to be configured. If the limit is
+exceeded, the gRPC server implementations MUST report a
+`RESOURCE_EXHAUSTED` code to the caller which the client MUST treat as a
+non-retryable error.
+
+The client SHOULD limit the size of the request message, including before
+compression, to avoid overwhelming the server. It is RECOMMENDED to use 32 MiB
+as the default limit. Implementations MAY allow this limit to be configured.
+
 #### OTLP/gRPC Concurrent Requests
 
 After sending the request the client MAY wait until the response is received
@@ -481,6 +498,18 @@ The client MAY gzip the content and in that case MUST include
 Non-default URL paths for requests MAY be configured on the client and server
 sides.
 
+The server MUST limit the size of the request body when parsing it, including
+after decompression, to mitigate possible excessive memory usage caused by a
+misconfigured or malicious client sending an oversized request. It is
+RECOMMENDED to use 32 MiB as the default limit. Implementations MAY allow this
+limit to be configured. If the limit is exceeded, the server MUST respond with
+`HTTP 413 Content Too Large`. The client MUST NOT retry the request when it
+receives `HTTP 413 Content Too Large` response.
+
+The client SHOULD limit the size of the request body, including before
+compression, to avoid overwhelming the server. It is RECOMMENDED to use 32 MiB
+as the default limit. Implementations MAY allow this limit to be configured.
+
 #### OTLP/HTTP Response
 
 The response body MUST be the appropriate serialized Protobuf message (see