Skip to main content

Minutes IETF115: jmap: Thu 13:00
minutes-115-jmap-202211101300-00

Meeting Minutes JSON Mail Access Protocol (jmap) WG
Date and time 2022-11-10 13:00
Title Minutes IETF115: jmap: Thu 13:00
State Active
Other versions markdown
Last updated 2022-11-10

minutes-115-jmap-202211101300-00

JMAP / EXTRA at IETF115 London

Date: Thu 10 Nov 2022
Time: 13:00-15:00 local (12:00-14:00 UTC)

Chairs: Bron, Jim and Jiankang - all present in person!

Jim presented the notewell.

JMAP

blob

  • new draft update based on SECDIR review
  • Murray has no comments yet, may later

No actions required.

sieve

  • People had comments in WGLC.
    • Wanted to find why an action had failed through this protocol.
      Might be a good extension.
    • Currently to deactivate a script, you use activate script with
      an empty string. Request was to add an explicit deactivate. No
      strong opinion.

Alexey: don't mind, just tell me what to do

Ken: just followed Managesieve.

Neil: spec says should be NULL, not empty string

  • Advantage to separate property is you don't have to submit every
    argument, which could be valuable for strongly typed languages.
  • There's no value you can pass that doesn't do something in current
    spec.

Ken: no big deal, will add.

Hans-Joerg: remember quite some time ago discussed sieve for JMAP -
related to sieve in non-JMAP context (how people build sieve rules from
another system).

  • Concern with sieve for JMAP, would be nice to know the underlying
    system which owns the sieve. Could there be a property? Can it be
    derived from JMAP response?

Alexey: is it library or author?

H-J: sieve structured by underlying software. Helpful for client to
know. There's a greeting via ManageSieve. In ManageSieve RFC this is
described as:
IMPLEMENTATION - Name of implementation and version. This capability
MUST always be returned by the server.

Bron: server header via HTTP?

Ken: if this is important, we can add a property to the capability which
lists the implementation, but guess some sites might want to suppress
that and not leak the implementation.

ACTION: H-J and Ken to discuss on the list about representation
ACTION: Ken to add "disable"

calendars

Joris: recently synced the jstasks draft with changes from calendars,
there are a lot of parallels.

  • stumbled on the "CalendarPreferences" object, haven't tagged along
    yet.
  • in JMAP Mail, there's a "role" property. For calendars, this was
    also there. "inbox" only for now, to say "this is the default
    folder". In the newest version this is moved to a separate object,
    wanted to understand.
  • Don't like that we have two approaches, different from mail to
    calendars. Want to know reason.

Neil:

  • discussed this. In mail it's immutable. Want to enforce "at most one
    is the default". Easier to enforce with a single object, there's no
    way to specify multiple.

Robert:

  • Regarding the dependency -> at calext we set the deadline for
    jscalendarbis to July 2023. Under assumption that there's no hard
    dependency but will see if that's really the case.

Bron:

  • yep, we'll wait and do them together.

Robert:

  • Regarding role vs calendarpreferences, it's more straightforward to
    have one property where the default is defined rather than
    implementations having to look at all roles and make sure
    requirements are satisfied. Already have to do it for JMAP Mailbox.
    Don't have a strong opinion on either.

Joris:

  • one crazy thing you could do is have both. Calendar Preferences is
    already defined as an extension, so only have role as a property
    inside the folder, or also have the preferences object. Don't need
    to look at all calendars, just fetch the preferences object.
  • For our use case, would be easier if inside the folder.
  • Might make sense to take it to the list.
  • Feedback on both? Neil: prefer NOT both, it would get confusing.

H-J:

  • didn't have time to look up in spec, but sounded like the default
    folder is the only role in mind so far?

Neil:

  • yeah, it's not called that any more.

H-J:

  • Might be other roles that are interested like "autogenerated
    birthdays", etc.
  • If more than one role, might be worth adding that.

Bron:

  • Fastmail has something like that too.

H-J:

  • some systems won't allow you to do things.

Neil:

  • Can tell from ACLs
  • Might want to have more thane with these too.

ACTION: role vs preferences discussion to the list.

sharing

Extracted changes out, much simpler.

Probably publish at the same time as JMAP Calendars.

Ken:

  • if this applies to JMAP email, go ahead and publish straight away.

Neil:

  • it's kind of abstract, but could apply to mail - but you'd have to
    make a separate spec for it.

Bron:

  • suggest publish it first.

ACTION: Neil to fix editorial
ACTION: Jim will take WGLC when it's ready

quotas

