From d8c3b3a4c838e1931605f4e2d8f8729a01f185dd Mon Sep 17 00:00:00 2001 From: Sebastian Opriel Date: Fri, 4 Aug 2023 12:05:10 +0200 Subject: [PATCH 1/4] Remove constricting CN state descriptions, to fit to all transitions --- negotiation/contract.negotiation.protocol.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/negotiation/contract.negotiation.protocol.md b/negotiation/contract.negotiation.protocol.md index 7f18d610..9f7952ac 100644 --- a/negotiation/contract.negotiation.protocol.md +++ b/negotiation/contract.negotiation.protocol.md @@ -20,10 +20,10 @@ the counter-party. Both parties have the same state of the CN. In case the state The CN states are: -- **REQUESTED** - A contract for an asset has been requested by the consumer based on an offer and the provider has sent an ACK response. +- **REQUESTED** - A contract for an asset has been requested by the consumer and the provider has sent an ACK response. - **OFFERED** - The provider has sent a contract offer to the consumer and the consumer has sent an ACK response. - **ACCEPTED** - The consumer has accepted the latest contract offer and the provider has sent an ACK response. -- **AGREED** - The provider has accepted the latest contract offer, sent an agreement to the consumer, and the consumer has sent an ACK response. +- **AGREED** - The provider has sent an agreement to the consumer, and the consumer has sent an ACK response. - **VERIFIED** - The consumer has sent an agreement verification to the provider and the provider has sent an ACK response. - **FINALIZED** - The provider has sent a finalization message including his own agreement verification to the consumer and the consumer has sent an ACK response. Data is now available to the consumer. From 427957a69cd2f8c6ae8614ebc959d7d81600f295 Mon Sep 17 00:00:00 2001 From: Sebastian Opriel Date: Fri, 4 Aug 2023 12:54:47 +0200 Subject: [PATCH 2/4] Add table to give non-normative examples of state transitions --- negotiation/contract.negotiation.protocol.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/negotiation/contract.negotiation.protocol.md b/negotiation/contract.negotiation.protocol.md index 9f7952ac..e04e9dab 100644 --- a/negotiation/contract.negotiation.protocol.md +++ b/negotiation/contract.negotiation.protocol.md @@ -39,6 +39,21 @@ The CN state machine is represented in the following diagram. Note that transiti 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 may not transition to another state. A new CN may be initiated if, for instance, the CN entered the `TERMINATED` state due to a network issue. +Following table gives non-normative examples of transitions: + +| Origin State | Actor | Transition Trigger Message | Target State | Non-normative Example | +|----------------------------|--------|-------------------------------------------|--------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| INIT | C | ContractRequestMessage | REQUESTED | The consumer requests a contract, without previous direct interaction with provider, e.g. through the usage of a central cataloging system, which provides all necessary information about the provider, to directly request a data contract. | +| INIT | P | ContractOfferMessage | OFFERED | The provider sends a contract offer directly to a consumer without previous interaction, e.g. because the provider knows about desired data (e.g., consumer placed a search for data request in a catalog) or consumer/provider are in an existing business relationship and provider wants to ship information to its business partner. | +| REQUESTED | P | ContractOfferMessage | OFFERED | The provider sends an offering for a requested resource. | +| REQUESTED | P | ContractAgreementMessage | AGREED | The provider directly sends a contract agreement as no terms must be agreed to, e.g. in case publicly data shall be shared without any policies. Be aware that implementation of such transitions must comply with local laws in application. | +| OFFERED | C | ContractRequestMessage | REQUESTED | The consumer declines the offered contract and might sent a counter offer to the provider. | +| OFFERED | C | ContractNegotiationEventMessage:accepted | ACCEPTED | The consumer accepts to comply with the defined details in the contract. | +| ACCEPTED | P | ContractAgreementMessage | AGREED | The provider sends a provider-signed contract agreement to the consumer. | +| AGREED | C | ContractAgreementVerificationMessage | VERIFIED | The consumer sends a both-sides signed contract agreement to the provider. | +| VERIFIED | P | ContractNegotiationEventMessage:finalized | FINALIZED | The provider assures the consumer to have received the signed agreement. | +| \*/{TERMINATED, FINALIZED} | {C, P} | ContractNegotiationTerminationMessage | FINALIZED | The provider or consumer is not willing to continue any further negotiation process. This might happen e.g. in the case the provider doesnt want to place any offer (i.e. data) to the consumer. | + ## Message Types The CN state machine is transitioned upon receipt and acknowledgement of a message. This section details those messages as abstract message types. From 96bb0f8b647e926a4d64945ffc2f6921e61ba6cf Mon Sep 17 00:00:00 2001 From: Sebastian Opriel Date: Thu, 10 Aug 2023 14:12:00 +0200 Subject: [PATCH 3/4] Update negotiation/contract.negotiation.protocol.md Co-authored-by: Julia Pampus <72392527+juliapampus@users.noreply.github.com> --- negotiation/contract.negotiation.protocol.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/negotiation/contract.negotiation.protocol.md b/negotiation/contract.negotiation.protocol.md index e04e9dab..e122ca3a 100644 --- a/negotiation/contract.negotiation.protocol.md +++ b/negotiation/contract.negotiation.protocol.md @@ -41,7 +41,7 @@ not transition to another state. A new CN may be initiated if, for instance, the Following table gives non-normative examples of transitions: -| Origin State | Actor | Transition Trigger Message | Target State | Non-normative Example | +| Origin State | Actor | Message | Target State | Non-normative Example | |----------------------------|--------|-------------------------------------------|--------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | INIT | C | ContractRequestMessage | REQUESTED | The consumer requests a contract, without previous direct interaction with provider, e.g. through the usage of a central cataloging system, which provides all necessary information about the provider, to directly request a data contract. | | INIT | P | ContractOfferMessage | OFFERED | The provider sends a contract offer directly to a consumer without previous interaction, e.g. because the provider knows about desired data (e.g., consumer placed a search for data request in a catalog) or consumer/provider are in an existing business relationship and provider wants to ship information to its business partner. | From 0b829b62b60272742cfc4485c86b53a892be6ca2 Mon Sep 17 00:00:00 2001 From: Sebastian Opriel Date: Fri, 11 Aug 2023 17:00:40 +0200 Subject: [PATCH 4/4] Update negotiation/contract.negotiation.protocol.md Co-authored-by: Julia Pampus <72392527+juliapampus@users.noreply.github.com> --- negotiation/contract.negotiation.protocol.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/negotiation/contract.negotiation.protocol.md b/negotiation/contract.negotiation.protocol.md index e122ca3a..af962f96 100644 --- a/negotiation/contract.negotiation.protocol.md +++ b/negotiation/contract.negotiation.protocol.md @@ -46,7 +46,7 @@ Following table gives non-normative examples of transitions: | INIT | C | ContractRequestMessage | REQUESTED | The consumer requests a contract, without previous direct interaction with provider, e.g. through the usage of a central cataloging system, which provides all necessary information about the provider, to directly request a data contract. | | INIT | P | ContractOfferMessage | OFFERED | The provider sends a contract offer directly to a consumer without previous interaction, e.g. because the provider knows about desired data (e.g., consumer placed a search for data request in a catalog) or consumer/provider are in an existing business relationship and provider wants to ship information to its business partner. | | REQUESTED | P | ContractOfferMessage | OFFERED | The provider sends an offering for a requested resource. | -| REQUESTED | P | ContractAgreementMessage | AGREED | The provider directly sends a contract agreement as no terms must be agreed to, e.g. in case publicly data shall be shared without any policies. Be aware that implementation of such transitions must comply with local laws in application. | +| REQUESTED | P | ContractAgreementMessage | AGREED | The provider sends a contract agreement after a successful validation of the consumer's contract request. | | OFFERED | C | ContractRequestMessage | REQUESTED | The consumer declines the offered contract and might sent a counter offer to the provider. | | OFFERED | C | ContractNegotiationEventMessage:accepted | ACCEPTED | The consumer accepts to comply with the defined details in the contract. | | ACCEPTED | P | ContractAgreementMessage | AGREED | The provider sends a provider-signed contract agreement to the consumer. |