openid
Verification request should return a 400 response if the stream is not enabled
Context: Yair Sarig (Omnissa) Yesterday at 4:16 PM Hello everyone. I'm looking for opinions on what should be the behavior of requesting a verification event for a stream that is disabled. The transmitter can't send the event to the receiver (per section 7.1.2) so it can either silently ignore the request or return a 400 (error) response to the caller. I'm leaning toward the second option (as it is usually better to be explicit) but I want to see if others have other opinions.
Rajvardhan Deshmukh (Cisco) Yesterday at 4:19 PM Good question. I would lean towards the 2nd option too. Don't know if this is addressed in any spec.
Brian Soby (AppOmni) Yesterday at 4:36 PM 400 seems correct to me
Apoorva Deshpande Yesterday at 6:02 PM Should this be extended to paused streams as well, since in the paused case the expectation from the Tx is the same as disabled. The Transmitter MUST NOT transmit events over the stream
Shayne Miel (Cisco) Today at 7:59 AM This seems reasonable. Will you put up a PR to make it explicit in the SSF spec? Or at least an Issue so we can track it
Swathi Kollavajjala (Cisco) Today at 10:33 AM Agree with returning 400 for paused and disabled streams. Do we need to support this for interop? (edited)
Ask: Add a clarification in section 7.1.4.2 that the response should be 400 if the stream status is disabled or pasued.
Specifying something that was not previous specified can be considered backwards-incompatible. How should we handle this?
We could add language to say this behavior is recommended, but not required. That keeps backward compatibility
I am rethinking this one.
Since Transmitter may initiate verification asynchronously, it may not know the status of the stream at the time of ack'ing the verification request.
I suggest not interconnecting the verification and status endpoints to overload them with duties. If the receiver needs to check whether the stream is active, it can initiate a get status call before calling the verify endpoint.
@appsdesh That argument makes sense to me. The "request a verification" endpoint can return successfully even if the transmitter is not able to send the verification event. The two moments (the Rx requesting a verification event and the Tx sending a verification event) are not tightly coupled. Imagine the case of a polling Tx. The Rx might request a verification event while the Tx is enabled and then the Tx is disabled before the Rx gets around to polling for the event.
I now agree with @appsdesh that we should close this issue as WONT FIX