# JMAP/EXTRA at IETF114   {#jmapextra-at-ietf114}

2 hour session joint with EXTRA  
Freedom G   
[MeetEcho][1]

10:00-12:00, Thurs July 29, 2022.

# Agenda   {#agenda}

*   Intro and notewell by chairs 5m

## JMAP Section   {#jmap-section}

### Current Drafts   {#current-drafts}

*   blob 5m (Bron)
*   calendars 5m (Robert)
*   quotas 5m (René)
*   sharing 5m (Neil)
*   sieve 5m (Ken)
*   SMIME sender 5m (Alexey)
*   tasks 5m (Joris/Hans-Jörg)

### Proposed Work   {#proposed-work}

*   JMAP for Migration and Portability 10m (Joris)
*   JMAP Preferences (settings) 5m (Joris)

### Milestone review 5m   {#milestone-review-5m}

### JMAP AOB 5m   {#jmap-aob-5m}

## EXTRA Section   {#extra-section}

### Current Drafts   {#current-drafts-1}

*   imap partial 10m (Alexey)
*   process imip 5m (Ken)
*   sieve registry 5m (Alexey/Ken)
*   sieve snooze 5m (Ken)

### Proposed work   {#proposed-work-1}

*   snooze and mailboxids 10m (Rik)
*   list return metadata 10m (Bron)

### Milestone review 5m   {#milestone-review-5m-1}

### EXTRA AOB 5m   {#extra-aob-5m}

# Minutes   {#minutes}

## JMAP section   {#jmap-section-1}

### blob   {#blob}

Nothing exciting, Bron will do the final then WGLC

### quotas   {#quotas}

Rene: got a few more comments from Alexey, thank you for that.

Added a few more examples to make it more clear.

Ready for Working Group Last Call

### smime   {#smime}

Neil: spec looks good. Only bikeshed is renaming `headerProtect` to
something like `smimeHeaderProtect` to be consistent.

For decryption, probably do something with Email/parse, ran out of time
to do this round. Think this is the only thing left.

Should be ready for WGLC very soon.

Sachin? Question about decryption -> how would the server know the keys
to decrypt?

Alexey: since the extension already knows how to sign and encrypt, so it
already has the keys in some kind of directory where the key is.

So idea is -> that server has key? Yes. So the client doesn't have to
care.

Alexey: in my implementation, keys are auto-generated, so automatically
done on the server.

### tasks   {#tasks}

Joris.

Robert: for grouping, what should systems do if they get a JSTask that
includes properties that are in a group that they don't support? Reject?
Store?

*   e.g. a recurring task, what should something like Zimbra do if it
    doesn't support recurrences?
*   Joris: if you don't understand a capability as a server, can't
    remember what the spec says.
*   Robert: it would probably reject. Have to send the task along with
    the capabilities that the data contains.
*   Neil: think this is for client talking to server. The client will
    negotiate with the server to turn on features. If you're importing
    tasks, then the import tool needs to strip things that the server
    doesn't support.

Neil: there were more groups on the previous page. Are there things that
nobody uses?

*   Slide 6 has some capabilities that Slide 7 doesn't use. Maybe they
    got lost in the slides being added.
*   Joris: didn't look into those bits.

Sachin: should server be liberal in what it accepts? Neglect what it
doesn't know. Need to be broad minded in what it accepts.

*   Also: impact == priority. My thinking is that impact is "what
    impacts me as a person creating the tasks". Priority is my decision
    whether I want to do it!
*   Think that's a way to differentiate -> both the priority of the
    person requesting, and that of the person accepting

Alexey: regarding rejecting properties you don't understand. Would
prefer server to accept and store properties rather than just reject.

*   Joris: think that's a thing in the core spec. Not entirely sure but
    think it's defined like that.

Robert: Two remarks not related to grouping:

*   Estimated work: understand there's multiple scales for estimating
    work, but only a single numeric value. Would it make sense to add a
    property to define the scale it's stored in.
*   Joris: typically there's just a scale, but most systems don't have a
    unit. The common thing I found was the fibbonachi scale. Happy to
    say "this is just a value", depends on the team -> this is a 6, this
    is a 10, difficult to have an interoperable unit that different
    systems. Don't understand why fibbonachi should be mentioned.
*   Bron: at least a direction - is smaller larger, or bigger number?

Robert: Second thing, now that JMAP for Tasks defines updates to
JSCalendar. Question for chairs.

*   Bron: maybe cluster togeter, maybe put JSCalendar first.
*   Neil: this probably wants to go at the same time as JMAP Calendars
    as well.

Joris: getting feedback from vendors:

*   WeKan, 2Do, CalConnect.
*   Still some next steps before last call definitely.

Don't need anything from the working group.

