Minutes IETF100: jmap
|Meeting Minutes||JSON Mail Access Protocol (jmap) WG|
|Title||Minutes IETF100: jmap|
|Other versions||plain text|
Notes from JMAP session, IETF100, Singapore 16-Nov-2017
* 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
* 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)
* debate over plural vs singular naming in methods
* all agreed that one is better than two, and there
were no objections in the room to going with plural
* 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
* 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
Document what "case insensitive search" means.
* need to at least provide an option to specify a
* 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
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?
* 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.