Remove references to pull- and push-transfers

[arnoweiss]

Initial Situation

The spec currently differentiates between Push- and Pull-Transfers in the Transfer Process Protocol, more specifically with regards to the dataAddress object. PUSH and PULL are a mental model that describes if the Provider or the Consumer is supposed to act upon the received dataAddress.

Problem

However, I want to discuss their removal from the spec text for the following readsons:

1. They have no reflection in the normative protocol payloads. Examples mention them in the format property of the Catalog.Dataset.Distribution and the TransferRequestMessage in a string also indicating the Transfer Protocol (HTTP).
2. The distinctions are fuzzy. When a Data Provider grants access to an HTTP-endpoint, that is by definition of the protocol a "PULL" transfer as the Provider attaches the DataAddress to the TransferStartMessage. If the resulting HTTP request contains an HTTP body, the client/consumer is the one "pushing" to the server/provider. Similar inconsistencies arise when initiating a transfer via a message-based transport protocol.

Suggestion

Remove all references to push- and pull-transfers. This should be defined in the transport profiles that detail out the mechanics and semantics of the properties necessary to initiate after the DataAddress has been exchanged.

[lgblaumeiser]

My thoughts are going into a similar direction. Actually, imho, there is a big difference between PUSH and PULL which is based on control flow.

A PULL transfer does not need an active component on provider side, because actually, the consumer could receive enough information to directly address the service that has been negotiated. So there is not even a passive component like the data plane in the reference implementation necessary, the access from the consumer to the negotiated service endpoint could be done directly with an option from a connector to validate the token that is used for the request.

A PUSH transfer always needs an active component on provider side, because after the transfer is initiated, some service on the provider side has to actively initiate the data transfer by taking the data from some backend and pushing it to the target provided by the consumer. But from a semantical point of view, this push could be transfered into a PULL scenario as there is imho no reason that the active component has to be a part of the connector. The same functionality can be provided by an independent resource server which would provide the PUSH functionality as a service initiated with a standard PULL transfer request after the consumer has negotiated the access to this resource server.

This would mean, that the DSP does not need any semantical understanding of transfer type, it only needs to provide meta information like the type of the service that is offered in a DataSet. The semantics are then between consumer client and provider resource server to understand how to initiate the concrete transfer. Todays support for certain transfer types would then be an independent implementation of a resource server and the scope of the DSP service would be reduced to the presentation of available resources and the negotiation of the access to a resource between consumer and provider.