In last call too. Thanks Murray for reviewing it.

Implementation in James server.

Screen share done!

identities

When frontend team started implementing, asked for a way to get default
identity to show.

Joris:

  • Also looked at this and saw the same thing, a lot of systems have a
    default signature. Also came up with own thing, will post it in the
    chat.
  • Own extension has signature name, and some systems have default for
    new vs reply vs forward signatures.

Rene:

  • could discuss more on the list.

Neil:

  • sort order might not be the right thing to do. Implies you might be
    able to manually order them. Have seen lots of "drag and drop
    mailboxes around" but generally identities are sorted alphabetically
    by a client.
  • Specifying default seems fine, ordering might be too complex.

Rene:

  • Rene

dkg:

  • Wanted to +1 the last two. There are potentials for multiple types
    of defaults, default for particular reply, etc.
  • Might want a different default when replying to a paricular person -
    want default or default in different contexts.
  • Leaves room for somebody to specify defaults for other contexts.

Bron:

  • Fastmail has more powerful stuff too, per-recipient address,
    different folder.

Neil:

  • The reason we didn't do more is it's hard to specify something
    universal that's powerful enough.

Rene:

  • Agree, yeah it's too complex. But at least a flag saying this is the
    default.

Neil:

  • Would definitely be a common thing

Jim:

  • A common case is with an organisation, where you might have a
    different signature for internal vs external email.

Joris:

  • With JMAP you can create your own extension and write your own
    capability, but if interest then discuss in IETF context.

ACTION: Rene will start discussion on the mailing list.

tasks

  • slide 6 -> should be VTODO not VEVENT

Robert:

  • Haven't given much thought on which I would prefer.
  • If this isn't a list, why is there a sort order property?
  • Why not a map of ID to propery (standard JMAP property)
  • Can be good reasons to use a list, but with key-value idiom you can
    patch update - add or remove, don't have to use whole list.
  • If you want to preserve the order, then the sortOrder property
    wouldn't be of use.
  • Second proposal looks more familiar to me in terms of how things are
    in other JMAP.

Jim Fenton:

  • Less about representation of multiple checklists, and how they will
    be handled.
  • Some clients support multiple, others don't.

Joris:

  • Didn't try to use clients, but Trello has API.

Jim:

  • Need to consider what clients can render, so if you have a client
    that doesn't support multiple checklists, do we determine client
    capabilities and handle them, or do the other checklists disappear?

Joris:

  • up to client how to handle.

Jim:

  • Not sure if client or server responsibility.

Joris:

  • Have a flag on the server to say "I do multiple checklists"

Jim:

  • does the client say it doesn't support multiple checklists?

Joris:

  • With how JMAP works now, would be easier other way.

Robert:

  • Other thing I was wondering about, are "assignee" and "isComplete"
    properties.
  • What's different between assignee and participant?

Joris:

  • Trying to keep checklist item as simple as possible, so not pull in
    whole complexity of task. Much simpler to have assignee.
  • Hmm, you're right - iit should be a participant. Goal is to make it
    simpler.

Robert:

  • Am biased obviously, thinking that using full blown task achieves
    everything you want minus the simplicity. Maybe a middle-ground to
    define what's necessary to achieve checklist. Use already defined
    scheduling properties and just not require implementation to do ALL
    of scheduling.

Joris:

  • If already implemented, should be easy to use.
  • Already a capability for "I support scheduling"

Robert:

  • want to support this for implementations that don't implement
    scheduing.

H-J:

  • For Jim, the case with mulitple checklists for Trello is a specific
    case, don't think we need to overengineer here.
  • From Audriga, coming from portability side, so interoperability is
    useful but format needs to be portable.
  • See this as an issue for the client, need to either support this or
    give a message to the user.
  • We're a third party system, in the middle - need to convert data,
    merge things together or whatever.
  • To Joris -> think it's necessary to have a "checklist" type,
    otherwise clients may be tempted to add properties to the task.
  • Issue for client - have to have all the instances and filter through
    them -> e.g. fetch a task and its related items.

Bron:

  • Propose that if doing muliple checklists, they're a single set of
    check items with IDs, and you can patch them - and a c

ACTION: Bron will send something to the list

Darrel:

  • Github issues allow you to create multiple checklists within a
    single issue as well.

ACTION: Joris keep working

smime

No changes

migration and portability

Last time Bron suggested path based

H-J:

  • One clarification -> the motivation is that we consider JMAP a good
    choice to wrap an existing legacy data store.
  • Increasingly seeing JMAP as a good option to lift existing data for
    migration purposes.
  • Not necessarily for public exposure, but restricted usage to move
    data.

