Subject: [quicwg/base-drafts] Pull some H2 content into the introduction (#2683)

From: Mike Bishop <[email-masked]>
Date: Thu, 09 May 2019 21:46:48 +0000 (UTC)

Some edits to the beginning of the draft based on an RFC7540 read-through.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Moar H2 - WIP
  * More WIP
  * Definitions

-- File Changes --

    M draft-ietf-quic-http.md (209)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2683.patch
https://github.com/quicwg/base-drafts/pull/2683.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/2683

---

From: MikkelFJ <[email-masked]>
Date: Thu, 09 May 2019 22:40:56 -0700

mikkelfj commented on this pull request.

> @@ -88,28 +88,100 @@ code and issues list for this draft can be found at
 
 HTTP semantics are used for a broad range of services on the Internet. These
 semantics have commonly been used with two different TCP mappings, HTTP/1.1 and
-HTTP/2.  HTTP/2 introduced a framing and multiplexing layer to improve latency
-without modifying the transport layer.  However, TCP's lack of visibility into
-parallel requests in both mappings limited the possible performance gains.
+HTTP/2.  HTTP/3 supports the same semantics over a new transport protocol, QUIC.
+
+## Prior versions of HTTP
+
+HTTP/1.1 was a TCP mapping which used whitespace-delimited text fields to convey

Past tense may not be appropriate as it is still in active use in a few places.

> @@ -88,28 +88,100 @@ code and issues list for this draft can be found at
 
 HTTP semantics are used for a broad range of services on the Internet. These
 semantics have commonly been used with two different TCP mappings, HTTP/1.1 and
-HTTP/2.  HTTP/2 introduced a framing and multiplexing layer to improve latency
-without modifying the transport layer.  However, TCP's lack of visibility into
-parallel requests in both mappings limited the possible performance gains.
+HTTP/2.  HTTP/3 supports the same semantics over a new transport protocol, QUIC.
+
+## Prior versions of HTTP
+
+HTTP/1.1 was a TCP mapping which used whitespace-delimited text fields to convey
+HTTP messages.  While these exchanges were human-readable, the whitespace led to
+parsing difficulties and workarounds to be tolerant of variant behavior.
+Because each connection could be used only for a single HTTP request and
+response at a time, multiple parallel TCP connections were used, reducing the

That is not true. Pipelining is a thing.

 QUIC is described in {{QUIC-TRANSPORT}}.  For a full description of HTTP/2, see
-{{!RFC7540}}.
-
-
-## Notational Conventions
+{{!HTTP2=RFC7540}}.
+
+# HTTP/3 Protocol Overview
+
+HTTP/3 provides a transport for HTTP semantics using the QUIC transport protocol
+and an internal framing layer similar to HTTP/2.
+
+An HTTP/3 endpoint is discovered using HTTP Alternative Services.  Once a client

Can be

> +
+An HTTP/3 endpoint is discovered using HTTP Alternative Services.  Once a client
+knows that an HTTP/3 server exists at a certain endpoint, it opens a QUIC
+connection. QUIC provides protocol negotiation, stream-based multiplexing, and
+flow control.
+
+Within each stream, the basic unit of HTTP/3 communication is a frame
+({{frames}}).  Each frame type serves a different purpose.  For example, HEADERS
+and DATA frames form the frames form the basis of HTTP requests and responses
+({{request-response}}).  Other frame types like SETTINGS, PRIORITY, and GOAWAY
+are used to managed the overall connection.
+
+Multiplexing of requests is performed using the QUIC stream abstraction, with
+each request and response consuming a single QUIC stream.  Streams are largely
+independent of each other, so one stream that is blocked or suffers packet loss
+does not prevent progress on other streams.

But progress of other streams can when flow credits are exhausted.

> +  endpoint is discovered and a connection is established.
+- Stream Mapping and Usage ({{stream-mapping}}) describes the way QUIC streams
+  are used.
+- HTTP Framing Layer ({{http-framing-layer}}) describes the frames used on
+  most streams.
+- HTTP Request Lifecycle ({{http-request-lifecycle}}) describes how HTTP
+  semantics are expressed using frames.
+- Connection Closure ({{connection-closure}}) describes how connections are
+  terminated, either gracefully or abruptly.
+- Extensions to HTTP/3 ({{extensions}}) describes how new capabilities can be
+  added in future documents.
+- Error Handling ({{errors}}) describes how error conditions are handled and
+  expressed, either on a particular stream or for the connection as a whole.
+
+Readers familiar with HTTP/2 will find a more detailed comparison with that
+protocol in {{h2-considerations}}.

With that protocol? HTTP/1.1?

> +  and receive HTTP responses.
+
+connection:
+: A transport-layer connection between two endpoints, using QUIC as the
+  transport protocol.
+
+connection error:
+: An error that affects the entire HTTP/3 connection.
+
+endpoint:
+: Either the client or server of the connection.
+
+frame:
+: The smallest unit of communication within an HTTP/3 connection, consisting of
+  a header and a variable-length sequence of octets structured according to the
+  frame type.

It may be worth noting that frames can span mutiple packets unlike QUIC 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/2683#pullrequestreview-235928570

---

From: ianswett <[email-masked]>
Date: Fri, 10 May 2019 01:01:42 -0700

ianswett commented on this pull request.

Thanks Mike, this is a great improvement

typically discovered?  Or may be discovered?

PRIORITY is used to manage the streams more than the connection

```suggestion
each request and response consuming a single QUIC stream.  Streams are
```

If you want to explain the QPACK caveat, I'd do that explicitly and/or separately.  But the streams themselves are independent and non-HoL blocking.

+({{frames}}).  Each frame type serves a different purpose.  For example, HEADERS
+and DATA frames form the frames form the basis of HTTP requests and responses
+({{request-response}}).  Other frame types like SETTINGS, PRIORITY, and GOAWAY
+are used to managed the overall connection.
+
+Multiplexing of requests is performed using the QUIC stream abstraction, with
+each request and response consuming a single QUIC stream.  Streams are largely
+independent of each other, so one stream that is blocked or suffers packet loss
+does not prevent progress on other streams.
+
+Server push is an interaction mode introduced in HTTP/2 {{!HTTP2}} which permits
+a server to push a request-response exchange to a client in anticipation of the
+client making the indicated request.  This trades off network usage against a
+potential latency gain.  Several HTTP/3 frames are used to manage server push,
+such as PUSH_PROMISE, DUPLICATE_PUSH, and CANCEL_PUSH.

You list almost all of them, any reason not to list all of them?

> +  {{QUIC-TRANSPORT}}. Where frames from {{QUIC-TRANSPORT}} are referenced, the
+  frame name will be prefaced with "QUIC."  For example, "QUIC CONNECTION_CLOSE
+  frames."  References without this preface refer to frames defined in
+  {{frames}}.
+
+peer:
+: An endpoint.  When discussing a particular endpoint, "peer" refers to the
+  endpoint that is remote to the primary subject of discussion.
+
+receiver:
+: An endpoint that is receiving frames.
+
+sender:
+: An endpoint that is transmitting frames.
+
+server:

nit: I'd put this right after client

> @@ -1774,7 +1898,7 @@ removed. Because stream termination is handled by QUIC, an END_STREAM flag is
 not required.  This permits the removal of the Flags field from the generic
 frame layout.
 
-Frame payloads are largely drawn from {{!RFC7540}}. However, QUIC includes many
+Frame payloads are largely drawn from {{!HTTP2}}. However, QUIC includes many

This section is quite long.  The changes to priority are substantial, so I'd break them out in their own sub-section.

> @@ -1742,7 +1866,7 @@ assigned by IANA.
 
 --- back
 
-# Considerations for Transitioning from HTTP/2
+# Considerations for Transitioning from HTTP/2 {#h2-considerations}
 
 HTTP/3 is strongly informed by HTTP/2, and bears many similarities.  This
 section describes the approach taken to design HTTP/3, points out important

Below "HTTP/3 departs from HTTP/2 primarily where necessary to
accommodate the differences in behavior between QUIC and TCP (lack of ordering,	accommodate the 
support for streams)."

I'd tweak this to be more along the lines of "We changed it when we thought a new design was better, with particular focus on taking advantage of QUIC's lack of head of line blocking" to reflect the state we're in today.  Don't take my suggestion verbatim, but I think that's the concept?

-- 
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/2683#pullrequestreview-235847760

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 10 May 2019 07:41:24 -0700

LPardue requested changes on this pull request.

I think this is a good addition to the document. I left a few minor comments and suggestions.

 This document defines a mapping of HTTP semantics over the QUIC transport
-protocol, drawing heavily on the design of HTTP/2. This document identifies
-HTTP/2 features that are subsumed by QUIC, and describes how the other features
-can be implemented atop QUIC.
+protocol, drawing heavily on the design of HTTP/2.  While delegating stream
+management and flow control issues to QUIC, a similar binary framing is used on

what does the term stream management mean in this case? In some perspectives, QUIC doesn't manage much other than ensuring the stream arrives and is presented in-order at the other end (as explained elsewhere in this doc). 

+{{!HTTP2=RFC7540}}.
+

```suggestion
and DATA frames form the basis of HTTP requests and responses
```

> +client:
+: The endpoint that initiates an HTTP/3 connection.  Clients send HTTP requests

I know this comes from HTTP/2 but one could argue that frames are not the smallest unit in HTTP/3.

disagree, the order is lexical and mirrors the ordering of terms in RFC 7540

> @@ -922,10 +1046,10 @@ implementation chooses.
 
 ## HTTP Message Exchanges {#request-response}
 
-A client sends an HTTP request on a client-initiated bidirectional QUIC
-stream. A client MUST send only a single request on a given stream.
-A server sends one or more HTTP responses on the same stream as the request,
-as detailed below.
+A client sends an HTTP request on a client-initiated bidirectional QUIC stream.
+A client MUST send only a single request on a given stream. A server sends zero
+or more non-final HTTP responses on the same stream as the request, followed by
+a single final HTTP response, as detailed below.

 
 --- back

Based on the evidence, the design changes seem to be motivated because we lost something we had, not because we are taking advantage of some new ability.

-- 
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/2683#pullrequestreview-236135667

---

From: Mike Bishop <[email-masked]>
Date: Fri, 10 May 2019 12:05:19 -0700

MikeBishop commented on this pull request.

Kind of.  Where it works, you're still sending a single request at a time and a single response at a time (i.e. they're sent serially); you're just able to start sending the next request before the previous response has been sent.

