* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Jmap Status Pages

JSON 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

Minutes

minutes-100-jmap-00 minutes



          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.
          
          



Generated from PyHt script /wg/jmap/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -