Re: [Webtransport] Confirming Consensus on WebTransport protocols

[Martin Thomson <[e-mail]>]

On Wed, Jan 13, 2021, at 16:57, Bernard Aboba wrote:
> Personally, I don't believe that either of these Issues are unsolvable, 
> but since pooling is an optimization, an argument can be made that the 
> WG should intiailly focus on more basic concerns.

I am was suggesting something different.  This working group should not express an opinion on these matters.  If implementations are willing to engage with these problems, they should be free to do so without some RFC (or Internet-Draft) saying that they should not.  

If we identify constraints based on the web security model, that might be cause for a browser not to attempt pooling.  Web security is sufficiently intricate that that is a distinct possibility.  However, that would be something the W3C working group deals with (I think that's the division of responsibilities here; though that is unclear).  Either way, that should not have a significant effect on the protocol definition, which should not care about this.

In any case, I'm not aware of any reasons that would actively prevent pooling other than those you list, which just amount to "there are some tricky bits".  But that mostly relates to performance and prioritization. The first issue you mention can't be a problem, because a server has to offer all of the webtransport capabilities at the start because it can't know if this is plain HTTP or webtransport at that point.  So I'm left with "prioritization is hard", which isn't exactly news.  Is there anything else?