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

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

On 21 Apr 2017, at 19:42, Adrien de Croy wrote:
> 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.

If JMAP is well aligned with submission, that's one less barrier to 
deployment of extensions. If it's not well aligned, then we have to 
change another spec and another piece of software to get something new 
deployed. I agree we should not make the extension uptake problem worse 
by having JMAP out of semantic alignment with Submission for extensions.

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

I made this exact argument many times while developing the ACAP base 
specification. It resulted in a 44-page specification that was unwieldy 
to implement and thus failed to deploy. I am opposed to changing the 
JMAP working charter to allow us to go down that path for message 
tracking/status functionality. I take this position because I want JMAP 
to deploy and I try to learn from my past mistakes.

At this point, I don't think I have anything more to add on the message 
tracking/status issue.

		- Chris

> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_jmap&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=QBZgPENFbjFadxqU4HJ3ZDpRz3X1JlDY-keqMt52FFo&m=3-MZtEL_JnGA64bIHNq8ZGszP3FJT07irtG2_lYIYrk&s=yXtYh6_dIHPe2bohL8G5YBE_9y5bxVWBqwJgKr_Pvzs&e=