diff --git a/index.html b/index.html
index 90be81b..85577b1 100644
--- a/index.html
+++ b/index.html
@@ -121,6 +121,9 @@ <h1 id="title">Dataspace Protocol 2025-1-RC2</h1>
 <section data-include="specifications/transfer/transfer.process.binding.https.md" data-include-format="markdown">
 </section>
 
+<section data-include="specifications/common/versioning.md" data-include-format="markdown">
+</section>
+
 <section id='conformance'></section>
 
 <section id="lower-level-types" class="appendix" data-include="specifications/common/type.definitions.md" data-include-format="markdown">
diff --git a/specifications/common/common.protocol.md b/specifications/common/common.protocol.md
index 734e4d9..01febb3 100644
--- a/specifications/common/common.protocol.md
+++ b/specifications/common/common.protocol.md
@@ -13,36 +13,4 @@ provides a JSON-LD context to serialize data structures and [=Message=] types as
 JSON-LD context is designed to produce [=Message=] serializations using compaction that validate against the Json Schema
 for the given [=Message=] type. This allows implementations to choose whether to process [=Messages=] as plain JSON or
 as JSON-LD and maintain interoperability between those approaches. Extensions that use JSON-LD are encouraged to provide
-similar contexts that facilitate this approach to interoperability.
-
-## Exposure of Versions {#exposure-of-dataspace-protocol-versions}
-
-[=Connectors=] implementing the [=Dataspace Protocol=] may operate on different versions and bindings. Therefore, it is
-necessary that they can discover such information reliably and unambiguously. Each [=Connector=]
-must provide the version metadata endpoint using the `dspace-version` Well-Known Uniform Resource Identifier [[rfc8615]]
-at the top of the path hierarchy. Example: `<host>/.well-known/dspace-version`
-
-A [=Connector=] must respond to a respective HTTPS request by returning a [`VersionResponse`](#VersionResponse-table)
-with at least one item. The item connects the version tag (`version` attribute) with a path to the endpoint.
-The semantics of the `path` property are specified by each protocol binding.
-
-This data object must comply to the [JSON Schema](message/schema/protocol-version-schema.json). The requesting
-[=Connector=] may select from the endpoints in the response. If the [=Connector=] can't identify a matching Dataspace
-Protocol version, it must terminate the communication. The version endpoint MUST be unversioned and unauthenticated.
-
-### HTTPS Binding
-
-When using the DSP HTTPS binding, the `path` property is an absolute URL path segment to be appended to the domain for
-all endpoints of this version.
-
-The following example demonstrates that a [=Connector=] offers the HTTPS binding from version `2024-1` at
-`<host>/some/path/2024-1`, the `2025-1` endpoints at`<host>/some/path/2025-1` and another [=Connector=] on the same host
-under `<host>/different/path/2025-1` - some of which signal the relevant authentication protocol overlay, determined by
-`protocol`, `version` and the `profile` array.
-
-<aside class="example" title="well-known version endpoint (HTTPS)">
-    <pre class="http">GET https://provider.com/.well-known/dspace-version
-    </pre>
-    <pre class="json" data-include="message/example/protocol-version.json">
-    </pre>
-</aside>
+similar contexts that facilitate this approach to interoperability.
\ No newline at end of file
diff --git a/specifications/common/versioning.md b/specifications/common/versioning.md
new file mode 100644
index 0000000..934f49f
--- /dev/null
+++ b/specifications/common/versioning.md
@@ -0,0 +1,27 @@
+# Exposure of Versions {#exposure-of-dataspace-protocol-versions}
+
+The adoption of versioning to implementations that comply with this specification is optional.
+
+## Introduction 
+
+[=Connectors=] implementing the [=Dataspace Protocol=] may operate on different versions and bindings. Such information should be discoverable reliably and unambiguously. If a [=Dataspace=] requires [=Connectors=] to expose supported versions, each [=Connector=] _MUST_ provide the version metadata endpoint using the `dspace-version` Well-Known Uniform Resource Identifier [[rfc8615]] at the top of the path hierarchy. Example: `<host>/.well-known/dspace-version`
+
+A [=Connector=] _MUST_ respond to a respective HTTPS request by returning a [`VersionResponse`](#VersionResponse-table)
+with at least one item. The item connects the version tag (`version` attribute) with a path to the endpoint.
+The semantics of the `path` property are specified by each protocol binding.
+
+This data object _MUST_ comply to the [JSON Schema](message/schema/protocol-version-schema.json). The requesting [=Connector=] _MAY_ select from the endpoints in the response. If the [=Connector=] cannot identify a matching [=Dataspace Protocol=] version, it _MUST_ terminate the communication. The version endpoint _MUST_ be unversioned and unauthenticated.
+
+## HTTPS Binding
+
+When using the DSP HTTPS binding, the `path` property is an absolute URL path segment to be appended to the domain for all endpoints of this version.
+
+The following example demonstrates that a [=Connector=] offers the HTTPS binding from version `2024-1` at
+`<host>/some/path/2024-1`, the `2025-1` endpoints at`<host>/some/path/2025-1` and another [=Connector=] on the same host under `<host>/different/path/2025-1` - some of which signal the relevant authentication protocol overlay, determined by `protocol`, `version`, and the `profile` array.
+
+<aside class="example" title="well-known version endpoint (HTTPS)">
+    <pre class="http">GET https://provider.com/.well-known/dspace-version
+    </pre>
+    <pre class="json" data-include="message/example/protocol-version.json">
+    </pre>
+</aside>