SETTINGS_ENABLE_CONNECT_PROTOCOL is defined as enabling the :protocol pseudo-header field on CONNECT.  The implication being that any protocol is OK once this setting is negotiated.

In reviewing WebTransport proposals, I realized that this is probably a mistake.  There, Victor (I think) realized that you need to negotiate the use of :protocol AND the use of the specific protocol.  Otherwise, you might attempt to use extended CONNECT when the server does not support some of the extra fancy stuff that is in WebTransport.

That leads me to ask:

Should this setting be defined as **extended CONNECT for WebSockets** rather than extended CONNECT more generally?

A generic thing might be useful if the purpose of the exchange is to negotiate for use of the bidirectional channel that is established by CONNECT.  That's all WebSockets does.  Maybe that's enough for a bunch of different cases.

A generic thing is not sufficient if there are other things going on in the protocol as a result.  WebTransport needs additional negotiation as it uses datagrams (and sometimes other streams).  Datagrams are the main thing here, but I don't know if we should limit our thinking to that, especially if we might want to consider partial reliability or other transport-level features.

The proposed solution for WebTransport is to provide a setting that covers the whole package needed by WebTransport.  Is that a better pattern in general?  Should we retcon SETTINGS_ENABLE_CONNECT_PROTOCOL to SETTINGS_ENABLE_WEBSOCKETS to follow this pattern?  Or, is this only a problem that "special" protocols need to concern themselves with?  Those that need more than just the "CONNECT stream".  

I struggle with the view that datagrams might be the only new and special thing.  For one, they are not in the current WebTransport for HTTP/3 proposal.  Also, it seems like with MASQUE and WebTransport, all uses of extended CONNECT require some special handling.

Now, you might say that these "special" protocols might just need to separately negotiate the features they use, like datagrams or non-request streams.  That might work, but these protocols are not all the same.  Support for one does not immediately imply support for all others, even if they use the same basic protocol features.  For instance, the datagrams they exchange cannot be generically handled without understanding the details of the protocol.

That leads me to think that maybe we need to treat this as a whole-stack thing.  A setting per :protocol value is pretty unambiguous.  What do others think?  Should we update the setting definition in RFC 8441?

Received on Tuesday, 2 November 2021 06:42:07 UTC