fix: resolve respec message definition errors

Author: arnoweiss

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
 

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.

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._
 

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._)
 

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).

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

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.