Subject: [Jmap] Ben Campbell's No Objection on draft-ietf-jmap-mail-14: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Wed, 20 Feb 2019 19:33:28 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-jmap-mail-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-jmap-mail/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for all the work on this. I have a few minor comments:

- Title, Abstract, and Introduction: Please expand JMAP on first mention.

§1.1: Is there a reason not to use the updated boilerplate from RFC 8174?

§1.5: "Servers MUST support the standard JMAP push mechanisms to receive
notifications when the state changes for any of the types defined in
this specification."
Which are the "standard" mechanisms? Does that mean both in-band notification
and the use of external push notification systems>

§1.6: "If a JMAP Mail server also provides an IMAP interface to the data and
supports [RFC8474] IMAP Extension for Object Identifiers, the ids
SHOULD be the same for mailbox, thread, and email objects in JMAP."
What happens if they are not?  (Why not MUST)?

§2: "This value is shared with
IMAP (exposed in IMAP via the [RFC6154] SPECIAL-USE extension).
However, unlike in IMAP, a mailbox may only have a single role,"
What happens if a mailbox is accessible via both IMAP and JMAP, and has
multiple roles in IMAP?

§7: "* "pending": It MAY be possible to cancel this submission."
The MAY seems more a statement of fact than permission.

---

From: "Neil Jenkins" <[email-masked]>
Date: Mon, 25 Feb 2019 00:02:16 -0500

Thanks for the comments.

> §1.1: Is there a reason not to use the updated boilerplate from RFC 8174?

This has been updated.

> and the use of external push notification systems>

I've rephrased this for clarity to reference the Core spec properly:

*Servers MUST support the JMAP push mechanisms, as specified in [@!I-D.ietf-jmap-core] section 7, to receive notifications when the state changes for any of the types defined in this specification.*

> What happens if they are not? (Why not MUST)?

It's not required for interoperability. But it's useful for building custom migration tools on top of, and given they have the same semantics it's confusing not to keep the same id.

> §2: "This value is shared with IMAP (exposed in IMAP via the [RFC6154] SPECIAL-USE extension).

The server must pick one to expose over JMAP, or modify the IMAP mailboxes to conform with this restriction. In practice almost all IMAP servers already enforce this and there are negligible instances of this in the wild; how to fix it should you come across it is, I think, best left up to the implementor, as they may have more insight into how it ended up this way in the first place and so how best to resolve.

> The MAY seems more a statement of fact than permission.

Yes, I will change this to lowercase.

Cheers,
Neil.