Re: [quicwg/base-drafts] STOP_SENDING in Ready state (#1797)

[Kazuho Oku <[e-mail]>]

@MikeBishop Clarification question: you seem to argue that it is not "unreasonable to send STOP_SENDING preemptively for unidirectional streams", and that we should "clarify that the delayed allocation of Stream ID only applies to locally-initiated streams".

However, my understanding is that if sending STOP_SENDING for unidirectional streams can only be done for remotely-initiated streams, by endpoints that have prior knowledge of what the stream ID of those streams would be.

So to me it seems that we can only have either one of the properties; i.e. either allow sending STOP_SENDING preemptively, or disallow delayed allocation of stream IDs.

Regarding the general idea of having a prior knowledge of what the stream IDs will be used for, I am not sure if we want to allow (or encourage) that type of design. IIUC we discussed that and the conclusion was to introduce the "type" octet for the unidirectional streams in the HTTP binding. I prefer sticking to the decision we made.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1797#issuecomment-424916478