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

[Raphael OUAZANA <[e-mail]>]

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.

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jmap