<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">My regrets on not making the call. It seems I have to update my calendar as all my OpenID meetings have disappeared.<div><br></div><div>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). </div><div><br></div><div>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.</div><div><br></div><div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Answering Tim’s comment, if an endpoint only supports 1 stream, why would it implement SSF? Implementing stream management seems like a burden.</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">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. </div></div><div><br></div><div><br></div><div><div>
<div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div>Phillip Hunt</div><div>phil.hunt@independentid.com</div><div><br></div></div><br class="Apple-interchange-newline"></div><br class="Apple-interchange-newline"><br class="Apple-interchange-newline">
</div>
<div><br><blockquote type="cite"><div>On Aug 2, 2023, at 12:15 PM, Phil Hunt <phil.hunt@yahoo.com> wrote:</div><br class="Apple-interchange-newline"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div dir="auto">In what way can the receiver change their request? <div><br></div><div>It is authorization because the server has a policy of allowing only a single stream. </div><div>403 means an administrator has to take action to resolve (what is needed). 409 literally means try the request again immediately. </div><div><br></div><div>In my experience 409 has always mean execute a retry. <br><br><div dir="ltr">Phil</div><div dir="ltr"><br><blockquote type="cite">On Aug 2, 2023, at 6:51 AM, Tim Cappalli <notifications@github.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div><br class="webkit-block-placeholder"></div>
<blockquote><p dir="auto">403 seems appropriate because it says retrying won't fix the issue.</p>
</blockquote><p dir="auto">We spent almost an hour debating this one yesterday. I don't think 403 is appropriate either as it talks about authorization.</p><p dir="auto">"...but refuses to authorize it."</p><p dir="auto">We landed on 409 because the receiver can ultimately resolve this by changing their request.</p><p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br>Reply to this email directly, <a href="https://github.com/openid/sharedsignals/pull/50#issuecomment-1662252987">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AAFQUXRTCNLIXEAN72EQV73XTJLOTANCNFSM6AAAAAAWEKE4XM">unsubscribe</a>.<br>You are receiving this because you commented.<img src="https://github.com/notifications/beacon/AAFQUXX6NNLWC2OZQL77TBTXTJLOTA5CNFSM6AAAAAAWEKE4XOWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTDCP33W.gif" height="1" width="1" alt=""><span style="color: transparent; font-size: 0; display: none; visibility: hidden; overflow: hidden; opacity: 0; width: 0; height: 0; max-width: 0; max-height: 0; mso-hide: all">Message ID: <span><openid/sharedsignals/pull/50/c1662252987</span><span>@</span><span>github</span><span>.</span><span>com></span></span></p>
</div></blockquote></div></div></div></blockquote></div><br></div></body></html>