Minutes IETF126: jmap: Mon 14:30
minutes-126-jmap-202607201430-00

Meeting Minutes JSON Mail Access Protocol (jmap) WG
Date and time 2026-07-20 14:30
Title Minutes IETF126: jmap: Mon 14:30
State Active
Other versions markdown
Last updated 2026-07-22

minutes-126-jmap-202607201430-00

JMAP/CALEXT joint session at IETF126, Vienna

Monday July 20th 16:30-18:30 (2 hours)
Room Name: Park Suite 6

Intro and notewell: 5 min

CALEXT WG

documents: https://datatracker.ietf.org/wg/calext/documents/
material: https://datatracker.ietf.org/meeting/126/session/calext

With IESG / RFC Editor: 5 min

Ricardo Signes: 10 min

Phillip Hallam-Baker: 10 min

New Work — Ravi Kashyap: 5 min

Expired Drafts: 5 min

anything of interest to revive?

AOB / Milestone review: 5 min

JMAP WG

documents: https://datatracker.ietf.org/wg/jmap/documents/
material: https://datatracker.ietf.org/meeting/126/session/jmap

With IESG: 5 min

Mauro De Gennaro: 15 min

Bron Gondwana: 15 min

Alexey Melnikov: 5 min

Expired Drafts: 5 min

