Merge pull request #4992 from quicwg/h3qp/final

Final fixes

rfc9114.md

@@ -2,7 +2,7 @@
 title: HTTP/3
 number: 9114
 docname: draft-ietf-quic-http-latest
-date: {DATE}
+date: 2022-05
 category: std
 ipr: trust200902
 area: Transport
@@ -638,7 +638,7 @@ frames but is invalid due to:
 - the inclusion of invalid characters in field names or values.
 
 A request or response that is defined as having content when it contains a
-Content-Length header field ({{Section 6.4.1 of RFC9110}}) is malformed if the
+Content-Length header field ({{Section 8.6 of RFC9110}}) is malformed if the
 value of the Content-Length header field does not equal the sum of the DATA
 frame lengths received. A response that is defined as never having content, even
 when a Content-Length is present, can have a non-zero Content-Length header
@@ -771,7 +771,7 @@ The following pseudo-header fields are defined for requests:
 
   : To ensure that the HTTP/1.1 request line can be reproduced accurately, this
     pseudo-header field MUST be omitted when translating from an HTTP/1.1
-    request that has a request target in origin or asterisk form; see {{Section
+    request that has a request target in a method-specific form; see {{Section
     7.1 of RFC9110}}.  Clients that generate HTTP/3 requests directly SHOULD use
     the :authority pseudo-header field instead of the Host header field. An
     intermediary that converts an HTTP/3 request to HTTP/1.1 MUST create a Host
@@ -982,7 +982,7 @@ indicates that it will be discarded upon receipt.
 Pushed responses that are cacheable (see {{Section 3 of RFC9111}}) 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; see {{Section 5.2.2.3 of RFC9111}}) at the
+cache response directive is present; see {{Section 5.2.2.4 of RFC9111}}) at the
 time the pushed response is received.
 
 Pushed responses that are not cacheable MUST NOT be stored by any HTTP cache.

rfc9204.md

@@ -3,7 +3,7 @@ title: "QPACK: Field Compression for HTTP/3"
 abbrev: QPACK
 number: 9204
 docname: draft-ietf-quic-qpack-latest
-date: {DATE}
+date: 2022-05
 category: std
 ipr: trust200902
 area: Transport
@@ -40,23 +40,66 @@ author:
 
 normative:
 
-  HTTP3:
+  RFC9114:
+    display: HTTP/3
     title: "Hypertext Transfer Protocol Version 3 (HTTP/3)"
-    date: {DATE}
+    date: 1970-01-01
     seriesinfo:
-      Internet-Draft: draft-ietf-quic-http-latest
+      RFC: 9114
+      DOI: 10.17487/RFC9114
     author:
       -
           ins: M. Bishop
           name: Mike Bishop
           org: Akamai Technologies
           role: editor
 
-  SEMANTICS: I-D.ietf-httpbis-semantics
+  RFC9110:
+    display: HTTP
+    title: "HTTP Semantics"
+    date: 1970-01-01
+    seriesinfo:
+      RFC: 9110
+      DOI: 10.17487/RFC9110
+    author:
+      -
+          ins: R. Fielding
+          name: Roy T. Fielding
+          org: Adobe
+          role: editor
+      -
+          ins: M. Nottingham
+          name: Mark Nottingham
+          org: Fastly
+          role: editor
+      -
+          ins: J. Reschke
+          name: Julian Reschke
+          org: greenbytes
+          role: editor
   RFC2360:
 
 informative:
 
+  RFC9113:
+    display: HTTP/2
+    title: "HTTP/2"
+    date: 1970-01-01
+    seriesinfo:
+      RFC: 9113
+      DOI: 10.17487/RFC9113
+    author:
+      -
+          ins: M. Thomson
+          name: Martin Thomson
+          org: Mozilla
+          role: editor
+      -
+          ins: C. Benfield
+          name: Cory Benfield
+          org: Apple Inc.
+          role: editor
+
   CRIME:
     target: http://en.wikipedia.org/w/index.php?title=CRIME&oldid=660948120
     title: "CRIME"
@@ -93,8 +136,8 @@ HPACK compression that seeks to reduce head-of-line blocking.
 
 The QUIC transport protocol ({{!QUIC-TRANSPORT=RFC9000}}) is designed to support
 HTTP semantics, and its design subsumes many of the features of HTTP/2
-({{?RFC7540}}). HTTP/2 uses HPACK ({{!RFC7541}}) for compression of the header
-and trailer sections.  If HPACK were used for HTTP/3 ({{HTTP3}}), it would
+({{?RFC9113}}). HTTP/2 uses HPACK ({{!RFC7541}}) for compression of the header
+and trailer sections.  If HPACK were used for HTTP/3 ({{RFC9114}}), it would
 induce head-of-line blocking for field sections due to built-in assumptions of a
 total ordering across frames on all streams.
 
@@ -123,7 +166,7 @@ HTTP fields:
 HTTP field line:
 
 : A name-value pair sent as part of an HTTP field section. See {{Sections 6.3
-  and 6.5 of SEMANTICS}}.
+  and 6.5 of RFC9110}}.
 
 HTTP field value:
 
@@ -1420,14 +1463,14 @@ or decoder stream.
 # IANA Considerations
 
 This document makes multiple registrations in the registries defined by
-{{HTTP3}}. The allocations created by this document are all assigned permanent
+{{RFC9114}}. The allocations created by this document are all assigned permanent
 status and list a change controller of the IETF and a contact of the HTTP
 working group (ietf-http-wg@w3.org).
 
 ## Settings Registration
 
 This document specifies two settings. The entries in the following table are
-registered in the "HTTP/3 Settings" registry established in {{HTTP3}}.
+registered in the "HTTP/3 Settings" registry established in {{RFC9114}}.
 
 |------------------------------|--------|---------------------------| ------- |
 | Setting Name                 |  Code  | Specification             | Default |
@@ -1443,7 +1486,7 @@ For formatting reasons, the setting names here are abbreviated by removing the
 ## Stream Type Registration
 
 This document specifies two stream types. The entries in the following table are
-registered in the "HTTP/3 Stream Types" registry established in {{HTTP3}}.
+registered in the "HTTP/3 Stream Types" registry established in {{RFC9114}}.
 
 | ---------------------------- | ------ | ------------------------- | ------ |
 | Stream Type                  |  Code  | Specification             | Sender |
@@ -1456,7 +1499,7 @@ registered in the "HTTP/3 Stream Types" registry established in {{HTTP3}}.
 ## Error Code Registration
 
 This document specifies three error codes. The entries in the following table
-are registered in the "HTTP/3 Error Codes" registry established in {{HTTP3}}.
+are registered in the "HTTP/3 Error Codes" registry established in {{RFC9114}}.
 
 | --------------------------------- | ------ | ---------------------------------------- | ---------------------- |
 | Name                              | Code   | Description                              | Specification          |