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

[Pete Resnick <[e-mail]>]

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. - [phone]