anything of interest to revive?

  • essential
  • portability
  • rest
  • smime-sender-extensions (see Alexey's alt draft above)
  • tasks

AOB / Milestone Review: 5 min

MINUTES

CALEXT

jscalendar

Robert speaking

  • In last call (one with ADs)
  • all done!

Neil: JMAP-Calendars went to AUTH48 and had to be held for JSCalendar
changes. Plan to do a short WGLC again on the minor changes made.

Neil will publish latest JMAP Calendars first.

ACTION: Chairs working group last call any calendar documents not
already (including JMAP Calendars)

jscontact

Robert speaking

  • 9555bis -> one more issue with localizations which will be done soon
  • should hold this for vcard4-bis changes and go together

JSContact at Fastmail:

  • Warts!
    • Street name & Number issues - ordering.

Bron: IETF has a liaison with ISO, we could ask them. Also, you could
state order in the object

  • Robert -> you can already give the order but maybe the
    implementation doesn't know. Would be great to have details from
    ISO.

ACTION: Bron to speak with ISO Liaison about address format spec.

No further work planned at the moment.

vCard4-bis

Rik speaking

  • some errata from 15 years ago!

Bron: what does a non-escaped comma mean in a URI?

Rik: if you know the type, you can parse it - if not you should treat it
as opaque!

text/directory => media type used by LDAP?

Andy: If you could tell me which errata are accepted but conflicting, I
can make it hold-for-doc-update, and there's an ldap mailing list.

Murray: can you tell me about text/directory?

  • Rik: in RFC introducting VCard 3, adds text/directory and some other
    things.
  • VCard 4: introduces text/vcard and deprecates text/directory.
  • Murray, so argument is that we shouldn't have deprecated it? Rik:
    yes

ACTION: Rik fold extensions into VCARD4-BIS that we should keep.

Cryptographic Extensions

PHB Speaking

  • Data URIs are bad because jscontact system shouldn't have to
    understand new formats.
  • have running code

Robert: would be in favour of doing a breaking change (so can store both
kinds of keys in the same object type).

  • PHB: also my preferred approach
  • won't break running code
  • Robert: shouldn't be afraid of breaking changes especially this
    early
  • Ken (via chat) +1 to breaking change

Robert: with registry of update sources - would you want that in
JSContact registry, or another registry?

  • PHB: IANA Registry under JSContact. Only reason not would be to use
    it for other data types (e.g. jscalendar)
  • Doesn't make sense unless we have millions of these.

AOB

Murray: may have a solution for text/directory.

JMAP

jmap-calendars

Spoken about during CALEXT

Mauro

Mauro speaking

  • Not much change since last sessions

Mail Sharing:

  • very simple

ACTION: Bron to issue WGLC for JMAP Mail Sharing

Metadata:

  • server advertises which objects you can add metadata to.
  • standard types
  • server advertises what's supported
  • properties -> pointers
  • IANA registry -> e.g. for filenode.

Will implement in Stalwart once people believe it's clean. Know people
who want to use this.

ACTION: All please read and give suggestions on JMAP metadata spec.

Result References:

Neil thinks too complicated. Suggested adding a Type property to
ResultReference object.

Arnt: Question about ERR -> drops some roundtrips, does it also drop
error handling between roundtrips? Does it make things atomic?

  • Mauro: if you're chaining requests and the first one fails, then
    second one fails. If error is that the query has no results, you
    know you can't trust the second one.
  • E.g. writing a calendar event and want to import participants from
    an object, but if query is wrong and yields no results then how do
    you handle that?
  • Query yielding no results is not an error.
  • Arnt: but still need error handling for servers that don't support
    it.
    • If referencing a previous item which failed then you fail this
      request, but if a query returns nothing that's not a failure.
    • Do we need to add a property for "must not be empty result set"?

Neil: was going to clarify for Arnt - don't think it affects error
handling, doesn't make things atomic, just reduces some round trips.

Alexey: Had dejavu with catenate etc in IMAP land, found it somewhat
useful but not widely deployed. Find some interesting enough, maybe
don't abandon but people need to think about it.

  • JSON pointer?
  • Ability to use in more places?

Mauro: server can say what it supports as well, JSON Pointer or JSON
Path? It's optional.

Bron: it's not dangerous to have this exist, question is who will
implement it.

Emailpush

Neil speaking

Not a lot to say. Last time were waiting for implementation experience.
Expect to have it by next meeting, and progress next time.

Mauro: have implemented it

  • Bundling the group of multiple email pushes so the payload does not
    get too big, but think we found a solution.

ACTION: Neil and Mauro to review bundling of pushes when multiple emails
being pushed and update emailpush draft

Filenode, etc

Bron speaking

Regarding "how much should we be compatible with"?

Arnt: just anything S3 supports. Everyone just cares about S3 compat!

Locking -> there wasn't significant interest for locking.

atomic swap -> clients use this for locking, so it's valuable to have
it. Will add to one of the existing specs.

ACTION: Bron to add more examples of interesting use cases and @Type
to FileNode

Mauro: Wants an extension for collaborative editing. Will talk about
what is involved in that during the week.

Bron thinks blobext is basically done.

ACTION: Jim to issue call for adoption for jmap object history and
conditional updates.

S/MIME

Alexey speaking

Bron: this looks like it should be a Blob/set option in the new blobext.

  • Alexey: woried about having to do everything in Blobext just to
    support this!

Bron: in favour of doing what you said on the slide.

ACTION: Alexey to update the adopted WG smime doc with the alt version

Parked docs:

Hans Joerg: majority of the expired docs were related just to our
use-cases.

  • Rest one appeared recently in context of somethign else.
  • Tasks - still on our agenda! Hope we get back to that soon.
  • Question for the room:
    • Have been discussing preferences things.
    • Missing something about Notes -> how do people deal with
      personal notes in their JMAP implementations. Would be natural
      for us. Reference in PDPa.
    • Also: working with Chat messages, but an import/export format
      maybe. Might be OK to use .eml mail files, but also interesting
      in options.

Alexey: devils advocate / serious? Can use metadata to store notes!

Rik: We implement JMAP Notes. You could use Files (in a format that
stores the text you want) - can have a separate account or datagroup for
it.

Hans-Joerg: appreciate the feedback, right now observing that a lot of
tools are moving to block-notes (e.g. like Notion). Maybe could just
store in a file, but -- even JMAP Contacts you don't really need because
you could just store it in a file.

Ben: Notes app for Nextcloud just uses TXT files on storage. Main issue
is "where do I store that?" -- don't want a directory visible to the
user. Want private storage for my app. Like how IMAP clients create
folders which show up - want it private.

... Tasks: if not solved by jscalendar, then is needed.

Rik: Tasks "solved" by jscalendar, but what it solves is the
representation of a VTODO (a JS Task) but we don't have a JMAP API to
manage them. Audriga's draft handles lots of formats. We want a minimal
core, plus extensions for the rest.

JMAP Server settings

Mauro: was supposed to work on with Hans Joerg. Already present in
Stalwart. Standard way to store/access/set common proporties defined in
most servers. Account settings, user timezone, language, etc.

ACTION: Mauro and Hans-Joerg to publish a draft for jmap account
settings.

Milestones

We did them.