7.1.1.3 PATCH and 7.1.1.4 PUT Switch Transmitter-Supplied Properties to SSF server-supplied properties

[independentid]

When creating a stream, SET PUSH and POLL are different in SSF.

For SET PUSH, a receiver stream endpoint must be pre-created. Therefore when creating a PUSH stream, the transmitter is the Stream Service config service provider.

For SET POLL, a publisher stream endpoint must be pre-created. Therefore when creating a POLL stream, the receiver is the Stream Service config service provider.

The spec uses transmitter vs. receiver without regard to RFC8935 vs 8936. This doesn't work since:

• SET PUSH configures the receiver end
• SET POLLING configures the transmitter end

In other words, the normative text doesn't support configuring SET PUSH streams since it would be "receiver-supplied properties".

Recommend replacing "transmitter-supplied properties" with "SSF server-supplied properties" as a simple fix.

[FragLegs]

This is the section of the spec you are referring to, correct?

delivery

A JSON object containing a set of name/value pairs specifying configuration parameters for the SET delivery method. The actual delivery method is identified by the special key "method" with the value being a URI as defined in Section 11.2.1. The value of the "delivery" field contains two sub-fields:

method

Receiver-Supplied, the specific delivery method to be used. This can be any one of "urn:ietf:rfc:8935" (push) or "urn:ietf:rfc:8936" (poll), but not both.

endpoint_url

The location at which the push or poll delivery will take place. If the method value is "urn:ietf:rfc:8935" (push), then this value MUST be supplied by the Receiver. If the method value is "urn:ietf:rfc:8936" (poll), then this value MUST be supplied by the Transmitter.

I'm not sure I understand where the problem is. The text makes it clear that the receiver must specify the delivery method and then, depending on the method chosen, either the receiver or transmitter must supply the details.

[independentid]

As an example:

An Event Receiver updates the current configuration of a stream by
making an HTTP PATCH request to the Configuration Endpoint. The
PATCH body contains a JSON [RFC7159] representation of the stream
configuration properties to change. On receiving a valid request the
Event Transmitter responds with a "200 OK" response containing a JSON
[RFC7159] representation of the entire updated stream configuration
in the body.

The term "Event Receiver" doesn't make sense if using SET PUSH (RFC8935). In push it would be the Transmitter that needs to update the receiver's configuration with SET PUSH.

This is because HTTP "client" and "server" are switched between POLL and PUSH modes.

AFAIK, SSF only support automatic creation of the stream HTTP "client" streams endpoints. (Receiver for SET POLL, and Transmitter for SET PUSH).
--> I would be happy to have the spec enhanced to support both transmitter and receiver stream configs for both transfer types.

[timcappalli]

@tulshi would this be covered by your new IETF draft for push/pull?