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

11–20 of 120 posts

Re: JMAP: A modern, open email protocol

#11

Post by hsk823 »

jolmg wrote: post #7
jwr wrote: post #5

I clicked on this with a lot of hope — alas, this only seems to address the "mailbox access" part of E-mail. I think that part actually works fairly well today (not optimally, but well enough in practice). The part that really needs fixing is SMTP.

> I think that part actually works fairly well today (not optimally, but well enough in practice). I haven't done much with IMAP, but I did setup a watcher for my mailboxes that uses the IDLE extension. I consider it a flaw that I need to create a separate connection, each needing their own session, for each folder I want to watch simultaneously. Servers understandably limit the amount of simultaneous connections you…

Being unauthenticated as a default certainly doesn't jive with modern security practices.

Re: JMAP: A modern, open email protocol

#12

Post by satyanash »

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

Re: JMAP: A modern, open email protocol

#13

Post by ocdtrekkie »

One of the things I particularly recall reading is FastMail devs explaining that the standardization process led to changes and improvements. (Even their about page says that "JMAP was built by the community, and continues to improve via the IETF standardization process.")

Really thrilled the FastMail team is working on this, and doing it in the way that changes to mail should be handled: Going through proper Internet standards bodies. It's in stark contrast to AMP4Email, which is being implemented by Google wholly without respect to Internet standards.

Re: JMAP: A modern, open email protocol

#14

Post by jolmg »

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

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?

Re: JMAP: A modern, open email protocol

#16

Post by jcranmer »

sdegutis wrote: post #10
jcranmer wrote: post #8

Earlier quoted context omitted.

IMAP is a really broken protocol; I'd characterize it as a database synchronization protocol that wasn't designed to be one. You need to rely on certain extensions to have a hope of being bug-free [1], and even those can be problematic (UIDVALIDITY changed, gotta clear your entire inbox!). [1] The IMAP protocol used to rely heavily on message sequence numbers, where each message in the folder was numbered sequentiall…

Where UID is used now sounds like a good use case for UUIDs (or GUIDs?) that don't ever change.

I don't specifically know the history of IMAP, particularly IMAP UID, but the semantics of UID to me implies that it was originally specified to permit its implementation as the file offsets into the mbox files that backed the store, and I believe some IMAP servers implemented it that way.

Some IMAP server implementations have a custom attribute they use to indicate a globally-unique message ID.

Re: JMAP: A modern, open email protocol

#17

Post by icebraining »

jolmg wrote: post #14
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).

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…

https://jmap.io/#why-use-https/json?

Re: JMAP: A modern, open email protocol

#18

Post by jcranmer »

jolmg wrote: post #14
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).

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…

The honest reason boils down to "there's a lot more closing down of generic TCP than HTTP in firewalls and application privilege frameworks."

Email has the other unfortunate property that it has arbitrary binary data (message bodies) mixed in with a UTF-8 control stream, which makes SMTP/IMAP/POP/NNTP especially annoying to implement in languages that draw very strong distinctions between binary and text strings, since you can't just wrap the TCP stream in a UTF-8 decoder/encoder and be done with it.

Re: JMAP: A modern, open email protocol

#19

Post by jolmg »

icebraining wrote: post #17
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…

https://jmap.io/#why-use-https/json ?

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.

Re: JMAP: A modern, open email protocol

#20

Post by satyanash »

jolmg wrote: post #14
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).

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.

Post reply on HN