JMAP/EXTRA at IETF119, Brisbane

Tuesday 2024-03-19 13:00 AET (03:00 UTC)

Note well and note very well were presented.

JMAP - 55 min

With IESG (10 min total)

sieve - 3 min
- SECDIR review came in yesterday too.
- comment on "methodCalls" and "methodResponses"
- Murray: finished last call, sitting in queue, not as far along
  as we think.
- Joris: fine if you leave it, so long as it's on purpose.
- Neil: JMAP Request with a capital 'R' is the full object.
- Bron: doesn't need another WGLC.
- ACTION: Ken to update jmap-sieve draft with remaining IETF
  last-call feedback.
sharing - 2 min
contacts - 5 min
- Neil: no slides
- Murray has done AD review of these two
- Published a sharing update this morning which addresses those.
- Contacts, will do tomorrow. Hoping we can progress those to the
  next stage.
- No blockers or any other people raising issues.
- Sharing has gone to last call for IETF.
- ACTION: Neil will update sharing and contacts drafts

In WG Last Call (10 min total)

calendars - 10 min
- Neil: think we have a way forward.
- Rename "scheduleId" to calendarUserAddress ( removes dependency
  on iTIP)
- The JSCalendar-bis work will remove the
- Joris: sounds like main issue is resolve, and it can go through.
- Neil: hope we can get them over the line by next meeting.
- ACTION: Neil will upload updated jmap-calendars draft
- ACTION: Bron will refresh the WGLC after Neil uploads
  jmap-calendars.

Existing drafts (15 min total):

rest - 5 min
- Joris: explain WHY we have these three specs.
- all about reducing barriers; and helping wiht migration.
- People not very happy with how it is!
- Makes sense to talk about what we do about it
- No JSON in request, no Routing in URI.
- Neil: you can leave out query, but you need some way to get all
  the objects.
- Maybe if you GET without an ID, get the api/account/Calendar you
  get a token to get the next page. But don't think you need to.
  It's a clunkier syntax for JMAP!
- URI Templates vs what's in JMAP Core?
- Neil: JMAP Core is already URI Templates level 1.
- Joris: ok, nice - I overlooked that, thanks.
- ACTION: Joris to update jmap-rest based on feedback so far, and
  discuss on the list
portability-extensions - 5 min
- still needs some work!
- still need logs when server prints out error response
- ACTION: Ken will implement jmap-portability-extensions in Cyrus
  server to get more implementation experience.
portability-guide - 5 min
- Think it's close! Not sure what's needed here.
- Any feedback?
- Jim: this document name sounds like it's "a guide for moving
  data" rather than "make it easier for people to deploy"!
- Joris: was also thinking - is the naming right? Use case is
  portability for us, but maybe useful for others.
- Jim: working on deployment, didn't think to look at this
  document.
- Hasn-Joerg: some history -> starting point was portability vs
  full interoparability. For portability, do one-off import/export
  which is our use case. Needed to find a subset. Turned out might
  also be useful for low-level interoperability scenarios.
- Neil: I'll re-read where this has got to. Want to make point
  "bare minimum means it will still work with a JMAP client, just
  very inefficient if doing more than bsaic stuff".
- As a client, I would connect and it would work.
- Bare minimum doesn't support anything, can choose "do you want
  to support creating", "support reading".
- Neil: danger; people say "we support JMAP" but it doesn't work.
  Saw that with "we support IMAP"
- Bron: should we call it "JMAP minimal profile" maybe? General
  support in the room.
- Joris: would be good to distinguish between only reading, or
  writing.
- ACTION: All - read and review jmap-portability-guide!
- ACTION: Joris will make the distinctions more clear in
  jmap-portability-guide, and rename it "Minimal Profile" so it's
  clearer to people what it does.

Expired Drafts (10 min):

smime-sender (and alt) - 5 min
- Revising alternative approach draft. If people are happy with
  alternative, use that instead as v05.
- Neil: how many reasonable different operations are there? RHS is
  more flexible, but more ways to screw it up!
  - Like that it's lot harder as a client to get the left wrong.
  - RHS allows supporting triple wrap.
- Alexey: You can do things in S/MIME like Compress.
  - RHS is very flexible.
  - Philip is the one who wanted this.
- Neil: could make it a property on the email object. Then you
  could fetch it, and it would come back. But you can't. NO
- Robert: is there any order implied in the smime operations array
  - Alexey: yes. LHS was sign first then encrypt second. No way
    to express on the lhs.
- Bron: suggest that we define the best way to do it. Doesn't
  include BCC recipients now?
  - Alexey: no, not supported!
  - Barry: all the systems I'm aware of do separate messages to
    everyone.
- Ken: agree with Neil that RHS is maybe too complex, but LHS
  won't handle future best practice.
  - Alexey; yeah RHS lets you do silly things.
- Neil: Maybe LHS you want just one operation
  - Alexey: you might want to just sign, or encrypt and sign.
- Robert: just an object?
  - Alexey; no might want to sign twice.
