Skip to main content

Minutes IETF119: jmap: Tue 03:00

Meeting Minutes JSON Mail Access Protocol (jmap) WG
Date and time 2024-03-19 03:00
Title Minutes IETF119: jmap: Tue 03:00
State Active
Other versions markdown
Last updated 2024-03-19


JMAP/EXTRA at IETF119, Brisbane

Tuesday 2024-03-19 13:00 AET (03:00 UTC)

Note well and note very well were presented.

JMAP - 55 min

With IESG (10 min total)

  • sieve - 3 min

    • SECDIR review came in yesterday too.
    • comment on "methodCalls" and "methodResponses"
    • Murray: finished last call, sitting in queue, not as far along
      as we think.
    • Joris: fine if you leave it, so long as it's on purpose.
    • Neil: JMAP Request with a capital 'R' is the full object.
    • Bron: doesn't need another WGLC.
    • ACTION: Ken to update jmap-sieve draft with remaining IETF
      last-call feedback.
  • sharing - 2 min

  • contacts - 5 min
    • Neil: no slides
    • Murray has done AD review of these two
    • Published a sharing update this morning which addresses those.
    • Contacts, will do tomorrow. Hoping we can progress those to the
      next stage.
    • No blockers or any other people raising issues.
    • Sharing has gone to last call for IETF.
    • ACTION: Neil will update sharing and contacts drafts

In WG Last Call (10 min total)

  • calendars - 10 min
    • Neil: think we have a way forward.
    • Rename "scheduleId" to calendarUserAddress ( removes dependency
      on iTIP)
    • The JSCalendar-bis work will remove the
    • Joris: sounds like main issue is resolve, and it can go through.
    • Neil: hope we can get them over the line by next meeting.
    • ACTION: Neil will upload updated jmap-calendars draft
    • ACTION: Bron will refresh the WGLC after Neil uploads

Existing drafts (15 min total):

  • rest - 5 min

    • Joris: explain WHY we have these three specs.
    • all about reducing barriers; and helping wiht migration.
    • People not very happy with how it is!
    • Makes sense to talk about what we do about it
    • No JSON in request, no Routing in URI.
    • Neil: you can leave out query, but you need some way to get all
      the objects.
    • Maybe if you GET without an ID, get the api/account/Calendar you
      get a token to get the next page. But don't think you need to.
      It's a clunkier syntax for JMAP!
    • URI Templates vs what's in JMAP Core?
    • Neil: JMAP Core is already URI Templates level 1.
    • Joris: ok, nice - I overlooked that, thanks.
    • ACTION: Joris to update jmap-rest based on feedback so far, and
      discuss on the list
  • portability-extensions - 5 min

    • still needs some work!
    • still need logs when server prints out error response
    • ACTION: Ken will implement jmap-portability-extensions in Cyrus
      server to get more implementation experience.
  • portability-guide - 5 min

    • Think it's close! Not sure what's needed here.
    • Any feedback?
    • Jim: this document name sounds like it's "a guide for moving
      data" rather than "make it easier for people to deploy"!
    • Joris: was also thinking - is the naming right? Use case is
      portability for us, but maybe useful for others.
    • Jim: working on deployment, didn't think to look at this
    • Hasn-Joerg: some history -> starting point was portability vs
      full interoparability. For portability, do one-off import/export
      which is our use case. Needed to find a subset. Turned out might
      also be useful for low-level interoperability scenarios.
    • Neil: I'll re-read where this has got to. Want to make point
      "bare minimum means it will still work with a JMAP client, just
      very inefficient if doing more than bsaic stuff".
    • As a client, I would connect and it would work.
    • Bare minimum doesn't support anything, can choose "do you want
      to support creating", "support reading".
    • Neil: danger; people say "we support JMAP" but it doesn't work.
      Saw that with "we support IMAP"
    • Bron: should we call it "JMAP minimal profile" maybe? General
      support in the room.
    • Joris: would be good to distinguish between only reading, or
    • ACTION: All - read and review jmap-portability-guide!
    • ACTION: Joris will make the distinctions more clear in
      jmap-portability-guide, and rename it "Minimal Profile" so it's
      clearer to people what it does.

