31–40 of 246 posts
Should have waited for 9001. Oh my mistake, they have several RFCs from 8999-9002.
Yeah, they form a "cluster" of documents: https://www.rfc-editor.org/cluster_info.php?cid=C430 , so that the earlier-numbered RFCs can reference later ones. For instance, rfc9000 normatively refers to rfc9001 and rfc9002.
The link to QUIC in that article goes to a 404 page.
Off topic, but doesn't GDPR stipulate[0] that cookie consent dialogs cannot have non-essential options that are by default opted in? This page seems to have those. > The use of pre-ticked opt-in boxes is invalid underthe GDPR. Silence orinactivity on the part of the data subject, as well as merely proceeding with a service cannot beregarded as an active indication of choice. [0] https://edpb.europa.eu/sites/default/f…
Huh, I didn't know that, I'd wondered why so many sites defaulted them all to unchecked. Fastly's one seems a pretty dark-patterned in general, throwing up a primary-styled "allow all" button (and simultaneously pushing the switches out of view) if you disable one of the options.
But it's still just a layer on top of UDP, and still implemented at the application, like in the past. So how is the ossification broken?
Every app has to implement it itself rather than calling a syscall and letting the OS deal with its complexities (same as for TLS, making fewer apps implement it without a lot of extra work). Which also increases context switching. In the future more protocols will be built on top of QUIC, expanding the user-space stack, increasing fragmentation of application-space IP stacks. And are network cards now going to start implementing it?
It's painful to watch us stride headlong into the future depending on band-aids because surgery is too complicated.
Earlier quoted context omitted.
Yeah, they form a "cluster" of documents: https://www.rfc-editor.org/cluster_info.php?cid=C430 , so that the earlier-numbered RFCs can reference later ones. For instance, rfc9000 normatively refers to rfc9001 and rfc9002.
Curious, why isn't it numbered the other way? My programming brain is telling me that if you're reading rfc9000 you can't reference rfc9001 because it hasn't been initialized yet. :D
Yeah, I'm absolutely great at parties!
> The internet transport ecosystem has been ossified for decades now, and QUIC breaks out of this ossification But it's still just a layer on top of UDP, and still implemented at the application, like in the past. So how is the ossification broken? Every app has to implement it itself rather than calling a syscall and letting the OS deal with its complexities (same as for TLS, making fewer apps implement it without a…
Earlier quoted context omitted.
Curious, why isn't it numbered the other way? My programming brain is telling me that if you're reading rfc9000 you can't reference rfc9001 because it hasn't been initialized yet. :D
It's in a lot of ways more about not being defined (but possibly declared) yet, rather than initialized. You'd be super sad if you could not reference a function defined later in a source file. Yeah, I'm absolutely great at parties!
> The internet transport ecosystem has been ossified for decades now, and QUIC breaks out of this ossification But it's still just a layer on top of UDP, and still implemented at the application, like in the past. So how is the ossification broken? Every app has to implement it itself rather than calling a syscall and letting the OS deal with its complexities (same as for TLS, making fewer apps implement it without a…
I think from their perspective the (Windows and Android) kernel is what causes ossification so moving transport into the app, along with encryption, solves it.
> moving transport into the app, along with encryption, solves it
This is only a good idea if the application's development moves faster than both the kernel and the rest of the userspace platform - which is a fine strategy if you're targeting old or obsolete platforms, but probably a bad idea if you're targeting currently-supported operating systems with a long support lifetime (like Windows).
It's a bad idea when a major security issue or compatibility problem with a transport or encryption library pops-up (which happens all the time, btw) - as it's part of your application then you don't benefit when the OS vendor ships a security update that your application gets for free. If you used dynamic-load+linking at runtime instead of a statically-linked encryption library then you might get lucky with a drop-in .so/.dll replacement without needing a rebuild, but YMMV.
Doing everything in the app instead of letting the parent platform handle it by default is kinda the software-engineering equivalent of libertarian ideological thinking: it only benefits you if you (and your team) really are far better than the state - otherwise you'll quickly run into problems - and it isn't suitable for the vast majority of the ecosystem.
> The internet transport ecosystem has been ossified for decades now, and QUIC breaks out of this ossification But it's still just a layer on top of UDP, and still implemented at the application, like in the past. So how is the ossification broken? Every app has to implement it itself rather than calling a syscall and letting the OS deal with its complexities (same as for TLS, making fewer apps implement it without a…
What difference is it for the caller if the interface is inside the kernel or in a userspace library? What if they can't tell?