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

["Bron Gondwana" <[e-mail]>]

On Thu, Jan 10, 2019, at 04:34, Alexey Melnikov wrote:
> Is it worth having a registry for these a la Section 6.2 of RFC 8494?

Do we want to do this afterwards and reference both JMAP and SMTP-SUBMISSION in an RFC which collects up the current status and bootstraps the registry, like we did for \Important? I ask because I'm not sure if we should do this work in JMAP or EXTRA.

> 
> 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?

It was the first of those, no two folders with the same (parentId, name) tuple.

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

This got discussed during the core review. I believe it's already fixed.

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

Yep, good point:

https://github.com/jmapio/jmap/issues/277

> 
> 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!

Leaving this one for Neil to comment on before creating an issue

> 
> 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?

That's sounds like a definitely worthwhile thing to point out!

https://github.com/jmapio/jmap/issues/278

> 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.

https://github.com/jmapio/jmap/issues/279
https://github.com/jmapio/jmap/issues/280

> 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.

The "bodyValues" is only defined for text/ parts I believe:

 o  *bodyValues*: "String[EmailBodyValue]" (immutable) This is a map
      of _partId_ to an *EmailBodyValue* object for none, some or all
      "text/*" parts.  Which parts are included and whether the value is
      truncated is determined by various arguments to _Email/get_ and
      _Email/parse_.  An *EmailBodyValue* object has the following
      properties:

Hence it always contains UTF-8 data.

> 
> 
> In Sections 4.8/4.9:
> 
> The document needs to explicitly allow EAI messages, not just RFC 5322 
> format.

https://github.com/jmapio/jmap/issues/281

> 
> 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.

https://github.com/jmapio/jmap/issues/282

> 
> 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.
> 

https://github.com/jmapio/jmap/issues/283

I also commented that it might be better to have the user's preferred language as part of core rather than part of mail.

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

https://github.com/jmapio/jmap/issues/284

> 
> 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.

https://github.com/jmapio/jmap/issues/285

Phew! Thanks for the detailed review Alexey.

Cheers,

Bron.

--
 Bron Gondwana, CEO, FastMail Pty Ltd
 [e-mail]