Murray: can you create a milestone for this please!

## calendars and sharing   {#calendars-and-sharing}

Neil: calendars is waiting on resolving the jscalendar discussion in
calext right now, particularly around the participant correspondence.

*   Hopefully get that resolved soon, so hopefully can do that along
    with sharing and tasks.

## sieve   {#sieve}

Ken: no slides, only change since Vienna was tracking changes in spec.
Was just waiting for test method. Suggest pull it out and leave as
extension. Think with processimip, just remove test method from this
spec?

Think ready for WGLC after pulling test method.

Alexey: think maybe just leave it in? Can pull it out.

*   Ken: already has its own capability
*   Alexey: feels incomplete without it.
*   Ken: as a replacement for managesieve, test isn't necessary at all.
*   Ken: can take it to the list.
*   Alexey: don't feel strongly about it.
*   Alexey: see about extending imip action for it? See if there's a
    generic ability to extend it.
*   Ken: only fear is that without anybody implementing and using it,
    may be missing pieces! Hate to publish something that might now
    work.
*   Rik: for incompleteness, there's no capability that matches sieve
    script testing behaviour -> novel thing designed for it.
    *   The reason it's not been done at Fastmail because we haven't
        figured out how to present it to the user.
    *   As a replacement for managesieve, it's good to go.

Ken will remove and we'll do a WGLC.

## jmap for migration and portability   {#jmap-for-migration-and-portability}

Joris: could easily expose many things with this wrapper.

Would be nice to put in some public place.

Bron: was looking even a long way back at creating a REST style API to
access the same data.

Alexey: should definitely be a document on this, and Bron's idea makes
sense.

Joris: is there interest in having a document for this in this working
group? Does it fit charter.

Bron: publish a draft, we can call for adoption as informational.

## jmap preferences   {#jmap-preferences}

Joris: lots of different dimensions, scopes, etc.

Sangin: largely an implementation issue for implementations -> to get
the settings. Particular case.

*   Next steps, why should it be part of JMAP rather than known to
    specific implementation.
*   Think that the JMAP server might have specific configuration
    attributes rather than being part of the protocol specification.
*   Think it's out of scope for the protocol.
*   Joris: likewise think it's more of a best practice document than
    part of the protocol.

Neil: JMAP is the protocol, but this is stil data you want to
synchronise.

*   don't think there's any common enough subset that's worth making a
    standard datatype.
*   A best practices document for "this is what you should consider when
    creating a preferences object" -> we have a bunch of them at
    Fastmail but they're all quite specific.

Hans-Joerg: something that UIs and clients will use.

*   see several systems that do things in similar ways.
*   For migrations, this is always a problem because it's a lot of work
    to do a translation, so having a best practices for JMAP might help
    vendors to create similar things and help with migrations.
*   Don't know if it needs to be an RFC, but wouldn't rule out that it
    would be helpful to standardise parts of it.

Neil: regarding blocklists, would consider that a separate datatype.
Each item is a block (email address, name, etc) -> easier to resync
rather than just having a whole blob.

Hans-Joerg: Might make sense to work out some specific settings and see
if there's common ground on them. Might be an opportunity to work on
that.

## MILESTONES   {#milestones}

# EXTRA   {#extra}

## imap partial   {#imap-partial}

Will go to WGLC.

## process imip   {#process-imip}

In production at Fastmail, seems to do the job

Maybe WGLC will get reviews! With Ned gone, we're missing.

Neil: the doc references a calendarId, but from the draft there's no way
to know what a calendar ID is or where to get it from.

Ken: good point, I'll add some text for that.

## snooze   {#snooze}

Same, in production, works - have had some reviews

Will send to WGLC.

Alexey: should stagged documents so there's no more than 2 at the same
time.

Barry: would say "give them extra time".

*   Alexey: will you review?
*   Barry: yes

## sieve registry   {#sieve-registry}

Ken and Alexey think it's ready. Need reviews. To WGLC.

Slightly weird because it's more mechanical, but should double-check the
data.

Ken: added an entry to the registry in snooze draft.

## snooze via IMAP   {#snooze-via-imap}

Rik: snooze via IMAP present in a few clients and servers. Also in sieve
just now!

Basic proposed command: Based on JMAP Snooze semantics, which we haven't
done yet! Move into a snooze mailbox.

Rik: this is how Fastmail and other places work. If there's feedback,
we'll change it!

Flag changes! -> when you unsnooze a message, what do we do with the
awaken flags? Semantics here are that we clear them.

The \\Snoozed mailbox is not the same.

Neil: doesn't look like there's any way to specify a folder to return to
other than implicitly. We do use both at Fastmail.

*   Rik: this started as "what's the simplest we could do"

