Robert Wilton's No Objection on draft-ietf-quic-http-33: (with COMMENT)

[Robert Wilton via Datatracker <[e-mail]>]

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?

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.

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

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.

Thanks,
Rob