Config Parameters for Receiver Streams

[independentid]

In scenarios where SSF endpoints can be both Transmitters and/or Receivers, the need arises to be able to indicate whether the SSSF server is creating a receiver or transmitter stream.

In order for the SSF service to tell whether it is creating a transmitter stream or a receiver need a new parameter is required.

• [inbound] is a boolean attribute which if defined an set to true means that the stream is a receiver stream. If not asserted or false, the stream is a transmitter stream.

When creating a POLLING receiver stream, the delivery method is set to urn:ietf:rfc8936 and the endpoint_url of the transmitter polling endpoint is provided.

When creating a PUSH receiver stream, the delivery method is set to urn:ietf:rfc8935 and the endpoint_url is NOT provided. In the stream creation response, the endpoint_url and endpoint_auth are provided.

Note: AFAIK by flagging a receiver with the optional boolean attribute, this enhancement should be backwards compatible.

It may also be worth indicating minimum parameters for each creation request: PUSH (Trans vs Recv) and POLL (Trans vs. Recv). Also in practice SET PUSH requires the receiver be configured first, but in SET POLL the transmitter is configured first (because the HTTP endpoints and credentials have to be established).

[independentid]

I will take a shot at updating the stream configuration parameters and the creating a stream section to cover the proposed 4 stream types:

"delivery_methods_supported": [
    "urn:ietf:rfc:8935",
    "urn:ietf:rfc:8936",
    "urn:ietf:rfc:8935:receive,
    "urn:ietf:rfc:8936:receive"],

I have a proposal that looks to be backwards compatible and have it mostly implemented now. :-)

[appsdesh]

I think, it would make sense to look at the Receiver as a separate entity and define the configuration APIs.

At minimum, the Receiver will need to store following info -

1. Delivery method it supports - Push or poll or both
2. In case of a poll, the transmitter URl
3. A well-known URL for the transmitter

Separately receiver would need to store AuthZ credentials for the transmitter

A receiver configuration should provide ability to create the config with at least these attributes.

[independentid]

We may be talking about the same thing. Because push and poll work in opposite directions the receive modes are just the reverse of transmit. Eg. for push, the receiver asserts the endpoint which must be settable afterwards on the transmitter. For poll it is the transmitter that asserts endpoint_url that is configured on the receiver. I should have a PR in today or tomorrow. With one exception  the schema is identical for all 4 cases. What changes is who asserts what.    The exception is that the polling receiver may want to configure polling parameters (eg long polling vs periodic check). PhilOn Sep 18, 2023, at 1:59 PM, Apoorva Deshpande @.***> wrote: I think, it would make sense to look at the Receiver as a separate entity and define the configuration APIs. At minimum, the Receiver will need to store following info -

Delivery method it supports - Push or poll or both In case of a poll, the transmitter URl A well-known URL for the transmitter

Separately receiver would need to store AuthZ credentials for the transmitter A receiver configuration should provide ability to create the config with at least these attributes.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>