On Tue, Jan 7, 2025 at 5:14 AM Rob Wilton (rwilton) <rwilton=40cisco.com@xxxxxxxxxxxxxx> wrote:
> Also lower the bar for IS.
>
> DHCPv6 RFC8415 will go to IS this year.
> We obsoleted two significant things.
> meanwhile there are still significant gaps in how DHCP relays and PD
> interact, which is "solved" today by inspection by DHCP relays. (I would
> like to fix this, but I no longer have a product with enough deployment to affect
> running code at all)
I was pleased to see the HTTP 1.1 become a full standard relatively recently, because I'm a cautious fellow I had been holding off deploying or using anything based on HTTP because of my concerns that it wasn't really stable and might still significantly change ;-).
My concern wasn't that nobody was using HTTP/1.1, it was that it is really difficult to tell people IETF standards status matters when the most widely used application protocol didn't become a standard for decades after it was finished.
Of course, for similar reasons, I suspect that is much wiser/safer to stick with the full Internet Standard HTTP 1.1 rather then be very brazen and implement or deploy the updated H/2, or H/3, neither or which are real standards, just something proposed to be a standard in future.
My real point being that our existing naming/categorisation isn't clear and useful to readers, or consumers of RFCs since I really think that H/2 and H/3 are the "current" stable versions of HTTP, and HTTTP 1.1 is legacy/historic.
I don't believe HTTP/1.1 is historic or that HTTP/2 is the right replacement for HTTP/1.1 in Web services. And I speak as the person who was writing probably the first 'Web Services' back at CEN in 1993 and the first person to make use of keep-alive.
The reason we ended up with every application protocol being layered on HTTP was to get round the corporate firewalls. And now we use HTTPS. Corporations like firewalls because they are a cheap way to get the auditors off their back.
I implemented OAUTH2 last week and today's fun is going to be ACME. And they each have slightly different approaches to the HTTP/1.1 binding. Neither of which is exactly right or wrong but standards are the process of making choices that don't matter. Having the two be the same would make it a lot simpler to build and also to manage. The reason people like JSON is that it facilitates debugging because the tools know how to format it which is less true of CBOR and not at all true for ASN.1
HTTP/2 was designed to optimize the protocol for its primary use case: Web browsing. And that was totally the right choice.But HTTP/2 is a terrible basis for Web Services, it has zero benefits unless your 'application' is essentially content retrieval and thus a subset of Web browsing.
HTTP/3 is even worse because now you have multiple streams in parallel and while that can be very useful in the context of a WebService, it isn't going to work unless the application developer has given a lot of thought to the implications of concurrency within a transaction.
What we need is a WebServices over QUIC protocol that provides the capabilities that are relevant to WebServices. So that instead of every application protocol describing a slightly different way to layer over HTTP/1.1, there is a common approach.
As it happens, the MOQ group is producing what is likely to be the first instance of such. If we can generalize that approach into Web Services over QUIC (WSOQ), then we can think about retiring HTTP/1.1, but not until.
