Skip to main content

Minutes IETF116: jmap: Tue 04:00

Meeting Minutes JSON Mail Access Protocol (jmap) WG
Date and time 2023-03-28 04:00
Title Minutes IETF116: jmap: Tue 04:00
State Active
Other versions markdown
Last updated 2023-04-05



2023-03-28: 13:00-15:00 (Yokohama time)

Intro and notewell 5 min

JMAP - 50 min

Existing drafts:

  • blob / quotas (at RFC Editor) - 5 min
    Nothing to report
  • calendars / contacts (on hold for CALEXT) - 5 min

Neil Jenkins: Calendars is nearly done. Small changes 10->11
Joris Baum: CalendarPreferences object different. Prefer to have more
roles.. Autogenerated birthdays etc. then this will be an event property
and not on the folder.
Hans-Joerg: Many systems have autogenerated folders, don't want to
duplicate. Special use role property? Currently use heuristics based on
folder name to avoid duplication on migration (we know it will be
created by target system as well)
Neil: please follow up on list.
Neil: we have time while jscalendar update happens. Hoping to take to
last call after this meeting.
Robert: would like to comment on default alerts. Recently implemented
default alerts. JMAP Calendar spec currently defines "if in multiple
calendars, use alerts set on all calendars that the event is in" - do
wonder if we should allow a way for the implementation to say "two equal
alerts on different calendars with same trigger and action don't trigger
Bron: propose that the default alert IDs - if the same across multiple
calendars - be suppressed.
Robert: yes, but maybe have different IDs but the same semantics.

  • sharing 5 min

Neil: hoping to take it to last call directly after this meeting.

  • sieve 5 min

Ken Murchison: Added onSuccessDeactivateScript argument to /set
Otherwise ready for Last Call
Hans-Joerg: Will be talking in Extra, but might have an impact on sieve.
Stay tuned.

  • smime-sender 5 min

Alexey: Working through to-do list, have prototype version of auto
decryption now. Might need extension to query. Probably done next time.

  • tasks 10 min

Joris Baum
Version 6 released. Restructured Person object. New comments and
checklists properties.
Checklists - single object
Future work to restructure Person usage, survey usage, finalize folder
extensions, etc.
ደሳለኝ መኳንንት: Does this also support internationalized scripts?

New work:

  • jmap for Migration and Data Portability 15 min
    Joris Baum

Motivation - Move existing data between systems, have an API spec for
legacy systems, combine with other solutions
RFC8620 is feature rich and generic, but complex
"how to quickstart JMAP" - minimal requirements for one-time migration
Example: no query method, or no copy or changes methods
Simplified request scheme
Overview table for specific applications
Feedback from list that this doesn't conform with RFC8620.
Possible approach to use constant values of error responses instead of
simply omitting parts of RFC8620. For example, only one account with
accountID "self"

Neil Jenkins: Think this makes sense. Some implementations are very
strict and might fail otherwise.
Hans-Joerg: The use case they're focusing on is migration/portability,
especially export from legacy systems. No point in asking vendors to
implement methods they will never use.
Q Misell: Agree with overall approach. Less happy about internal errors
for core echo
Bron: Why not require core echo? It's very simple, not a big ask.
Jim Fenton: Think of this as a profile of the jmap spec.

Simplified request scheme - put request properties in the URI?
Neil: This is either extra work or something. Duplicating ways to do
Q Misell: Its own spec document would be useful
Jim Fenton: Be careful about anything that might be secret that goes
into the URI.
Bron: Consider http2 request that links to individual things you might
request. This would be a standards-track spec

JMAP debug - supply log messages alongside usual data exchange. Helps
with running on 3rd party infrastructure.

JMAP backend info - ability to identify servers that don't properly
follow RFC 8620

Hans-Joerg: These last 2 make sense when dealing with legacy situations.
For syncing contacts minimal API may be sufficient, so might be useful
beyond portability applications as well.

EXTRA - 50 min

Existing drafts:

  • partial / actionregistry (at RFC Editor) - 5 min

Murray Kucherawy: One issue - document says informational, rest says
proposed standard.
Alexey: Don't care which really.
Barry Leiba: What's wrong with publishing a new draft?
Decision: Alexey will publish a new draft with proposed standard in

  • imap-messagelimit - 5 min

Alexey: WIll be ready for next IETF.

  • imap-uidonly - 5 min

Alexey: Don't remember if there are open issues. Would like to
experiment a bit more with implementations but the text is almost done.

  • sieve-processimip - 5 min

Ken Murchison: Problem with some automated systems that don't send a
request in the data, user would like to have the event added to their
calendar. Should this be renamed? (not imip any more)
Neil Jenkins: Lean toward renaming
Alexey: Agree with Neil for simplicity. Should this wait for structured
Bron: Calling this process-calendar is a better idea
Hans-Joerg: Don't see a sieve extension for structured email soon, and
this might be useful sooner so don't wait.
Alexey: (agree)

  • sieve-snooze - 5 min

Ken Murchison: Only outstanding issue was Pete was unhappy with haing a
special "snoozed" mailbox.
Pete Resnick: Lowercase the MAY because it's not a protocol option.

  • imap-jmapaccess (in last call) - 5 min

Bron filling in: Help IMAP clients migrate to JMAP. We really want
Arnt (later):Would really like to see an implementation.

New work:

  • list-return-metadata - 5 min

Ken Murchison: Request annotation data along with LIST commend. Is this
worth WG adoption?
Alexey: Seems sensible.
Bron will issue call for adoption.

  • imap-inprogress - 10 min

Marco Battini: Command progress notifications for search on very large
folders and copy/move. Helps avoid user confusion. Send progress as a
percentage, consolidated among things happening in parallel.
Bron: Looks really good. Does there also need to be a way for clients to
ask the server to stop? Tags in responses: Don't put ] in your tags.
Need security considerations to make sure clients don't make assumptions
and divide by 0. Total and goal can change in both directions.
Alexey: All good points. Like this a lot. Having a structured field for
this is good.
Pete Resnick: This is good, but disagree with Bron: progress always has
to be positive. Clients can't act on this if it's random stuff. Support
adopting it.
Hans-Joerg: Also support this, second Pete's comments but think the
count could change because it may be hard to measure. Possible security
issue: is the server exposing information that might be exploited?
Concern re throttling: limitation on what a server allows a single user
to do.
Alexey: Throttling might be a separate thing.
Bron will issue a call for adoption on the list.

  • sieve-filter-rule-metadata - 10 min

Hans-Jörg Happel:
How is Sieve used in the wild? direct usage (expert users) via direct
file access or ManageSieve vs. indirect usage used by regular users. The
latter is the dominant form.
Indirect rules tend not to use things like ELSE and ELSEIF.
Problem: interoperability - More sophisticated Sieve UI may interfere
with vendor-specific scheme. So perhaps define standard set of rile
comments, recommended deeactivation method, etc.
Do we need "Sieve lite"?
Pete Resnick: Coming up with a document would be great, this is a severe
problem. Lots of interesting ways to approach this.
Hans-Joerg: Perhaps do something constrained like the comment thing.
Alexey: All implementations need to do things like comments so having a
common way to do this would be good. Like the document, glad we're
making progress.
Ken Murchison: Might affect jmap-sieve, but think this is outside the
Hans-Joerg: Being able to identiogy the source of the script would be
Bron: Proxies might interfere as well.

AOB - 10 min