6 ms·

If this takes off, it would remove one of the last few holdouts of non-HTTP application specific protocols. That just leaves us with SMTP really. While using HT

If this takes off, it would remove one of the last few holdouts of non-HTTP application specific protocols. That just leaves us with SMTP really. While using HTTP is not necessarily a bad thing, it's certainly an interesting indication of how application developers prefer convention based protocol definitions (JSON over HTTP) instead of having a strictly defined protocol over a duplex stream (IMAP over TCP).

verisimilitudes 7y ago
How disconcerting. >If this takes off, it would remove one of the last few holdouts of non-HTTP application specific protocols. IRC and FTP come to mind, but yes. It's as if email's being attacked at all angles, lately. >While using HTTP is not necessarily a bad thing, it's certainly an interesting indication of how application developers prefer convention based protocol definitions (JSON over HTTP) instead of having a strictly defined protocol over a duplex stream (IMAP over TCP). Using HTTP is a bad thing, I think, because it's a complex protocol and it's entirely unnecessary; JSON is a poor, ad-hoc format that isn't optimal for parsing. I don't believe developers ''prefer'' any of this so much as it's being forced on them. You can really only define things rigidly if you want to make much in the way of guarantees. Any system held together by conventions can have those conventions violated and this is a harrowing sign of things to come.
- jolmg 7y ago
  > IRC and FTP come to mind They're niche now, though. HTTP and email protocols are probably the only open protocols that almost everyone uses. There's ssh, but it's also arguably niche in comparison.
- groovybits 7y ago
  > IRC and FTP IRC and FTP have widely used secure counterparts. Meanwhile, STARTTLS did not gain the traction that everyone hoped it would. Edit: Additionally, we have secure working replacement protocols for IRC and FTP (such as Matrix and SSH/SCP).
  - jolmg 7y ago
    STARTTLS is vulnerable to man-in-the-middle and encryption downgrade attacks. Using a distinct port that only allows these application protocols over SSL/TLS (e.g. SMTPS and IMAPS) is better. It's also widely accepted. I don't think there's many that are still running unencrypted SMTP or IMAP connections.
    - jcranmer 7y ago
      Opportunistic STARTTLS is vulnerable to encryption downgrade attacks. Good email clients don't implement opportunistic STARTTLS, they implement mandatory STARTTLS or TLS, with plaintext being either an option that's heavily discouraged by UX flow, enabled only for tests, or not available at all.
      - jolmg 7y ago
        Sure, but a user has no way of knowing if their mail client does opportunistic STARTTLS or not. It's not something the average user can test, and not something mail clients would typically feel the need to mention. On the other hand, you can tell people that good practice is to use ports 993 for IMAP and 465 for SMTP and they'll be good to go, that using any other ports opens them to potential attack.
