Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
ysarig75 opened this issue Oct 9, 2024 · 0 comments

Comments

@ysarig75
Copy link

ysarig75 commented Oct 9, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant