diff --git a/.github/scripts/checkout-tags.sh b/.github/scripts/checkout-tags.sh index 2e36aa2..2ca133e 100644 --- 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 index eb72d17..f3f4b41 100644 --- a/.github/scripts/index.html +++ b/.github/scripts/index.html @@ -3,12 +3,12 @@ - + content="0;url=https://eclipse-dataspace-protocol-base.github.io/DataspaceProtocol/2025-1-err1"/> +

- This redirects to the latest Release Candidate here + This redirects to the latest Release Candidate here

\ No newline at end of file diff --git a/index.html b/index.html index 1bf356e..eec3ddc 100644 --- a/index.html +++ b/index.html @@ -6,7 +6,7 @@ - Dataspace Protocol NEXT + Dataspace Protocol Release 2025-1

@@ -68,7 +68,7 @@
Copyright © 2025 The Eclipse Foundation AISBL

-

Dataspace Protocol NEXT

+

Dataspace Protocol 2025-1

The Dataspace Protocol is a specification designed to facilitate interoperable data sharing between @@ -80,8 +80,6 @@

Dataspace Protocol NEXT

Status of this document

- With 2025-1 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 International Data Spaces Association diff --git a/specifications/catalog/catalog.binding.https.md b/specifications/catalog/catalog.binding.https.md index c1fd599..638d6cc 100644 --- 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:///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 index 20460d7..bd67519 100644 --- 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 index 6215724..d666007 100644 --- 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 index 00420b9..8fc1015 100644 --- 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 `` notation indicates the base URL for a [=Connector=] endpoint. For example, if the base [=Connector=] URL is `connector.example.com`, the URL `https:///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: ... -- 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 index 6ce307c..e4b7c99 100644 --- 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 index 6377897..8006103 100644 --- 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 `` 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 `/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 index 18c22c3..0f107e6 100644 --- 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.