I don't really understand what the fuss is about. If your city builds a new road, you may need to take different turns to drive to work. If Python deprecates a function, you need to patch up your code. Just deal with it.
(I'm the author of the linked-to entry, and I should have done a better job of explaining this in the original entry.)
Another way of looking at it would be that you have been actively blocking HTTP/3 (and probably many other useful but uncommon protocols) for your users and all that needs to happen to make it work is for you to stop doing that. Blocking all unknown things by default is just another form of protocol ossification.
That said when you're responsible for network security I can imagine how a block-by-default policy is tempting and hopefully people subjecting their users to such a policy will read your article and add an exception.
You owe it to others on the internet to not allow everything out indiscriminately from untrusted strangers who happen to be on your access network. It’s just neighborly to make sure you’re not sending ddos or spam, for example.
How is that different from an ISP? Or do you think ISPs should also block everything except TCP ports 80 and 443?
If the incentives aren’t there to do proper maintenance, no amount of blaming people for following those incentives will fix the problem.
In any case it does not really matter; either Utoronto will eventually rewrite their firewall configs, or they won't and then they will not be able to use HTTP3. These issues have a way of eventually becoming urgent enough to fix and at that time the incentives will sort themselves out.
There are only so many hours in the day/week, and it's usually already filled with work that needs to be done for internal needs. Someone external comes along unbidden and wants to add to your work for something that seems to have very little benefit for the organization.
Why should I do the work for them? What problem of mine does this effort solve?
If firewall changes are necessary for HTTP/3 to be adopted (eg connection tracking in routers may not work anymore), that can cause big problems in adoption.
Even if the effort required to adopt something would bring in disproportionate returns, they would skip it because the effort is nonzero?
(just a generalization, no idea if H3 worth it or not)
Moving from Python 2.7 to 3 involves a lot of work for some people with an old stable code base, and benefits those writing new code.
Of course as Python is open there’s nothing stoping you from maintaining 2.7 yourself - except that’s more work, and until now you’ve likely benefitted from the work others have done more than you’ve contributed.
I had some fairly new code written in nodejs recently that fubared when node was upgraded. Looking at the tangled web of code to try to get working again, and the fact it was under 13 months old before it was reduced to a valueless mess, I spent 4 hours replacing its function with a stable language as that was a better use of my time.
If firewall changes are necessary for HTTP/3, then it's a slightly 'dumb' protocol in some ways.
If that's a prerequisite, then perhaps more effort should have been spent in getting SCTP and DCCP accepted and run HTTP over one/both of those. QUIC seems to have basically the same feature set AFAICT.
Besides the architecture decision of having QUIC being on top of UDP, are there specific features that are much better than SCTP and/or DCCP? Are the other two better in particular areas? How complementary or competitive are the two approaches? (Genuinely curious.)
> connection tracking in routers may not work anymore
What do you mean by this? Tracking of UDP flows has been supported by routers for decades.