Verification request should return a 400 response if the stream is not enabled

[ysarig75]

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.

[FragLegs]

Specifying something that was not previous specified can be considered backwards-incompatible. How should we handle this?

[tulshi]

We could add language to say this behavior is recommended, but not required. That keeps backward compatibility