Authors,

While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.

1) <!-- [rfced] Is the intent for the title of this document to be formatted similarly to RFC 7540?  Or would it make sense for the title to match RFC-to-be 9112?  Please review and let us know if any updates are needed. 

RFC 7540: Hypertext Transfer Protocol Version 2 (HTTP/2)
RFC 9112: HTTP/1.1
This RFC: Hypertext Transfer Protocol Version 3 (HTTP/3)
-->


2) <!-- [rfced] Please insert any keywords (beyond those that appear in the
title) for use on https://www.rfc-editor.org/search. -->


3) <!--[rfced] Please review the number of times the document mentions
that HTTP/3 uses QUIC and is similar to HTTP/2.  This seems
somewhat redundant by Section 2.-->


4) <!--[rfced] We see that RFC-to-be 9114 (draft-ietf-quic-qpack) contains:

Original:
   QPACK is a name, not an acronym.

Should a similar comment be made about HPACK?
-->


5) <!-- [rfced] Because HTTP/3 requests is plural, may we update this as follows?

Original:
   All HTTP/3 requests MUST include exactly one value for the ":method",
   ":scheme", and ":path" pseudo-header fields, unless it is a CONNECT
   request; see Section 4.2.

Perhaps A:
   All HTTP/3 requests MUST include exactly one value for the ":method",  
   ":scheme", and ":path" pseudo-header fields, except for CONNECT  
   requests; see Section 4.2.  

Perhaps B:
   All HTTP/3 requests MUST include exactly one value for the ":method",  
   ":scheme", and ":path" pseudo-header fields, unless the request is a CONNECT  
   request; see Section 4.2.  
-->


6) <!--[rfced] This text is a bit tricky to read with all the -ing endings.  Is there a way to rephrase?

Original:
   This means resetting the
   sending parts of streams and aborting reading on receiving parts of
   streams; see Section 2.4 of [QUIC-TRANSPORT].


-->


7) <!--[rfced] Should this sentence be made parallel by explaining both unidirectional and bidirectional?  Or may we remove the explanatory clause as unidirectional is used several times prior to this occurrence?

Original:
   QUIC streams can be either unidirectional, carrying data only from
   initiator to receiver, or bidirectional.
-->


8) <!-- [rfced] Note that we updated instances of 'artwork type="drawing"' to type="ascii-art".  However, we wonder if any of these should be tagged as sourcecode instead.  Please review. 

Original (in the XML):
   <artwork type="drawing" name="" align="left" alt="">

See <https://authors.ietf.org/rfcxml-vocabulary#sourcecode> for more information about sourcecode. 
-->


9) <!--[rfced] Which of these interpretations is correct?  Also, note that this sentence is quite long and may benefit from further rephrasing to break it up.

Original:
To avoid blocking, the transport parameters sent
by both clients and servers MUST allow the peer to create at least
one unidirectional stream for the HTTP control stream plus the number
of unidirectional streams required by mandatory extensions (three
being the minimum number required for the base HTTP/3 protocol and
QPACK), and SHOULD provide at least 1,024 bytes of flow control
credit to each stream.

Perhaps A:
To avoid blocking, the transport parameters sent
by both clients and servers 1) MUST allow the peer to create at least
one unidirectional stream for the HTTP control stream plus the number
of unidirectional streams required by mandatory extensions (three
being the minimum number required for the base HTTP/3 protocol and
QPACK) and 2) SHOULD provide at least 1,024 bytes of flow-control
credit to each stream.

Perhaps B:
To avoid blocking, the transport parameters sent
by both clients and servers MUST allow the peer to create at least
one unidirectional stream for the HTTP control stream plus the number
of unidirectional streams required by mandatory extensions (three
being the minimum number required for the base HTTP/3 protocol and
QPACK), and the peer SHOULD provide at least 1,024 bytes of flow-control
credit to each stream.
-->


10) <!-- [rfced] When IANA notified us that the IANA actions were complete, they included the following: 

   NOTE: In the new registries, the padding has been adjusted for consistency from one 
   registry to another and with iana.org/assignments/quic. We understand that there may
   be a request to change it.

The padding for the HTTP/3 registries is now inconsistent with the padding for the HTTP/2 registries.  Please review and let us know if the padding is preferred or if we should ask IANA to remove the added padding. 
-->


11) <!-- [rfced] We note that RFC-to-be 9114 registers names in the HTTP/3 Settings registry that are preceded by "SETTINGS_".  They also include the following note in the IANA section: 

   For fomatting reasons, the setting names here are abbreviated by removing the 
   'SETTING_' prefix.

Should "MAX_FIELD_SECTION_SIZE" be "SETTINGS_MAX_FIELD_SECTION_SIZE"?  Should a similar note be included here a well? 
-->


12) <!-- [rfced] We believe "original authors of this specification" refers to the authors of draft-shade-quic-http2-mapping; may we clarify that here? 

Original:
   The original authors of this specification were Robbie Shade and Mike
   Warres.

Perhaps:
   Robbie Shade and Mike Warres were the authors of draft-shade-quic-http2-mapping, which was the basis for this document.  
-->


13) <!--[rfced] Throughout the text, we see repeated citations used each time a given term is mentioned.  

For example:

Original:
Endpoints MUST treat a request or response that contains
   undefined or invalid pseudo-header fields as malformed
   (Section 4.1.3).

[Then, only one sentence later..]

Any request or response that contains a
   pseudo-header field that appears in a header section after a regular
   header field MUST be treated as malformed (Section 4.1.3).

Please consider whether each citation is necessary or if the
repetition may begin to distract the reader.  Note - It may be easier
to update the XML file directly with these changes as you review than
communicate this via email.

-->


14) <!-- [rfced] Please review the following questions related to terminology:

a) Throughout the text, the following terminology appears to be used
inconsistently. Please review these occurrences and let us know if any
updates are necessary.

frame payload vs. Frame Payload

stream ID vs Stream ID
Note that the authors of RFC 9000 indicated "stream ID" is correct.  Should this document be updated to align with RFC 9000?  This document introduces "Push ID" - should "stream ID" and "push ID" have the same capitalizaton? 


b) Please review the way header field, field, and state names are treated.  Should any of these be updated for consistency?  

For example, we see:

Host field vs. "Host" header field

Content-Length header field

"Cookie" field vs. cookie field lines

"Data Recvd" state (init. caps and double quotes) vs. TIME_WAIT state (CAPS, underscore, no quotes)

c) Please review the way characters and ASCII equivalents are displayed with regard to quotation and whether the ASCII value is listed etc. and let us know if/how to update.


':' character (ASCII 0x3a)
"?" character
the value '*' 
0x3b, 0x20 (the ASCII string "; ") 
carriage return (CR, ASCII 0xd)
line feed (LF, ASCII 0xa)
zero character (NUL, ASCII 0x0


d) This document consistently uses key-value pairs.  RFC-to-be 9110 (draft-ietf-httpbis-semantics) uses the following:

key/value pairs (4 instances) / name/value pairs (1 instance) / name=value pairs (3 instances)

We have asked whether these should made consisent.  Do you want to be consistent RFC 9110 once the authors have resolved this question for RFC 9110?  
-->


15) <!-- [rfced] Please review the "Inclusive Language" portion of the online 
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. 

Note that there is an outstanding question about the use of "whitespace" in draft-ietf-httpbis-messaging.  We will let you know if they decide to make any updates so this document can be updated accordingly. 

Original: 
   HTTP/1.1 ([HTTP11]) uses whitespace-delimited text fields to convey
   HTTP messages.
-->


Thank you.

RFC Editor