Skip to main content

Minutes IETF113: jmap

Meeting Minutes JSON Mail Access Protocol (jmap) WG
Date and time 2022-03-21 13:30
Title Minutes IETF113: jmap
State Active
Other versions plain text
Last updated 2022-03-23

# JMAP @ IETF 113 -- combined with EXTRA

Monday 2022-03-21 13:30-15:30 UTC


Approximate time estimates - 75 min JMAP, 45 min EXTRA

Intro and Note Well: 5 min


With Editors:
- draft-ietf-jmap-smime / RFC9219 to be

Active Drafts: 65 min
- draft-ietf-jmap-blob - 5 min
- draft-ietf-jmap-quotas - 5 min
- draft-ietf-jmap-sharing - 10 min
- draft-ietf-jmap-calendars - 20 min
- draft-baum-jmap-tasks - 20 min
- draft-ietf-jmap-smime-sender-extensions - 5m

JMAP Milestone review: 5 min


With Editors:
- draft-ietf-extra-quota / RFC9208 to be

Active Drafts: 30 min
- draft-ietf-extra-sieve-action-registry - 10 min
- draft-ietf-extra-sieve-snooze - 10 min
- draft-ietf-extra-imap-partial - 10 min (if adopted)

Proposed: 10 min
- draft-murchison-sieve-processimip - 10 min

EXTRA Milestone review: 5 min


Bron presented the Note Well and meeting tips.

## jmap-smime

Alexey is working out a few formatting things with the RFC editor.  After that,
will be done.

## jmap-blob

Blob-set now Blob/upload
Catenate removed
Capabilities simpler (blob size etc)

Has gone through WGLC, so make comments soon if needed. Otherwise Jim will pass
it on to IESG

Comment: Hans-Jörg Happel --

* possible to explicitly only fetch the size, which is cheaper than fetching
just the data, so create an example with that, and point out the possibility.

Second: does it make sense to have a list of all blobs?  (Blob/query)

Alexey: think taking out catenate is good.

Neil: not sure Blob/query is a good idea.  Point was in-band upload and
download.  Blob isn't a real object in the same way.

ACTION: Bron to push out another revision of jmap-blob and then Jim will repeat

## jmap-quotas - Rene Cordier

QuotaIds removed, capability now an empty object
Removed custom extension for scope and resource type
Resource type in octets

ACTION: Bron to WGLC jmap-quotas

## jmap-sharing - Neil Jenkins

Draft is fairly simple, can probably progress quickly

1 more update then WGLC

ACTION: Neil to update jmap-sharing draft, then Bron to WGLC

## jmap-calendars - Neil Jenkins

Fair amount of implementation experience now.

### CalendarEvent#isSource
- property indicating if the JMAP server is the source or elsewhere
- Whether to send RSVPs or if you control it
- Any better names for this? (Barry Leiba suggests Controller)

Bron: Need to think about how this is set on import/export. Server needs to
know addresses it receives at.

Joris Baum: Added a source property for jmap-tasks so might be confusing to
have isSource and Source

### Default calendars: Does there need to be one?

Barry: default calendar is like IMAP INBOX.
* if needed and doesn't exist, create a new one.  So require a default.  Would
be useful to have

Ken Murchison: clearly in favour.  If a server processes iTIP, need somewhere
to put them. * Neil - does that mean MUST always be at least one? * What if you
delete it?  Have to create a new default?  Prohibit delete.  Barry Thumbs Up.

Pete / Barry -> maybe like with INBOX.

Robert S: don't care so much if default calendar MUST be specified.  Could
still state that servers might pick whatever calendar, or create one, or invite
can't be delivered. * Fastmail implementation: allow delete default, but
immediately pick a new one. * Might make sense in the spec to say "set to NULL,
but server might choose something else".

For participant identities -> should align JMAP and CalDAV spec.  6638 says "if
destoryed in caldav, this disables scheduling for that account" - suggests that
JMAP must be non-empty participant IDs. * Neil: Server is allowed to reject
destroy, and might reject you destorying your username.  Allow or not should be
a flag in capabilities.

Alexey: what are benefits of not having a default calendar?
* from IMAP experience, multiple outcomes is bad for clients.

Hans-Jorg: in favour of default calendar, unaware of systems that don't have
one.  And from UI perspective, would be weird. * most systems, default
pre-exists with a particular name and is a problem if it's deleted. * Case is:
not allow delete.

Ken: can't speak to interop, but:
* if the expects scheduling, they need at least one read-write calendar. 
Default is just "please put new invites here".  Shouldn't make it more than
that in JMAP.

### Default alerts for new calendar

- Default to null or default calendar alerts? or vendor specific?

Ken: Attach default alerts to principal

- Can you set default alerts if you don't have mayUpdatePrivate ACL?

Robert: Agree that setting default alerts then doesn't make sense

### Other preferences

like first day of week, date format

Daniel: Not sure why default timezone is by principal, rather than by calendar.

Neil: Calendar has a timezone, but inherits from principal

Daniel: feels like it belongs in the same place.  Ken agrees.

### IANA registry for per-user properties?

Bron: Should modify existing registry rather than create a new one. IANA can
handle registry mods.

Almost there, need to add examples. Hope to get to last call before next IETF

ACTION: Neil to update jmap-calendars draft with more examples.

## jmap-tasks - Joris Baum

Task survey posted on GitHub

Added `source` property, `estimatedWork`, `impact`.
Extended `progress` property, `relation` object.

### progress property

New values: deferred, resolved, needs-feedback, confirmed

Robert: think we can just extend the existing registry in jscalendar.

dkg: confirmed seems orthoganal to other properties.  Also not sure why both
Resolved and Completed.

