Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JMAP: A modern, open email protocol

ietf.org

Post reply on HN
Print view View original

51–60 of 120 posts

Re: JMAP: A modern, open email protocol

#51

Post by greggyb »

voidcommonstock wrote: post #49

There is so much NIH going on in this protocol, it's as if the authors we're completely unaware of modern HTTP API design. They're not just doing IMAP over http, they invented their own error bodies, schema's , negotiation and RPC.

I think their goal is to have transport layer be a pluggable subsystem, divorced from their request-response protocol.

They even essentially say that HTTP is not necessary to their protocol, so I think it's pretty apparent that HTTP is a utilitarian choice, but they're not trying to build email-over-http.

Re: JMAP: A modern, open email protocol

#52

Post by jolmg »

jcranmer wrote: post #40
jolmg wrote: post #27

Earlier quoted context omitted.

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.

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.

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.

Re: JMAP: A modern, open email protocol

#53

Post by lucideer »

westurner wrote: post #28

What are the optimizations in JMAP that make it faster than, say, Solid? Solid is built on a bunch of W3C Web, Security, and Linked Data Standards; LDP: Linked Data Protocol, JSON-LD: JSON Linked Data, WebID-TLS, REST, WebSockets, LDN: Linked Data Notifications. [1][2] Different worlds, I suppose. There's no reason you couldn't represent RFC5322 data with RDF as JSONLD. There's now a way to do streaming JSON-LD. LDP…

I would say your comment, and the first reply, both demonstrate quite effectively why JMAP is probably a better choice for email.

> It may or may not (yet?) be as efficient for synchronization as JMAP, but it's definitely designed for all types of objects

If we hypothetically allow for equal adoption & mindshare of both, and assume both are non-terrible designs, I'd guess the one designed for "all types of objects" is less likely to ever be as efficient as the one designed with a single use-case in mind.

And narrow focus is not only good for optimising specific use-cases, it's also good for adoption as people immediately understand what your protocol is for and how to use it when it has a single purpose and a single source of truth for reference spec, rather than a series of disparate links and vague all-encompassing use-cases.

Solid has brilliant people behind it, but it's too broad, too ambitious, and very much lacks focus, and that will impair adoption because it isn't the "one solution" for anyone's "one problem".

--

To take another perspective on this, there are other commenters in this thread bemoaning the loss of non-HTTP-based protocols. Funnily enough, HTTP itself is a broadly used, broadly useful protocol than can be used for pretty much anything (and had TBL behind it also). The big difference was that Tim wasn't proposing that HTTP be the solution to all our internet problems and needs in 1989—it was just for hypertext documents. It's only now, post-adoption, that it is used for so much more than that.

Re: JMAP: A modern, open email protocol

#54

Post by jolmg »

zeroxfe wrote: post #29
jolmg wrote: post #14

Earlier quoted context omitted.

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…

> This isn't hypertext. That ship has long sailed. HTTP is no longer just hypertext -- it's a ubiquitous and well-understood transport for RPCs, with lots of tooling and infrastructure support across the Internet. I think at its core, HTTP abstracts away some of what you would want in a request-response protocol, but not really all of it. But _simply because of the ubiquity of tooling_, you get a whole lot of other s…

> Yes, TCP streams are very complicated to work with (in my experience) -- there are way too many failure modes and corner cases to consider.

Isn't it the same thing, but simpler and more flexible? You write a message, and then you read a reply, rinse and repeat. Could you expand on such things that are complicated with TCP that HTTP helps with?

Re: JMAP: A modern, open email protocol

#56

Post by jcelerier »

jolmg wrote: post #54
zeroxfe wrote: post #29

Earlier quoted context omitted.

> This isn't hypertext. That ship has long sailed. HTTP is no longer just hypertext -- it's a ubiquitous and well-understood transport for RPCs, with lots of tooling and infrastructure support across the Internet. I think at its core, HTTP abstracts away some of what you would want in a request-response protocol, but not really all of it. But _simply because of the ubiquity of tooling_, you get a whole lot of other s…

> Yes, TCP streams are very complicated to work with (in my experience) -- there are way too many failure modes and corner cases to consider. Isn't it the same thing, but simpler and more flexible? You write a message, and then you read a reply, rinse and repeat. Could you expand on such things that are complicated with TCP that HTTP helps with?

> You write a message, and then you read a reply, rinse and repeat.

well, no, you don't "read a message" with TCP, because it is a stream-oriented protocol. you read bytes that keep coming and wait until you have enough or reach a delimiter that you chose.

Re: JMAP: A modern, open email protocol

#57

Post by kitsunesoba »

verisimilitudes wrote: post #22
satyanash wrote: post #12

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

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…

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.

Re: JMAP: A modern, open email protocol

#58

Post by afiori »

vbezhenar wrote: post #34
jolmg wrote: post #14

Earlier quoted context omitted.

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…

1. Everyone does that, why should I do different thing? 2. I've heard about corporate firewalls which close everything and nobody has power to overcome that, so I'll tunnel everything via HTTP(S) and forget about those horrors. 3. HTTPS provide absolutely hassle-free encryption with reverse-proxies. I don't even need to think about it. Using TLS library sounds too complex and I must make some real effort to implement…

Do you also have a list for why many people oppose HTTP (or better what is sometimes called "shoehorning everything in a HTTP shaped box")? I guess that the versioning and advanced features are a stark contrast with versionless TCP from the '80, but I am interested in hearing more opinions on the matter as I am ignorant of any dealbreaker regarding HTTP.

Re: JMAP: A modern, open email protocol

#59

Post by afiori »

satyanash wrote: post #20
jolmg wrote: post #14

Earlier quoted context omitted.

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…

> Is it so complicated to work with a duplex-stream? It's not that duplex-stream is complicated, it's just that request/response semantics are much more suited for most use cases. Where duplex streams make sense, we now have websockets. Even then, on top of that you'll end up implementing stateful request/response semantics because you need some structure unless you're literally dumping binary data into the socket.

Another difference is that the request/response pattern is much better suited for slow/unreliable connections and chaching.

Re: JMAP: A modern, open email protocol

#60

Post by mey »

verisimilitudes wrote: post #22
satyanash wrote: post #12

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

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 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.
Post reply on HN