State machine, flow control, ID allocation....

Pending the discussion on https://github.com/httpwg/http-core/issues/194; once that discussion settles on core text to describe finding candidate ports and protocols from a URI, this will change to reflect it.  Currently, this document describes Alt-Svc as the only discovery mechanism and the rest proceeds from the assumption that you somehow discovered the port was there.

I can try to wordsmith a little more.  It's used to manage the allocation of connection resources amongst the streams, not to manage the lifetime of any particular stream/request.

```suggestion
such as PUSH_PROMISE, DUPLICATE_PUSH, MAX_PUSH_ID, and CANCEL_PUSH.
```

I'm struggling to see how the antecedent of "that protocol" is unclear here.

 --- back

We've gotten a little stretchy in places, but we've been explicitly trying to stay out of the "improve on HTTP/2 in ways unrelated to QUIC" game.  (Some fixes to the more egregious gaps in prioritization are the primary exception.)  I'm trying to reflect that aspiration, though you're correct that we might want to reflect the stretchiness a bit as well.

-- 
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/2683#discussion_r283002776

---

From: Mike Bishop <[email-masked]>
Date: Fri, 10 May 2019 12:05:41 -0700

@MikeBishop pushed 1 commit.

7cbc837411f7021d932dd2502b70376b1bde7ef4  Apply suggestions from code review

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2683/files/996943e0f2f2a5dadeab071ad7357d5ef237a96f..7cbc837411f7021d932dd2502b70376b1bde7ef4

