eclipse-dataspace-protocol-base · ssteinbuss · Nov 12, 2025 · Nov 12, 2025 · Nov 12, 2025 · Nov 12, 2025
diff --git a/.github/scripts/checkout-tags.sh b/.github/scripts/checkout-tags.sh
@@ -13,7 +13,7 @@ do
   echo starting with tag $tag
   mkdir $tag
   cd $tag
-  git clone https://github.com/eclipse-dataspace-protocol-base/DataspaceProtocol.git --depth 1 --branch ${tag} --quiet
+  git clone $GITHUB_SERVER_URL/$GITHUB_REPOSITORY.git --depth 1 --branch ${tag} --quiet
   mv ./DataspaceProtocol/* .
   cd ..
 done

diff --git a/.github/scripts/index.html b/.github/scripts/index.html
@@ -3,12 +3,12 @@
 <head>
     <meta charset="utf-8">
     <meta http-equiv="refresh"
-          content="0;url=https://eclipse-dataspace-protocol-base.github.io/DataspaceProtocol/2025-1"/>
-    <link rel="canonical" href="https://eclipse-dataspace-protocol-base.github.io/DataspaceProtocol/2025-1"/>
+          content="0;url=https://eclipse-dataspace-protocol-base.github.io/DataspaceProtocol/2025-1-err1"/>
+    <link rel="canonical" href="https://eclipse-dataspace-protocol-base.github.io/DataspaceProtocol/2025-1-err1"/>
 </head>
 <body>
 <h4>
-    This redirects to the latest Release Candidate <a href="https://eclipse-dataspace-protocol-base.github.io/DataspaceProtocol/2025-1">here</a>
+    This redirects to the latest Release Candidate <a href="https://eclipse-dataspace-protocol-base.github.io/DataspaceProtocol/2025-1-err1">here</a>
 </h4>
 </body>
 </html>
diff --git a/index.html b/index.html
@@ -6,7 +6,7 @@
     <script class='remove'>
         var respecConfig = {
             specStatus: "unofficial",
-            latestVersion: "https://eclipse-dataspace-protocol-base.github.io/DataspaceProtocol/2025-1",
+            latestVersion: "https://eclipse-dataspace-protocol-base.github.io/DataspaceProtocol/2025-1-err1",
             editors: [{
                name: "Sebastian Steinbuss",
                url: "https://github.com/ssteinbuss",
@@ -60,15 +60,15 @@
             maxTocLevel: 3,
         };
     </script>
-    <title>Dataspace Protocol NEXT</title>
+    <title>Dataspace Protocol Release 2025-1</title>
 </head>
 <body>
 <p class="copyright">
     This document is licensed under <a href="https://www.apache.org/licenses/LICENSE-2.0.html">The Apache License, Version 2.0</a>.
     <br/>
     Copyright © 2025 The Eclipse Foundation AISBL
 </p>
-<h1 id="title">Dataspace Protocol NEXT</h1>
+<h1 id="title">Dataspace Protocol 2025-1</h1>
 <section id='abstract'>
     <p>
         The Dataspace Protocol is a specification designed to facilitate interoperable data sharing between
@@ -80,8 +80,6 @@ <h1 id="title">Dataspace Protocol NEXT</h1>
 <section id='sotd'  class="override">
     <h2>Status of this document</h2>
     <p>
-        With <a href="https://eclipse-dataspace-protocol-base.github.io/DataspaceProtocol/">2025-1</a> released, further releases of the DSP are currently not planned.
-
         This version (2025-1) of the Dataspace Protocol specification is a release of the specification and considered to be
         stable. Further changes shall not affect conformity. All changes made to the specification can be reviewed in
         the GitHub repositories - up to and including `2024-1` under the governance of the <a href="https://github.com/International-Data-Spaces-Association/ids-specification">International Data Spaces Association</a>

diff --git a/specifications/catalog/catalog.binding.https.md b/specifications/catalog/catalog.binding.https.md
@@ -10,7 +10,7 @@ This binding defines a RESTful Application Programming Interface (API) over HTTP
    URL is `api.example.com`, the URL `https://<base>/catalog/request` will map
    to `https//api.example.com/catalog/request`.
 
-2. All request and response [=Messages=] MUST use the `application/json` media type.
+2. All request and response messages MUST use the `application/json` media type.
 
 ### Catalog Error
 

diff --git a/specifications/common/common.protocol.md b/specifications/common/common.protocol.md
@@ -8,10 +8,10 @@ does not require authorization.
 
 ## Schemas & Contexts
 
-All protocol [=Messages=] are normatively defined by a [[json-schema]]. This specification also uses JSON-LD 1.1 and
+All protocol messages are normatively defined by a [[json-schema]]. This specification also uses JSON-LD 1.1 and
 provides a JSON-LD context to serialize data structures and [=Message types=] as it facilitates extensibility. The
 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
+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. Profiles that use JSON-LD are encouraged to provide
 similar contexts that facilitate this approach to interoperability. As this specification's JSON-LD objects are 
 `@protected`, [=Profile=] authors are advised to define their custom terms as protected to spot term redefinition early.

diff --git a/specifications/common/introduction.md b/specifications/common/introduction.md
@@ -2,7 +2,7 @@
 
 The __Dataspace Protocol__ is used in the context of [=Dataspaces=] as described and defined in the subsequent sections with the purpose to support _interoperability_. In this context, the specification provides fundamental technical interoperability for [=Participants=] in [=Dataspaces=]. 
 
-This specification builds on protocols located in the [ISO OSI model (ISO/IEC 7498-1:1994)](https://www.iso.org/standard/20269.html) layers, like the Hypertext Transfer Protocol (HTTP). The purpose of this specification is to define interactions between systems independent of such protocols, but describing how to implement it in an unambiguous and extensible way. To do so, the [=Messages=] that are exchanged during the process are described in this specification and the states and their transitions are specified as state machines, based on the key terms and concepts of a [=Dataspace=]. On this foundation the bindings to [=Data Transfer Protocols=], like Hypertext Transfer Protocol Secure (HTTPS), are described.
+This specification builds on protocols located in the [ISO OSI model (ISO/IEC 7498-1:1994)](https://www.iso.org/standard/20269.html) layers, like the Hypertext Transfer Protocol (HTTP). The purpose of this specification is to define interactions between systems independent of such protocols, but describing how to implement it in an unambiguous and extensible way. To do so, the messages that are exchanged during the process are described in this specification and the states and their transitions are specified as state machines, based on the key terms and concepts of a [=Dataspace=]. On this foundation the bindings to [=Data Transfer Protocols=], like Hypertext Transfer Protocol Secure (HTTPS), are described.
 
 _Note: This specification does not cover the data transfer as such. While this is controlled by the [=Transfer Process Protocol=], e.g., the initiation of the transfer channels or their decomissioning, the data transfer itself and especially the handling of technical exceptions is an obligation to the transport protocol._
 

diff --git a/specifications/negotiation/contract.negotiation.binding.https.md b/specifications/negotiation/contract.negotiation.binding.https.md
@@ -9,7 +9,7 @@ This binding defines a RESTful API over HTTPS for the [Contract Negotiation Prot
 1. The `<base>` notation indicates the base URL for a [=Connector=] endpoint. For example, if the base [=Connector=] URL
    is `connector.example.com`, the URL `https://<base>/negotiations/request` will map
    to `https//connector.example.com/negotiation/request`.
-2. All request and response [=Messages=] MUST use the `application/json` media type. Derived media types,
+2. All request and response messages MUST use the `application/json` media type. Derived media types,
    e.g., `application/ld+json` MAY be exposed in addition.
 
 ### Contract Negotiation Error
@@ -89,10 +89,10 @@ Authorization: ...</pre>
     </pre>
 </aside>
 
-- The `callbackAddress` property specifies the base endpoint `URL` where the client receives [=Messages=] associated with
+- The `callbackAddress` property specifies the base endpoint `URL` where the client receives messages associated with
   the [=Contract Negotiation=]. The HTTPS scheme MUST be supported. Implementations MAY optionally support other URL schemes.
 
-- Callback [=Messages=] will be sent to paths under the base URL as described by this specification. (_NOTE:
+- Callback messages will be sent to paths under the base URL as described by this specification. (_NOTE:
   [=Providers=] SHOULD properly handle the cases where a trailing `/` is included
   with or absent from the `callbackAddress` when resolving full URL._)
 

diff --git a/specifications/negotiation/contract.negotiation.protocol.md b/specifications/negotiation/contract.negotiation.protocol.md
@@ -5,7 +5,7 @@
 A [=Contract Negotiation=] involves two parties, a [=Provider=] that offers one or more [=Datasets=] along with a [=Policy=] 
 and a [=Consumer=] that requests [=Datasets=]. A [=Contract Negotiation=] is uniquely identified through an Internationalized Resource Identifier (IRI) [[rfc3987]]. Each [=Contract Negotiation=]
 requires a newly generated IRI, which MAY not be used in a [=Contract Negotiation=] after a terminal state has been reached. A [=Contract Negotiation=] progresses
-through a series of states, which are tracked by the [=Provider=] and [=Consumer=] using [=Messages=]. A [=Contract Negotiation=] transitions to a
+through a series of states, which are tracked by the [=Provider=] and [=Consumer=] using messages. A [=Contract Negotiation=] transitions to a
 state in response to an acknowledged Message from the counter-party. Both parties have the same state of the [=Contract Negotiation=]. In case
 the states differ, the [=Contract Negotiation=] MUST be terminated and a new [=Contract Negotiation=] MAY be initiated.
 
@@ -32,12 +32,12 @@ The [=Contract Negotiation=] state machine is represented in the following diagr
 
 !["Contract Negotiation State Machine"](figures/contract.negotiation.state.machine.png "Contract Negotiation State Machine")
 
-Transitions marked with `C` indicate a Message sent by the [=Consumer=], transitions marked with `P` indicate
+Transitions marked with `C` indicate a message sent by the [=Consumer=], transitions marked with `P` indicate
 a [=Provider=] Message. Terminal states are final; the state machine MUST NOT transition to another state. A new [=Contract Negotiation=] MAY be initiated if, for instance, the [=Contract Negotiation=] entered the `TERMINATED` state due to a network issue.
 
 ## Message Types
 
-The [=Contract Negotiation=] state machine is transitioned upon receipt and acknowledgement of a Message. This section details those [=Messages=] as abstract [=Message Types=].
+The [=Contract Negotiation=] state machine is transitioned upon receipt and acknowledgement of a Message. This section details those messages as abstract [=Message Types=].
 
 - Concrete wire formats are defined by the protocol binding,
   e.g., [Contract Negotiation HTTPS Binding](#contract-negotiation-https-binding).

diff --git a/specifications/transfer/transfer.process.binding.https.md b/specifications/transfer/transfer.process.binding.https.md
@@ -9,7 +9,7 @@ This binding defines a RESTful API over HTTPS for the [Transfer Process Protocol
 1. The `<base>` notation indicates the base URL for a [=Connector=] endpoint. For example, if the scheme is `https` and
    the full hostname is `connector.example.com`, the URL `<base>/transfers/request` will map
    to `https://connector.example.com/transfers/request`.
-2. All request and response [=Messages=] MUST use the `application/json` media type. Derived media types,
+2. All request and response messages MUST use the `application/json` media type. Derived media types,
    e.g., `application/ld+json` MAY be exposed in addition.
 
 ### Transfer Error

diff --git a/specifications/transfer/transfer.process.protocol.md b/specifications/transfer/transfer.process.protocol.md
@@ -4,7 +4,7 @@
 
 A [=Transfer Process=] involves two parties, a [=Provider=] that offers one or more [=Datasets=] along with
 a [=Policy=] and a [=Consumer=] that requests [=Datasets=]. A [=Transfer Process=] progresses through a series of states, which are
-controlled by the [=Provider=] and [=Consumer=] using [=Messages=]. A [=Transfer Process=] transitions to another state as a result of an
+controlled by the [=Provider=] and [=Consumer=] using messages. A [=Transfer Process=] transitions to another state as a result of an
 exchanged Message.
 
 ### Prerequisites
@@ -15,7 +15,7 @@ subsection.
 #### Control and Data Planes
 
 A [=Transfer Process=] involves two logical constructs, a control plane and a data plane. Serving as a coordinating layer, services on the
-_control plane_ receive [=Messages=] and manage the local state of the [=Transfer Process=] (same as for the [=Catalog Protocol=] and
+_control plane_ receive messages and manage the local state of the [=Transfer Process=] (same as for the [=Catalog Protocol=] and
 the [=Contract Negotiation Protocol=]). On the _data plane_, the actual transfer of data takes place using a wire
 protocol. Both [=Participants=] in a data sharing scenario run services logically regarded as control and/or data plane
 services.