PHB: have you considered the interaction of this with tasks? When I'm
using this capability it's normally because I want to create a reminder
for myself.

*   Rik: I can daydream about what I want!

Hans-Joerg: a couple of questions!

*   How does this interact with existing clients? What is the client
    expected to do?
*   Some clients expect to move things to the Snoozed mailbox? Might
    have to migrate messages in.

Rik: the client is simply expected to show the user that the message is
back in the awakened to mailbox. We use a flag to indicate that the
message has returned to the mailbox. Think that a convention would be
useful but not necessarily.

*   Definitely make it clear this is a SERVER initiated unsnooze, so it
    should happen without a specific client.
*   Migration: would do it via

Barry: haven't read a draft. (there isn't one)

*   Barry: use of special-use mailbox, having one that's read-only is
    unique. Don't have one that doesn't let you move things in and out.
*   Think some servers don't have this requirement yet.
*   Rik: have two options -> either have default behaviour if moved in,
    and if moved out it's implicitly awoken.
*   Option: require ACL support and have ACL control.

Alexey: Agree with Barry, magic mailboxes aren't a great idea. The other
thing is "not yet fully sold of new command" -> we need to review all
extensions that affect UID COPY and UID MOVE to make sure this is
handled in the same way.

*   Suspect from the reaction from people remote and in the room that
    there's enough interest in this.

Pete: as describing this, wondered "what's the use of the Snoozed
mailbox in the first place"? Implementation-wise, why not just add the
snoozing to the message wherever it might live? The move mailbox could
be removed from this, could still implement it that way. As a generic
thing, add a "defer" command.

*   Bron: yeah and a UID MOVE removes the old one.
*   Alexey: agree with Pete, can do it with removal of flags.

Sachin: agree, should just put all of this on each message.

Ken: should look at the sieve snooze draft. Should align them.

*   Pete: glad to review it, have no dog in this fight. Seems like a
    cool feature, just architecturally it seems useful to make it much
    more generic.

Neil: disagree about making it more generic. There's a common paradigm
implemented in a lot of places. Trying to make it more generic than this
will mean most people won't implement it.

*   Rik: tentatively, the more general feels like the "all things to all
    people"

Neil: then clients could implement however they want, which loses the
value that multiple clients can have the same view.

*   Pete: because that's the way the backend does it! The reason IMAP
    was so messy is because that's the way Mark's filesystem did it.
    Because client had to work out what the backend did.
*   Rik: more generally -> if what we want is to handle Snooze, we want
    a way to make this something that multiple clients.
*   Neil: approach was more "this is how it works as a product",
    consistency for users.

Bron: want to align JMAP, IMAP and SIEVE?

Alexey: roughtly two ways to do this:

1.  magic IMAP keywords that make it disppear from the client
2.  a magic mailbox
    *   maybe once a draft is written, we'll discuss the approaches.
    *   Also suggest that chairs put a limit on how long we'll discuss
        and then pick one approach. Advantages and disadvantages.

Neil: it has to be a mailbox, otherwise it won't work in clients that
don't support it.

Alexey: server can still hide it from view. Magic keyword. We'll take
this to the list.

Sachin: mailbox as a concept or a place on the filesystem (implemented
in database, whatever) - might need to think more about how it would
happen in the database.

### the $new flag at Fastmail is useful (unsnoozed)   {#the-new-flag-at-fastmail-is-useful-unsnoozed}

And the SAVEDATE extension is useful.

## mailboxes as labels   {#mailboxes-as-labels}

Many clients let you see email with labels on it.

JMAP is built around the idea that an email is in multiple folders. If
we want to expose in IMAP, we need a way to do it.

Sachin: talking about things like Thunderbird on mulitple machines, best
place to put things like a Preferences object - have a way for clients
to store something. An object store at the server level, e.g. Outlook
does something that lets preferences go in the cloud.

*   Rik: Can definitely talk about JMAP being useful, but having a
    specific property "color" rather than other things. This bit is
    simple

## list return metadata   {#list-return-metadata}

Ken: this is the only way to get the information all at once, since when
METADATA was changed from ANNOTATION we remove the wildcard ability.
Adding this makes sense to me.

## MILESTONES:   {#milestones-1}

### EAI document!   {#eai-document}

Barry: can we just kick it away to the future?

Alexey: there is a document! Somebody from OpenXChange wrote something,
the difficulty is that last time Ned looked at it and said we needed
work.

Barry: push it a year?

Alexey: ask Stephan to refresh it, and adopt.

Bron to ask for an update.

Barry happy to take it over.

..

Sachin: Gmail has X-LABELS, but it uses names rather than IDs, similar
but worse!



[1]: https://meetings.conf.meetecho.com/ietf114/?group=jmap&short=&item=1