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

["Neil Jenkins" <[e-mail]>]

Hi Raphael,

Sorry I missed replying to this before. In answer to your questions:

> >> The client SHOULD NOT issue a sendMDN request if the message has
> >> the
> >> "$MDNSent" keyword set. In this case, the server MUST reject the
> >> submission with a standard "forbiddenToSend" SetError.
> > 
> > I don't think this should be a forbiddenToSend error; that implies the
> > user does not have permission to send. An alreadyExists error might be
> > appropriate, or some kind of new "precondition-failed" type error.
> 
> I wrote it in the sense of forbidden by the RFC:
>  [...]In any case, in the presence of the $MDNSent keyword,
>  the client MUST ignore all other flags or keywords for the
>  purpose of generating an MDN and MUST NOT send the MDN.
> 
> AlreadyExists seems misleading as the user could just not want to send 
> the MDN, and in this case it will never exist. 

You mean the user set an `$MDNSent` flag but didn't send the MDN before?

> Maybe AlreadyProcessed or something like that then?

That would be OK, although I still think `alreadyExists` is a reasonable mapping.

> >> o *created*: "String[EmailSubmission]" A map of creation id
> >> (client-
> >> specified) to an email sent from the referenced properties.
> > 
> > The type says this is a map to EmailSubmission objects, but the
> > description says it is a map to an Email. Which is it?
> 
> I wrote a map to "an email sent [...]". Maybe my English is not good 
> enough, but for me an email sent means an EmailSubmission. How could I 
> clarify?

I would write "an EmailSubmission object" instead of "an email sent".

It's unclear to me exactly which properties you expect to be returned for the EmailSubmission object in this case. Is it creating a whole EmailSubmission record? This seems overkill and also a poor match: almost none of the properties are relevant or useful, and indeed would be confusing if you got this back with other EmailSubmission objects representing user email submission.

I think it would be better if it just returned a success/failure response, without creating an EmailSubmission object. The other, probably better and more JMAP-y way of modelling this would be to just use a standard "MDN/set" to create an MDN object, separate from the EmailSubmission data type entirely. There does not have to be /get, /query etc. methods.

> >> EMAILSUBMISSION/PARSEMDN
> > 
> > This method is nothing to do with EmailSubmission really. Probably
> > should be called MDN/PARSE.
> 
> Probably, I hesitated because like this all the MDN stuff is related to 
> EmailSubmission, but I can write a MDN/parse if you think it's better.

Yes, I think this would definitely be better. So this spec then defines the MDN data type, plus MDN/set and MDN/parse methods.

Cheers,
Neil.