Re: Comments on Extensible Prioritization Scheme for HTTP

[Glenn Strauss <[e-mail]>]

On Thu, Mar 31, 2022 at 01:06:45PM +0100, Lucas Pardue wrote:
> It's noble to want a pattern but I don't think we have enough examples of
> HTTP/2 extensions at the IETF to form consensus on one.

My understanding is that communicating/negotiating feature support
is among the raison d'être of HTTP/2 SETTINGS.

Communicating and negotiating features is not new.  For example, the
*1977* RFC 731 for telnet has IAC WILL/IAC WONT and IAC DO/IAC DONT.

I believe that draft-ietf-httpbis-priority for PRIORITY_UPDATE has
serious omissions in this regard -- communicating and negotiating
use of the optional feature -- especially since the draft recognizes
limitations of PRIORITY and proposes an alternative to provide
substantially overlapping functionality.  For example:

https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-priority-12#section-2.1.1
makes an assumption which I find incorrect.

   Similarly, if the client receives SETTINGS_NO_RFC7540_PRIORITIES with
   value of 0 or if the settings parameter was absent, it SHOULD stop
   sending PRIORITY_UPDATE frames (Section 7.1), since those frames are
   likely to be ignored.

My server (lighttpd) parses and discards PRIORITY frames, but I am
planning on implementing the coarser, but simpler, PRIORITY_UPDATE,
as well as supporting the proposed HTTP request header Priority.
draft-ietf-httpbis-priority does not currently provide a clean way
to communicate server HTTP/2 support preference for PRIORITY_UPDATE, 
but not PRIORITY, to the client.  Using HTTP/2 SETTINGS appears to
me to be a simple and an appropriate place to communicate this.

Cheers, Glenn