Re: Repurpose of protocol elements | Re: Repurpose of priority | ⋯ | Re: Setting to disable HTTP/2 Priorities

[Lucas Pardue <[e-mail]>]

Hi Kari,

Thanks for sharing your thoughts on this thread (and also thanks to you and
Matthew Kerwin for sharing your thoughts on other threads).

To best track things, I plan to summarize some of the discussed options as
an issue on the I-D's repo. When I get around to that, I'll share the link
back to the list.

Cheers
Lucas

On Sat, Aug 3, 2019 at 9:07 AM Kari Hurtta <[e-mail]>
wrote:

> > Any client that is taking the chance to make a semantic change to the
> > frames it is sending would be foolish to not wait on an affirmative
> signal
> > from the server. RFC 7540 Section 5.5. calls specific attention to such a
> > repurposing:
> >
> > >    Extensions that could change the semantics of existing protocol
> >    components MUST be negotiated before being used.  For example, an
> >    extension that changes the layout of the HEADERS frame cannot be used
> >    until the peer has given a positive signal that this is acceptable.
> >
> > Lucas
>
> Okei,
>
> Generally repurpose of protocol element requires 3 values (or 2
> bits from bitmask) for SETTINGS parameter SETTINGS_ENABLE_{feature}.
> For example values
>
>  •  0       {feature}_NOT_SUPPORTED,
>  •  1       {feature}_AVAILABLE
>  •  3       SENDING_{feature}
>
>
> Recipient of repurposed protocol element sends first
> SETTINGS parameter SETTINGS_ENABLE_{feature} with value
> 1 ({feature}_AVAILABLE).
>
>
> Sender of repurposed protocol element sends SETTINGS parameter
> SETTINGS_ENABLE_{feature} with value 3 (SENDING_{feature})
> before it starts sending repurposed protocol element.
>
>
> Recipient interprets protocol element without {feature}
> until it receives SETTINGS parameter SETTINGS_ENABLE_{feature}
> with value 3 (SENDING_{feature}).
>
>
> Sending SETTINGS parameter SETTINGS_ENABLE_{feature} with
> value 3 (SENDING_{feature}) is protocol violation unless
> SETTINGS parameter SETTINGS_ENABLE_{feature} with value
> 1 ({feature}_AVAILABLE) or 3 (SENDING_{feature}) is received
> first.
>
> Both directions needs separately send SETTINGS parameter
> SETTINGS_ENABLE_{feature} with value 3 (SENDING_{feature})
> before repurposed protocol element can be sent.
>
> SETTINGS parameter SETTINGS_ENABLE_{feature} value 3 (SENDING_{feature})
> imply total ordering of frames, so this means HTTP/2. ( Also
> HTTP/3 do not allow several SETTINGS frames.)
>
> SETTINGS frame with parameter SETTINGS_ENABLE_{feature} with
> value 3 (SENDING_{feature}) indicates time when change
> on purpose of protocol element happens.
>
> It is not just enough to know that change is acceptable
> for recipient. Recipient must know when change happens.
>
> Introducing of new protocol elements do not require
> sending SETTINGS parameter SETTINGS_ENABLE_{feature}
> with value 3 (SENDING_{feature}) when frame content
> indicates precense of protocol element.
>
> / Kari Hurtta
>
>