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

[Brandon Long <[e-mail]>]

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.

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

Brandon