#46 add stream exists behavior

[timcappalli]

Issue #46: add stream exists behavior

[independentid]

409 may not be appropriate. If you look at the definition the problem is that the client should try again...

https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.9

403 seems appropriate because it says retrying won't fix the issue.

[timcappalli]

403 seems appropriate because it says retrying won't fix the issue.

We spent almost an hour debating this one yesterday. I don't think 403 is appropriate either as it talks about authorization.

https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.9 > "...but refuses to authorize it."

We landed on 409 because the receiver can ultimately resolve this by changing their request.

[independentid]

In what way can the receiver change their request?  It is authorization because the server has a policy of allowing only a single stream.  403 means an administrator has to take action to resolve (what is needed). 409 literally means try the request again immediately. In my experience 409 has always mean execute a retry.  PhilOn Aug 2, 2023, at 6:51 AM, Tim Cappalli @.***> wrote:

403 seems appropriate because it says retrying won't fix the issue.

We spent almost an hour debating this one yesterday. I don't think 403 is appropriate either as it talks about authorization. "...but refuses to authorize it." We landed on 409 because the receiver can ultimately resolve this by changing their request.

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

[independentid]

My regrets on not making the call. It seems I have to update my calendar as all my OpenID meetings have disappeared.

Reading from the minutes of last tuesday, I got the impression that the group was trying to assign high-level meaning to the response. When dealing with HTTP Status messages you have to always think about protocol meaning. In RFC7231, the client is allowed to immediately re-try the request (e.g. beause another client PUT or POSTED at the same time).

For me the issue is accademic. If i2goSignals was only going to allow 1 stream it would return 403 because the client is only authorized to have 1 stream. From a protocol perspective, whether the reason is technical or policy, the protocol response should be the same - because we should want the requestor to stop trying.

Answering Tim’s comment, if an endpoint only supports 1 stream, why would it implement SSF? Implementing stream management seems like a burden.

i2scim.io will only support 1 incoming stream and 1 outgoing stream. It has no stream management because it uses SET PUSH to deliver and SET POLL to receive. Stream management is what i2scim.io calls as an HTTP client to set itself up.

Phillip Hunt @.***

On Aug 2, 2023, at 12:15 PM, Phil Hunt @.***> wrote:

In what way can the receiver change their request?

It is authorization because the server has a policy of allowing only a single stream.
403 means an administrator has to take action to resolve (what is needed). 409 literally means try the request again immediately.

In my experience 409 has always mean execute a retry.

Phil

On Aug 2, 2023, at 6:51 AM, Tim Cappalli @.***> wrote:



403 seems appropriate because it says retrying won't fix the issue.

We spent almost an hour debating this one yesterday. I don't think 403 is appropriate either as it talks about authorization.

"...but refuses to authorize it."

We landed on 409 because the receiver can ultimately resolve this by changing their request.

— Reply to this email directly, view it on GitHub https://github.com/openid/sharedsignals/pull/50#issuecomment-1662252987, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFQUXRTCNLIXEAN72EQV73XTJLOTANCNFSM6AAAAAAWEKE4XM. You are receiving this because you commented.