Re: [Jmap] Message Tracking and JMAP extensibility (was Re: Submission is not hard)

["Adrien de Croy" <[e-mail]>]

I think this is just another facet of the problem around implementation 
uptake of optional features.

There's still enough uncertainty about whether the entire end-to-end 
path of a message will support the envelope options to cast doubt onto 
any decision to implement it.  A lot of the specs for these options have 
quite onerous requirements for dealing with non-compliant systems (those 
that do not advertise the extension).

So I think this becomes a circular argument.  We don't make new things 
because history has shown new things don't get implemented.  New things 
don't get implemented because other existing things don't get upgraded 
to add them.

So I believe that's an argument to put things in from the start, rather 
than deferring things.

So much pain goes into trying to figure out how to deal with legacy 
non-compliant systems.

So I agree with Ted, we should do JMAP right from the start, and that 
can then provide some real benefit on the first hop, and real incentive 
for subsequent hops rather than a lowest-common-denominator approach.  
So IMO the starting point should be what can be the best possible first 
hop, in terms of best possible user experience.  Because for 
intra-server messaging, we can get (and then demonstrate/prove the value 
of) the benefit of this from the outset.

Adrien


------ Original Message ------
From: "Chris Newman" <[e-mail]>
To: "Adrien de Croy" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Sent: 22/04/2017 2:26:36 PM
Subject: [Jmap] Message Tracking and JMAP extensibility (was Re: 
Submission is not hard)

>On 21 Apr 2017, at 15:34, Adrien de Croy wrote:
>>------ Original Message ------
>>From: "John Levine" <[e-mail]>
>>To: "[e-mail]" <[e-mail]>
>>Cc: "[e-mail]" <[e-mail]>
>>Sent: 22/04/2017 3:16:36 AM
>>Subject: Re: [Jmap] Submission is not hard
>>>
>>>Finally, if people want to try whizbang ways to show animations of
>>>mail zipping through the aether, that sounds like a swell optional
>>>add-on to try and implement and test and perhaps bring back later as
>>>an extension, but it'd be nuts to try to invent it now.
>>
>>IME, if we don't design it now, it will never happen.  Surely it's 
>>important enough to do the work up front?
>
>I believe that client-convenient message tracking status is a desirable 
>feature of a mail system. But the real world shows that tracking status 
>and automated DSN/MDN handling is not sufficiently important for 
>clients to have used existing facilities to provide that functionality; 
>even though it's completely possible to do so. So no, I do not think 
>this feature should be included in the base JMAP specification and 
>believe the client developer community has spoken through their actions 
>that it is not high priority. Furthermore, Message Tracking 
>functionality is presently out of scope for the JMAP charter. The WG 
>Chair can shut down any significant discussion on the topic to keep us 
>on track to deliver the base JMAP specification.
>
>What I'd consider appropriate to discuss on this list is if JMAP is 
>extensible in such a way that we can add client-convenient tracking 
>status to JMAP in a future extension. Extensibility is critical for a 
>base specification to get right.
>
>Here's an example client-convenient tracking model: have a 
>server-mutable object attached to messages in the \Sent folder that can 
>convey tracking status along the lines of RFC 3887 + DSN + MDN. I 
>believe that's a completely workable model for message tracking that 
>can be added in the future as a JMAP extension. Such an extension could 
>go further and allow the JMAP view of the mailstore to convert DSN and 
>MDN to status on the message in the \Sent folder (if such a message can 
>be found) for clients that want the convenient 
>delivery/tracking/MDN-status feature.
>
>So the question that's in-scope for the working group is if there's 
>anything in the present design of JMAP that would prevent an extension 
>along those lines?
>
>   - Chris
>
>_______________________________________________
>Jmap mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/jmap