Subject: [Jmap] Working group last call: draft-ietf-jmap-mdn-03

From: "Bron Gondwana" <[email-masked]>
Date: Thu, 21 Nov 2019 14:34:32 +1100

Thanks Raphael for uploading a new draft that updates the references to the published RFCs.

This email starts a working group last call, which will expire on Sunday December 8th (a little over 2 weeks from now). At that point the documented will be submitted to the IESG for publication unless problems are uncovered during the last call.

If you have any issues with this document, now is the time to raise them!

Cheers,

Bron.

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

---

From: "Neil Jenkins" <[email-masked]>
Date: Fri, 22 Nov 2019 12:51:52 +0800

Overall I think this doc is good. A few nits:

> o  forEmailId: "String" Email Id of the received email this MDN is
   relative to.

This needs to be nullable, as described in MDN/parse.

> o  originalMessageID: "String|null" (server-set)

I think this should be *originalMessageId* (lowercase d on the end) for consistency.

> *
> 2.1 <https://tools.ietf.org/html/draft-ietf-jmap-mdn-03#section-2.1>.  MDN/set

*
   Standard "/set" method as described in [RFC8620 <https://tools.ietf.org/html/rfc8620>] where only the
   _create_ parameter is supported.

This is not quite right: the "accountId" and "ifInState" arguments are fine. I think this text should say something like:

> Only create is supported; any attempt to update/destroy MUST be rejected with a "forbidden" SetError.

And as a general comment, in the final versions of RFC8620/8621 we cleaned up the formatting so it worked better in the plain text version of the RFCs; I suggest adopting the same. So we use "quote" for a property name reference (not _underscore_) and remove the *asterisks* around the property names in the definitions.

Cheers,
Neil.

---

From: "Bron Gondwana" <[email-masked]>
Date: Fri, 22 Nov 2019 16:19:14 +1100

Raphael,

With my chair hat on - I'm happy for you to either issue drafts with updates during the last call period, or wait until the end and issue another draft containing all the feedback at the end of the last call period.

Either way, I'm happy to submit to publication after this last call without doing another last call - so long as those who have given feedback during this time agree that it's been addressed in the final draft!

Cheers,

Bron.

   relative to.

   Standard "/set" method as described in [RFC8620 <https://tools.ietf..org/html/rfc8620>] where only the
   _create_ parameter is supported.
> _______________________________________________
> Jmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jmap
>

---

From: cketti <[email-masked]>
Date: Sat, 23 Nov 2019 19:44:18 +0100

Capability

>
>       1.3. Addition to the capabilities object
>
>
>
>    The capabilities object is returned as part of the standard JMAP
>    Session object; see the JMAP spec.  Servers supporting _this_
>    specification MUST add a property called "urn:ietf:params:jmap:mdn"
>    to the capabilities object.

This could be more explicit and require the value to be an empty object,
like it is for e.g. "urn:ietf:params:jmap:vacationresponse".

But I think the capability should also be added to the
"accountCapabilities" property of all accounts that support "MDN/set". I
assume in most deployment scenarios this will only be the case for
accounts that also have the "urn:ietf:params:jmap:submission" capability.
The availability of "MDN/parse" can then be tied to the capability being
present in "capabilities". The availability of "MDN/set" to the
capability being present in "accountCapabilities" of the specific account.

Text suggestion:

> Capabilities are announced as part of the standard JMAP Session
> resource; see [@!RFC8620], section 2.
>
> Support for the "MDN" data type and the "MDN/parse" method are
> represented by the capability "urn:ietf:params:jmap:mdn" being present
> in the "capabilities" property.
> The capability "urn:ietf:params:jmap:mdn" being present in the
> "accountCapabilities" property of an account represents support for
> creating and sending MDN messages via the "MDN/set" method.
> Servers that include the capability in one or more
> "accountCapabilities" properties MUST also include the property in the
> "capabilities" property.
>
> The value of this "urn:ietf:params:jmap:mdn" property is an empty
> object in both the JMAP session "capabilities" property and an
> account's "accountCapabilities" property.

          MDN/set and Email object modifications

"EmailSubmission/set" can also modify referenced "Email" objects. RFC
8621 requires the method to include an "Email/set" response with the
changes. It seems like a good idea to copy this mechanism for "MDN/set".

Text suggestion (mostly copied from RFC 8621):

> After all items in the "MDN/set" invocation have been processed, a
> single implicit "Email/set" call MUST be made to set the "$MDNSent"
> keyword on "Email" objects referenced by "MDN" objects that have been
> successfully created. The response to this MUST be returned after the
> "MDN/set" response.

          Minor issues

>    o  *forEmailId*: "String" Email Id of the received email this MDN is
>       relative to.

Expanding on the comment from Neil, the type should be "Id|null".

>    The Email/parse method takes the following arguments:
>
>    o  *accountId*: "String" The id of the account to use.

This should be "MDN/parse method" and the type for "accountId" should be
"Id".

Best,
cketti