---

From: MikkelFJ <[email-masked]>
Date: Fri, 10 May 2019 13:37:29 -0700

I'm doing that, processing multiple requests concurrently on different backends and streaming the responses back in order.

-- 
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/2683#discussion_r283034796

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 10 May 2019 19:16:44 -0700

janaiyengar commented on this pull request.

a few comments

add a reference

+and DATA frames form the basis of HTTP requests and responses

maybe add a reference to streams section in draft-transport?

@mikkelfj : I suspect you're missing that comparison "of HTTP/3" is assumed (which is reasonable, IMO)

 --- back

How about "HTTP/3 departs from HTTP/2 where QUIC's behavior differences from TCP are either beneficial or need to be accommodated (absence of linear ordering, support for framing)."

-- 
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/2683#pullrequestreview-236357847

---

From: MikkelFJ <[email-masked]>
Date: Fri, 10 May 2019 23:18:44 -0700

Well, understand the text, but it reads as if was written immediately after the first paragraph and then a lot of text was thrown in, end then "that protocol" stands dangling becuse it might mean either HTTP/1.1 or QUIC until you realize it cannot mean QUIC since QUIC didn't exist when HTTP/2 was written. So I merely suggest typing out HTTP/1.1 explicitly.

Also, my feedback have come across a bit grumpy, that was not the intention. I really do appreciate the extra clarifying text on this topic.

-- 
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/2683#discussion_r283084296

---

From: MikkelFJ <[email-masked]>
Date: Fri, 10 May 2019 23:32:35 -0700

Actually I am missing that. I was assuming HTTP/1.1 but now it is HTTP/3. So yes, I think a clarification is needed.

-- 
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/2683#discussion_r283084670

