Re: [quicwg/base-drafts] Easy RFC Editor Questions (PR #4954)

[Mike Bishop <[e-mail]>]

@MikeBishop commented on this pull request.

Including the actual AUTH48 questions this addresses.

> @@ -1,6 +1,5 @@
 ---
-title: Hypertext Transfer Protocol Version 3 (HTTP/3)
-abbrev: HTTP/3
+title: HTTP/3

See #4944.

> @@ -606,7 +605,7 @@ The following pseudo-header fields are defined for requests:
     {{Section 7.1 of SEMANTICS}}.
 
 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
+and ":path" pseudo-header fields, unless the request is a CONNECT request; see

RFC Editor asked:
>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.


> +Implementations SHOULD cancel requests by abruptly terminating any directions of
+a stream that are still open.  To do so, an implementation resets the sending
+parts of streams and aborts reading on the receiving parts of streams; see
+{{Section 2.4 of QUIC-TRANSPORT}}.

RFC Editor asked:
> This text is a bit tricky to read with all the -ing endings.  Is there a way to rephrase?

> +receiver, or bidirectional, carrying data in both directions.  Streams can be
+initiated by either the client or the server.  For more detail on QUIC streams,
+see {{Section 2 of QUIC-TRANSPORT}}.

RFC Editor asked:
> 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?

I opted to parallelize, since I don't see the initiator-to-receiver direction stated elsewhere, but I'm also happy to shorten the text if it's adequately covered elsewhere.

> +to use.
+
+Each endpoint needs to create at least one unidirectional stream for the HTTP
+control stream. QPACK requires two additional unidirectional streams, and other
+extensions might require further streams. Therefore, the transport parameters
+sent by both clients and servers MUST allow the peer to create at least three
+unidirectional streams. These transport parameters SHOULD also provide at least
+1,024 bytes of flow control credit to each unidirectional stream.

RFC Editor asked:

> 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.

> +For fomatting reasons, setting names can be abbreviated by removing the
+'SETTING_' prefix.
+

RFC Editor asked:
> 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 registered as "SETTINGS_MAX_FIELD_SECTION_SIZE"?  
> See https://www.iana.org/assignments/http3-parameters
> 
> Should a similar note be included in the IANA text as well? 

On re-reading, this may suggest the IANA page itself should be corrected to include SETTINGS_

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

RFC Editor asked:
> We believe "original authors of this specification" refers to the authors of draft-shade-quic-http2-mapping; may we clarify that here?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4954#pullrequestreview-882042640
You are receiving this because you are subscribed to this thread.

Message ID: <quicwg/base-drafts/pull/4954/review/[e-mail]>