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

JSON Mail Access Protocol Specification (JMAP)

jmap.io

Post reply on HN
Print view View original

51–60 of 65 posts

Re: JSON Mail Access Protocol Specification (JMAP)

#51

Post by masklinn »

bodyfour wrote: post #12

Unfortunately it includes my biggest gripe about IMAP -- the requirement that messages are given a server-side message number. Maybe breaking with IMAP on this would make interop too hard though. This requirement is convenient for the client but makes implementing robust servers harder than it need be. If instead each message was identified by a {timestamp,UUID} tuple then multiple MX servers could do final delivery…

> Unfortunately it includes my biggest gripe about IMAP -- the requirement that messages are given a server-side message number. Maybe breaking with IMAP on this would make interop too hard though.

I don't understand this criticism, the criticism is usually that IMAP does not require maintaining UIDs (the server can announce UIDNOTSTICKY[0])

> While I'm on the subject, another less-common POP3 extension I liked was "XTND XMIT". This gave a simple way for the POP3 client to send mail

https://news.ycombinator.com/item?id=4826447

> IMAP has actually been extended to support that feature (not just kind of randomly, but by the IETF "Lemonade" working group), even allowing (in concert with other extensions) compositing a message from parts (such as attachments) on the server without having to download them first to the client.

> However, and I think this is actually more relevant in this context, Mark Crispin was an "opponent". (Note: the following e-mail snippet by Mark Crispin, was written years after the Lemonade Submit proposal expired, and thereby should be considered to already take into account that context.)

>> For many years, there have been various proposals to add mail sending capabilities to mail access protocols such as POP and IMAP.

>> These proposals are always strongly opposed. It is one of the "attractive nuisances" of email protocols. The value of the capability is obvious to many people, but the high cost of having it in POP or IMAP is much less obvious.

>> I am one of the opponents. For the past 25 or so years we have been in the overwhelming majority. It is quite unlikely that this concensus will change. If anything, it has become stronger in recent years.

>> […]

>> If you're not really that curious, suffice it to say that the people who design the protocols and systems understand the attraction but have excellent reasons not to do it.

http://mailman2.u.washington.edu/pipermail/imap-uw/2009-Janu...

[0] http://mailman2.u.washington.edu/pipermail/imap-protocol/200...

Re: JSON Mail Access Protocol Specification (JMAP)

#52

Post by nmjenkins »

masklinn wrote: post #51
bodyfour wrote: post #12

Unfortunately it includes my biggest gripe about IMAP -- the requirement that messages are given a server-side message number. Maybe breaking with IMAP on this would make interop too hard though. This requirement is convenient for the client but makes implementing robust servers harder than it need be. If instead each message was identified by a {timestamp,UUID} tuple then multiple MX servers could do final delivery…

> Unfortunately it includes my biggest gripe about IMAP -- the requirement that messages are given a server-side message number. Maybe breaking with IMAP on this would make interop too hard though. I don't understand this criticism, the criticism is usually that IMAP does not require maintaining UIDs (the server can announce UIDNOTSTICKY[0]) > While I'm on the subject, another less-common POP3 extension I liked was "…

(Author of the spec here)

We will be adding sending to the JMAP spec, although support may be optional. The way it currently works at FastMail is a bit too specific to our architecture though, so we want to clean it up before adding it to the spec.

Re: JSON Mail Access Protocol Specification (JMAP)

#53

Post by masklinn »

nmjenkins wrote: post #52
masklinn wrote: post #51

Earlier quoted context omitted.

> Unfortunately it includes my biggest gripe about IMAP -- the requirement that messages are given a server-side message number. Maybe breaking with IMAP on this would make interop too hard though. I don't understand this criticism, the criticism is usually that IMAP does not require maintaining UIDs (the server can announce UIDNOTSTICKY[0]) > While I'm on the subject, another less-common POP3 extension I liked was "…

(Author of the spec here) We will be adding sending to the JMAP spec, although support may be optional. The way it currently works at FastMail is a bit too specific to our architecture though, so we want to clean it up before adding it to the spec.

>>> These proposals are always strongly opposed. It is one of the "attractive nuisances" of email protocols. The value of the capability is obvious to many people, but the high cost of having it in POP or IMAP is much less obvious.

Re: JSON Mail Access Protocol Specification (JMAP)

#54

Post by nmjenkins »

masklinn wrote: post #53
nmjenkins wrote: post #52

Earlier quoted context omitted.

(Author of the spec here) We will be adding sending to the JMAP spec, although support may be optional. The way it currently works at FastMail is a bit too specific to our architecture though, so we want to clean it up before adding it to the spec.

>>> These proposals are always strongly opposed. It is one of the "attractive nuisances" of email protocols. The value of the capability is obvious to many people, but the high cost of having it in POP or IMAP is much less obvious.

Lucky I'm not considering adding it to either POP or IMAP then. :)

