Hi Éric,

Thanks for the review. I've created a GitHub issue to track each comment on
the QUIC WG respository, see the URL in line.

On Tue, Jan 19, 2021 at 1:54 PM Éric Vyncke via Datatracker <
[email protected]> wrote:

> Éric Vyncke 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:
> ----------------------------------------------------------------------
>
> Thank you for the work put into this document.
>
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated), and two nits.
>
> I hope that this helps to improve the document,
>
> Regards,
>
> -éric
>
> == COMMENTS ==
>
> For many comments, please bear with my lack of expertise in HTTP in
> general.
>
> -- Section 1.1 --
> This section mixes "HTTP/1.1" and "HTTP/1.x" and it is unclear to me what
> the
> link is between the first 2 sentences.
>

https://github.com/quicwg/base-drafts/issues/4751


> -- Section 3.1 --
> In "clients SHOULD attempt to use TCP-based versions of HTTP in this case."
> Should the version(s) of HTTP be specified or is it done on purpose to
> allow a
> HTTP/4 over TCP (if ever) ?
>

https://github.com/quicwg/base-drafts/issues/4752


> -- Section 4.2 --
> Should this section mention the work in MASQUE? While I am not really
> familiar
> with MASQUE, isn't it using the CONNECT H/2 method (e.g.,
> draft-ietf-masque-connect-udp albeit for UDP) ?
>
>
https://github.com/quicwg/base-drafts/issues/4753

-- Section 4.4 --
> Should the client behavior be specified when server does not respect "A
> server
> SHOULD use Push IDs sequentially, beginning from zero. " ?
>
>
https://github.com/quicwg/base-drafts/issues/4754


-- Section 5.3 --
> Should the CONNECT method behavior be specified when the client does an
> immediate closure?
>

https://github.com/quicwg/base-drafts/issues/4755


> -- Section 5.4 --
> Should the server behavior be specified when the QUIC transport aborts ?
> It is
> mostly obvious that all states will be cleared but what about the CONNECT
> method ?
>

https://github.com/quicwg/base-drafts/issues/4756


> -- Section 11.2.1 and others --
> I must admit that the purpose of the special "0x1f * N + 0x21" values are
> unknown to me (or is it only for application padding as described in the
> security section?) but shouldn't they be reserved in the IANA registry?
>

https://github.com/quicwg/base-drafts/issues/4757


> == NITS ==
>
> -- Section 1 --
> " These semantics have most commonly been used with
>    HTTP/1.1, over a variety of transport and session layers, and with
>    HTTP/2 over TLS. "
>
> The asymmetric use of comas is puzzling, should there be a coma after
> "HTTP/2" ?
>

https://github.com/quicwg/base-drafts/issues/4758


> -- Section 11.2 --
> Should "and a contact of the HTTP working group ([email protected])."
> rather
> be "and a contact of the W3C HTTP working group ([email protected])." ?
>

https://github.com/quicwg/base-drafts/issues/4759

Cheers
Lucas
On behalf of QUIC WG Chairs

Reply via email to