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

EXTRA AOB - 5 min

EXTRA Milestone Review - 5 min