Re: JSON Mail Access Protocol Specification (JMAP)

#55

Post by kalleboo »

jmspring wrote: post #18

Call me curmudgeonly, why replace a protocol that works...instead roll up a library to provide the functionality... Those things called standards generally find their way through bodies like the IETF. Maybe I missed it while reading on my phone, but I don't see this submitted as an IETF draft...

Because IMAP doesn't work.

Re: JSON Mail Access Protocol Specification (JMAP)

#56

Post by cursork »

I'm a big proponent of everything-behind-http because of the way it introduces a common language for integrating disparate services.

However! as someone who has had to debug some particularly gnarly email issues in the past I really do quite like the ability to telnet into an IMAP server to dig around. I also have an appreciation of some of the more horrific things that can go wrong...

So my point is that I'm not sure I agree with "generally much easier to work with than IMAP" - there's two types of "working with". One is building a new client/server from scratch - I'd agree this might be easier, but not something that is done that often. The other is being able to quickly investigate issues with hand-crafted queries, and unfortunately I'd say a simple plain text question-answer interface is better - and here IMAP wins.

Maybe I'm just getting old - it's probably true that almost everyone is happier with HTTP than "telnet-able" protocols (SMTP, IMAP, Redis, etc.) nowadays.

Re: JSON Mail Access Protocol Specification (JMAP)

#57

Post by mercurial »

nmjenkins wrote: post #49
mercurial wrote: post #34

Interesting. What is the reason for grouping method calls together? Is this to reduce the number of requests sent to the server? If not, is there no way of providing a higher level operation instead of bundled discrete operations? In any case, I think you could have something a lot closer to REST, even if you carry on with grouping calls together. Something like: [ [ "GET", "/messages", { "search": "foo" }], [ "GET",…

(Author of the spec here) REST is way too slow. The JMAP format massively reduces round trip times, especially when you have sequential operations where you must wait for one to finish before the next can happen. And once you're not doing REST, I don't personally think putting HTTP verbs in the method calls doesn't really make it any clearer, and is just likely to confuse matters.

> The JMAP format massively reduces round trip times, especially when you have sequential operations where you must wait for one to finish before the next can happen.

I hear you (REST and batch operations don't mix too well). But wouldn't it be possible to simply provide higher level operations, grouping several of these commands?

> And once you're not doing REST, I don't personally think putting HTTP verbs in the method calls doesn't really make it any clearer, and is just likely to confuse matters.

As I said, it wouldn't necessarily be restricted to HTTP verbs (eg, using 'create' and 'update' instead of 'POST' and 'PUT'), but I do like the idea of separating the resource you act on from the action on this resource.

Re: JSON Mail Access Protocol Specification (JMAP)

#58

Post by bjourne »

IMAP is mostly slow as hell when dealing with large mailboxes. For example fetching the 10 most recently updated threads (for a sane definition of what a thread/conversation is, which imap doesn't deal with at all) is insanely slow. It entails scanning the whole mailbox trying to figure out what the threads are and when someone last posted to them. Not fast when you can have millions of mails in a mailbox. Is that the kind of problems JMAP might solve?

Also interested in hearing if you know anything about GMail's json api? Surely they must have something similar to JMAP which their web client is using even if it the api is proprietary?

Re: JSON Mail Access Protocol Specification (JMAP)

#59

Post by nona »

nmjenkins wrote: post #49
mercurial wrote: post #34

Interesting. What is the reason for grouping method calls together? Is this to reduce the number of requests sent to the server? If not, is there no way of providing a higher level operation instead of bundled discrete operations? In any case, I think you could have something a lot closer to REST, even if you carry on with grouping calls together. Something like: [ [ "GET", "/messages", { "search": "foo" }], [ "GET",…

(Author of the spec here) REST is way too slow. The JMAP format massively reduces round trip times, especially when you have sequential operations where you must wait for one to finish before the next can happen. And once you're not doing REST, I don't personally think putting HTTP verbs in the method calls doesn't really make it any clearer, and is just likely to confuse matters.

I didn't take the time yet to have a proper look at it, but nothing stops you from doing batch REST operations on collections. You can do compound documents - with references - à la jsonapi.org. One thing I would consider essential though, is using RFC2518 MOVE, COPY etc, you really want to do those server-side.

Do you have an example of the type of operation that would map poorly to REST?

Re: JSON Mail Access Protocol Specification (JMAP)

#60

Post by masklinn »

nmjenkins wrote: post #54
masklinn wrote: post #53

Earlier quoted context omitted.

>>> These proposals are always strongly opposed. It is one of the "attractive nuisances" of email protocols. The value of the capability is obvious to many people, but the high cost of having it in POP or IMAP is much less obvious.

Lucky I'm not considering adding it to either POP or IMAP then. :)

Good luck with your doom-repeating experiment, I guess.
Post reply on HN