Hacker News Reader

Comment by shadowgovt | Hacker News Reader

I'm not convinced, though there are, obviously, advantages to RFCs and IETF.

The primary disadvantage is speed. A private corporation innovating on its full stack can come up with a faster and more secure HTTP alternative for their use case in the time it takes the RFC process to get up in the morning and find its shoes. Google has a streamed cloud gaming service running in its web browser right now; how long would it take the RFC process to kick out the protocols necessary to enable that?

View on HN

> A private corporation innovating on its full stack can come up with a faster and more secure HTTP alternative for their use case in the time it takes the RFC process to get up in the morning and find its shoes.

But...that's part of standards process. It's quite common for the actors like Google to propose a new/revised standard after implementing it independently SPDY (became HTTP/2), HTTP over QUIC (became HTTP/3), Web SQL DB (became dead, but still started the standardization process), etc., all went this route.

Exactly.

I was talking to people at the IETF about this last year. One person said the ideal use of the IETF (and RFC process) is to take situations when multiple companies have solved the same problem. The IETF puts everyone in a room (/mailing list) together and lets us collectively figure out a single interoperable protocol that all the members can implement in order to make their systems compatible.

The golden path isn't "Joe blogs needs a protocol for something so he writes an RFC". Its "Joe need a protocol. He writes his own and iterates on it. Later he meets Sarah and Dave who've all written similar protocols to solve the same problem at their own organizations. Together they approach the IETF and form a working group to discuss a standard."

Reality is usually much more messy than this; but generally the IETF should never be a bottleneck for people who want to write code and try things out. Racing ahead of whats written in RFCs doesn't stand in opposition to the RFC process. The opposite - racing ahead is a necessary part of the process, because we need collective experience in how to solve a problem in order to write good standards.

There is another downside to IETF/RFC/public standard: it's hard to move forward.

My favorite example: e-mail. SMTP and IMAP are old and have so many issues. On the SMTP side it is hard to identify authorized senders, which is a reason for spam, IMAP doesn't really work nice with mobile devices. On the other hand there are messengers like WhatsApp which solves many of those issues and allows adding features (for good or bad) and contrary to mail is fully encrypted and signed (assuming Facebook didn't break it, yet, after adding Signal's technology)

RFCs don't get changed, they get replaced by new ones. Until we find something that is 'good enough'. SMTP and IMAP are now older than quite a few of HN's readers. They could be replaced by something better, all someone would have to do is design it and put out a new RFC.

What is true though is that once a protocol is 'good enough and it gains mass adoption that change is hard but this is more to be blamed on human nature and inertia than that it is to be blamed on the RFC system in itself.

And this is happening. The JMAP working group at the IETF is writing new RFCs to replace SMTP/IMAP, Caldav, and others with a much cleaner protocol built on top of JSON and HTTP.

Its already in use at Fastmail and a few other places. (The fastmail web client talks JMAP to get your emails from the fastmail servers.)

Specs and more here: https://jmap.io/

Still no sign of adoption by gmail / etc but hopefully we'll see the industry move forward eventually.

This was the final straw. I have been considering it for literally years but I believe in open standards including email itself. If fastmail is supporting and advancing that I have no problem paying for their service.

I just created a fastmail account and set it up on my devices. Now begins the long process of moving away from gmail.

Unless your plan is to change human nature, where the “blame” goes is pretty academic. The inertia is still an issue when going the RFC route, and less of an issue when standards are developed first to fill a specific need for an interested party.

The inertia is a good measure for how successful a particular protocol version is. See for instance IPV4 and how hard it is to get rid of it. And that inertia is good, you don't want to rip up your standards every two years.

Every two years, no.

When the standard starts to actively limit further development, though...

https://en.m.wikipedia.org/wiki/IPv4_address_exhaustion

Nobody stops you from adopting IPv6, the reason that many people don't do it is because they have legacy stuff that they can not reconfigure so they're stuck. But it will happen, and IPv6 adoption is steadily on the rise.

Here in Australia my expensive fibre connection still has no ipv6 support. I file an issue every year or so to my ISP asking when they're going to add ipv6 support, so at least they know I care. But the answer is always "Its not on the roadmap".

Its difficult to remember to write ipv6-compatible software when I can't use or test it myself. Short of writing to my member of parliament and asking them to legislate it, I'm not sure what else I can do.

And on the other hand, any mail client can connect to any mail server, and any two mail servers can exchange email between each other, so the service is fully federated. The benefits here outweigh the downsides.

But also, why isn't there a commonly accepted better email standard yet? It's not because the RFC process is slower - it may be, but it's not that slow. It's because none of the big providers are interested in this form of interoperability. It's plainly obvious when you look at the sorry state of affairs in IM.

We're really, really lucky to have the interop that we have, solely because early days of the Internet were more collaborative, and enough of it got early adoption and stuck around, because it was too hard to uproot. But the more we go forward down the present path, the more Internet is splintered into proprietary bubbles.

Inability to move forward has less to do with IETF/RFC/public standards than it does with email and SMTP, to use your example, being heavily entrenched. Anyone can come up with a new way of doing something, but it's a walled-garden until it's interoperable with other tooling that other people, everyone else, are using.

OnLive was streaming games years before Google entered the space, there isn't much novelty in what Stadia has done.

The novelty will be if it's profitable / something people want.

There are already RFCs for realtime streaming of data. Also IIUC the RFC process often starts with a draft based on am existing implementation.

I don‘t know that much about how the standardization in machine building is done, just from using this standards when working in this industry. However, I would assume a lot of those standards took very long to establish but they are stable, work basically everywhere and are easy to understand.

A lot of standards coming from Google are - so it seems - here to solve things just Google likes to solve and nobody else mostly does not care about. And it‘s not standardization if you‘re the only one caring about it and forcing it onto other.

this is what organizations that participate in the RFC ecosystem have always done - they just view protocol-level interop and open standards as important.

Reply on news.ycombinator.com