- Alexey: Philip wanted RHS to create nonsensical options.
- Jim: speaking as an individual, I can think of situations where
  you might want more than one signature on a message; e.g.
  organisation and individual.
  - Alexey; the way it works with S/MIME - you encrypt payload
    with random key, and for each recipient you include "how to
    decrypt"
  - Jim: with signatures - can you have multiple signatures?
  - Alexey: think it's all dictated by S/MIME.
  - Jim: argues for more flexible approach.
- Bron: would say we should give an enum of hcp options; keep it
  very simple for the client.
- ACTION: chairs talk on best approach for JMAP S/MIME extensions,
  tell Alexey what to do.
tasks - 5 min
- Joris; haven't worked on it - status same as last time.
- Joris: Nice to see Calendars is progressing, so just need to
  catch up.
- ACTION: Joris to post new jmap-tasks draft.

JMAP AOB - 5 min

Barry heckled.

Webpush-vapid:

Neil; in support! You need it to support Push.
Think we should progress it to last call.
ACTION: Daniel to post new jmap-webpush-valid draft.
ACTION: Jim will do a WGLC for jmap-webpush-vapid after Daniel
publishes a new draft.

JMAP Milestone Review - 5 min

Ken: JMAP Sieve document had a /test method which was split out. Is
there interest?
- Alexey: I like it.
- Ken: did split into a separate draft with the existing test.
  Biggest open question was "are there enough parameters to handle
  what people might want to test"
- ACTION: Ken Will publish an individual draft for jmap-sieve-test

EXTRA - 55 min

Agenda Bash:

Spec about S-expressions? Do we need one?
- Nobody jumped up to say we want this.

With IESG: (15 min total)

imap-jmapaccess - 7 min (Ken has discussion points)
- Does not add any new grammar to IMAP
- Does not add any substantial new capability to IMAP
- Doesn't need a capability? But should it have one? My opinion is
  that it doesn't need one.
- Ken: had an argument with myself on the mailing list! My reading
  is that all we really have is a new response code. Doesn't need
  a capability. Arnt will remove the wording to remove confusion.
  - Only advantage I see to having a capability is that client
    can re-fetch if they miss it.
  - Fine with leaving as a response code if you need it.
  - Neil: client won't be asleep; if it wants it!
- Murray: IANA action missing.
  - Ken: when I thought capability, no IANA capability needed.
  - Arnt: IANA has done the action for response code.
  - Ken: it was my argument with myself.
- no action to do here.
imap-inprogress - 2 min
- Marco: minor revisions
- rewording examples.
- point from Murray - why SHOULD vs MUST?
- Didn't receive any negative or positive feedback.
- Murray: nothing outstanding, it's ready for IESG.
- no action to do here
imap-messagelimit - 2 min
- Didn't think I needed slides! But realised I had missed some
  comments.
- MULTIAPPEND says it's atomic - all success or failure. No
  partial failure.
- Barry: those two comments were intended for somebody who's just
  reading this document. One sentance to clarify.
- Alexey: difference between UID EXPUNGE and EXPUNGE. Reason for
  this "EXPUNGE shouldn't be used, it does everything".
- UID EXPUNGE mirrors how search and fetch works - if somebody
  hits limit, will get an error, same with UID expunge. Make it
  symetrical. If I say "EXPUNGE" it will do everything, if I say
  "UID EXPUNGE" it's limited, this is odd.
- Alexey: this is doing a chunked response - maybe UID expunge
  isn't a special case.
- Barry: if you can show a case where it's useful to have a limit
  on UID EXPUNGE; it's useful. Would prefer to see consistency
  with EXPUNGE rather than with these other commands.
- Alexey; don't think we've thought about - was more certain
  before coming to mike, now less certain!
- Trying to reduce memory usage on server; but deleting messages
  reduces disk usage, so...
- Ken: Clarification - is it up to the client to know what the
  limit is? And if they use multi-append and it takes them over,
  it fails. Same as with quota, etc.
- Optimisation to reduce round trips in some cases (used for
  migration sometimes) but it's a lousy situation! Have to fail
  the whole thing.
- Alexey: whole argument about what happens if you exceed the
  limit. Limit of 1000 was considered "reasonable". This affects
  users who keep all their email in one mailbox. Users with small
  mailboxes won't be affected.
- Barry: this is one of the first extensions we've put in which
  isn't compatible with clients who don't know about it.
- Alexey: don't know how to resolve this! Would rather not
  advertise soft limit. Can do that I suppose.
- Ken: agree with Barry, it's tough for existing deployed
  software. Clients that become aware of message limit can either
  limit size of mailboxes users can create, or tell them.
- Barry: raises issue that clients that know, will know and might
  try.
- Ken: ran into same situation with append limit - largely well
  known client trying over and over.
- Arnt: we have another extension LOGINDISABLED which limits IMAP.
  Record for client bugs provoked per extension. Limiting didn't
  work well for LOGINDISABLED except to say bad karma.
- Barry: maybe we need to say "servers can choose to tolerate
  badly behaved clients" - non-normative language.
- Alexey will look at UID EXPUNGE to see if there's a reason to
  limit it.
