Re: [Jmap] draft-ietf-jmap-mdn-06

[Bron Gondwana <[e-mail]>]

On Thu, Jun 11, 2020, at 20:39, cketti wrote:
> On 10.06.20 14:45, Bron Gondwana wrote:
>>> *3.1 Sending an MDN*
>>> 
>>> The Email/set example is incorrect. Since the implicit request is a patch to "keywords/$mdnsent", a server would not be expected to echo the full value of the keywords property in the result, since it didn't unilaterally change it. I would expect this response:
>>> 
>>>      [ "Email/set", {
       "accountId": "ue150411c",
       "oldState": "23",
       "newState": "42",
       "updated": {
         "Md45b47b4877521042cec0938": {}
       }
     }, "0" ]]
>>> 
>>> 
>>> Where "updated" maps the emailId from the forEmailId property to an empty object.
>>> 
> 

> This would be annoying for clients. They'd have to hard-code what the implicit Email/set looks like.

> It also makes it harder to change what the implicit Email/set call looks like in a future version of the spec. If an additional property was to be modified it would have to be included in the response to be backward compatible to this spec. Then you'd have to come up with a new way to specify an implicit request ("include these changed properties in the response, but not those").

> I do realize that including the modified keyword in the response makes things more complicated for the server. But to me it feels like the better alternative.


The argument of "if an additional property was to be modified" doesn't apply in JMAP land, because that additional property would come with an additional "using" parameter, and the client would have to set that - in which case it would know what the server would do. There's no backwards/forwards compatibility issue because the client explicitly requests which specs are to be used, and the server explicitly lists which ones it supports.

HOWEVER...

You raise pretty much the same objection that I have to implicit sets in the first place. They shouldn't exist. So what would it look like to have an EXPLICIT set?

       [[ "MDN/send", {
         "accountId": "ue150411c",
         "identityId": "I64588216",
         "send": {
           "k1546": {
             "forEmailId": "Md45b47b4877521042cec0938",
             "subject": "Read receipt for: World domination",
             "textBody": "This receipt shows that the email has been
                 displayed on your recipient's computer. There is no
                 guaranty it has been read or understood.",
             "reportingUA": "linagora.com; OpenPaaS",
             "disposition": {
               "actionMode": "manual-action",
               "sendingMode": "MDN-sent-manually",
               "type": "displayed"
             }
           }
         },
*         "onSuccessUpdateEmail": {
           "#k1546": {
             "keywords/$mdnsent": true**
**           }**
**         }*
       }, "0" ]]

This would match the semantics of EmailSubmission/set, which this is kind of a special case of in some ways, and would then mean that there's never any need to worry about the automatic tasks that the server takes, because it never does. Yes, you need to hard-code that logic into clients, but it strongly matches with my hard earned belief that automatic magical behaviour on the server is bad - the client should explicitly ask for side-effects.

I would also put a SHOULD or even MUST in the spec that the server reject an MDN/send which doesn't result in setting the keyword $mdnsent on the server in that case.

But - I'm happy with either way - but I'm not happy with requiring the Email/set response to act differently from every other triggered Email/set response, because as a server author this makes things really messy.

Bron.

--
 Bron Gondwana, CEO, Fastmail Pty Ltd
 [e-mail]