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:
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.
partial
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.