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

From: "Bron Gondwana" <[email-masked]>
Date: Mon, 11 Feb 2019 09:25:30 -0500

Hi Raphaël,

This document recently expired. Do you have the time to prepare an updated draft before Prague?

Thanks,

Bron.

On Sat, Dec 22, 2018, at 04:05, Raphael OUAZANA wrote:
> 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_.
> > 
> >> 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 [3]] 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.
> > 
> > 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
> 
> _______________________________________________
> Jmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jmap
> 

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

---

From: Raphael OUAZANA <[email-masked]>
Date: Tue, 12 Feb 2019 10:07:51 +0100

Hi Bron,

Yes, I'll take the time to update it soon.

Regards,
Raphaël.

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 12 Feb 2019 04:14:49 -0500

Awesome, thanks for that.

Cheers,

Bron.

---

From: Raphael OUAZANA <[email-masked]>
Date: Wed, 27 Feb 2019 16:41:29 +0100

Hi,

Thank you for your comments. I handled them and created a pull request:
https://github.com/jmapio/jmap/pull/288

I finally decided to come back to directly send MDN, and not create 
temporary MDN. I also took time to explain other MDN related processes, 
and to add some examples.

I will take some time to handle eventual comments on the pull request 
before resubmitting an IETF draft.

Regards,
Raphaël.