- satyanash 7y ago
  > You can really only define things rigidly if you want to make much in the way of guarantees. Any system held together by conventions can have those conventions violated and this is a harrowing sign of things to come. The problem with this is that most new protocols (or APIs as they're popularly known now) are built by startups aiming for rapid growth. Writing an RFC for the underlying protocol of the newfangled dating app you're building is counterproductive if you don't know the company will exist six months later.
- kitsunesoba 7y ago
  I’ll take JSON over text any day. Email parsing can break in so many subtle and/or obscure ways that I have trouble putting any confidence in the parsing code I’ve written… it’s quite frustrating, especially since there aren’t well tested mail parsing libraries for every language/platform to fall back on. On the other hand, JSON parsing errors are reasonably bounded and there’s well-tested highly optimized libraries for it for practically every supported platform and language. No it’s not perfect or even well suited for the task, but it’s still an improvement.
  - the8472 7y ago
    If it has to be a loose bag of value data format you could at least CBOR instead of JSON.
    - y4mi 7y ago
      >> there’s well-tested highly optimized libraries for it (JSON) for practically every supported platform and language. > If it has to be a loose bag of value data format you could at least CBOR instead of JSON. so you think there are well tested, good performing CBOR parsing libraries in basically all languages?
      - kahlonel 7y ago
        Yes there are: https://cbor.io/impls.html https://cbor.io/impls.html
- mey 7y ago
  A minimal HTTP 1.1 client is rather straight forward. It's not asynchronous, doesn't use any non-printable characters, not fixed width, US-ASCII, etc. Adding encryption and compression complicates things, but that is true of all protocols.
jolmg 7y ago
Why is this happening? Forgetting ubiquity of tooling, is there something technical about HTTP that makes it so attractive? I get JSON. People don't want to write text-parsers. But what's attractive about this abuse of HTTP? This isn't hypertext. Is it so complicated to work with a duplex-stream? Could a library alleviate the complications? Could it be that developers are more familiar with HTTP than with TCP and so TCP scares them even though it's simpler to use?
- icebraining 7y ago
  https://jmap.io/#why-use-https/json https://jmap.io/#why-use-https/json?
  - jolmg 7y ago
    Everything mentioned there is because of its ubiquity, nothing about how the way HTTP operates makes it more suitable. What you link even says: > the encoding/transport part of JMAP [i.e. HTTP] is not core to its operation, so future specifications could easily add alternatives So HTTP is useless for this except for the fact that everyone uses it.
    - detaro 7y ago
      "possible to replace with alternatives" != "useless"
      - jolmg 7y ago
        By useless I meant that the use of HTTP doesn't contribute anything essential. Though maybe I could be wrong? But that's what I understood by "is not core to its operation". I understand it to just wrap the JSON in HTTP for the benefits that come from its ubiquity in use and not so much because of merits of the mechanisms described in the HTTP spec.
        detaro 7y ago
        No, it's just the most widely supported protocol of that kind, so why not use it? Is there anything specific against it/how do you answer for another protocol the question of "why not HTTP, which is similar and has better support?"? (Caveat: I think you'd ideally want http/2, which isn't as widely supported) EDIT: actually, one point: you can talk JMAP over HTTP(S) directly from a browser without a translating server.
gumby 7y ago
Gosh, I depend on NTP, DNS, BGP, DHCP, ARP...the list goes on. And I'd bet you depend on them too.
- stonogo 7y ago
  None of those are application protocols, although they ARE shoving DNS into HTTP now anyway.
  - gumby 7y ago
    What is an "application protocol" in your mind? These are mostly RFC 1135 application layer protocols. I manipulate them with applications directly. HTTP is a botch that is slowly getting better and is far too heavyweight for most things.
sneak 7y ago
Skype. SIP. Video Games. Bittorrent. Cryptocurrencies. There’s lots of stuff that HTTP isn’t eating.

verisimilitudes 7y ago

How disconcerting. >If this takes off, it would remove one of the last few holdouts of non-HTTP application specific protocols. IRC and FTP come to mind, but yes. It's as if email's being attacked at all angles, lately. >While using HTTP is not necessarily a bad thing, it's certainly an interesting indication of how application developers prefer convention based protocol definitions (JSON over HTTP) instead of having a strictly defined protocol over a duplex stream (IMAP over TCP). Using HTTP is a bad thing, I think, because it's a complex protocol and it's entirely unnecessary; JSON is a poor, ad-hoc format that isn't optimal for parsing. I don't believe developers ''prefer'' any of this so much as it's being forced on them. You can really only define things rigidly if you want to make much in the way of guarantees. Any system held together by conventions can have those conventions violated and this is a harrowing sign of things to come.

jolmg 7y ago
> IRC and FTP come to mind They're niche now, though. HTTP and email protocols are probably the only open protocols that almost everyone uses. There's ssh, but it's also arguably niche in comparison.
groovybits 7y ago
> IRC and FTP IRC and FTP have widely used secure counterparts. Meanwhile, STARTTLS did not gain the traction that everyone hoped it would. Edit: Additionally, we have secure working replacement protocols for IRC and FTP (such as Matrix and SSH/SCP).
- jolmg 7y ago
  STARTTLS is vulnerable to man-in-the-middle and encryption downgrade attacks. Using a distinct port that only allows these application protocols over SSL/TLS (e.g. SMTPS and IMAPS) is better. It's also widely accepted. I don't think there's many that are still running unencrypted SMTP or IMAP connections.
  - jcranmer 7y ago
    Opportunistic STARTTLS is vulnerable to encryption downgrade attacks. Good email clients don't implement opportunistic STARTTLS, they implement mandatory STARTTLS or TLS, with plaintext being either an option that's heavily discouraged by UX flow, enabled only for tests, or not available at all.
    - jolmg 7y ago
      Sure, but a user has no way of knowing if their mail client does opportunistic STARTTLS or not. It's not something the average user can test, and not something mail clients would typically feel the need to mention. On the other hand, you can tell people that good practice is to use ports 993 for IMAP and 465 for SMTP and they'll be good to go, that using any other ports opens them to potential attack.
satyanash 7y ago
> You can really only define things rigidly if you want to make much in the way of guarantees. Any system held together by conventions can have those conventions violated and this is a harrowing sign of things to come. The problem with this is that most new protocols (or APIs as they're popularly known now) are built by startups aiming for rapid growth. Writing an RFC for the underlying protocol of the newfangled dating app you're building is counterproductive if you don't know the company will exist six months later.
kitsunesoba 7y ago
I’ll take JSON over text any day. Email parsing can break in so many subtle and/or obscure ways that I have trouble putting any confidence in the parsing code I’ve written… it’s quite frustrating, especially since there aren’t well tested mail parsing libraries for every language/platform to fall back on. On the other hand, JSON parsing errors are reasonably bounded and there’s well-tested highly optimized libraries for it for practically every supported platform and language. No it’s not perfect or even well suited for the task, but it’s still an improvement.
- the8472 7y ago
  If it has to be a loose bag of value data format you could at least CBOR instead of JSON.
  - y4mi 7y ago
    >> there’s well-tested highly optimized libraries for it (JSON) for practically every supported platform and language. > If it has to be a loose bag of value data format you could at least CBOR instead of JSON. so you think there are well tested, good performing CBOR parsing libraries in basically all languages?
    - kahlonel 7y ago
      Yes there are: https://cbor.io/impls.html https://cbor.io/impls.html
mey 7y ago
A minimal HTTP 1.1 client is rather straight forward. It's not asynchronous, doesn't use any non-printable characters, not fixed width, US-ASCII, etc. Adding encryption and compression complicates things, but that is true of all protocols.

jolmg 7y ago

Why is this happening? Forgetting ubiquity of tooling, is there something technical about HTTP that makes it so attractive? I get JSON. People don't want to write text-parsers. But what's attractive about this abuse of HTTP? This isn't hypertext. Is it so complicated to work with a duplex-stream? Could a library alleviate the complications? Could it be that developers are more familiar with HTTP than with TCP and so TCP scares them even though it's simpler to use?

icebraining 7y ago
https://jmap.io/#why-use-https/json https://jmap.io/#why-use-https/json?
- jolmg 7y ago
  Everything mentioned there is because of its ubiquity, nothing about how the way HTTP operates makes it more suitable. What you link even says: > the encoding/transport part of JMAP [i.e. HTTP] is not core to its operation, so future specifications could easily add alternatives So HTTP is useless for this except for the fact that everyone uses it.
  - detaro 7y ago
    "possible to replace with alternatives" != "useless"
    - jolmg 7y ago
      By useless I meant that the use of HTTP doesn't contribute anything essential. Though maybe I could be wrong? But that's what I understood by "is not core to its operation". I understand it to just wrap the JSON in HTTP for the benefits that come from its ubiquity in use and not so much because of merits of the mechanisms described in the HTTP spec.
      - detaro 7y ago
        No, it's just the most widely supported protocol of that kind, so why not use it? Is there anything specific against it/how do you answer for another protocol the question of "why not HTTP, which is similar and has better support?"? (Caveat: I think you'd ideally want http/2, which isn't as widely supported) EDIT: actually, one point: you can talk JMAP over HTTP(S) directly from a browser without a translating server.

gumby 7y ago

Gosh, I depend on NTP, DNS, BGP, DHCP, ARP...the list goes on. And I'd bet you depend on them too.

stonogo 7y ago
None of those are application protocols, although they ARE shoving DNS into HTTP now anyway.
- gumby 7y ago
  What is an "application protocol" in your mind? These are mostly RFC 1135 application layer protocols. I manipulate them with applications directly. HTTP is a botch that is slowly getting better and is far too heavyweight for most things.

sneak 7y ago

Skype. SIP. Video Games. Bittorrent. Cryptocurrencies. There’s lots of stuff that HTTP isn’t eating.