Subject: Re: [Jmap] Review: draft-ietf-jmap-mdn-04

From: "Bron Gondwana" <[email-masked]>
Date: Fri, 07 Feb 2020 15:07:00 +1100

HI Raphael - sorry for the late review and then being pushy! I'm keen to submit this for publication, but waiting for your response on the review.

FYI Ken has been working on an implementation for Cyrus IMAPd, so hopefully we'll have our own copy to test against soon :)

Cheers,

Bron.

On Wed, Jan 29, 2020, at 17:21, Bron Gondwana wrote:
> As promised, a review of the current draft.
> 
> *2.1 MDN/set*
> 
> Looking at this some more, it doesn't make sense to call this method /set - it doesn't work the same way as regular set commands. It doesn't create an object which can later be fetched, or return an id. It would be better to rename this so it doesn't create confusion.
> 
> I suggest something like:
> 
>        [[ "MDN/generate", {
         "accountId": "ue150411c",
         "for": {
           "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"
             }
           }
         }
       }, "R1" ]]
> Response:
>      [[ "MDN/generate", {
       "accountId": "ue150411c",
       "generated": {
         "Md45b47b4877521042cec0938": {
           "finalRecipient": "rfc822; [email-masked]",
           "originalMessageId": "<[email-masked] <mailto:[email-masked]>>"
         }
       }
     }, "R1" ],
>      [ "Email/set", {
       "updated" : [ "Md45b47b4877521042cec0938" ],
       ... 
     }, "R1" ]]
> 
> 
> and of course: there's also "notGenerated" : { "emailId" : { ErrorObject }} with probably a specific error code for mdnAlreadySent.
> 
> 
>        [[ "MDN/generate", {
         "accountId": "ue150411c",
         "for": {
           "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"
             }
           }
         }
       }, "R2" ]]
