Re: [quicwg/base-drafts] Editorial nits for HTTP (#3942)

[Martin Thomson <[e-mail]>]

@martinthomson approved this pull request.

Nice.  A few suggestions, but these are mostly easy or obvious fixes.  Feel free to use follow-up issues for the trickier comments.

>    references the PUSH_PROMISE frame using a Push ID.  See
   {{frame-push-promise}}.
 
 PING (0x6):
-: PING frames do not exist, since QUIC provides equivalent functionality.
+: PING frames do not exist in HTTP/3, since QUIC provides equivalent

```suggestion
: PING frames do not exist in HTTP/3, as QUIC provides equivalent
```

> @@ -2406,7 +2416,7 @@ INADEQUATE_SECURITY (0xc):
 : Not applicable, since QUIC is assumed to provide sufficient security on all
   connections.
 
-H3_1_1_REQUIRED (0xd):
+HTTP_1_1_REQUIRED (0xd):

HTTP 3.1.1 for Workgroups, perhaps?

>  
 SETTINGS_INITIAL_WINDOW_SIZE:
 : QUIC requires both stream and connection flow control window sizes to be
-  specified in the initial transport handshake.  Specifying
-  SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame is an error.
+  specified in the initial transport handshake.  Specifying the
+  SETTINGS_INITIAL_WINDOW_SIZE parameter in the SETTINGS frame is an error.

Are we using "parameter" now?  I seem to recall that h2 uses "setting".  And SETTINGS_INITIAL_WINDOW_SIZE isn't a defined parameter, so you might want to say "Specifying a setting with an identifier of `<insert numeric value>` (the identifier for SETTINGS_INITIAL_WINDOW_SIZE in HTTP/2) must be treated as a connection error of type `<blah>`."

Same for the concurrent stream limit. 

> @@ -2246,7 +2254,7 @@ Because the Flags field is not present in generic HTTP/3 frames, those frames
 which depend on the presence of flags need to allocate space for flags as part
 of their frame payload.
 
-Other than this issue, frame type HTTP/2 extensions are typically portable to
+Other than these issue, frame type HTTP/2 extensions are typically portable to

```suggestion
Other than these issues, frame type HTTP/2 extensions are typically portable to
```

> +includes two additional fields. Permanent registrations in this registry SHOULD
+include the following field:

Are you worried about the greasing values with this?

> @@ -446,21 +450,24 @@ response following a final HTTP response MUST be treated as malformed
 
 An HTTP message (request or response) consists of:
 
-1. the header field section (see Section 5 of {{!SEMANTICS}}), sent as a single
-   HEADERS frame (see {{frame-headers}}),
+1. the header field section, sent as a single HEADERS frame (see
+   {{frame-headers}}),
+
+2. optionally, the payload body, if present, sent as a series of DATA frames
+   (see {{frame-data}}),

Is this a list?
```suggestion
   (see {{frame-data}}), and
```

-- 
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/3942#pullrequestreview-453830792