Expired Drafts (10 min):

  • smime-sender (and alt) - 5 min

    • Revising alternative approach draft. If people are happy with
      alternative, use that instead as v05.
    • Neil: how many reasonable different operations are there? RHS is
      more flexible, but more ways to screw it up!

      • Like that it's lot harder as a client to get the left wrong.
      • RHS allows supporting triple wrap.
    • Alexey: You can do things in S/MIME like Compress.

      • RHS is very flexible.
      • Philip is the one who wanted this.
    • Neil: could make it a property on the email object. Then you
      could fetch it, and it would come back. But you can't. NO

    • Robert: is there any order implied in the smime operations array

      • Alexey: yes. LHS was sign first then encrypt second. No way
        to express on the lhs.
    • Bron: suggest that we define the best way to do it. Doesn't
      include BCC recipients now?

      • Alexey: no, not supported!
      • Barry: all the systems I'm aware of do separate messages to
    • Ken: agree with Neil that RHS is maybe too complex, but LHS
      won't handle future best practice.

      • Alexey; yeah RHS lets you do silly things.
    • Neil: Maybe LHS you want just one operation

      • Alexey: you might want to just sign, or encrypt and sign.
    • Robert: just an object?

      • Alexey; no might want to sign twice.
    • Alexey: Philip wanted RHS to create nonsensical options.

    • Jim: speaking as an individual, I can think of situations where
      you might want more than one signature on a message; e.g.
      organisation and individual.

      • Alexey; the way it works with S/MIME - you encrypt payload
        with random key, and for each recipient you include "how to
      • Jim: with signatures - can you have multiple signatures?
      • Alexey: think it's all dictated by S/MIME.
      • Jim: argues for more flexible approach.
    • Bron: would say we should give an enum of hcp options; keep it
      very simple for the client.

    • ACTION: chairs talk on best approach for JMAP S/MIME extensions,
      tell Alexey what to do.

  • tasks - 5 min

    • Joris; haven't worked on it - status same as last time.
    • Joris: Nice to see Calendars is progressing, so just need to
      catch up.
    • ACTION: Joris to post new jmap-tasks draft.

JMAP AOB - 5 min

  • Barry heckled.


  • Neil; in support! You need it to support Push.
  • Think we should progress it to last call.
  • ACTION: Daniel to post new jmap-webpush-valid draft.
  • ACTION: Jim will do a WGLC for jmap-webpush-vapid after Daniel
    publishes a new draft.

JMAP Milestone Review - 5 min

  • Ken: JMAP Sieve document had a /test method which was split out. Is
    there interest?
    • Alexey: I like it.
    • Ken: did split into a separate draft with the existing test.
      Biggest open question was "are there enough parameters to handle
      what people might want to test"
    • ACTION: Ken Will publish an individual draft for jmap-sieve-test

EXTRA - 55 min

Agenda Bash:

  • Spec about S-expressions? Do we need one?
    • Nobody jumped up to say we want this.

With IESG: (15 min total)

  • imap-jmapaccess - 7 min (Ken has discussion points)

    • Does not add any new grammar to IMAP
    • Does not add any substantial new capability to IMAP
    • Doesn't need a capability? But should it have one? My opinion is
      that it doesn't need one.
    • Ken: had an argument with myself on the mailing list! My reading
      is that all we really have is a new response code. Doesn't need
      a capability. Arnt will remove the wording to remove confusion.

      • Only advantage I see to having a capability is that client
        can re-fetch if they miss it.
      • Fine with leaving as a response code if you need it.
      • Neil: client won't be asleep; if it wants it!
    • Murray: IANA action missing.

      • Ken: when I thought capability, no IANA capability needed.
      • Arnt: IANA has done the action for response code.
      • Ken: it was my argument with myself.
    • no action to do here.

  • imap-inprogress - 2 min

    • Marco: minor revisions
    • rewording examples.
    • point from Murray - why SHOULD vs MUST?
    • Didn't receive any negative or positive feedback.
    • Murray: nothing outstanding, it's ready for IESG.
    • no action to do here
  • imap-messagelimit - 2 min

    • Didn't think I needed slides! But realised I had missed some
    • MULTIAPPEND says it's atomic - all success or failure. No
      partial failure.
    • Barry: those two comments were intended for somebody who's just
      reading this document. One sentance to clarify.
    • Alexey: difference between UID EXPUNGE and EXPUNGE. Reason for
      this "EXPUNGE shouldn't be used, it does everything".
    • UID EXPUNGE mirrors how search and fetch works - if somebody
      hits limit, will get an error, same with UID expunge. Make it
      symetrical. If I say "EXPUNGE" it will do everything, if I say
      "UID EXPUNGE" it's limited, this is odd.
    • Alexey: this is doing a chunked response - maybe UID expunge
      isn't a special case.
    • Barry: if you can show a case where it's useful to have a limit
      on UID EXPUNGE; it's useful. Would prefer to see consistency
      with EXPUNGE rather than with these other commands.
    • Alexey; don't think we've thought about - was more certain
      before coming to mike, now less certain!
    • Trying to reduce memory usage on server; but deleting messages
      reduces disk usage, so...
    • Ken: Clarification - is it up to the client to know what the
      limit is? And if they use multi-append and it takes them over,
      it fails. Same as with quota, etc.
    • Optimisation to reduce round trips in some cases (used for
      migration sometimes) but it's a lousy situation! Have to fail
      the whole thing.
    • Alexey: whole argument about what happens if you exceed the
      limit. Limit of 1000 was considered "reasonable". This affects
      users who keep all their email in one mailbox. Users with small
      mailboxes won't be affected.
    • Barry: this is one of the first extensions we've put in which
      isn't compatible with clients who don't know about it.
    • Alexey: don't know how to resolve this! Would rather not
      advertise soft limit. Can do that I suppose.
    • Ken: agree with Barry, it's tough for existing deployed
      software. Clients that become aware of message limit can either
      limit size of mailboxes users can create, or tell them.
    • Barry: raises issue that clients that know, will know and might
    • Ken: ran into same situation with append limit - largely well
      known client trying over and over.
    • Arnt: we have another extension LOGINDISABLED which limits IMAP.
      Record for client bugs provoked per extension. Limiting didn't
      work well for LOGINDISABLED except to say bad karma.
    • Barry: maybe we need to say "servers can choose to tolerate
      badly behaved clients" - non-normative language.
    • Alexey will look at UID EXPUNGE to see if there's a reason to
      limit it.
    • ACTION: Barry and Alexey will wordsmith some text for
      MESSAGELIMIT handling of naive clients, then ask Murray to
      progress the document.
  • imap-uidonly - 2 min

    • Alexey: response code SHOULD vs MUST - historically it's been
      good but world won't fall apart.
    • Alexey: for debugging client bugs as well as for server
      operators to find out what issue is - if server returns just BAD
      • having UIDREQUIRED will give them something to Google.
    • Arnt: if server disregards a MUST, protocol police will come
      arrest you.
    • Alexey: is there a server where response code is more than a
      text string.
    • Ken: as a server developer, it's trivial to add the code. If
      client violates MUST NOT they will know - but a BAD could be for
      other reasons, so including UIDREQUIRED will tell anyone looking
      what is up.
    • Alexey: happy with MUST
    • ACTION: Alexey to upload new revision of imap-uidonly, then
      Murray will progress it.
  • imap-list-metadata - 2 min

    • RFC8792 describes how to notate overly long lines in text RFC!
      Will use that.
    • ACTION: Ken will publish new revision of imap-list-metadata,
      then Murray will progress it.

