Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-mdn-00.txt

From: "Neil Jenkins" <[email-masked]>
Date: Tue, 04 Dec 2018 19:46:28 -0500

Finally sending my feedback on this draft, as promised in Bangkok. Sorry for the delay! Generally this looks good, just some comments to bring it up to date with the current JMAP conventions and a confusion over how you're actually meant to send the MDN! 
 
> *
> 2 <https://tools.ietf.org/html/draft-ietf-jmap-mdn-00#section-2>.  Email/createMDN
> 

*
>    The Email/createMDN method create a [RFC5322 <https://tools.ietf.org/html/rfc5322>] message from MDN
   properties.
 
Where are these Email objects being created? It's not clear to me whether these are intended to be saved to the account's mail store or not. If they *are* being saved to the mail store, we need to give mailboxIds and keywords arguments. If they are not being saved, but just being sent immediately, that needs to be made clear and the method probably renamed to *sendMDN*. 
 
>    It takes the following arguments:

   o  *accountId*: "String|null" The id of the account to use for this
      call.  If "null", defaults to the "urn:ietf:params:jmap:mail"
      primary account.
 
This should be non-optional now to match the same change in the other JMAP specs. 
 
   o  *mdns*: "String[MDN]" A map of creation id (client specified) to
      MDN objects

   An *MDN* object has the following properties:

   o  *referencedMessageId*: "String" Message Id of the received message
      the user wants to create an MDN for.
 
Again, to match current JMAP convention this should be `referencedEmailId`, or maybe just `forEmailId`? 
 
>    o  *subject*: "String" Subject that will be used as "Subject" header
      for this MDN.

   o  *textBody*: "String" Human readable part of the MDN, as plain
      text.

   o  *reportingUA*: "String" Name of the MUA creating this MDN.  It is
      used to build the MDN Report part of the MDN.

   o  *disposition*: "Disposition" Object containing the diverse MDN
      disposition options.

   A *Disposition* object has the following properties:

   o  *actionMode*: "String" This MUST be one of the following strings:
      "manual-action" / "automatic-action"

   o  *sendingMode*: "String" This MUST be one of the following strings:
      "MDN-sent-manually" / "MDN-sent-automatically"

   o  *type*: "String" This MUST be one of the following strings:
      "deleted" / "dispatched" / "displayed" / "processed"

   See [RFC8098 <https://tools.ietf.org/html/rfc8098>] for the exact meaning of these different fields.
 
This all looks fine. 
 
>    If the _referencedMessageId_, _subject_, _textBody_, _reportingUA_,
   _disposition_ properties are invalid (e.g. missing, wrong type, id
   not found), the server MUST reject the import with an
   "invalidProperties" SetError.
> 
>    If the email cannot be created because it would take the account over
   quota, the creation should be rejected with a "maxQuotaReached"
   SetError.
 
import -> create (I presume this is a copy-paste error) and the maxQuotaReached error is now just called `overQuota`. But rather than specify the last two paragraphs, probably better just to say it may return any standard SetError that is defined for a *create* in the core spec. 
 
>    The response has the following arguments:

   o  *accountId*: "String" The id of the account used for this call.

   o  *created*: "String[Email]" A map of the creation id to an object
      build from the referenced properties.  The _blobId_ field of the
      Email objects can then be used to effectively send the MDN.
 
Again, I'm unclear how you are supposed to use the blobId to send this MDN. The EmailSubmission object uses an emailId reference rather than a blobId. If it's creating an email object, it also needs to be clear about which properties the servers should return for each object in the response (e.g. id, threadId, blobId, etc.). 
 
>    o  *notCreated*: "String[SetError]" A map of creation id to a
      SetError object for each Email that failed to be created.  The
      possible errors are defined above.
 
This document needs a security considerations section at the end. 
 
Cheers, 
Neil.

---

From: Raphael OUAZANA <[email-masked]>
Date: Fri, 21 Dec 2018 18:05:07 +0100

Hi Neil,

Thank you very much for your feedback. Not enough time to handle it for 
the moment, but it will be in my next year resolutions.

Regards,
Raphaël.

Le 2018-12-05 01:46, Neil Jenkins a écrit :
> Finally sending my feedback on this draft, as promised in Bangkok.
> Sorry for the delay! Generally this looks good, just some comments to
> bring it up to date with the current JMAP conventions and a confusion
> over how you're actually meant to send the MDN!
> 
>> 2 [1].  Email/createMDN
>> 
>> The Email/createMDN method create a [RFC5322 [2]] message from
>> MDN
>> properties.
> 
> Where are these Email objects being created? It's not clear to me
> whether these are intended to be saved to the account's mail store or
> not. If they _are_ being saved to the mail store, we need to give
> mailboxIds and keywords arguments. If they are not being saved, but
> just being sent immediately, that needs to be made clear and the
> method probably renamed to _sendMDN_.
> 
> Again, to match current JMAP convention this should be
> referencedEmailId, or maybe just forEmailId?
> 
>> See [RFC8098 [3]] for the exact meaning of these different
>> fields.
> 
> This all looks fine.
> 
> import -> create (I presume this is a copy-paste error) and the
> maxQuotaReached error is now just called overQuota. But rather than
> specify the last two paragraphs, probably better just to say it may
> return any standard SetError that is defined for a _create_ in the
> core spec.
> 
> Again, I'm unclear how you are supposed to use the blobId to send this
> MDN. The EmailSubmission object uses an emailId reference rather than
> a blobId. If it's creating an email object, it also needs to be clear
> about which properties the servers should return for each object in
> the response (e.g. id, threadId, blobId, etc.).
> 
> Links:
> ------
> [1] https://tools.ietf.org/html/draft-ietf-jmap-mdn-00#section-2
> [2] https://tools.ietf.org/html/rfc5322
> [3] https://tools.ietf.org/html/rfc8098
> 
> _______________________________________________
> Jmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jmap