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

91–100 of 120 posts

Re: JMAP: A modern, open email protocol

#91

Post by crest »

closeparen wrote: post #86
jolmg wrote: post #50

Earlier quoted context omitted.

SMTP is the protocol that's used to route email between servers. How is Fastmail supposed to authenticate with Gmail or Yahoo with Hotmail? Better yet, how is a new mail server in the internet supposed to authenticate with all existing mail servers? Really, authentication for all uses of SMTP doesn't make sense.

If only there were infrastructure and standards for asserting ownership over domain names.

Do you really want to put the power to block mails into DNSSEC the PKI operators?

Re: JMAP: A modern, open email protocol

#92

Post by crest »

flukus wrote: post #72

Looking at the request it contains properties like collapseThreads and sort, moving this sort of functionality server side is a regression. This is an API for hosted services, it's disingenuous to compare it to imap.

Do you see anything that should (or could) be done via IMAP but not via JMAP? Adding support for higher level operations to the protocol can be worth the complexity if it removes network roundtrips. Not everyone is lucky enough to have a reliable, fast, low latency link to his IMAP server.

Re: JMAP: A modern, open email protocol

#93

Post by upofadown »

afiori wrote: post #62
upofadown wrote: post #55

Article uses the word "modern" 5 times, including in the title. Sort of a pet peeve of mine for this sort of thing. New does not imply better. Article also mentions that JSON is used...

What drawbacks do you see in JSON here? For machine to machine communication it is a pretty good serialization format I would say (It is not great for many other things, but this sound like its strong point)

It seemed to me that the article was only using the fact of JSON use as more evidence of modernness. It implied that JSON didn't map that well into their problem space but they overcame.

Re: JMAP: A modern, open email protocol

#94

Post by lucideer »

ocdtrekkie wrote: post #76
popzq wrote: post #66

Unpopular prediction: Gmail will never implement JMAP, so it's already dead in the water.

Why wouldn't Google implement JMAP? Interestingly enough JMAP adds support for Gmail-specific behaviors like labels, which IMAP lacks. This would allow other apps and services to better integrate with Gmail's quirky behavior, improving the experience for Gmail users.

IMAP doesn't lack Gmail's "labels", Gmail just never bothered implementing their labels as IMAP labels, leading to every IMAP client requiring horrible hacks to work around Gmail's inane implementation.

Google are unlikely to implement JMAP for the same reason they've:

- ignored pleas to implement IMAP properly going back to its inception

- have IMAP disabled by default for new users, and for most corporate users (requiring a GSuite admin to explicitly enable IMAP if employees want to access their corporate email with a client).

Google benefit massively from people not using IMAP clients and being forced into their product UIs.

That said, I wouldn't call it dead in the water for this reason. Google's tactics here have reduced the overall usage of IMAP clients, but they also serve as strong motivation for that small niche of users to move away from Gmail.

Re: JMAP: A modern, open email protocol

#95

Post by p_l »

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…

I'll give a potentially flamebaity response... But it's because reality appears to say that OSI protocols were right and TCP was wrong.

Plain TCP essentially emulates a full duplex serial port. Applications need more on top of that. Methods for framing, attaching Metadata, data flows, secure transport layers, etc.

So HTTP which provides a modicum of those options ends up being default, because it's available.

For comparison, OSI defined various components to handle those elements and a proper OSI stack should have then available to application developer.

Another example would be Symbolics Lisp Machines (Genera) where the network layer provided a bunch of mid-layer protocols, like one which provided messages that were formed of basic typed data structures. So people would use those to quickly build custom protocols for their applications, thanks to not having to deal with low level details.

Various Middleware also come to mind.

TCP is not enough.

Re: JMAP: A modern, open email protocol

#96

Post by rakoo »

graffitici wrote: post #71
popzq wrote: post #66

Unpopular prediction: Gmail will never implement JMAP, so it's already dead in the water.

But someone can write a proxy that exposes Gmail as a JMAP endpoint?

There already is one, written by the people behind JMAP even, with a public demo instance at https://proxy.jmap.io/ (don't use the demo with your own credentials of course, host it yourself)

Re: JMAP: A modern, open email protocol

#97

Post by tracker1 »

btown wrote: post #47
wmf wrote: post #39

Earlier quoted context omitted.

JMAP is still young; just wait until a plethora of non-interoperable optional extensions get added.

However bad this is, it's better than a plethora of non-interoperable optional IMAP extensions! https://developers.google.com/gmail/imap/imap-extensions

Sigh... this is why implementing IMAP is a beast... Also doesn't cover what Exchange/Office 365 adds to the mix.

I'm happy to see a newer standard that is at least simpler to understand and implement.

Re: JMAP: A modern, open email protocol

#98

Post by tracker1 »

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…

You can write a web front end that communicates with the mail server API directly.

Re: JMAP: A modern, open email protocol

#99

Post by tracker1 »

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?

Try adding TLS support, then debugging the message transport.

Re: JMAP: A modern, open email protocol

#100

Post by acct1771 »

jolmg wrote: post #4
butz wrote: post #3

Does it solve SPAM problem?

I haven't read JMAP, but I don't think that's the problem it's tackling. Also, I think SPAM is as solved as it can be with blacklists, heuristics-based filtering software like spamassasin, and personal filtering with sieve scripts. What else would anyone suggest?

GPG exchange with trusted personal and commercial contacts being as easy (UX) to add to your keychain as adding someone into the contacts of your phone.
Post reply on HN