Existing drafts: (10 min total)

  • email-snooze - 5 min

    • Thought we had shelved it, not enough support for moving it
    • Could park it? "State Parked"
  • sieve-processimip - 5 min

    • ACTION: Bron will WGLC sieve-processimip

Other work: (10 min total)

  • differences between IMAP4rev1+UTF8=ACCEPT and IMAP4rev2 (Arnt) - 10

    • IMAP servers; discovered difference
    • APPEND; (UTF {}) vs just {}
    • Python imaplib is using 6855 syntax, always.
    • Difficult to fix bugs in Python. Don't know that EAI is being
      used. Not much value in fixing it. Complication for not much
    • BODYSTRUCTURE is incompatible.

      • Dovecot will compute bodystructure once, send to every
        client that ask for it.
      • Problem for RFC6855 messages. If client has enabled
        UTF8=ACCEPT; then wrong one cached.
      • Alexey: problem that clients will barf if v2 bodystructure
        is returned.
      • Alexey: think 9051 is right! Arnt: agree.
    • Pete: servers don't have a problem with looking through message
      and dealing with it.

      • My concern is that client which doesn't support UTF8 will be
        handed something that isn't UTF8.
      • If you append UTF8 in the headers, we won't handle it.
      • Pete: don't care how they do it; if I'm a client that
        doesn't say UTF8=ACCEPT, messages I get back shouldn't have
        UTF8 in the headers.
      • Arnt: all servers support an append.
    • Pete: if I come along as a client which doesn't support UTF8,
      will you as a server downgrade it for me?

      • Arnt: all the servers which allow clients to retrieve
        UTF8=accept, they have a way to append message where the
        client says UTF8.
      • Arnt: if server wants to downgrade, can't rely on the append
        bit, also features a way to get message where append bit
        doesn't exist.
    • Alexey: question is "client A appends with UTF-8, fetches with -
      fine". Client B - will it get UTF8, or downgraded version in the

      • Arnt: that question isn't related to appending.
      • Pete: reason we went to all this trouble; claimed "servers
        are too stupid" - server needs to handle multiple protocols.
    • Pete: server has to hide or downgrade message. Do all servers do

      • Will servers blindly give out UTF8 to clients?
      • UTF8 marker in append - gives servers ways to resolve the
      • Arnt: server has to take responsibility to for that anyway,
        supports multiple things.
    • Ken: clients will push UTF8 regardless; we have to handle.

    • Arnt: aware of multiple servers; who ignore UTF8 marker, or send
      random crap. So don't know.

      • Believe that all servers don't look at UTF8.
      • Ken: had a similar issue with Binary.
    • Alexey: suggest we'll have an RFC which says "you have to

      • Arnt: we have two RFCs which specify downgrading. If current
        document doesn't say it, we have to.
      • 6855-bis SHOULD say.
      • Arnt: how do you feel about an 6855-bis which is explicitly
        compatible with 9051.
      • Want it to be easy to do in client libraries.
      • Pete: has to say "you have picked up responsibility to do
    • ACTION: Bron wil do call for adoption on 6855-bis.

Rechartering: 10 min


    • Also - MAILMAN/MAILMAINT etc
  • Autoconfig and Big

  • talked in Prague about rechartering this group into a new working
    group - want to let this one finish its work and wind it down;
    unless this group thinks it needs to recharter to do new work. Call
    it MAILMAINT maybe - charter by end of April. Go read the charter.

    • expect it to charter by end of April

EXTRA AOB - 5 min

EXTRA Milestone Review - 5 min