---

From: Mike Bishop <[email-masked]>
Date: Mon, 13 May 2019 10:31:20 -0700

Doesn't exhausted flow control credits fall under "is blocked"?

-- 
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/2683#discussion_r283454700

---

From: Mike Bishop <[email-masked]>
Date: Mon, 13 May 2019 10:34:29 -0700

+
+connection:

That's a good suggestion, but I'm not sure I want to overload what is essentially a glossary with that.  I'll add that to the description of frames in general.

-- 
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/2683#discussion_r283455811

---

From: Mike Bishop <[email-masked]>
Date: Mon, 13 May 2019 10:39:39 -0700

@MikeBishop pushed 3 commits.

c64ff6f3aef0257a2664e1ee2ff6400d7b651fba  Present tense
c057bbd005f1c1b9fe81de87ac4b712524903231  Other review feedback
6bc32a1eba96c81c9ba9aeaed6f6efaa4412ef1c  Suggested frame clarification

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2683/files/7cbc837411f7021d932dd2502b70376b1bde7ef4..6bc32a1eba96c81c9ba9aeaed6f6efaa4412ef1c

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 May 2019 01:43:46 +0000 (UTC)

martinthomson commented on this pull request.

Generally pretty good.

> @@ -88,28 +88,101 @@ code and issues list for this draft can be found at
 
 HTTP semantics are used for a broad range of services on the Internet. These
 semantics have commonly been used with two different TCP mappings, HTTP/1.1 and
-HTTP/2.  HTTP/2 introduced a framing and multiplexing layer to improve latency
-without modifying the transport layer.  However, TCP's lack of visibility into
-parallel requests in both mappings limited the possible performance gains.
+HTTP/2.  HTTP/3 supports the same semantics over a new transport protocol, QUIC.
+
+## Prior versions of HTTP
+
+HTTP/1.1 is a TCP mapping which uses whitespace-delimited text fields to convey
+HTTP messages.  While these exchanges are human-readable, the whitespace leads

It isn't just the whitespace, but the use of whitespace for delineation makes some aspects of parsing and processing difficult.  You should be careful not to talk about shortcomings that this version doesn't address.

> @@ -88,28 +88,101 @@ code and issues list for this draft can be found at
 
 HTTP semantics are used for a broad range of services on the Internet. These
 semantics have commonly been used with two different TCP mappings, HTTP/1.1 and
-HTTP/2.  HTTP/2 introduced a framing and multiplexing layer to improve latency
-without modifying the transport layer.  However, TCP's lack of visibility into
-parallel requests in both mappings limited the possible performance gains.
+HTTP/2.  HTTP/3 supports the same semantics over a new transport protocol, QUIC.
+
+## Prior versions of HTTP
+
+HTTP/1.1 is a TCP mapping which uses whitespace-delimited text fields to convey
+HTTP messages.  While these exchanges are human-readable, the whitespace leads
+to parsing difficulties and workarounds to be tolerant of variant behavior.
+Because each connection can transfer only a single HTTP request or response at a
+time in each direction, multiple parallel TCP connections are used, reducing the

"are used" or "are often used"

> @@ -88,28 +88,101 @@ code and issues list for this draft can be found at
 
 HTTP semantics are used for a broad range of services on the Internet. These
 semantics have commonly been used with two different TCP mappings, HTTP/1.1 and
-HTTP/2.  HTTP/2 introduced a framing and multiplexing layer to improve latency
-without modifying the transport layer.  However, TCP's lack of visibility into
-parallel requests in both mappings limited the possible performance gains.
+HTTP/2.  HTTP/3 supports the same semantics over a new transport protocol, QUIC.
+
+## Prior versions of HTTP
+
+HTTP/1.1 is a TCP mapping which uses whitespace-delimited text fields to convey
+HTTP messages.  While these exchanges are human-readable, the whitespace leads
+to parsing difficulties and workarounds to be tolerant of variant behavior.
+Because each connection can transfer only a single HTTP request or response at a
+time in each direction, multiple parallel TCP connections are used, reducing the
+ability of the congestion controller to accurately manage traffic between
+endpoints.

Only because people haven't worked out how to run the same congestion controller for multiple connections.  I mean, there is no reason you can't do that... in theory.

-## Notational Conventions
+HTTP/3 provides a transport for HTTP semantics using the QUIC transport protocol
+and an internal framing layer similar to HTTP/2.
+
+An HTTP/3 endpoint can be discovered using HTTP Alternative Services; this
+process is described in greater detail in {{discovery}}.  Once a client knows
+that an HTTP/3 server exists at a certain endpoint, it opens a QUIC connection.
+QUIC provides protocol negotiation, stream-based multiplexing, and flow control.