> Response:
>      [[ "MDN/generate", {
       "accountId": "ue150411c",
       "notGenerated": {
         "Md45b47b4877521042cec0938": {
           "type": "mdnAlreadySent",
           "description" : "$MDNSent keyword is already present"
         }
       }
     }, "R2" ],
> 
> 
> 
> The emailId makes sense as the key for the object, since it's only legal to do one per email.
> 
> *NOTE: *I didn't mention oldState and newState here. There's not much point, because the MDN itself doesn't have state. The Email/set response should have state, because email objects have state, but it doesn't make sense to have state for MDN objects, because you can't query or fetch them.**
> 
> *3.1. Sending an MDN for a received email*
> 
> The first example needs to show the Email/set response with the same method call id. There should also be an example (as above) for the error case.
> 
> *3.2. Asking for MDN*
> 
> "header:Disposition-Notification-To": "[email-masked]",
> 
> This doesn't do quite what you expect - default is "asRaw", which doesn't add a leading space. You probably want.
> 
> "header:Disposition-Notification-To:asText": "[email-masked]",
> 
> *3.3 Parsing a received MDN*
> 
> Likewise, this should have an example of what to do when it's called on a blob which doesn't parse as a MDN, or what happens when the blob doesn't exist.
> 
> 
> 
> *General Comments***
> 
> Ideally each method should mention what kinds of errors are likely to be created, e.g this kind of thing from RFC8620.
> 
>    The following SetError types are defined and may be returned for set
   operations on any record type where appropriate:

   o  "forbidden": The action
      would violate an ACL or other permissions policy.

   o  "overQuota": The create would exceed a server-
      defined limit on the number or total size of objects of this type.

   o  "tooLarge": The create would result in
      an object that exceeds a server-defined limit for the maximum size
      of a single object of this type.

   o  "rateLimit": Too many objects of this type have been
      created recently, and a server-defined rate limit has been
      reached.  It may work if tried again later.

   o  "notFound": The id given
      cannot be found.
> 
> Obviously, these need to be chosen from the existing error registry, or the IANA section should include registration for any newly added errors.
> 
> I expect security review might ask you to expand a little on the security considerations as well.
> 
> Cheers,
> 
> Bron.
> **
> -- 
>  Bron Gondwana, CEO, Fastmail Pty Ltd
>  [email-masked]
> 
> 
> _______________________________________________
> Jmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jmap
> 

--
 Bron Gondwana, CEO, Fastmail Pty Ltd
 [email-masked]

---

From: Ken Murchison <[email-masked]>
Date: Thu, 6 Feb 2020 23:17:45 -0500

On 2/6/20 11:07 PM, Bron Gondwana wrote:
> HI Raphael - sorry for the late review and then being pushy!  I'm keen 
> to submit this for publication, but waiting for your response on the 
> review.
>
> FYI Ken has been working on an implementation for Cyrus IMAPd, so 
> hopefully we'll have our own copy to test against soon :)
>
> Cheers,
>
> Bron.
>
>> Looking at this some more, it doesn't make sense to call this method 
>> /set - it doesn't work the same way as regular set commands.  It 
>> doesn't create an object which can later be fetched, or return an 
>> id.  It would be better to rename this so it doesn't create confusion.
>>

Or call the method /send or /submit, since it both generates the MDN and 
submits it to an MSA.

Also, should the request have an additional boolean argument which 
dictates whether the original message should be included in the MDN?

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Raphael OUAZANA <[email-masked]>
Date: Fri, 7 Feb 2020 13:27:49 +0000

Hi Bron,

Sorry too, I don't have much time to dig into this now.

Anyway I already proposed a version where the method was not called set, and I received some remarks telling me it should be a "set" method to be more uniform. So I'm waiting for a consensus on this subject before updating again the specification.

Else I generally agree on your remarks, just need time to update the doc.

Regards,

Raphaël.

Le 7 février 2020 05:07, de [email-masked]

Cheers,

Bron.

2.1 MDN/set

[[ "MDN/generate", {

Response:

[[ "MDN/generate", {
"accountId": "ue150411c",
"generated": {
"Md45b47b4877521042cec0938": {
"finalRecipient": "rfc822; [email-masked]",
"originalMessageId": "<[email-masked]>"
}
}
}, "R1" ],

[ "Email/set", {

[[ "MDN/generate", {

Response:

[[ "MDN/generate", {

NOTE: I didn't mention oldState and newState here.  There's not much point, because the MDN itself doesn't have state.  The Email/set response should have state, because email objects have state, but it doesn't make sense to have state for MDN objects, because you can't query or fetch them.

3.1. Sending an MDN for a received email

3.2. Asking for MDN

3.3 Parsing a received MDN

General Comments

Cheers,

Bron.

--

[email-masked]

Jmap mailing list

[email-masked]

--

[email-masked]

---

From: Raphael OUAZANA <[email-masked]>
Date: Fri, 7 Feb 2020 13:54:49 +0000

Le 7 février 2020 05:17, de [email-masked]

Or call the method /send or /submit, since it both generates the
MDN and submits it to an MSA.

Yes, /send seems a better naming for me, it was one of my first proposal (in fact I put it in MessageSubmission so it was MessageSubmission/sendMDN).

Also, should the request have an additional boolean argument
which dictates whether the original message should be included in
the MDN?

For me MDN are lightweight notifications with almost, and we tend to use them only for automatic handling, where the original message is ignored.

But you are right, being part of the specification it could be an added option.

Regards,

Raphaël.

---

From: "Neil Jenkins" <[email-masked]>
Date: Mon, 10 Feb 2020 14:55:33 +1100

> Yes, /send seems a better naming for me, it was one of my first proposal (in fact I put it in MessageSubmission so it was MessageSubmission/sendMDN).

The main issue with the original proposal was that this was not an action on MessageSubmission objects, so this wasn't the right noun to be on the left. We definitely want `MDN/`. While I originally thought this was a `/set`, having thought about this more I agree this is different enough that it should be called something different, so I agree with Bron it should be something like `MDN/send`.

Neil.

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 25 Feb 2020 08:10:01 +1100

Hi Raphael,

It would be good to get this edit done soon if you can so we can get the document underway before Vancouver.

Cheers,

Bron.

On Sat, Feb 8, 2020, at 00:54, Raphael OUAZANA wrote:

>> Or call the method /send or /submit, since it both generates the MDN and submits it to an MSA.

>> Also, should the request have an additional boolean argument which dictates whether the original message should be included in the MDN?

---

From: Raphael OUAZANA <[email-masked]>
Date: Wed, 26 Feb 2020 18:21:05 +0000

Hello,

It seems I missed this point while updating the draft.

I will wait for 1 or 2 days for remarks, and update again the draft with this added argument and eventual fixes from remarks.

Regards,

Raphaël.

Le 7 février 2020 14:54, de [email-masked]

Regards,

Raphaël.