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

61–70 of 120 posts

Re: JMAP: A modern, open email protocol

#61

Post by afiori »

jolmg wrote: post #31
detaro wrote: post #23

Earlier quoted context omitted.

"possible to replace with alternatives" != "useless"

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.

Which can be read also as: HTTP allows to embed arbitrary semantics with close to no friction. Which sounds like a really good point together with the tooling and ubiquity

Re: JMAP: A modern, open email protocol

#62

Post by afiori »

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)

Re: JMAP: A modern, open email protocol

#63

Post by jolmg »

jcelerier wrote: post #56
jolmg wrote: post #54

Earlier quoted context omitted.

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

Yes, that's what I meant. I would expect a good parser to hang until the message is complete as determined by the syntax of the protocol and return that, leaving the stream at the point the next message should start.

I'm getting the feeling that the popularity of JSON and HTTP come by good part from the lack of good parsing libraries in many languages. People generally only know how to work with what regexes are able to handle and nothing more.

Re: JMAP: A modern, open email protocol

#64

Post by contingencies »

ocdtrekkie wrote: post #13

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 Interne…

Really thrilled the FastMail team is working on this

Sorry to be 'that guy'. I like Fastmail but maybe they could fix some of the irritating bugs we keep asking for resolutions on before embarking on fun protocol invention missions. Two killers:

(1) When forwarding an email there is no link between the forwarded email and the original thread (TOTAL TIME WASTER), when reported they "don't consider it a bug [because of SMTP ID handling in existing daemons]". Missing the point here so hard guys!

(2) When creating a new filter it doesn't have a checkbox to include matching emails. This means you have to manually go replicate the search again, for consistency, to get things where they should be.

Frustrated at lack of response from reporting these as a commercial user. Inventing new protocols should not be higher priority than fundamental annoyances that are wasting customer time NOW.

Re: JMAP: A modern, open email protocol

#65

Post by the8472 »

kitsunesoba wrote: post #57
verisimilitudes wrote: post #22

Earlier quoted context omitted.

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…

If it has to be a loose bag of value data format you could at least CBOR instead of JSON.

Re: JMAP: A modern, open email protocol

#67

Post by zeroxfe »

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?

When you're working with sockets there's lots to think about that you can simply ignore with an HTTP library -- connection setup and teardown, buffering, serialization, byte ordering etc. But more importantly, you'll have to build your own status/error handling, cache control, content encoding, TLS etc. (Simply, doing TLS correctly itself is not easy.)

To be clear, I'm not saying that there's no place for socket programming -- there definitely is. I've spent a good part of my life doing obscure network programming on all kinds of platforms, so I try not to use TCP/UDP unless I have a really good reason. (It's kinda the same reason I won't use C or C++ -- too much to worry about for most general purposes.)

Re: JMAP: A modern, open email protocol

#68

Post by stonogo »

gumby wrote: post #45
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).

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

None of those are application protocols, although they ARE shoving DNS into HTTP now anyway.

Re: JMAP: A modern, open email protocol

#69

Post by Skunkleton »

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?

I handle spam by handing a unique email address to every entity that requests my address (domain wildcard). What would be better is if there was an initial "hello" where some entity requested permission to send me email, and I could approve, deny, or even revoke in the future.

Basically, the issue is that senders cannot be reliably identified. If this were fixed, then spam filtering would be trivial.

Re: JMAP: A modern, open email protocol

#70

Post by gumby »

stonogo wrote: post #68
gumby wrote: post #45

Earlier quoted context omitted.

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

None of those are application protocols, although they ARE shoving DNS into HTTP now anyway.

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.

Post reply on HN