Subject: [quicwg/base-drafts] http-core and Friends (#3513)

From: Mike Bishop <[email-masked]>
Date: Wed, 11 Mar 2020 12:39:10 -0700

- Fixes #1523 by migrating all RFC723X references to http-core drafts
- Fixes #3452 by changing all HTTP references to &quot;HTTP (header) fields&quot;; core editors especially, please double-check my use of the new terminology
    - I have *not* attempted to make corresponding changes to QPACK; @afrind, I can do that in a future PR if you don&#39;t get to it first.
- Precursor to fixing #253 and #2223, since they depend on text in http-core
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Import most H2 references
  * Review feedback
  * Ian&#39;s feedback
  * Request staying open isn&#39;t normative
  * Point to HTTP core; updated field names

-- File Changes --

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

-- Patch Links --

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

---

From: Mike Bishop <[email-masked]>
Date: Wed, 11 Mar 2020 12:45:09 -0700

Note that my intention in this PR is to keep the references to HTTP/1.1 (draft-ietf-httpbis-messaging) informative-only, though some of those references flirt with the boundary of normative a little too closely.  I've filed a few http-core issues where something that's used cross-version is found in the 1.1 draft.

-- 
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/3513#issuecomment-597831994

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Mar 2020 15:44:40 -0700

martinthomson approved this pull request.

FIELDS!

> @@ -86,25 +86,28 @@ code and issues list for this draft can be found at
 
 # Introduction
 
-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/3 supports the same semantics over a new transport protocol, QUIC.
+HTTP semantics {{!Semantics=I-D.ietf-httpbis-semantics}} are used for a broad

```suggestion
HTTP semantics {{!SEMANTICS=I-D.ietf-httpbis-semantics}} are used for a broad
```
All caps is, I think that is conventional.

> @@ -820,11 +820,12 @@ CANCEL_PUSH frame, the client can abort reading the stream with an error code of
 H3_REQUEST_CANCELLED. This asks the server not to transfer additional data and
 indicates that it will be discarded upon receipt.
 
-Pushed responses that are cacheable (see Section 3 of {{!RFC7234}}) can be
-stored by the client, if it implements an HTTP cache.  Pushed responses are
-considered successfully validated on the origin server (e.g., if the "no-cache"
-cache response directive is present (Section 5.2.2 of {{!RFC7234}})) at the time
-the pushed response is received.
+Pushed responses that are cacheable (see Section 3 of
+{{!Caching=I-D.ietf-httpbis-cache}}) can be stored by the client, if it

```suggestion
{{!CACHING=I-D.ietf-httpbis-cache}}) can be stored by the client, if it
```

-- 
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/3513#pullrequestreview-373173645

---

From: Mike Bishop <[email-masked]>
Date: Wed, 11 Mar 2020 17:36:10 -0700

@MikeBishop pushed 1 commit.

52c97221047bc8cb48f9cbecdd982754c87e955d  Capital!

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3513/files/de1c40d329d57bd8baef7ff6966a4a13daeb60b8..52c97221047bc8cb48f9cbecdd982754c87e955d

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 11 Mar 2020 19:12:41 -0700

LPardue commented on this pull request.

-#### Pseudo-Header Fields
+#### Pseudo-Fields

Do we need to make this change? The requirement is that they MUST NOT appear in trailers

-To allow for better compression efficiency, the cookie header field {{!RFC6265}}
-MAY be split into separate header fields, each with one or more cookie-pairs,
-before compression. If a decompressed header list contains multiple cookie
+To allow for better compression efficiency, the "Cookie" field {{!RFC6265}}
+MAY be split into separate field lines, each with one or more cookie-pairs,
+before compression. If a decompressed field list contains multiple cookie
 header fields, these MUST be concatenated into a single octet string using the

```suggestion
fields, these MUST be concatenated into a single octet string using the
```

> @@ -1193,8 +1194,8 @@ connection error ({{errors}}) of type H3_FRAME_UNEXPECTED.
 
 ### HEADERS {#frame-headers}
 
-The HEADERS frame (type=0x1) is used to carry a header block, compressed using
-QPACK. See [QPACK] for more details.
+The HEADERS frame (type=0x1) is used to carry a block of HTTP fields, compressed
+using QPACK. See [QPACK] for more details.
 
 ~~~~~~~~~~  drawing
  0                   1                   2                   3

the diagram still contains "Header Block"

> @@ -1387,7 +1388,7 @@ error of type H3_SETTINGS_ERROR.
 ### PUSH_PROMISE {#frame-push-promise}
 
 The PUSH_PROMISE frame (type=0x5) is used to carry a promised request header
-set from server to client on a request stream, as in HTTP/2.
+field set from server to client on a request stream, as in HTTP/2.
 
 ~~~~~~~~~~  drawing
  0                   1                   2                   3

the diagram still contains "Header Block"

-- 
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/3513#pullrequestreview-373234297

---

From: Mike Bishop <[email-masked]>
Date: Thu, 12 Mar 2020 16:29:00 -0700

MikeBishop commented on this pull request.

"Pseudo-header fields" is an odd term no matter how you slice it, unless you say that the beginning of the header part is the "pseudo-header" and these are the fields that occur there.  I'd be open to defining that term, I suppose.

-- 
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/3513#discussion_r391957273

---

From: Mike Bishop <[email-masked]>
Date: Thu, 12 Mar 2020 16:29:29 -0700

Should be "field lines," actually.  Good catch!

-- 
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/3513#discussion_r391957407

---

From: Mike Bishop <[email-masked]>
Date: Thu, 12 Mar 2020 16:33:49 -0700

b47a75fec0c4e093292b70063f1ee8496ffc7c3b  Lucas' feedback

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3513/files/52c97221047bc8cb48f9cbecdd982754c87e955d..b47a75fec0c4e093292b70063f1ee8496ffc7c3b

---

From: Mike Bishop <[email-masked]>
Date: Thu, 12 Mar 2020 16:37:25 -0700

53184c8817c3973cff77b12537f05b7d1435dc42  Interim

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3513/files/b47a75fec0c4e093292b70063f1ee8496ffc7c3b..53184c8817c3973cff77b12537f05b7d1435dc42

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 12 Mar 2020 16:59:04 -0700

mnot requested changes on this pull request.

I've reviewed the diffs, not the changes in situ.

>  Because HPACK {{?HPACK=RFC7541}} relies on in-order transmission of compressed
-header blocks (a guarantee not provided by QUIC), HTTP/3 replaces HPACK with
+field blocks (a guarantee not provided by QUIC), HTTP/3 replaces HPACK with

"field sections" is the term of art - see https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#header.fields
```suggestion
field sections (a guarantee not provided by QUIC), HTTP/3 replaces HPACK with
```

 ## Discovering an HTTP/3 Endpoint {#discovery}
 
 An HTTP origin advertises the availability of an equivalent HTTP/3 endpoint via
-the Alt-Svc HTTP response header field or the HTTP/2 ALTSVC frame
+the Alt-Svc HTTP response field or the HTTP/2 ALTSVC frame

AIUI Alt-Svc is a header field, so this is fine either way.

-Just as in previous versions of HTTP, header field names are strings of ASCII
+Just as in previous versions of HTTP, field names are strings of ASCII

Hm. It's not _all_ ASCII characters.

>  characters that are compared in a case-insensitive fashion.  Properties of HTTP
-header field names and values are discussed in more detail in Section 3.2 of
-{{!RFC7230}}, though the wire rendering in HTTP/3 differs.  As in HTTP/2, header
-field names MUST be converted to lowercase prior to their encoding.  A request
-or response containing uppercase header field names MUST be treated as
-malformed ({{malformed}}).
+field names and values are discussed in more detail in Section 4.3 of
+{{!SEMANTICS}}.  As in HTTP/2, field names MUST be converted to lowercase prior
+to their encoding.  A request or response containing uppercase field names MUST

```suggestion
to their encoding.  A request or response containing uppercase characters in field names MUST
```

>  QPACK [QPACK].  QPACK uses separate unidirectional streams to modify and track
-header table state, while header blocks refer to the state of the table without
+field table state, while field blocks refer to the state of the table without

```suggestion
field table state, while field sections refer to the state of the table without
```

-Like HTTP/2, HTTP/3 does not use the Connection header field to indicate
-connection-specific header fields; in this protocol, connection-specific
-metadata is conveyed by other means.  An endpoint MUST NOT generate an HTTP/3
-message containing connection-specific header fields; any message containing
-connection-specific header fields MUST be treated as malformed ({{malformed}}).
+Like HTTP/2, HTTP/3 does not use the Connection field to indicate

Again, it's perfectly OK to call it a "header field" if it hasn't said it can be used in trailers.

-Like HTTP/2, HTTP/3 does not use the Connection header field to indicate
-connection-specific header fields; in this protocol, connection-specific
-metadata is conveyed by other means.  An endpoint MUST NOT generate an HTTP/3
-message containing connection-specific header fields; any message containing
-connection-specific header fields MUST be treated as malformed ({{malformed}}).
+Like HTTP/2, HTTP/3 does not use the Connection field to indicate
+connection-specific fields; in this protocol, connection-specific metadata is
+conveyed by other means.  An endpoint MUST NOT generate an HTTP/3 message

```suggestion
conveyed by other means.  An endpoint MUST NOT generate an HTTP/3 field section
```

There are not pseudo-trailer fields, and I fervently hope we won't be defining any. Let's just keep it as pseudo-header.

-To allow for better compression efficiency, the cookie header field {{!RFC6265}}
-MAY be split into separate header fields, each with one or more cookie-pairs,
-before compression. If a decompressed header list contains multiple cookie
-header fields, these MUST be concatenated into a single octet string using the
-two-octet delimiter of 0x3B, 0x20 (the ASCII string "; ") before being passed
-into a context other than HTTP/2 or HTTP/3, such as an HTTP/1.1 connection, or a
+To allow for better compression efficiency, the "Cookie" field {{!RFC6265}} MAY
+be split into separate field lines, each with one or more cookie-pairs, before
+compression. If a decompressed field list contains multiple cookie field lines,

```suggestion
compression. If a decompressed field section contains multiple cookie field lines,
```

 A request or response that includes a payload body can include a
-`content-length` header field.  A request or response is also malformed if the
-value of a content-length header field does not equal the sum of the DATA frame
-payload lengths that form the body.  A response that is defined to have no
-payload, as described in Section 3.3.2 of {{!RFC7230}} can have a non-zero
-content-length header field, even though no content is included in DATA frames.
+`content-length` field.  A request or response is also malformed if the value of

Again, C-L is very definitely a header field; it cannot appear in a trailer.

> @@ -809,7 +809,7 @@ using the same format described for responses in {{request-response}}.
 Due to reordering, push stream data can arrive before the corresponding
 PUSH_PROMISE frame.  When a client receives a new push stream with an
 as-yet-unknown Push ID, both the associated client request and the pushed
-request headers are unknown.  The client can buffer the stream data in
+request fields are unknown.  The client can buffer the stream data in

Can you push request trailers?

 ~~~~~~~~~~  drawing
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          Push ID (i)                        ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|                       Header Block (*)                      ...
+|                        Field Block (*)                      ...

See previous comments about Block v Section.

-- 
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/3513#pullrequestreview-373968241

---

From: Mike Bishop <[email-masked]>
Date: Fri, 13 Mar 2020 06:29:00 -0700

The problem is that "header blocks" was an HPACK term of art:  The sequence of compressed bytes containing the header set.  I think in this section we need to do QPACK first, then apply the appropriate terms to H3 once we've got them straight over there.

-- 
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/3513#discussion_r392226778

---

From: Mike Bishop <[email-masked]>
Date: Fri, 13 Mar 2020 06:31:48 -0700

Field names are defined to be `token`, which is `1*tchar`, which is "any visible US-ASCII character" "except delimiters."  Are there non-ASCII values in that?

-- 
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/3513#discussion_r392228256

---

From: Mike Bishop <[email-masked]>
Date: Fri, 13 Mar 2020 06:33:05 -0700

See QPACK comment above.

-- 
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/3513#discussion_r392228949

---

From: Mike Bishop <[email-masked]>
Date: Fri, 13 Mar 2020 08:20:57 -0700

76ca6d1a454dfc078130093c1ead0f6ce31210c8  Feedback from MNot

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3513/files/53184c8817c3973cff77b12537f05b7d1435dc42..76ca6d1a454dfc078130093c1ead0f6ce31210c8

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 15 Mar 2020 18:58:38 -0700

mnot commented on this pull request.

There is no concept of header (or trailer) blocks in QPACK -- it doesn't split things up into multiple frames like HPACK/H2 did. 

-- 
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/3513#discussion_r392751466

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 15 Mar 2020 18:59:37 -0700

_except delimiters_. This spec should either just refer to the authoritative definition (preferred), or accurately describe them.

-- 
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/3513#discussion_r392751619

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 15 Mar 2020 19:00:45 -0700

> @@ -809,7 +810,7 @@ using the same format described for responses in {{request-response}}.
 Due to reordering, push stream data can arrive before the corresponding
 PUSH_PROMISE frame.  When a client receives a new push stream with an
 as-yet-unknown Push ID, both the associated client request and the pushed
-request fields are unknown.  The client can buffer the stream data in
+request headerss are unknown.  The client can buffer the stream data in

```suggestion
request header fields are unknown.  The client can buffer the stream data in
```

-- 
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/3513#pullrequestreview-374875589

---

From: Mike Bishop <[email-masked]>
Date: Mon, 16 Mar 2020 17:52:59 -0700

Ah, I misunderstood the direction of your comment. I'll update in the morning. 

-- 
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/3513#discussion_r393388082

---

From: Mike Bishop <[email-masked]>
Date: Tue, 17 Mar 2020 15:02:18 -0700

86492704e648a8b4af7b5bd51144b7fd96b31b30  Not all

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3513/files/76ca6d1a454dfc078130093c1ead0f6ce31210c8..86492704e648a8b4af7b5bd51144b7fd96b31b30

---

From: Mike Bishop <[email-masked]>
Date: Tue, 17 Mar 2020 15:03:30 -0700

5db967cf8bd0ad69e09c31274cdb3fb2b5ea1b9b  MNot fix

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3513/files/86492704e648a8b4af7b5bd51144b7fd96b31b30..5db967cf8bd0ad69e09c31274cdb3fb2b5ea1b9b

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 17 Mar 2020 17:02:15 -0700

Looks good.

-- 
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/3513#discussion_r394038030

---

From: Julian Reschke <[email-masked]>
Date: Tue, 17 Mar 2020 23:05:28 -0700

reschke commented on this pull request.

I'm a bit concerned because in the core specs, sections *will* still move around, and in the MD format, you have no way to automatically adjust those...

-- 
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/3513#pullrequestreview-376584184

---

From: Mike Bishop <[email-masked]>
Date: Wed, 18 Mar 2020 08:10:29 -0700

Yes, I assume we'll need to do a pass once the docs are mostly-final to verify all the references, particularly to things that haven't hit RFC yet.  I don't feel like that would be substantially more work than re-doing this migration at some point in the future.

-- 
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/3513#issuecomment-600678253

---

From: Mike Bishop <[email-masked]>
Date: Wed, 18 Mar 2020 09:18:37 -0700

@MikeBishop pushed 7 commits.

b6fad5474e0da4ef5218fee2fc6c33a6891f2e17  Point to HTTP core; updated field names
262740da573633dfcd996b9fd46b7d8581afca5a  Capital!
a122994dc79066b82de18ae17f2b88cd599f70e0  Lucas' feedback
4d9a8fd692673ce15538ffbf1dcd46a394f55f81  Interim
16bf8bc3a60d1a9759d5daa38fa7cb0630c5dac6  Feedback from MNot
cff4cc5fe8a44e5ae439fee0123b35d322d3201b  Not all
54a60439a6148a5f32d9fe7a323dc74d8fdac626  MNot fix

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3513/files/5db967cf8bd0ad69e09c31274cdb3fb2b5ea1b9b..54a60439a6148a5f32d9fe7a323dc74d8fdac626

---

From: ianswett <[email-masked]>
Date: Sat, 21 Mar 2020 13:41:36 -0700

ianswett commented on this pull request.

 # Introduction
 
-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/3 supports the same semantics over a new transport protocol, QUIC.
+HTTP semantics {{!SEMANTICS=I-D.ietf-httpbis-semantics}} are used for a broad
+range of services on the Internet. These semantics have commonly been used with

```suggestion
range of services on the Internet. These semantics have most commonly been used with
```

> -HTTP messages.  While these exchanges are human-readable, using whitespace for
-message formatting 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 often used, reducing the ability of the congestion controller to
-accurately manage traffic between endpoints.
-
-HTTP/2 introduced a binary framing and multiplexing layer to improve latency
-without modifying the transport layer.  However, because the parallel nature of
-HTTP/2's multiplexing is not visible to TCP's loss recovery mechanisms, a lost
-or reordered packet causes all active transactions to experience a stall
-regardless of whether that transaction was impacted by the lost packet.
+HTTP/1.1 {{?HTTP11=I-D.ietf-httpbis-messaging}} is a TCP mapping which uses
+whitespace-delimited text fields to convey HTTP messages.  While these exchanges
+are human-readable, using whitespace for message formatting leads to parsing
+difficulties and workarounds to be tolerant of variant behavior. Because each

```suggestion
complexity and motivates tolerance of variant behavior. Because each
```

Motivates may not be the best word, but requires was my other suggestion, and that's not quite accurate.

> -request or response at a time in each direction, multiple parallel TCP
-connections are often used, reducing the ability of the congestion controller to
-accurately manage traffic between endpoints.
-
-HTTP/2 introduced a binary framing and multiplexing layer to improve latency
-without modifying the transport layer.  However, because the parallel nature of
-HTTP/2's multiplexing is not visible to TCP's loss recovery mechanisms, a lost
-or reordered packet causes all active transactions to experience a stall
-regardless of whether that transaction was impacted by the lost packet.
+HTTP/1.1 {{?HTTP11=I-D.ietf-httpbis-messaging}} is a TCP mapping which uses
+whitespace-delimited text fields to convey HTTP messages.  While these exchanges
+are human-readable, using whitespace for message formatting 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 often used, reducing the
+ability of the congestion controller to accurately manage traffic between

```suggestion
ability of the congestion controller to effectively manage traffic between
```

> -or reordered packet causes all active transactions to experience a stall
-regardless of whether that transaction was impacted by the lost packet.
+HTTP/1.1 {{?HTTP11=I-D.ietf-httpbis-messaging}} is a TCP mapping which uses
+whitespace-delimited text fields to convey HTTP messages.  While these exchanges
+are human-readable, using whitespace for message formatting 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 often used, reducing the
+ability of the congestion controller to accurately manage traffic between
+endpoints.
+
+HTTP/2 {{?HTTP2=RFC7540}} introduced a binary framing and multiplexing layer to
+improve latency without modifying the transport layer.  However, because the
+parallel nature of HTTP/2's multiplexing is not visible to TCP's loss recovery
+mechanisms, a lost or reordered packet causes all active transactions to
+experience a stall regardless of whether that transaction was impacted by the

```suggestion
experience a stall regardless of whether that transaction was directly impacted by the
```

-- 
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/3513#pullrequestreview-378949891

---

From: Mike Bishop <[email-masked]>
Date: Mon, 23 Mar 2020 08:22:42 -0700

e92c94feaf24f2e543517623213ea8506894c919  Remove field blocks

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3513/files/54a60439a6148a5f32d9fe7a323dc74d8fdac626..e92c94feaf24f2e543517623213ea8506894c919

---

From: Mike Bishop <[email-masked]>
Date: Mon, 23 Mar 2020 08:23:35 -0700

e92c94f matches the removal of "blocks" from #3520.

-- 
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/3513#discussion_r396533519

---

From: Mike Bishop <[email-masked]>
Date: Mon, 23 Mar 2020 08:26:23 -0700

b78ed816abdc3518a72ca148aca1a6c7ecb8fb98  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/3513/files/e92c94feaf24f2e543517623213ea8506894c919..b78ed816abdc3518a72ca148aca1a6c7ecb8fb98

---

From: Mike Bishop <[email-masked]>
Date: Mon, 23 Mar 2020 08:27:16 -0700

44565d422611c4998bb8b85b218598cc888c714f  Rewrap suggestions

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3513/files/b78ed816abdc3518a72ca148aca1a6c7ecb8fb98..44565d422611c4998bb8b85b218598cc888c714f

---

From: Bence Béky <[email-masked]>
Date: Thu, 26 Mar 2020 05:27:52 -0700

@bencebeky requested changes on this pull request.

LGTM modulo nits.

 #### Pseudo-Header Fields
 
-As in HTTP/2, HTTP/3 uses special pseudo-header fields beginning with the ':'
-character (ASCII 0x3a) to convey the target URI, the method of the request, and
-the status code for the response.
+As in HTTP/2, HTTP/3 uses a series of pseudo-header field lines beginning with

Why "field lines" not "fields"?  Focus is on semantics, not representation.

 #### Pseudo-Header Fields
 
-As in HTTP/2, HTTP/3 uses special pseudo-header fields beginning with the ':'
-character (ASCII 0x3a) to convey the target URI, the method of the request, and
-the status code for the response.
+As in HTTP/2, HTTP/3 uses a series of pseudo-header field lines beginning with
+the ':' character (ASCII 0x3a) to convey the target URI, the method of the

It is not the field lines or fields that being with the ':' character, but the field name.  Maybe "a series of pseudo-fields with field name beginning with the ':' character"?

>  pseudo-header fields other than those defined in this document, except as
 negotiated via an extension; see {{extensions}}.
 
-Pseudo-header fields are only valid in the context in which they are defined.
-Pseudo-header fields defined for requests MUST NOT appear in responses;
-pseudo-header fields defined for responses MUST NOT appear in requests.
-Pseudo-header fields MUST NOT appear in trailers.  Endpoints MUST treat a
-request or response that contains undefined or invalid pseudo-header fields as
-malformed ({{malformed}}).
+Pseudo-fields are only valid in the context in which they are defined.

"Pseudo-field" is used here without any introduction.  Another problem is that the punctuation in "pseudo-header field" is misleading: it is a header field that is pseudo, not a field that is pseudo-header.  "Pseudo header-field" would be more accurate, but clumsy.  I recommend removing "pseudo-header field" entirely and only using "pseudo-field".  Then first sentence of this section becomes "As in HTTP/2, HTTP/3 uses a series of pseudo-fields in the header field section".

 #### Pseudo-Header Fields
 
-As in HTTP/2, HTTP/3 uses special pseudo-header fields beginning with the ':'
-character (ASCII 0x3a) to convey the target URI, the method of the request, and
-the status code for the response.
+As in HTTP/2, HTTP/3 uses a series of pseudo-header field lines beginning with

"As in HTTP/2, HTTP/3 uses" does not make sense.  A subject is missing: who is using pseudo-headers in HTTP/2.  It would be better to write either "Like HTTP/2, HTTP/3 uses" or "As in HTTP/2, in HTTP/3 one uses".

>  promises. When the same Push ID is promised on multiple request streams, the
-decompressed request header sets MUST contain the same fields in the
+decompressed request field sets MUST contain the same fields in the

"field set" is not defined in SEMANTICS.  Maybe "field sections" would be more appropriate?

> @@ -1308,7 +1310,7 @@ peer combines the two sets to conclude which choice will be used.  SETTINGS does
 not provide a mechanism to identify when the choice takes effect.
 
 Different values for the same parameter can be advertised by each peer. For
-example, a client might be willing to consume a very large response header,
+example, a client might be willing to consume a very large response field set,

Maybe "field section" instead of "field set", because "field set" is not defined in SEMANTICS.

> @@ -1410,15 +1412,15 @@ error of type H3_SETTINGS_ERROR.

Maybe "field section" instead of "field set", because "field set" is not defined in SEMANTICS.

> @@ -1445,7 +1447,7 @@ order, and both the name and the value in each field MUST be exact
 matches. Clients SHOULD compare the request header sets for resources promised
 multiple times. If a client receives a Push ID that has already been promised
 and detects a mismatch, it MUST respond with a connection error of type
-H3_GENERAL_PROTOCOL_ERROR. If the decompressed header sets match exactly, the
+H3_GENERAL_PROTOCOL_ERROR. If the decompressed field sets match exactly, the

Maybe "field sections"?

-- 
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/3513#pullrequestreview-381108014

---

From: Mike Bishop <[email-masked]>
Date: Fri, 27 Mar 2020 11:32:07 -0700

@MikeBishop commented on this pull request.

That's what it was in an earlier version of this PR; the pushback was that these only occur in the header, not in trailers, so it's more precise to say header fields than simply fields.  I agree that "pseudo-header field" makes it sound like there's a region called the "pseudo-header," and there kind of is since these have to be first, but we don't call it that.

-- 
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/3513#discussion_r399463847

---

From: Mike Bishop <[email-masked]>
Date: Fri, 27 Mar 2020 11:35:33 -0700

4a8213bdab0c1d90cb0aa22e0c03066fa6014ef6  Bence's feedback

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3513/files/44565d422611c4998bb8b85b218598cc888c714f..4a8213bdab0c1d90cb0aa22e0c03066fa6014ef6

---

From: Mike Bishop <[email-masked]>
Date: Fri, 27 Mar 2020 11:37:38 -0700

Ah, the pedanticism warms the cockles of my cold, picky heart.  😉  Well caught!

-- 
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/3513#discussion_r399466793

---

From: Martin Thomson <[email-masked]>
Date: Fri, 27 Mar 2020 17:18:26 -0700

@martinthomson commented on this pull request.

@MikeBishop, you might want to consider seeing a physician about that.  Sounds serious.

-- 
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/3513#discussion_r399591621

---

From: Mike Bishop <[email-masked]>
Date: Mon, 30 Mar 2020 08:57:59 -0700

Landing now; any additional work can be in a follow-up PR.

-- 
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/3513#issuecomment-606086609

---

From: Mike Bishop <[email-masked]>
Date: Mon, 30 Mar 2020 08:58:09 -0700

Merged #3513 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/3513#event-3179332411