Re: New Version Notification for draft-momoka-httpbis-settings-enable-websockets-00.txt

Hey Glenn,



On Tue, Feb 28, 2023 at 5:50 PM Glenn Strauss <
gs-lists-ietf-http-wg@gluelogic.com> wrote:

> On Tue, Feb 28, 2023 at 05:24:41PM +0000, Lucas Pardue wrote:
> >
> > On Tue, Feb 28, 2023 at 5:03 PM Glenn Strauss <
> > gs-lists-ietf-http-wg@gluelogic.com> wrote:
> >
> > > On Tue, Feb 28, 2023 at 04:12:21PM +0800, Momoka Yamamoto wrote:
> > > > Hello,
> > > > I have submitted a new revision of this
> > > > draft draft-momoka-httpbis-settings-enable-websockets.
> > > > > URL:
> > > > >
> > >
> https://www.ietf.org/archive/id/draft-momoka-httpbis-settings-enable-websockets-01.txt
> > >
> > > Why should SETTINGS_ENABLE_WEBSOCKETS be added to HTTP/2, HTTP/3,
> HTTP/X
> > > protocols instead of using existing service discovery mechanisms such
> as
> > > alt-svc or the proposed alt-svcb?
> > >
> > >
> https://martinthomson.github.io/alt-svcb/draft-thomson-httpbis-alt-svcb.html
> >
> >
> > The service discovery is decoupled from the service. This means the
> client
> > has to take a gamble that out-of-band information is in agreement with
> the
> > active connection. Settings are a means to discover the features of the
> > service's active connection.
> >
> > As discussed upthread, there are other proposals that could put this
> > information in e.g. the DNS. That might help address other problems but
> is
> > separate from this proposal.
>
> Thanks.  ISTR the DNS discussion.  I'll go find it in the archives.
>
> My point is that this proposal should reference other potential
> solutions and should discuss pros and cons of this proposal versus
> other potential solutions, especially solutions that already exist.
>

I disagree. The proposal is succinct and focused. Discussion of the problem
space  can take place elsewhere like this mailing list, an IETF meeting,
another problem statement, an explainer, a use case document etc.


> > Might there be settings created for other protocols that leverage
> > > SETTINGS_ENABLE_CONNECT_PROTOCOL?  Why should a new SETTING be created
> > > for websockets and not for ... ?
> > >
> >
> > Yes, this is already the case for WebTransport over HTTP/2 [1] and
> > WebTransport over HTTP/3 [2], which define a
> SETTINGS_ENABLE_WEBTRANSPORT.
> > So adding a setting explicitly for WebSocket would make things
> consistent.
> > [1] -
> >
> https://www.ietf.org/archive/id/draft-ietf-webtrans-http2-04.html#section-3.2
> > [2] -
> >
> https://www.ietf.org/archive/id/draft-ietf-webtrans-http3-04.html#section-3.1
>
> Those are drafts, too.
> Personally, I remain unconvinced that these should be their own SETTING.
>
> At a minimum, I would like to see the drafts highlight that these new
> SETTINGS are absolutely optional to indicate specific support, meaning
> that clients can use this information if provided, but SHOULD NOT use
> absense of this (IMO protocol bloat) information in any way.
>

Note that in the case of SETTINGS_ENABLE_WEBTRANSPORT, it is a
bidirectional signal that is bound to a single connection and sent
independent of requests. That has some attractive properties, such as being
possible to encode in TLS handshake via the ALPS proposal [1].


> As an alternative, I would think another extensible service discovery
> mechanism might be extending OPTIONS responses with additional response
> headers.  Others may choose DNS or to extend /.well-known/.  These are
> existing discovery mechanisms (with their own pros and cons) and might
> be extended for service discovery as well as protocol feature discovery.
>

Yes that might be possible. I suggested OPTIONS upthread [2] , and didn't
hear much support for it at the time. But perhaps others think it is nice?


>
> SETTINGS_ENABLE_WEBSOCKETS and SETTINGS_ENABLE_WEBTRANSPORT proposals
> aim to allow protocol feature discovery upon the initial connection and
> without an additional round trip, and so should highlight why this is of
> such importance, and why someone using these features is also someone
> who is visiting the site for the very first time and might not have
> cached alternate protocol feature discovery from a prior set of
> connections and requests.  If I connect to example.com and attempt
> websockets over HTTP/3, I can then cache (maybe for a week or so)
> if it succeeded or failed, and use that for subsequent connections.
>

I mean that's a possibility. But then we risk caching issue edge case just
like Alt-Svc has today in mutli-CDN setups. Which Alt-Svc plan B is
intended to back us out of.

Cheers,
Lucas

[1] - https://datatracker.ietf.org/doc/html/draft-vvv-tls-alps
[2] - https://lists.w3.org/Archives/Public/ietf-http-wg/2023JanMar/0016.html