Subject: [quicwg/base-drafts] Unidirectional Stream Headers in HTTP (#1359)

From: Mike Bishop <[email-masked]>
Date: Fri, 18 May 2018 17:24:42 -0700

Fixes #910, implements the idea discussed in #1323.

Unidirectional streams have a header which indicates what type they are.  Two types are defined by HTTP (control stream, push stream); two by QPACK (encoder stream, decoder stream).  Others can be defined in the future, somewhat analogously to new frame types.  (But if you send one the peer doesn't understand, you get a STOP_SENDING.)

Also revived HTTP_CLOSED_CRITICAL_STREAM, which got dropped somewhere along the way, but was still referenced.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/1359

-- Commit Summary --

  * WIP: Unidirectional stream headers
  * Fixups
  * Critical streams
  * QPACK control streams
  * IANA registration

-- File Changes --

    M draft-ietf-quic-http.md (249)
    M draft-ietf-quic-qpack.md (30)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1359.patch
https://github.com/quicwg/base-drafts/pull/1359.diff

-- 
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/pull/1359

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 18 May 2018 19:12:27 -0700

LPardue requested changes on this pull request.

Surprisingly unpainful and I am comfortable with the overall concept.

Some minor nits plus some suggestions. Happy to discuss further.

>  When HTTP headers and data are sent over QUIC, the QUIC layer handles most of
 the stream management.
 
-An HTTP request/response consumes a single client-initiated, bidirectional
-stream.  A bidirectional stream ensures that the response can be readily
-correlated with the request. This means that the client's first request occurs
-on QUIC stream 4, with subsequent requests on stream 8, 12, and so on.
-
-Server push uses server-initiated, unidirectional streams.  Thus, the server's
-first push consumes stream 7 and subsequent pushes use stream 11, 15, and so on.
+QUIC reserves the first client-initiated, bidirectional stream (Stream 0) for
+cryptographic operations. All remaining client-initiated bidirectional streams
+are used for requests and responses.  A bidirectional stream ensures that the
+response can be readily correlated with the request. This means that the
+client's first request occurs on QUIC stream 4, with subsequent requests on
+stream 8, 12, and so on. HTTP/QUIC does not use server-initiated bidirectional

HTTP over QUIC

>  When HTTP headers and data are sent over QUIC, the QUIC layer handles most of
 the stream management.
 
-An HTTP request/response consumes a single client-initiated, bidirectional
-stream.  A bidirectional stream ensures that the response can be readily
-correlated with the request. This means that the client's first request occurs
-on QUIC stream 4, with subsequent requests on stream 8, 12, and so on.
-
-Server push uses server-initiated, unidirectional streams.  Thus, the server's
-first push consumes stream 7 and subsequent pushes use stream 11, 15, and so on.
+QUIC reserves the first client-initiated, bidirectional stream (Stream 0) for
+cryptographic operations. All remaining client-initiated bidirectional streams
+are used for requests and responses.  A bidirectional stream ensures that the
+response can be readily correlated with the request. This means that the
+client's first request occurs on QUIC stream 4, with subsequent requests on
+stream 8, 12, and so on. HTTP/QUIC does not use server-initiated bidirectional

This paragraph loses the previous language convention "X-initiated**,** Ydirectional"

>  When HTTP headers and data are sent over QUIC, the QUIC layer handles most of
 the stream management.
 
-An HTTP request/response consumes a single client-initiated, bidirectional
-stream.  A bidirectional stream ensures that the response can be readily
-correlated with the request. This means that the client's first request occurs
-on QUIC stream 4, with subsequent requests on stream 8, 12, and so on.
-
-Server push uses server-initiated, unidirectional streams.  Thus, the server's
-first push consumes stream 7 and subsequent pushes use stream 11, 15, and so on.
+QUIC reserves the first client-initiated, bidirectional stream (Stream 0) for
+cryptographic operations. All remaining client-initiated bidirectional streams
+are used for requests and responses.  A bidirectional stream ensures that the

HTTP requests and responses?

> +
+Unidirectional streams in both directions possess a stream header that indicates
+the stream's purpose.  Some purposes are defined in this document; other
+purposes MAY be defined by extensions to HTTP/QUIC.
+
+~~~~~~~~~~ drawing
+ 0 1 2 3 4 5 6 7
++-+-+-+-+-+-+-+-+
+|Stream Type (8)|
++-+-+-+-+-+-+-+-+
+~~~~~~~~~~
+{: #fig-stream-header title="Unidirectional Stream Header"}
+
+The stream header consists of a single byte, indicating the type of data to
+follow.  The format and structure of that data are defined by the specification
+of the stream type.

Suggest replacing this paragraph (as some of its text was absorbed above):

This document specifies two stream types: control stream ({{control-streams}}) and push stream ({{server-push}}). Other stream types MAY be defined by extensions to HTTP over QUIC.

> @@ -432,17 +409,76 @@ either by identifying the stream that carries a request or by using a Push ID
 Only a client can send PRIORITY frames.  A server MUST NOT send a PRIORITY
 frame.
 
+## Unidirectional Streams
+
+Unidirectional streams in both directions possess a stream header that indicates
+the stream's purpose.  Some purposes are defined in this document; other
+purposes MAY be defined by extensions to HTTP/QUIC.
+

Suggest:

Unidirectional streams, in either direction, may be used for a range of purposes. The identity of a purpose is indicated by a stream type, which is signaled to the peer using a stream header. This is a single octet that is sent as the first data on a stream, the format and structure of data that follows the stream header is dependent on the stream type.

> +the stream's purpose.  Some purposes are defined in this document; other
+purposes MAY be defined by extensions to HTTP/QUIC.
+
+~~~~~~~~~~ drawing
+ 0 1 2 3 4 5 6 7
++-+-+-+-+-+-+-+-+
+|Stream Type (8)|
++-+-+-+-+-+-+-+-+
+~~~~~~~~~~
+{: #fig-stream-header title="Unidirectional Stream Header"}
+
+The stream header consists of a single byte, indicating the type of data to
+follow.  The format and structure of that data are defined by the specification
+of the stream type.
+
+If the header indicates a stream type which is not supported by the recipient,

the stream header

-HTTP/QUIC supports server push in a similar manner to {{!RFC7540}}, but uses
+Each side MUST initiate a single control stream at the beginning of the
+connection and send its SETTINGS frame as the first frame on this stream.  Only
+one control stream is permitted; receipt of a second stream which claims to be a

one control stream per peer

>  different mechanisms. During connection establishment, the client enables server
 push by sending a MAX_PUSH_ID frame (see {{frame-max-push-id}}). A server cannot
-use server push until it receives a MAX_PUSH_ID frame.
+use server push until it receives a MAX_PUSH_ID frame.  Only servers can push;
+if a server receives a client-initiated push stream, this MUST be treated as a
+stream error of type HTTP_PUSH_LIMIT_EXCEEDED.

The error type seems a bit wonky since the limit will never increase passed 0. I'd suggest either a different error (just a protocol error) or perhaps a recoined HTTP_PUSH_REFUSED. 

See my later point on stream type IANA.

-As with server push for HTTP/2, the server initiates a server push by sending a
-PUSH_PROMISE frame (see {{frame-push-promise}}) that includes request headers
-for the promised request.  Promised requests MUST conform to the requirements in
+The remaining data on this stream consists of HTTP frames, as defined in
+{{frames}}, and carries the response side of an HTTP message exchange as
+described in {{request-response}}.  The request headers of the exchange is

s/is/are

-As with server push for HTTP/2, the server initiates a server push by sending a
-PUSH_PROMISE frame (see {{frame-push-promise}}) that includes request headers
-for the promised request.  Promised requests MUST conform to the requirements in
+The remaining data on this stream consists of HTTP frames, as defined in
+{{frames}}, and carries the response side of an HTTP message exchange as
+described in {{request-response}}.  The request headers of the exchange is
+carried by a PUSH_PROMISE frame (see {{frame-push-promise}}) on the request

on the request stream?

> @@ -452,12 +488,8 @@ certain parts of the response is important (see Section 8.2.1 of {{!RFC7540}}).
 
 Unlike HTTP/2, the PUSH_PROMISE does not reference a stream; it contains a Push
 ID. The Push ID uniquely identifies a server push. This allows a server to
-fulfill promises in the order that best suits its needs.
-
-When a server later fulfills a promise, the server push response is conveyed on
-a push stream.  A push stream is a server-initiated, unidirectional stream.  A
-push stream identifies the Push ID of the promise that it fulfills, encoded as a
-variable-length integer.
+fulfill promises in the order that best suits its needs.  When a server later
+fulfills a promise, the server push response is conveyed on a push stream.

Perhaps this paragraph now fits better above the push stream header drawing?

> +
+Code:
+: The 8-bit code assigned to the stream type.
+
+Specification:
+: A reference to a specification that includes a description of the stream type,
+  including the layout semantics of its payload.
+
+The entries in the following table are registered by this document.
+
+| ---------------- | ------ | -------------------------- |
+| Stream Type      | Code   | Specification              |
+| ---------------- | :----: | -------------------------- |
+| Control Stream   | 0x43   | {{control-streams}}        |
+| Push Stream      | 0x50   | {{server-push}}            |
+| ---------------- | ------ | -------------------------- |

@I think it would be useful to state explicitly which direction that unidirectional stream types apply to i.e. client-initiated, server-initiated or both. Then we can just have a generic rule that says if a stream header is received on a directional that is not permitted by the type specification, then generate a generic error with HTTP_WRONG_STREAM_TYPE (or something else).

-- 
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/pull/1359#pullrequestreview-121604594

---

From: Martin Thomson <[email-masked]>
Date: Sun, 20 May 2018 17:45:38 -0700

martinthomson commented on this pull request.

I like this design.  The possibilities it opens are fairly appealing.

Or shorter: "Unidirectional streams, in either direction, are used for a range of purposes. The purpose is indicated by a stream type, which is sent as a single octet header at the start of the stream.  The format and structure of data that follows this header is determined by the stream type.

s/MAY/can/  (not an interoperability requirement, but a statement of fact)

+ 0 1 2 3 4 5 6 7
++-+-+-+-+-+-+-+-+
+|Stream Type (8)|
++-+-+-+-+-+-+-+-+
+~~~~~~~~~~
+{: #fig-stream-header title="Unidirectional Stream Header"}
+
+The stream header consists of a single byte, indicating the type of data to
+follow.  The format and structure of that data are defined by the specification
+of the stream type.
+
+If the header indicates a stream type which is not supported by the recipient,
+the stream MUST be aborted (using a QUIC STOP_SENDING frame) with an error of
+type HTTP_UNKNOWN_STREAM_TYPE.  The remainder of the stream SHOULD NOT be read
+by the recipient.

If your strategy here is to permit the use of these extensions without negotiation, the possibility that stream errors might be promoted to connection errors remain.  You should be clearer on this point.

I also don't think that you can require the stream to be stopped.  I won't send STOP_SENDING if the stream closes before I get around to it.

And for "SHOULD NOT be read", that's not necessary.  The semantics are undefined, so whether or not the data is read is immaterial.

-HTTP/QUIC supports server push in a similar manner to {{!RFC7540}}, but uses
+Each side MUST initiate a single control stream at the beginning of the
+connection and send its SETTINGS frame as the first frame on this stream.  Only
+one control stream is permitted; receipt of a second stream which claims to be a
+control stream MUST be treated as a connection error of type
+HTTP_TOO_CONTROLLING.  If the control stream is closed at any point, this MUST

I'm not a big fan of these very-specific error codes.  A "you screwed up" code is sufficient for these cases.

-HTTP/QUIC supports server push in a similar manner to {{!RFC7540}}, but uses
+Each side MUST initiate a single control stream at the beginning of the
+connection and send its SETTINGS frame as the first frame on this stream.  Only
+one control stream is permitted; receipt of a second stream which claims to be a
+control stream MUST be treated as a connection error of type
+HTTP_TOO_CONTROLLING.  If the control stream is closed at any point, this MUST
+be treated as a connection error of type HTTP_CLOSED_CRITICAL_STREAM.

Have you considered creating a special stream for "settings", that is closed when all settings-related information is complete?  That would allow for sending MAX_PUSH_ID there with some certainty about status.  You could then reserve the "control" stream type for PRIORITY, MAX_PUSH_ID, CANCEL_PUSH, and GOAWAY frames.

-HTTP/QUIC supports server push in a similar manner to {{!RFC7540}}, but uses
+Each side MUST initiate a single control stream at the beginning of the
+connection and send its SETTINGS frame as the first frame on this stream.  Only
+one control stream is permitted; receipt of a second stream which claims to be a
+control stream MUST be treated as a connection error of type
+HTTP_TOO_CONTROLLING.  If the control stream is closed at any point, this MUST
+be treated as a connection error of type HTTP_CLOSED_CRITICAL_STREAM.
+
+Since most connection-level concerns will be managed by QUIC, the primary use of
+the control streams will be for the SETTINGS frame when the connection opens and
+for PRIORITY frames subsequently.

and push-related control frames, and GOAWAY

+A push stream is indicated by a stream type of `0x50`, followed by the Push ID

Care to share your rationale for picking these values?

> +| HTTP_WRONG_STREAM                   | 0x000A     | A frame was sent on the wrong stream     | {{http-error-codes}}   |
+| HTTP_PUSH_LIMIT_EXCEEDED            | 0x000B     | Maximum Push ID exceeded                 | {{http-error-codes}}   |
+| HTTP_DUPLICATE_PUSH                 | 0x000C     | Push ID was fulfilled multiple times     | {{http-error-codes}}   |
+| HTTP_MALFORMED_FRAME                | 0x01XX     | Error in frame formatting or use         | {{http-error-codes}}   |
+| HTTP_UNKNOWN_STREAM_TYPE            | 0x0D       | Unknown unidirectional stream type       | {{http-error-codes}}   |
+| HTTP_TOO_CONTROLLING                | 0x0E       | Multiple control streams                 | {{http-error-codes}}   |
+| HTTP_CLOSED_CRITICAL_STREAM         | 0x0F       | Critical stream was closed               | {{http-error-codes}}   |
+| ----------------------------------- | ---------- | ---------------------------------------- | ---------------------- |
+
+## Stream Types {#iana-stream-types}
+
+This document establishes a registry for HTTP/QUIC unidirectional stream types.
+The "HTTP/QUIC Stream Type" registry manages an 8-bit space.  The "HTTP/QUIC
+Stream Type" registry operates under either of the "IETF Review" or "IESG
+Approval" policies {{?RFC8126}} for values between 0x00 and 0xef, with values
+between 0xf0 and 0xff being reserved for Experimental Use.

inclusive or exclusive?  (You might need to fix you copied too.)

> @@ -179,17 +179,23 @@ x ...
 QPACK instructions occur in three locations, each of which uses a separate
 instruction space:
 
- - Table updates are carried by a unidirectional stream from encoder to decoder.
-   Instructions on this stream modify the dynamic table state without generating
-   output to any particular request.
+ - Table updates are carried by a unidirectional stream of type `0x48` from
+   encoder to decoder. Instructions on this stream modify the dynamic table
+   state without generating output to any particular request.

You name this "encoder stream" in two places later, but don't establish the name here where it is defined.  "An encoder stream is a unidirectional stream that carries table updates..." and "An acknowledgment stream is a unidirectional stream that carries acknowledgments..."

Is it better as "table update stream"?

-- 
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/pull/1359#pullrequestreview-121661090

---

From: Mike Bishop <[email-masked]>
Date: Mon, 21 May 2018 10:19:08 -0700

MikeBishop commented on this pull request.

 the stream management.

I don't really like the comma in that construction, since it's describing which flavor of Ydirectional stream rather than two independent descriptors of the stream.  So I fixed it by removing the other commas.  😉

"HTTP/QUIC" is used 60 times in this document, "HTTP over QUIC" is used 5.  I think of them equivalently to "HTTP/2" and "HTTP version 2" in RFC7540.  I'll do a pass separately to see if it's appropriate to trim any other "over"s.

-- 
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/pull/1359#discussion_r189655420

---

From: Mike Bishop <[email-masked]>
Date: Mon, 21 May 2018 10:28:41 -0700

Reasonable suggestion; let's maybe do that as a second stage, though?

-- 
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/pull/1359#discussion_r189657853

---

From: Mike Bishop <[email-masked]>
Date: Mon, 21 May 2018 10:32:52 -0700

True, the control stream has expanded again since this text was first written elsewhere.  Let's just drop that paragraph.

-- 
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/pull/1359#discussion_r189658920

---

From: Mike Bishop <[email-masked]>
Date: Mon, 21 May 2018 13:42:10 -0700

If we think a table and 0x00, 0x01, etc. is better, I can do that easily enough.  However, 0x00 in particular seems like a first byte you could get reasonably by accident.  I think non-sequential usage will make it somewhat less likely that bugs/experiments will collide, so I selected these via ASCII values.

Control streams are ASCII "C", push is ASCII "P", and header compression uses "H" and "h".  It has a nice side-effect of viewing the stream data in a UI that renders the bytes into ASCII/UTF-8.

-- 
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/pull/1359#discussion_r189707865

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 May 2018 16:30:41 -0700

Of course :)

-- 
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/pull/1359#discussion_r189741449

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 May 2018 16:31:54 -0700

Just wondering.  I don't do ASCII conversion in my head, so the numbers looked a little odd.  There is no real reason to pick numbers sequentially.

-- 
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/pull/1359#discussion_r189741617

---

From: Mike Bishop <[email-masked]>
Date: Mon, 21 May 2018 19:27:09 -0700

@MikeBishop pushed 1 commit.

5fb30e2  Review feedback

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1359/files/f875161e9f4bad86ad467b69129e33221637728d..5fb30e22746d809e03a84bc2579ec4221b143c51

---

From: Mike Bishop <[email-masked]>
Date: Mon, 21 May 2018 19:42:48 -0700

Not specific to this PR, but happy to address separately.

-- 
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/pull/1359#discussion_r189764739

---

From: Mike Bishop <[email-masked]>
Date: Mon, 21 May 2018 19:44:33 -0700

c909214  Introduce stream terms

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1359/files/5fb30e22746d809e03a84bc2579ec4221b143c51..c9092143710f8e3da2ed933a4b846140ab9233a3

---

From: afrind <[email-masked]>
Date: Tue, 22 May 2018 14:27:05 -0700

afrind commented on this pull request.

-HTTP/QUIC supports server push in a similar manner to {{!RFC7540}}, but uses
+###  Control Streams
+
+The control stream is indicated by a stream type of `0x43`.  Data on this stream
+consists of HTTP frames, as defined in {{frames}}.
+
+Each side MUST initiate a single control stream at the beginning of the
+connection and send its SETTINGS frame as the first frame on this stream.  Only
+one control stream per peer is permitted; receipt of a second stream which
+claims to be a control stream MUST be treated as a connection error of type
+HTTP_TOO_CONTROLLING.  If the control stream is closed at any point, this MUST

lol.  HTTP_CONTROL_FREAK

-HTTP/QUIC supports server push in a similar manner to {{!RFC7540}}, but uses
+###  Control Streams
+
+The control stream is indicated by a stream type of `0x43`.  Data on this stream

Maybe add "(ASCII 'C')", etc - otherwise everyone is going to ask.

> @@ -179,18 +179,25 @@ x ...
 
- - Table updates are carried by a unidirectional stream from encoder to decoder.
-   Instructions on this stream modify the dynamic table state without generating
-   output to any particular request.
- - Acknowledgements of table modifications and header processing are carried by
-   a unidirectional stream from decoder to encoder.
+ - The encoder stream is a unidirectional stream of type `0x48` which carries

H and D, not E and D?

-- 
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/pull/1359#pullrequestreview-122356501

---

From: Mike Bishop <[email-masked]>
Date: Tue, 22 May 2018 16:36:31 -0700

H and h, actually, for header compression.

-- 
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/pull/1359#discussion_r190085323

---

From: Mike Bishop <[email-masked]>
Date: Tue, 22 May 2018 16:37:16 -0700

b00d2b7  ASCII codes

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1359/files/c9092143710f8e3da2ed933a4b846140ab9233a3..b00d2b79fbc002fd185cc3bb5826376ad363ba99

---

From: Mike Bishop <[email-masked]>
Date: Tue, 22 May 2018 16:38:24 -0700

It now is, GitHub just doesn't see the diff that way.

-- 
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/pull/1359#discussion_r190085602

---

From: Mike Bishop <[email-masked]>
Date: Tue, 29 May 2018 15:38:58 -0700

9b6dd09  Fix ref breakage, again

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1359/files/2d5ce907c7e12ef0a22b08ebe2676cab0e69f4c4..9b6dd09394deaf8063248f28f0c88f1757f1eb47

---

From: Mike Bishop <[email-masked]>
Date: Tue, 29 May 2018 16:12:55 -0700

0b3c18f  Stray assumptions of control stream ID

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1359/files/9b6dd09394deaf8063248f28f0c88f1757f1eb47..0b3c18fab7e25346166d43772b285ba04b199f66

---

From: Martin Thomson <[email-masked]>
Date: Tue, 29 May 2018 18:24:41 -0700

One thing that you might consider doing either as part of this or as a followup is changing the text about extensions to explain that an alternative to using a frame type a unidirectional stream type might work. 

For instance, I wonder if CERTIFICATE might be better suited to a stream than a frame.  The head-of-line it creates might be minor now that header compression is off the control stream in QUIC, but it could still interfere with itself and maybe a little with PRIORITY frames.

-- 
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/pull/1359#issuecomment-393000280

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 29 May 2018 18:59:19 -0700

Martin makes a good point, I kind of agree but thinking this through for something else I ask the question "what makes this an extension to HTTP"? To elaborate, if all we are doing is reserving some of QUICs streams to sit independently alongside HTTP request/response, then what of HTTP does this extend?

I don't think an answer is hard, nor required but this is yet another variable to consider (and there is not much guidance) on how to select an extension format.

-- 
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/pull/1359#issuecomment-393005642

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 29 May 2018 19:15:13 -0700

To be less vague, consider how WebSockets could be implemented in QUIC with this unidirectional stream approach.

-- 
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/pull/1359#issuecomment-393008152

---

From: Mike Bishop <[email-masked]>
Date: Tue, 29 May 2018 19:51:25 -0700

My thought had been that things which the sender has in hand all at once should be frames, while things which develop over long stretches should be a stream.  Of course, that's all in the eye of the beholder, but it would argue for an ALTSVC frame but a QPACK stream.

I think the thing this extends of HTTP is that the HTTP implementation owns the full set of QUIC streams.  If an HTTP plugin chooses to pipe a stream off to some secondary function, that's its prerogative.

-- 
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/pull/1359#issuecomment-393013703

---

From: Martin Thomson <[email-masked]>
Date: Tue, 29 May 2018 19:58:33 -0700

I like Mike's view here: if it's discrete and finite always, use a frame.  They are easier to use.

If it might run on continuously, use a stream.

Other factors might change that though: ordering relative to other activity often forces things into being frames.  And head of line blocking concerns might push towards a stream.  Even a small, discrete message might need to sit in a receive buffer until some condition is fulfilled, which you don't want to have blocking an important stream.

-- 
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/pull/1359#issuecomment-393014765

---

From: Mike Bishop <[email-masked]>
Date: Tue, 29 May 2018 20:57:16 -0700

I'm inclined to follow this PR with a separate editorial one expounding on when you might want to use each.  However, this one is parked for the coming week or two, so I might create that one before this one lands.

-- 
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/pull/1359#issuecomment-393022643

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 30 May 2018 01:26:21 -0700

So I made a typo earlier and meant to write "is hypothetical feature X an extension of HTTP" rather than imply the changes on this PR.

Nonetheless I think we are the same page. The proposal SGTM.

For the WebSocket example it could be considered in terms of an application layer multiplexing that is boot strapped by a HTTP request. The sinple design choice would be to keep it on a bidirectional stream (as in H2), something more exotic would be to launch the request on a unidirectional stream and expect a paired response on a different uni stream.

-- 
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/pull/1359#issuecomment-393075287