4 ms·

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. O

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)

jacquesm 6y ago
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.
- johncolanduoni 6y ago
  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.
  - jacquesm 6y ago
    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.
    - shadowgovt 6y ago
      Every two years, no. When the standard starts to actively limit further development, though... https://en.m.wikipedia.org/wiki/IPv4_address_exhaustion https://en.m.wikipedia.org/wiki/IPv4_address_exhaustion
      - jacquesm 6y ago
        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.
        josephg 6y ago
        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.
- josephg 6y ago
  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/ https://jmap.io/ Still no sign of adoption by gmail / etc but hopefully we'll see the industry move forward eventually.
  - mulmen 6y ago
    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.
thwarted 6y ago
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.
int_19h 6y ago
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.

jacquesm 6y ago

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.

johncolanduoni 6y ago
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.
- jacquesm 6y ago
  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.
  - shadowgovt 6y ago
    Every two years, no. When the standard starts to actively limit further development, though... https://en.m.wikipedia.org/wiki/IPv4_address_exhaustion https://en.m.wikipedia.org/wiki/IPv4_address_exhaustion
    - jacquesm 6y ago
      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.
      - josephg 6y ago
        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.
josephg 6y ago
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/ https://jmap.io/ Still no sign of adoption by gmail / etc but hopefully we'll see the industry move forward eventually.
- mulmen 6y ago
  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.

thwarted 6y ago

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.

int_19h 6y ago

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.