Re: Comments on Extensible Prioritization Scheme for HTTP

Hi Glenn,

Response inline

On Thu, Mar 31, 2022 at 2:46 PM Glenn Strauss <
gs-lists-ietf-http-wg@gluelogic.com> wrote:

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

That depends on the case. For instance, extension frames can be sent
without any need of negotiation and we formally have ALTSVC (RFC 7838) and
ORIGIN (RFC 8336) that do it that way. Examples where settings have been
used are strictly where the HTTP/2 or HTTP/3 semantics have been changed,
such as extended CONNECT (RFC 8441), or the pending HTTP/3 DATAGRAM
setting, or WebTransport extensions to HTTP/2 and HTTP/3. All of these are
quite different in their needs, the advice in
https://httpwg.org/http2-spec/draft-ietf-httpbis-http2bis.html#section-5.5
holds but there are no clear patterns in my opinion.


> 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 don't see the relevance between telnet and HTTP/2 or HTTP/3.


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

We've been over this through the standardization process. There wasn't an
appetite to attempt to define a rich negotiation process for a
prioritization scheme. Instead, an HTTP/2 server that send
SETTINGS_NO_RFC7540_PRIORITIES=1 is most likely going to support Extensible
Priorities because there is nothing else. If at some future point somebody
decides they need a different priority scheme, they will probably have to
do work to figure out how it gets used. We don't need to spend effort today
trying to solve a problem that might never exist.

Cheers,
Lucas