Re: SETTINGS_HTTP3_PRIORITY_MASK? | Re: SETTINGS_PRIORITY_SCHEME | Re: Setting to disable HTTP/2 Priorities

On Wed, 31 Jul 2019, 19:34 Kari Hurtta, <hurtta-ietf@elmme-mailer.org>
wrote:

>
> I perhaps interpret this incorrectly, but I try reword your design.
>
> So  HTTP/2 you have SETTINGS paramaters
>
>  • SETTINGS_PROVIDE_HTTP2_PRIORITIES (aka SETTINGS_ENABLE_HTTP2_PRIORITIES)
>  • SETTINGS_HTTP3_PRIORITY_MASK
>
> and on HTTP/3 you have on SETTINGS paramater
>
>  • SETTINGS_HTTP3_PRIORITY_MASK
>
>
> where SETTINGS_HTTP3_PRIORITY_MASK is enable mask (or bitmask) of
> HTTP/3 priority schemes which sender of SETTINGS frame support.
>
> Because SETTINGS_HTTP3_PRIORITY_MASK does not include bit for
> HTTP/2 tree priorites, HTTP/3 does not support them.
>
> Available HTTP/3 priority schemes is intersection (or "binary and")
> between sent and received SETTINGS_HTTP3_PRIORITY_MASK.
>
>
> Because HTTP/3 there is only one SETTINGS frame per direction,
> sending of SETTINGS_HTTP3_PRIORITY_MASK can not delayed until
> SETTINGS_HTTP3_PRIORITY_MASK received from peer is learned.
>
> Therefore SETTINGS frame can not used to indicate selected
> priority scheme (if there more than one priority scheme available).
>
>
> So I assume that HTTP/3 client indicates selected priority scheme
> by just using it.
>
> I my guess correct?
>
>
> ( If priority mask style desing is allowed to include bit
>   for HTTP/2 tree priorites, then SETTINGS_PROVIDE_HTTP2_PRIORITIES
>   and SETTINGS_HTTP3_PRIORITY_MASK SETTINGS parameters
>   collapse to one SETTINGS paramater:
>
>     SETTINGS_PRIORITY_MASK
>
> )
>
> / Kari Hurtta
>

When you put it like that, the MASK design has elegance in that it
specifies a signal mechanism for priority scheme selection. That has
attractive properties because it avoids each scheme having to define a
discovery mechanism.

Lucas

>