- ACTION: Barry and Alexey will wordsmith some text for
  MESSAGELIMIT handling of naive clients, then ask Murray to
  progress the document.
imap-uidonly - 2 min
- Alexey: response code SHOULD vs MUST - historically it's been
  good but world won't fall apart.
- Alexey: for debugging client bugs as well as for server
  operators to find out what issue is - if server returns just BAD
  - having UIDREQUIRED will give them something to Google.
- Arnt: if server disregards a MUST, protocol police will come
  arrest you.
- Alexey: is there a server where response code is more than a
  text string.
- Ken: as a server developer, it's trivial to add the code. If
  client violates MUST NOT they will know - but a BAD could be for
  other reasons, so including UIDREQUIRED will tell anyone looking
  what is up.
- Alexey: happy with MUST
- ACTION: Alexey to upload new revision of imap-uidonly, then
  Murray will progress it.
imap-list-metadata - 2 min
- RFC8792 describes how to notate overly long lines in text RFC!
  Will use that.
- ACTION: Ken will publish new revision of imap-list-metadata,
  then Murray will progress it.

Existing drafts: (10 min total)

email-snooze - 5 min
- Thought we had shelved it, not enough support for moving it
  forward.
- Could park it? "State Parked"
sieve-processimip - 5 min
- ACTION: Bron will WGLC sieve-processimip

Other work: (10 min total)

differences between IMAP4rev1+UTF8=ACCEPT and IMAP4rev2 (Arnt) - 10
min
- IMAP servers; discovered difference
- APPEND; (UTF {}) vs just {}
- Python imaplib is using 6855 syntax, always.
- Difficult to fix bugs in Python. Don't know that EAI is being
  used. Not much value in fixing it. Complication for not much
  reason.
- BODYSTRUCTURE is incompatible.
  - Dovecot will compute bodystructure once, send to every
    client that ask for it.
  - Problem for RFC6855 messages. If client has enabled
    UTF8=ACCEPT; then wrong one cached.
  - Alexey: problem that clients will barf if v2 bodystructure
    is returned.
  - Alexey: think 9051 is right! Arnt: agree.
- Pete: servers don't have a problem with looking through message
  and dealing with it.
  - My concern is that client which doesn't support UTF8 will be
    handed something that isn't UTF8.
  - If you append UTF8 in the headers, we won't handle it.
  - Pete: don't care how they do it; if I'm a client that
    doesn't say UTF8=ACCEPT, messages I get back shouldn't have
    UTF8 in the headers.
  - Arnt: all servers support an append.
- Pete: if I come along as a client which doesn't support UTF8,
  will you as a server downgrade it for me?
  - Arnt: all the servers which allow clients to retrieve
    UTF8=accept, they have a way to append message where the
    client says UTF8.
  - Arnt: if server wants to downgrade, can't rely on the append
    bit, also features a way to get message where append bit
    doesn't exist.
- Alexey: question is "client A appends with UTF-8, fetches with -
  fine". Client B - will it get UTF8, or downgraded version in the
  fetch?
  - Arnt: that question isn't related to appending.
  - Pete: reason we went to all this trouble; claimed "servers
    are too stupid" - server needs to handle multiple protocols.
- Pete: server has to hide or downgrade message. Do all servers do
  this?
  - Will servers blindly give out UTF8 to clients?
  - UTF8 marker in append - gives servers ways to resolve the
    problem.
  - Arnt: server has to take responsibility to for that anyway,
    supports multiple things.
- Ken: clients will push UTF8 regardless; we have to handle.
- Arnt: aware of multiple servers; who ignore UTF8 marker, or send
  random crap. So don't know.
  - Believe that all servers don't look at UTF8.
  - Ken: had a similar issue with Binary.
- Alexey: suggest we'll have an RFC which says "you have to
  downgrade".
  - Arnt: we have two RFCs which specify downgrading. If current
    document doesn't say it, we have to.
  - 6855-bis SHOULD say.
  - Arnt: how do you feel about an 6855-bis which is explicitly
    compatible with 9051.
  - Want it to be easy to do in client libraries.
  - Pete: has to say "you have picked up responsibility to do
    this"
- ACTION: Bron wil do call for adoption on 6855-bis.

Rechartering: 10 min

https://notes.ietf.org/extra-charter-bis
- Also - MAILMAN/MAILMAINT etc
Autoconfig and Big
talked in Prague about rechartering this group into a new working
group - want to let this one finish its work and wind it down;
unless this group thinks it needs to recharter to do new work. Call
it MAILMAINT maybe - charter by end of April. Go read the charter.
- expect it to charter by end of April

JMAP/EXTRA at IETF119, Brisbane

JMAP - 55 min

With IESG (10 min total)

In WG Last Call (10 min total)

Existing drafts (15 min total):

Expired Drafts (10 min):

JMAP AOB - 5 min

JMAP Milestone Review - 5 min

EXTRA - 55 min

Agenda Bash:

With IESG: (15 min total)

Existing drafts: (10 min total)

Other work: (10 min total)

Rechartering: 10 min

EXTRA AOB - 5 min

EXTRA Milestone Review - 5 min