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

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

On 24 Apr 2017, at 17:54, Ted Lemon wrote:
> On Apr 24, 2017, at 8:39 PM, Chris Newman <[e-mail]> 
> wrote:
>> 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.
>
> This seems like a problem, though.   If the whole thing is geared 
> toward server vendors, then UX is out not at all visible: you don't 
> get to find out about UX until you have an MUA.

Yes, this has been a common problem in design of mail protocols. If you 
have any ideas on how to keep the mail client authors who think more 
about UX issues engaged in the JMAP standardization debate, I'd love to 
hear them.

>> 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.
>
> This doesn't really follow.   It's perfectly possible that the way 
> that the backend implements this is that when something is stuffed in 
> outbox, it's put in the global mail queue, moved to sent, and the 
> delivery status in sent is "pending."   Now the MUA can tell that the 
> message has been queued, but no delivery attempt has been made.   Once 
> the delivery attempt is completed, the MTA returns a status to the 
> JMAP server indicating that the mail has been sent, or that it failed. 
>   Or it doesn't; if it doesn't support this, then we just mark the 
> message as "sent" as soon as it is queued.   But the facility for a 
> richer status report is present.   In principle the JMAP server can 
> use properly formatted and authenticated bounce messages to update 
> delivery status if that is available.   (obviously, iterate across all 
> the destination addresses on the message.)

True, if the WG finds rough consensus around the outbox model despite my 
objections, then my implementation will have an always-empty outbox as 
that's the only way to implement it without infrastructure disruption. 
I'd prefer a JMAP design that allows me to provide delivery status UX 
without infrastructure disruption.

>> 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).
>
> I'm probably revealing my naivete here, but _seriously_?   IMAP allows 
> 8-bit messages, and even provides a way to require that clients 
> support them.   Are you saying that these million-user IMAP servers 
> are so ancient and clunky that they don't do that, or am I missing 
> something?

Pretty much everything deployed is 8-bit clean in message bodies (UTF-8 
does not need to be encoded for IMAP). But a lot of the email 
infrastructure is not binary clean (e.g., a lot of mail stores will not 
store binary MIME with NUL octets). Now we do have BINARYMIME/CHUNKING 
extensions for SMTP as well as binary append and fetch extensions for 
IMAP. So I have no problem with JMAP requiring support for binary MIME 
on the wire; but it shouldn't say anything that prevents the server from 
converting to 8-bit MIME (using base64 to encode parts with NUL octets) 
for storage purposes.

		- Chris