Re: [Jmap] Best vs Good enough - adoption of JMAP

["Chris Newman" <[e-mail]>]

On 26 Apr 2017, at 15:25, Brandon Long wrote:
> On Mon, Apr 24, 2017 at 5:39 PM, Chris Newman 
> <[e-mail]>
> wrote:
>
>> On 24 Apr 2017, at 15:43, Adrien de Croy wrote:
>>
>>> On the topic of best vs good enough.
>>>
>>
>> This is a misleading dichotomy for an engineering discussion. My 
>> immediate
>> response when you say "best" is "best for whom?" If you design the 
>> best
>> possible protocol for end-user experience, it will place unreasonable
>> requirements on servers and won't deploy. Good engineering involves
>> tradeoffs, cost/benefit analysis, deployability analysis, 
>> extensibility
>> design, etc.
>>
>> I agree they are perhaps opposed, you could say that good enough is 
>> the
>>> enemy of best however, since once you have something that is good 
>>> enough,
>>> your incentive to do any better is greatly diminished.
>>>
>>> However, we are up against several obstacles when it comes to 
>>> adoption of
>>> JMAP.
>>>
>>> 1. Server authors won't want to add support unless there are clients
>>> 2. Client authors won't want to add support unless there are servers
>>> 3. Client or server authors won't want to add support unless they 
>>> can
>>> make things significantly better for mail users.
>>>
>>
>> I've never heard of a mail client author implementing a feature 
>> before the
>> server exists. Server authors are the ones who have moved first in 
>> the
>> email community. So the key to JMAP deployability is to make it not
>> unnecessarily hostile to server developers (like myself) and server
>> operators. But I agree we also want JMAP to provide significant 
>> benefits to
>> client authors and their users. There are many design choices JMAP 
>> can make
>> that meet all of these goals.
>>
>> 4. We are losing customers to alternate messaging systems.
>>>
>>> If our target is just going to end up providing no benefits to users 
>>> over
>>> what we already have with IMAP+SMTP, then nobody will bother.
>>>
>>> Where it gets interesting for me personally at least is if we can 
>>> push
>>> the boundary of mail experience.  In many cases this can be done in 
>>> the MUA
>>> but in some cases it requires support from the protocols.
>>>
>>> I hear the arguments that the more complex we make the spec, the 
>>> less
>>> likely it will be implemented, at least correctly. I'm not a fan of
>>> complexity either, and neither of my suggestions do I consider to be
>>> particularly complex.
>>>
>>> My argument is that if the design doesn't hold out a carrot for 
>>> better
>>> mail experience for users, then nobody will bother, and we're 
>>> wasting our
>>> time here, which would be a shame because we have the potential to 
>>> achieve
>>> a lot here.
>>>
>>> At the moment, there is a benefit on the table, mostly being the 
>>> ability
>>> to only require configuration of access to 1 service (that's if JMAP 
>>> does
>>> submission).
>>>
>>> I believe we should be looking for opportunities to make mail the 
>>> best
>>> experience possible, come up with ideas, and we may decided to defer 
>>> some
>>> or not implement others, but we should keep them in mind so that 
>>> perhaps we
>>> don't close off the path to some of them.  We don't need another 
>>> protocol
>>> that is hamstrung by lack of foresight.
>>>
>>> there are plenty of ideas around, look at the competition.
>>>
>>
>> Email is the most widely deployed multi-vendor messaging system on 
>> the
>> Internet. The major value of doing JMAP as a standard is to get
>> multi-vendor deployment. A walled garden will always have features 
>> that an
>> open multi-vendor system can't achieve (simply for privacy reasons). 
>> Yes,
>> we should look at the features that are popular in walled garden 
>> messaging
>> systems and do a cost/benefit analysis. If the cost is low and 
>> benefit is
>> high, let's consider it. But if the cost is high or the feature will
>> involve a lot of careful design work and is outside the charter 
>> scope, then
>> you'll get opposition to adding that feature to the JMAP base spec.
>>
>> A multi-vendor standard needs to support both small and large 
>> deployments
>> and support both cloud and on-premises deployments. There are 
>> hundreds of
>> deployed IMAP and Submission server implementations on the Internet 
>> and
>> JMAP will deploy a lot faster if it "plays well" with those
>> implementations. And by "play well", I mean it can be added to an 
>> existing
>> deployment without major infrastructure changes.
>>
>> For example, if I'm operating a million-user deployment, it's 
>> critical to
>> monitor the mail queues for problems. The proposed JMAP "outbox" 
>> model
>> means I'm adding one million new mail queues to the monitoring 
>> system.
>> That's a major deployment change; and thus a significant barrier to 
>> JMAP
>> deployability.
>>
>> Suppose we remove the "outbox" model from JMAP and replace it with a
>> submission command with envelope extensions. Now suppose we want to 
>> require
>> JMAP servers to support BINARYMIME submission (and/or append) as a 
>> boon to
>> JMAP submission client authors? Well that's no problem from an
>> infrastructure viewpoint as long as the JMAP server is permitted to 
>> perform
>> the base64-encoding on binary message parts at submission/append time 
>> in
>> order to remain compatible with IMAP mail stores (and non-BINARYMIME
>> submission servers). Want to have the JMAP submission command handle 
>> both
>> the \Sent folder copy and the Submission without duplicate data
>> transmission? I think we need to do that. Want to have the base JMAP
>> submission or append command include IMAP CATENATE functionality 
>> (assemble
>> a message including server-stored attachments in order to "forward 
>> without
>> download")? I have no problem with that.
>>
>> There's quite a bit of room to improve the JMAP client author's 
>> experience
>> without forcing major infrastructure changes. The WG exists to 
>> discuss the
>> cost/benefit of various features and make an engineering judgment 
>> call. The
>> proposals that are most likely to succeed are ones that can be 
>> implemented
>> in a JMAP proxy without significant changes to IMAP/Submission. And
>> proposals that would require reasonably straightforward or 
>> well-understood
>> IMAP/Submission extensions are worth considering (e.g., if I need a
>> per-user unique/persistent message identifier for IMAP, I understand 
>> the
>> implications of that).
>
> But, if all JMAP is is a proxy of existing protocols, then it seems 
> like an
> expensive undertaking for little gain.

The JMAP charter states:

"JMAP needs to be implementable on top of an IMAP server, which also 
supports IMAP extensions specified below. The JMAP data model needs to 
remain backwards compatible with the IMAP mailstore model (where a 
message is always associated with a single mailbox), but it might 
support other underlying models (e.g. Gmail-style labels).

I largely support that constraint on the WG. Although the WG can change 
its charter to add non-controversial IMAP extensions to the list (e.g., 
draft-brandt-imap-replace-02 may fall in that category).

> And does that mean any future extensions have to be also implemented 
> in IMAP?

No. I'd implement all JMAP mail store functionality I choose to expose 
as IMAP extensions, but that's my personal implementation choice and not 
a constraint on the WG.

		- Chris