[quicwg/base-drafts] Applications and Stream IDs (#910)

[Mike Bishop <[e-mail]>]

@nibanks previously proposed a QUIC API that didn't expose specific Stream IDs to applications.  That doesn't actually work for HTTP/QUIC as currently defined, but there are only two places where the HTTP/QUIC implementation needs to reference a Stream ID.

- PRIORITY frames reference requests by Stream ID.  The solution to this would be to expand #701 to use a Request ID for client-initiated requests as well as Push ID.  (At first glance, these don't need to be throttled since QUIC MAX_STREAM_ID effectively controls this.)
- The long-lived control stream is a specific stream ID.  This could be eliminated by putting a stream header (again, à la #701) on unidirectional streams that identifies them as control streams.  We still need the control stream to be unique to support order-dependent frames like PRIORITY.

If HTTP goes this direction, there's an associated question for the abstraction design team as to whether we want to explicitly recommend that the Stream ID is always an internal property of the transport.  (This would make it easier to make changes to Stream IDs and how they work in future versions, incidentally.)

-- 
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/910