ACTION: Joris will create a draft.

EXTRA

partial

  • Comments from Murray

ACTION: Alexey to publish changes when last call finishes

sieve action registry

  • Replied to Murray, he asked about a column. Need to decide.

ACTION: Alexey to publish changes

MESSAGELIMIT

split off

There is desire for server to be able to do this WITHOUT the client
opting in.

Client doesn't want to opt in, no benefit for client.

Barry:

  • what's the actual benefit to the server? If the client wants to copy
    10k messages, it just does 10 copy commands. You've made the client
    more complicated and the server doesn't have to do any less work.

Vikram:

  • primarily need this on fetch and search
  • problem is clients don't understand that there's a large set of
    messages and they give 1:* and it gets timeouts on server.

Barry:

  • so you want the client to do 10 copy commands?

Alexey:

  • can have the server keep sending untagged responses? Can do that to
    stop timeouts.

Barry:

  • if we make copy checkpointable (server just sends a checkpoint every
    N messages) then the client doesn't have to retry it and it fixes
    the timeout, but doesn't require client to resend every command.

Ken:

  • Want to clarify - we still allow server to return "NO MESSAGELIMIT"
    if too large.

Alexey: yes

Barry:

  • And we'll think about an alternative for copy that works better for
    Vikram's case.

Alexey:

  • then we remove ENABLE messagelimit.
  • unextended client will be unable to copy large message sets then.
  • Extra SEARCH criteria
  • Right now, you can't do a UID based range without doing two queries
    that you can't pipeline.
  • do we WANT to do this?

Barry:

  • It looks clever, will anybody implement this and care about it?

Alexey:

  • am writing a webmail server -> get lowest message that is non-junk
    non-deleted.

Barry:

  • Don't object if there are clients who will want to implement it?
    Just "will we write it up because it's cool"

Alexey:

  • Will play with it, and only write up if it's interesting. Not part
    of this document.

Bron:

  • re searchres: save what you found, so if limit, safe the limited
    bit.

Ken:

  • wouldn't be hard to implement (server side) in the Cyrus server
  • Don't think we'd implement at Fastmail
  • It'll be an option in the server.

Alexey:

  • if you can do it, would be good to have feedback.

Vikram:

  • will do interop testing in early Dec.

ACTION: Alexey do another revision and wait for implementations. Interop
testing in early Dec.

process imip

Don't think there's outstanding issues.

Got running code in production.

ACTION: Bron to do last call.

snooze

There was an issue with snooze via IMAP and special purpose mailbox.
Pete had an issue, haven't heard back. Ken will ask during emailcore.

JMAP upgrade

Ken:

  • think it's worthwhile
  • is there any reason to not put the URI in the capabilities post
    authentication?

Bron:

  • don't want to generate one for every single connection.

H-J:

  • I have a different use-case, platform migration.
  • Wonder if there's a bigger picture for this. Need to think more.
  • Maybe need to think more and come back on mailing list

Alexey:

  • IMAP has REFERAL extension which has a URI. There's a "server" and a
    "mailbox". If server, can just say "HTTPS URI is now legal, go
    there". Don't know if it's a good idea or not.
  • If we're going to automatically generate auth token when requested,
    it goes against OAuth philosophy, you'll get a token or it will
    fail. User might never see the page saying "you're connecting to
    this server". In which case doing SASL Oauth.

Bron:

  • sounds like an argument for "using OAuth via IMAP, same token".

H-J:

  • migration enthusiast.
  • Maybe some relationship to the draft in HTTPAPI working group for
    non-interactive OAuth.
  • Would it be better to support changing auth schemes in a different
    fashion. If provider is shutting down IMAP, client can tell user
    they now need to upgrade.
  • If we want clients to adopt, it will need to be explained.

Ken:

  • Getting too far into weeds, feels like poeple are interesting

Bron:

  • anyone want to speak AGAINST adopting?

Alexey:

  • Think there's enough interest in the room to investigate this
    problem. Don't think the proposal on the table is cooked enough to
    be adopted.

Barry:

  • Don't think things need to be fully baked to be adopted.
  • There's enough here to start thinking, can use that.

ACTION: Bron to put together a draft, then we can talk.

AOB

John Levine:

  • Have a draft to revivify Expires: header, do we want to add
    something to IMAP?

Alexey:

  • This is boolean, and flags aren't boolean.
  • Are you trying to get the server to annotate with "ISEXPIRED"?

John:

  • I think that's what I'm asking.

ACTION: To the list.