Notes from JMAP session, IETF100, Singapore 16-Nov-2017

Authentication:
 * security area may have comments about auth options
 * Neil to write up security considerations section for
   authentication (including BASIC) ASAP.
 * Barry will forward draft to security area for early
   review.

Require/Using:
  * Should say URN rather than URL
  * Will use ietf: for standard specs, have vendors
    use URN in own domain for vendor extensions (like
    XML namespaces for *DAV)

Plurals:
  * debate over plural vs singular naming in methods
    and datatypes
  * all agreed that one is better than two, and there
    were no objections in the room to going with plural

Message Format:
  * tradeoffs between "easy for the common case" and
    "preserves the intent expressed in MIME structure"
  * core issue: IMAP clients currently have to fetch
    the BODYSTRUCTURE and then make grouped fetches for
    all the messages where the interesting text or html
    part has the same part number, leading to multiple
    round trips and client complexity.  We want to avoid
    this issue with JMAP.
  * possibly an array of text or html items rather than
    just a single item, annotated with source MIME part
    number like IMAP, with a selector syntax that
    allows for not transferring excessive copies.  The
    tricky area is only getting the most interesting
    one from multipart/alternative.
  * still have to solve the "return only N bytes" issue
    for clients that don't want to download potentially
    megabytes of plain text for big messages.

  * might have more discussion on the mailing list

SMIME signature verification on server
  * Alexey will look at writing up something for this,
    possibly a separate document rather than part of
    JMAP-Mail itself.

Security considerations:
  * will have to say something about HTML filtering
  * in particular, if an HTML part gets truncated in
    the middle of a URL this can be a security issue.

$Seen / rights:
  * preference for keeping parity with IMAP ACL spec,
    so $Seen (\Seen) flag gets a separate ACL
  * can always bundle rights on server
  * no strong preference either way for keeping $Seen
    as a keyword vs splitting out to a separate top-level
    isUnread value, but leaning towards keeping it as
    a keyword.

Document what "case insensitive search" means.
  * need to at least provide an option to specify a
    collation algorithm.
  * must support at least i;unicode-casemap
  * fuzzy is good as it allows servers to optimize
    without insisting on an exact algorithm which
    doesn't allow for improvements in search
    engine heuristics.

Searching in and returning headers:
  * lots of debate about decoding of unknown headers, where
    applying RFC2047 decoding may be incorrect, both for search
    and for display.
  * header names must be ASCII, so lowercasing is safe there,
    it is well defined.
  * there was no agreement in the room, we need to take this one
    to the list.  Should "unknown" headers be returned as raw 7bit
    bytes, or decoded to characters that become UTF-8 JSON?
  * likewise for search - does there need to a knob to do encoded/raw
    access to the header?

Editorial note:
  * examples are all $Keyword, but user-specified keywords don't have
    to start with $.  Should have some examples to demonstrate that.

More confusion over emailId vs Message-Id (RFC822/5322) header.
  * Multiple messages with RFC822-Message-Id can be allowed by the
    server, but they may have different emailId.
  * Indeed, depending on the server, even identical blobs might have
    different blobIds and if they are emails, identical emails might
    have different emailIds.

RFC822 import of invalid message:
  * can JMAP server modify during importMessages e/g stripping NULLs
    or fixing invalid headers?
  * everyone agreed: yes, so long as the server gives a new blobId
    for the message in the response.

Removal of messages or parts for policy reasons (DCMA / virus)
  * needs to be a way to say "POLICY REFUSED" when a message or
    even just blob is requested, regardless of whether the server
    still has a copy.

end.