Clarify specification compliance

CHANGELOG.md

@@ -41,6 +41,10 @@ release.
 
 ### Common
 
+- Clarify compliance requirement by restricting implementations from providing
+  features/functionalities that are not covered by the specification.
+  ([#2968](https://github.com/open-telemetry/opentelemetry-specification/pull/2968))
+
 ## v1.18.0 (2023-02-09)
 
 ### Context

specification/README.md

@@ -50,12 +50,22 @@ The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
 [[RFC8174](https://tools.ietf.org/html/rfc8174)] when, and only when, they
 appear in all capitals, as shown here.
 
-An implementation of the [specification][] is not compliant if it fails to
-satisfy one or more of the "MUST", "MUST NOT", "REQUIRED", "SHALL", or "SHALL
-NOT" requirements defined in the [specification][]. Conversely, an
-implementation of the [specification][] is compliant if it satisfies all the
-"MUST", "MUST NOT", "REQUIRED", "SHALL", and "SHALL NOT" requirements defined in
-the [specification][].
+An implementation of the [specification][] is compliant if and only if it meets
+all the following conditions:
+
+* It MUST satisfy all the "MUST", "MUST NOT", "REQUIRED", "SHALL", and "SHALL
+NOT" requirements defined in the [specification][].
+* For an implementation of the API Specification (note that this restriction
+  does not apply to an SDK implementation), it MUST NOT provide additional
+  features or functionalities that are not covered by the [specification][],
+  except for any of the following situations:
+  * Such feature/functionality is very specific to a programming language,
+    runtime or framework, and not expected to interfere or overlap with any
+    feature that might (likely) be added to the cross-language specification in
+    future.
+  * Anything that is retrospective, for example, a feature/functionality which
+    has been released as a stable/GA offering before this compliance rule was
+    formalized (release 1.19.0).
 
 ## Project Naming