Jmap Status PagesJSON Mail Access Protocol (Active WG)
Art Area: Adam Roach, Alexey Melnikov, Ben Campbell | 2017-Mar-16 —Chairs:
IETF-100 jmap minutes
Session 2017-11-16 1330-1530: Bras Basah - Audio stream - jmap chatroom
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.