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

Hi Mike,

On Tue, 13 Aug 2019, 19:48 Mike Bishop, <mbishop@evequefou.be> wrote:

> This form of negotiation appears to presuppose sending multiple SETTINGS
> frames.  First you advertise that something is available, and only if it's
> available on the other side do you then declare that you're sending it.
>
>
>
> HTTP/3 only permits a single SETTINGS frame in each direction, and for
> latency reasons you really shouldn't wait to see the peer's values before
> sending your own.  Therefore, I think you wind up in one of three postures
> for negotiating something like this:
>
>    - Each side declares their supported schemes.  There is a defined
>    algorithm by which each side, having both declarations, can conclude the
>    most mutually-preferred scheme.  Clients can’t generate PRIORITY frames
>    until they’ve seen the server’s declaration.
>    - The server declares its supported schemes, each of which will use
>    different frame types.  The client SHOULD NOT send more than one scheme
>    simultaneously (but perhaps MAY send all of them until it sees the SETTINGS
>    frame).
>    - Define a separate extension which is used for negotiation separate
>    from SETTINGS.
>
>
>

I agree. If I were to enumerate your points, then for point 1 Brad has some
WIP text that makes our initial proposal more robust in this sense.  And
for point 3 I have a strawman not-yet-shared negotiation mechanism that
uses extension frames in the manner you describe. Though seeing it written
down I'm not convinced it doesn't generate another set of complication.

Lucas

> -----Original Message-----
> From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
> Sent: Saturday, August 3, 2019 3:58 AM
> To: Lucas Pardue <lucaspardue.24.7@gmail.com>; HTTP Working Group <
> ietf-http-wg@w3.org>
> Cc: Kari Hurtta <hurtta-ietf@elmme-mailer.org>; HTTP Working Group <
> ietf-http-wg@w3.org>; Matthew Kerwin <matthew@kerwin.net.au>; Brad Lassey
> <lassey@chromium.org>; Dmitri Tikhonov <dtikhonov@litespeedtech.com>
> Subject: Repurpose of protocol elements | Re: Repurpose of priority | ⋯ |
> Re: Setting to disable HTTP/2 Priorities
>
>
>
> > 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
>
>
>
>
>