Hi Rob, Thanks for the review. I've created GitHub issue(s) to track each comment on the QUIC WG repository, see the URL(s) in line.
On Thu, Jan 21, 2021 at 1:24 PM Robert Wilton via Datatracker < [email protected]> wrote: > Robert Wilton has entered the following ballot position for > draft-ietf-quic-http-33: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-quic-http/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Another well written document coming out of the QUIC WG, thank you for > that. > > Some minor comments: > > 4.1.1. Field Formatting and Compression > > As in previous versions of HTTP, field names are strings containing a > subset of ASCII characters that are compared in a case-insensitive > fashion. Properties of HTTP field names and values are discussed in > more detail in Section 5.1 of [SEMANTICS]. As in HTTP/2, characters > in field names MUST be converted to lowercase prior to their > encoding. A request or response containing uppercase characters in > field names MUST be treated as malformed (Section 4.1.3). > > Why make the comparison case-insensitive given that the request MUST only > use > lowercase characters? Presumably implementations will just do a regular > case > sensitive comparison? > https://github.com/quicwg/base-drafts/issues/4804 > 4.1.1.2. Field Compression > > Given that section 4.1.1.1. states that "Pseudo-header fields are not HTTP > fields.", it might be helpful to be explicit that pseudo-header fields are > also > compressed using QPACK. > https://github.com/quicwg/base-drafts/issues/4805 > 6.1. Bidirectional Streams > > So as to not unnecessarily limit > parallelism, at least 100 requests SHOULD be permitted at a time. > > Given that this section is about streams, perhaps better if the limit is > stated > in terms of streams, e.g., perhaps change "requests" to "request streams". > https://github.com/quicwg/base-drafts/issues/4806 > 10.6. Use of Compression > > Implementations communicating on a secure channel MUST NOT compress > content that includes both confidential and attacker-controlled data > unless separate compression contexts are used for each source of > data. Compression MUST NOT be used if the source of data cannot be > reliably determined. > > This wasn't entirely clear to me. I presume (perhaps wrongly) that the > issue > is about the use of compression before the confidential data has been > encrypted. I.e., I would presume that compressing a stream of data that > includes both encrypted and non encrypted data is okay? Perhaps this > could be > clarified. > https://github.com/quicwg/base-drafts/issues/4807 Cheers Lucas On behalf of QUIC WG Chairs