Joris: methodology was looked at issue tracking systems - they have properties
like status, impact, etc.  Not sure if there's an issue tracker that allows
confirmed vs assigned.

dkg: have seen issue trackers where there's a separate state for "confirmed" vs
"assigned".  Useful to have separate tracking.  Would also be worth clarifying
resolved vs completed.

Joris: believe resolved == fixed, but completed might be a wontfix.  Just not
working on any more.

Maybe needs to be specified better.

ACTION: Joris to specify the progress tracking better, or split up.

Ken: agree that they're probably the same thing, naming is UI.

### grouping properties

Adding lots more properties to jsevent object, some systems don't need certain

Ken: why do we need grouping?  What's the goal?

Joris: if server does the whole JS calendar spec, you expect it to understand
all the properties.

Hans-Jorg: replying to Ken.  Found that task systems are much more hetrogenous
than calendar systems.  So many won't support all our fields.  If you want to
use this for interoperability, you need to be able to say what the servers
support somehow.

Neil: think that the grouping idea with a small set of possibilites makes sense.

Ken: rather than specifying which properties go in various groups, come up with
levels of capability.  Make the common stuff mandatory, then if you have other
feature sets, you describe the properties required.  Make the rest

Robert: if grouping comes, then suggest also introduce a new setError ->
notSupported, gives the required capability?

Ken: agree with Robert that for base draft, we can expect implementations to
know they don't support it, but for future extensions we're stuck either way.

### blob.created

When blob was created: do we want this?

Neil: we should put it on the referencing object (so inside the task/event) not
on the blob.

Robert: promised to come up with a spec for all JMAP object types for property
changes. * depends on the semantics -> if it's for the link, then it would be
when that was created - if it's for the underlying data, it's different. *
Joris: no consensus on this. * Hans-Jorg: think this is JMAP specific.  Most
systems don't let you reference items.  So what you're talking about is when
the user linked it.

### keywords

Discussed on the mailing list -> having the colour property on the task list
makes sense.

Same for calendar?  Neil -> haven't seen it there.

Neil: should it be a separate datatype?  TaskList object?  It's like a label.

Robert: like Bron's proposal.

### future work

Still need to get feedback from task system vendors.

### final notes.

Robert: for estimated work, think property is useful.  Not sure if arbitrary
number is useful, because probably mean different things for products and teams
-> may not be useful for interchange.  Wonder if impact is necessary, or if
priority is enough.  For source property _ wonder how much value it provides if
free-text.  Would different implementations do the same, or do we want to
enumerate?  Or product ID?

ACTION: Joris to produce an updated jmap-tasks draft based on feedback from
this meeting

## jmap-smime-sender-extensions - Alexey

No recent update to draft

S/MIME signing control

Daniel: believe we're reaching where default could be true.  Also how would
SMIME signing work?  Delegate keys to server -> Bron: yes, server is part of
your "end" in the JMAP case.

Alexey: we can talk about decrypting next time.


## extra-quota

Alexey: IANA issue being resolved, will publish soon.

## sieve-action-registry

Basically done - send to WGLC

ACTION: Bron to WGLC sieve-action-registry

## sieve snooze

Implemented at Fastmail in Cyrus.


Alexey: checked diff, is fine.

ACTION: Bron to WGLC sieve-snooze

## sieve process IMIP

Ken suggested this.  Decided on action vs test.  Documented what we implemented.

Deployed to Fastmail users last week, appears to be doing the right thing.

Alexey: have scanned the spec, seems to make sense.  Couple of comments:
* first time there's two output parameters, but seems OK.
* outcome: might be better to split into two different values
* Now that sieve action is in last call, have to deal with that.

Hans-Jorg: is there a standard way that IMIP is currently implemented in
systems?  And this hooks in a dependency.

Ken: only two ways known are:
* a) clients do processing
* b) server has an out-of-band way.
* this is a way for the user to be in control in a standard way.

Alexey: before it was hard coded everything or specific limits.

Ken: yep, and this doesn't tell you when to do processing, just how - you can
wrap sieve.

Bron: will do call for adoption on the list.

Alexey: not everybody will implement, but it looks sensible and belongs in this

ACTION: Bron to call for adoption sieve-process-imip

## imap partial

Extension to deal with large mailboxes (large >~50k)
- Paged search

Do we allow a mix of negative or positive?  No, it's one or the other.  E.g.

Clarified use of PARTIAL and CONSTORE ogether
New extenson: MESSAGELIMIT

Should COPY/UID COPY fail partially?
Bron: Should return an error
Ken: Does this affect inbox renaming?

Barry: previously don't have any stuff in IMAP where the server puts limits on
things that the client may not know about.  This is the first.  Don't like
this.  If the server tries to do anything above the limit, it should get NO.  A
client that understands the limit knows what to do.  A client that doesn't
understand won't do weird things.

Users will try clients, get error, complain, client has to discuss with server

Bron: agree, we should reject operation rather than partial complete.

Barry: as with what Ken said with INBOX rename.  Have to have an exception to
message limit for INBOX rename.  Server can say "NO" or has to do the lot.

Alexey: please send reminder to mailing list.

ACTION: update draft to say about INBOX rename.

Ken: as a server dev, think partial is straightforward to implement.  Have you
implemented in clients?  Would like to see running code.

Alexey: Did implement on client side.  But didn't test with server.  Actually
makes handling big mailboxes with webmail clients etc nicer.

Don't need to map 400k messages.

ACTION: Alexey to update imap-partial draft based on discussion at this meeting

## Milestone review (both WGs)

Appropriate adjustments made directly in datatracker.