I'd invert this paragraph.  The key points are in the second sentence.  The alternative services thing is really secondary here.

+endpoint:

Love the circular definition here.

 HTTP/3 is strongly informed by HTTP/2, and bears many similarities.  This
 section describes the approach taken to design HTTP/3, points out important
 differences from HTTP/2, and describes how to map HTTP/2 extensions into HTTP/3.
 
 HTTP/3 begins from the premise that similarity to HTTP/2 is preferable, but not
-a hard requirement.  HTTP/3 departs from HTTP/2 primarily where necessary to
-accommodate the differences in behavior between QUIC and TCP (lack of ordering,
-support for streams).  We intend to avoid gratuitous changes which make it
-difficult or impossible to build extensions with the same semantics applicable
-to both protocols at once.
+a hard requirement.  HTTP/3 departs from HTTP/2 where QUIC's behavior
+differences from TCP (lack of ordering, support for streams) are either

```suggestion
where QUIC differs from TCP, either to take advantage of QUIC features (like streams) or to accommodate important shortcomings (such as a lack of total ordering).
```

 HTTP/3 is strongly informed by HTTP/2, and bears many similarities.  This
 section describes the approach taken to design HTTP/3, points out important
 differences from HTTP/2, and describes how to map HTTP/2 extensions into HTTP/3.
 
 HTTP/3 begins from the premise that similarity to HTTP/2 is preferable, but not
-a hard requirement.  HTTP/3 departs from HTTP/2 primarily where necessary to
-accommodate the differences in behavior between QUIC and TCP (lack of ordering,
-support for streams).  We intend to avoid gratuitous changes which make it
-difficult or impossible to build extensions with the same semantics applicable
-to both protocols at once.
+a hard requirement.  HTTP/3 departs from HTTP/2 where QUIC's behavior
+differences from TCP (lack of ordering, support for streams) are either
+beneficial or need to be accommodated.  HTTP/3 attempts to avoid gratuitous
+changes which make it difficult or impossible to build extensions with the same
+semantics applicable to both protocols at once.

I think that we can lose this sentence now.  It might be time to face up to reality:

> These differences make HTTP/3 similar to HTTP/2 in key aspects, such as the relationship of requests and responses to streams.  However, the details of the HTTP/3 design are substantially different than HTTP/2.

-- 
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/2683#pullrequestreview-236990732

---

From: MikkelFJ <[email-masked]>
Date: Tue, 14 May 2019 01:32:55 -0700

Agree with @martinthomson 
Technically, whitespace is very easy to parse, and can be more efficient than variable length encoded frames. The real problem is the vague definition of what constitutes whitespace, when and where to expect it, and the different kinds of whitespace in existence. JSON has no such issues with whitespace.

-- 
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/2683#discussion_r283683805

---

From: Mike Bishop <[email-masked]>
Date: Tue, 14 May 2019 09:46:28 -0700

+endpoint:

Everyone loves [their own baby](https://tools.ietf.org/html/rfc7540#section-2.2). 😉

-- 
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/2683#discussion_r283897934

---

From: Mike Bishop <[email-masked]>
Date: Tue, 14 May 2019 09:50:34 -0700

I heard that proposal again in Prague, as a matter of fact.  I wish them all success.

-- 
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/2683#discussion_r283899482

---

From: Mike Bishop <[email-masked]>
Date: Tue, 14 May 2019 16:54:05 +0000 (UTC)

d0965b34e854d2c21b68265eadd4314c775c254f  Suggestions from review

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2683/files/6bc32a1eba96c81c9ba9aeaed6f6efaa4412ef1c..d0965b34e854d2c21b68265eadd4314c775c254f

---

From: Mike Bishop <[email-masked]>
Date: Tue, 14 May 2019 09:59:19 -0700

4f75917af7d9c4f6b4a758abcd0224832f8c4439  Americanise ;-)

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2683/files/d0965b34e854d2c21b68265eadd4314c775c254f..4f75917af7d9c4f6b4a758abcd0224832f8c4439

---

From: Mike Bishop <[email-masked]>
Date: Tue, 14 May 2019 10:20:33 -0700

I'd prefer to handle that separately, since that's distinct from what I'm doing here and potentially sizable.  I've opened #2698 with a first pass at that change.

-- 
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/2683#discussion_r283911869

---

From: Mike Bishop <[email-masked]>
Date: Wed, 15 May 2019 16:56:27 +0000 (UTC)

Merged #2683 into master.

-- 
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/2683#event-2343969470