ietf
[Top] [All Lists]

Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) - reducing configuration complexity

2017-02-08 15:10:09
On 8 Feb 2017, at 9:52, Ted Lemon wrote:

IMAP and POP both use the wrong data abstraction, and consequently are very hard to get right, and generally aren't gotten right.

So a new protocol that has the data abstraction right is actually a substantial improvement. I don't know if that's the case with JMAP—if it's the same data abstraction as IMAP, it's not worth bothering with, but that's something that at least in theory can be discussed.

What JMAP does afford is the opportunity to have an embedded web client that doesn't suck, and a way to escape it if you want something more stateful.

Yep, this is the bit that convinces me that this effort should go forward. IMAP's problem has always been its combination of semantic bottleneck and leakage: It constrained the semantics that you could communicate across the pipe in some ways (hence the myriad of extensions required to have a workable IMAP implementation), but leaked a bunch of server-specific semantics (e.g., the storage model, the constraints on network resources) through to the client instead of having a clean protocol. Putting a rich and leak-free protocol in front of IMAP is an improvement, and being able to remove IMAP from the equation eventually is a laudable goal.

Yes, there are transition and conversion issues. But I haven't heard anyone come up with a solution to the problems inherent in IMAP that doesn't involve transition pain. The answer can't simply be, "Never attempt to solve the IMAP implementation problems" or "Only solve IMAP implementation problems within IMAP". Neither one of those answers leads to a solution.

(BTW: The submission issue seems a rather boring one to me. There's never been good deployment of BURL and the other LEMONADE mechanisms to make it happen. If this work just creates a decent protocol interface to those submission mechanisms, more power to them. I don't think there's anything magical here.)

I have no objection to clarifying the charter in many of the ways suggested to make clear what the motivations are and what the constraints are on the work, but overall I think this effort should go forward.

pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

<Prev in Thread] Current Thread [Next in Thread>