[Jmap] AD review of draft-ietf-jmap-mail-12

[Alexey Melnikov <[e-mail]>]

Hi,

The document is nearly ready for IETF LC, but there are a few things 
that need to be fixed before it would be ready to be reviewed by wider 
IETF community.


The document is not clear that RFC XXXX is draft-ietf-jmap-core-XX (This 
is only clear for somebody already following JMAP WG). If you don't know 
how to insert a proper Normative reference to draft-ietf-jmap-core-XX, 
at least add a note explaining that this is what is intended.


In Section 1.3.2:

    o  *submissionExtensions*: "String[String[]]" A JMAP implementation
       that talks to a Submission [RFC6409] server SHOULD have a
       configuration setting that allows an administrator to expose a new
       submission EHLO capability in this field.  This allows a JMAP
       server to gain access to a new submission extension without code
       changes.  By default, the JMAP server should hide EHLO
       capabilities that are to do with the transport mechanism and thus
       are only relevant to the JMAP server (for example PIPELINING,
       CHUNKING, or STARTTLS).  Each key in the object is the _ehlo-
       name_, and the value is a list of _ehlo-args_.  Examples of
       Submission extensions to include:

       *  FUTURERELEASE ([RFC4865])

       *  SIZE ([RFC1870])

       *  DSN ([RFC3461])

       *  DELIVERYBY ([RFC2852])

       *  MT-PRIORITY ([RFC6710])

Is it worth having a registry for these a la Section 6.2 of RFC 8494?


In Section 1.5:

    In addition, servers MUST support a psuedo-type called
    "EmailDelivery" in the push mechanisms.  The state string for this
    MUST change whenever a new Email is added to the store, but SHOULD

    NOT change upon any other change to the Email objects.

I think an example or pointer to an example would be useful here. I only 
found an example in JMAP CORE, but I am still not entirely sure what you 
are describing here.


In Section 2:

 > Servers MUST forbid sibling Mailboxes with the same name.

What exactly is this trying to say? Do you mean 2 siblings with the same 
name? (is it just a way to say that a mailbox name is unique among all 
of its siblings?)

Or does it mean that a mailbox A can't have sibling A? If yes, then why?


RFC 4314 (IMAP ACL) needs to be referenced at least Informatevely (due 
to Myrights command reference).



IMAP4rev1 (RFC 3501) should be an Informative reference (due to 
referencing the following terms: subscriptions, internal date).


In Section 4.1.2.1:

 >   A server MAY use heuristics to
 >   determine a charset and decode the octets, or MAY replace any octet
 >   or octet run with the high bit set that violates UTF-8 syntax with
 >   the unicode replacement character (U+FFFD).

Do we really want to encourage the "MAY use heuristics" part? Such email 
messages are non compliant and thus not in scope for this document!


So RAW will typically have the leading space, as most generated messages 
have a space after ":" that terminates the header field name. Is it 
worth pointing this out to implementors?

In Section 4.1.2.2:

 >5. Any [RFC6532] UTF-8 values decoded.

Decoded from what? They are already in UTF-8!

    o  Comment

RFC 5322 defines "Comments" header field (note that it is plural).

Also, what about "Keywords" header field?

Is it worth explicitly mentioning Content-Description header field here 
as well?


In Section 4.1.2.3:

"Any [RFC6532] UTF-8 values MUST be decoded." -- again, decoded from what?


Is RFC 2231 encoding allowed in this and the following section?


In 4.1.3:

asText and asAddresses is not defined in the document. Did you mean:

4.1.2.2.  Text

4.1.2.3.  Addresses

?

If yes, you need to clarify this somewhere.


In Section 4.1.4:

You need to define handling for unrecognised Content-Transfer-Encoding 
values here.


"cid:" needs to Normatively reference RFC 2392. HTML needs a reference 
as well.

In Section 4.2 (and similar text in 4.9):

maxBodyValueBytes:

  "The server MUST ensure the truncation results in valid UTF-8 and does 
not occur mid-codepoint." --

The document needs to make sure that this is only true for body parts 
which are known to be textual (e.g. text/plain, text/html, XML, JSON). 
If a body part is a JPEG image, this requirement doesn't make sense.



In Sections 4.8/4.9:

The document needs to explicitly allow EAI messages, not just RFC 5322 
format.


In Section 5:

HTML is now definitely a Normative reference. More details of what is 
expected in HTML escaping, other than <mark> wrap?


In Section 7:

Are "MDN" and "DSN" blobIds referencing only the machine parseable part 
or the whole multipart/report coming back? I think the document should 
clarify this and (ideally) give some examples.


End of Section 7.5:

  "The server MAY choose to localise this string into the user's 
preferred language, if known."

How can this be done? Should the identity object contain some preferred 
language tag(s)? This needs a bit more thought.


In Section 9.3: SMTP XCLIENT should be an Informative reference.


In Section 10.4.4 (Registration of JMAP keyword '$answered')

    Security Considerations: A server implementing this keyword as a
    shared keyword may disclose that a user considers the message as
    flagged for urgent/special attention.

This looks like a cut & paste error from the text specified for $flagged.

    This information would be
    exposed to other users with read permission for the mailbox keywords.


Best Regards,

Alexey