W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2021

Zaheduzzaman Sarker's No Objection on draft-ietf-httpbis-priority-11: (with COMMENT)

From: Zaheduzzaman Sarker via Datatracker <noreply@ietf.org>
Date: Tue, 14 Dec 2021 14:52:47 -0800
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-httpbis-priority@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, tpauly@apple.com, tpauly@apple.com
Message-ID: <163952236658.6440.4236013170821279459@ietfa.amsl.com>
Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-httpbis-priority-11: 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/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


Thanks for working on the HTTP priority. I hope to see this specification gets
deployed and we learn how to efficiently use priorities more.

I have two comments that might have been already thought about -

  - Section 12: I was wondering how much it would be different to have same
  considerations for TCP as we have for QUIC - specially for "Endpoints SHOULD
  prioritize retransmission of data over sending new data, unless priorities
  specified by the application indicate otherwise". Could this be a very
  transport agnostic behavior this specification can define?

  - Section 13.1 : it says  -

      "if a server knows the intermediary is coalescing requests, then it could
      avoid serving the responses in their entirety and instead distribute
      bandwidth (for example, in a round-robin manner)"

    It would be great if we can mention any known or standard way for the
    servers to know about the intermediary. If there is non or if the is not
    deterministic way for the server to learn about how the intermediary works
    then I would argue that Section 13.1 is an unnecessary details.
Received on Tuesday, 14 December 2021 22:53:02 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 14 December 2021 22:53:04 UTC