Subject: [Jmap] Review of draft-ietf-jmap-mail-06

From: Stephan Bosch <[email-masked]>
Date: Mon, 30 Jul 2018 17:53:09 +0200

Hi,

Here are some of the comments and suggestions I collected while reading 
draft-ietf-jmap-mail-06. As stated in my previous review, I haven't 
followed the discussions and developments much lately, so there could be 
some stuff there (design choices) that is obvious to everyone else, but 
not to me. Some comments may therefore be redundant.

Text from the document itself is pasted here as-is. My comments are 
prefixed with "-> ".

Regards,

Stephan.

## Section 1.1:

*sever-set*:
-> Typo

Section 1.2:

-> Why not refer to core, where this information is replicated?

## Section 2:

This may be any Net-Unicode string ([RFC5198]) of at least 1
character in length and maximum 255 octets in size.
-> 255 octets could be very limited for languages involving multi-byte
characters. Could this perhaps be a server capability property? Where 
does this limit come from anyway? IMAP?
-> Also, stating the limit in octets rather than UTF-8 characters (or 
maybe just codepoints) makes this inconsistent between languages (for 
display).

-> Is there a maximum mailbox hierarchy depth? How would the client know 
about it? What minimum depth must be supported by any server?

-> How are IMAP namespaces mapped to JMAP? More specifically: how are 
personal and shared mailboxes identified in JMAP?

## Section 2.3:

-> How to find a mailbox by name without downloading the full list?
-> Should wildcard name queries be possible?

-> Why only *hasRole* and not allow query for a specific *role* and a 
value of "*" meaning any? I think this could be particularly useful for 
backreferences to operate on a specific mailbox by role rather than id 
or name.

-> Comparing to IMAP LIST-EXTENDED: Would filters for *hasChildren* be 
useful?

## Section 4.1.1:

       *keywords*: "String[Boolean]" (default: "{}") A set of keywords
       that apply to the email.  The set is represented as an object,
       with the keys being the _keywords_. The value for each key in the
       object MUST be "true".
-> Why is this an object?

   o  *receivedAt*: "UTCDate" (immutable; default: time of creation on
       server) The date the email was received by the message store.
       This is the _internal date_ in IMAP.
-> Could we define savedAt already (IMAP SAVEDATE)?

## Section 4.4.2:

    o  *allInThreadHaveKeyword* - This value MUST be considered "true"
       for the email if *all* of the emails in the same thread
       (regardless of mailbox) have the keyword given as the _keyword_
       property on this _Comparator_ object.
-> There is no _keyword_ property in this _Comparator_ object.

## Section 4.4.3:

"collapseThreads == true"
-> Editorial comment: shouldn't this just be a sentence? This looks weird.

## Section 4.6:

-> Should we add a "tooLarge" SetError? (defined for EmailSubmission/set)

## Section 4.7:

    If the email cannot be imported because it would take the account
    over quota, the import should be rejected with a "maxQuotaReached"
    SetError.
-> core, Section 4.3 defines "overQuota"

## Section 5.3:
    o  "maxQuotaReached": The user has reached a server-defined limit on
       the number of identities.
-> core, Section 4.3 defines "overQuota"

-> Should we add a "tooLarge" SetError? (defined for EmailSubmission/set)

## Section 9.3:

-> Please provide an URL reference for SMTP XCLIENT capability, or at 
least describe it here in more detail.
-> Same for "milter protocol"