Skip to main content

Minutes IETF118: jmap: Tue 08:30

Meeting Minutes JSON Mail Access Protocol (jmap) WG
Date and time 2023-11-07 08:30
Title Minutes IETF118: jmap: Tue 08:30
State Active
Other versions markdown
Last updated 2023-11-07



Tuesday 2023-11-07 09:30 CET (08:30 UTC)

Intro and notewell 5 min

  • Bron and Jim did intro


In WG Last Call: (5 min total)

  • sieve - 3 min
    • Ken - No slides, no comments, ready to go to IESG

ACTION: Bron to submit jmap-sieve document to IESG

  • sharing - 2 min
    • Neil - should have gone to last call
    • will do contacts and calendars

ACTION: Bron to complete jmap-sharing WGLC

  • calendar - 5 min
  • contacts - 5 min
    • jscontact is basically done
    • Just published updated JMAP Contacts and JMAP Calendars specs
    • Actually think both are ready.
    • Once both are published, can update the spec and they're both
      ready for WGLC.
    • Were waiting for JSCalendar BIS
    • Robert - the work on it (from calext working group) has been
      dormant while we focused on jscontact last year.
    • Will go into more detail in the calext meeting later today - but
      nothing in jscalendar-bis should be a blocker for JMAP for
      calendar or JMAP for tasks.
    • Will see if -bis is needed.
    • Neil: one thing we might need is scheduleid, but we don't need a
      bis document, could even document in JMAP Calendars and add to
      the registry.

ACTION: Jim/Bron to do WGLC on JMAP Calendars/Contacts

Existing drafts:

  • smime-sender (and alt) - 5 min

    • Have we done WGLC?

      • Bron: no, we haven't.
    • Suggestion to make it more generic

    • Array of actions?
    • Control over which headers are protected:
    • Neil: a thought on the properties - would be nice if "this is
      what it is" rather than "this is what you should do".

      • "This message is SMIME encrypted / signed / etc" - and get
        the same back? Otherwise wonder it should be arguments to
        Email/set rather than to the object.
      • Lean towards "keep it as simple as possible, but has to do
        what people need".
      • Alexey: if we have to add more things, more generic syntax
        would be better.
    • Ben: left side is less chatty.

      • Alexey: array is so you can add more things.
    • Ken:

      • Not all that concerned about the syntax, but if there's use
        cases for chaining them, keen to
    • Hans-Joerg:

      • Second what Neil says, if it's an operation not a property,
        then should be on Email/set
      • When scanning an account, want to know if there are
        signed/encrypted emails.
    • Alexey:

      • Think what I'm hearing is "let's try approach on right but
        move to parameters on Email/set not properties".
      • There might be asymmetry between create and view.
    • Philip (via chat) - Not even just for triple wrapped.
      Signed→Encrypted messages can't be determined as signed on the
      receiving side.

NEXT STEPS: needs more work

ACTION: Alexey to produce new version of jmap-smime-sender

  • tasks - 5 min
    • Joris: not much changed since IETF117
    • Need to sync

ACTIONS: Joris to talk with Neil re jmap-tasks and publish new by next

Other work:

  • portability - 5 min

    • Joris: has undergone revisions since Yokohama.
    • "Essential Parts" - reduce barrier.
    • JMAP Debug Logging - add log messages.
    • JMAP Backend Info - extention to capabilities and extension
    • REST Mapping - specifies a REST mapping for JMAP endpoints.

      • Arnt: asked for an example
      • Joris: sorry didn't give example since same as yokohama.
    • Request; call for adoption on all 4

    • Neil: shoud debug and serverinfo be the same document?
    • Bron: you can have more than one

ACTION: Bron will do 3 calls for adoption for jmap-* documents

JMAP AOB - 5 min

  • Hans-Joerg: JMAP Archive thing
    • Alexey also volunteered to help.
    • PST style file for JMAP.

ACTION: Hans-Joerg will publish a draft for JMAP Archive for adoption

JMAP Milestone Review - 5 min

  • done

Friends of Email Dinner

  • 14 hands
  • Dietary -> Restaurant will do mixed starters for us, Arnt said yes.
    Will make sure it's not all meat. At least one more.
  • Hans Joerg has two more maybe.
  • Will say 18


Agenda Bashing

  • Murray: IETF extra-jmapaccess - security considerations section

Rechartering: 10 min

  • Ben: autoconfig wouldn't fit this.
  • Ken: notice that JMAP for Sieve isn't on there.
  • Arnt: email message format isn't there.
  • Alexey: have you considered merging JMAP and EXTRA?
  • Neil: question is "do you merge in calext as well?" there's also a
    lot of JMAP overlap.
  • Jim: split those off?
  • Murray: do you mind picking up DKIM too?

  • Alexey: just flagging that SMTP Submission might be an issue, some
    people not here might object.

    • Jim: where else would it live?
    • Alexey: if EMAILCORE makes enough progress, it might be there.
  • Pete: there was some talk in DISPATCH about the perenial "I have
    some email stuff to do" - perhaps we need a general email stuff
    group. Tempted to unlimit EXTRA a bit.

    • Make anything currently in EMAILCORE, DKIM, DMARC, etc out of
      scope - have the working group have a dispatching process.
      Starting to feel "why are we being so tight about this?"
    • Murray: you're not the only person to ask this.
    • Also work going to ISE.
    • If we can come up with a charter that doesn't become a dumping
      ground, we could come up with something.
    • Bron: how and when and where will this conversation happen?
    • Murray: if I was to initiate, it would start on the ART list.
      Have a draft charter for this (MAILMAN) - can dust that off.
    • Bron: do you have time in the next couple of days?
    • Pete: the reason that DISPATCH occurred was that SIP was
      overwhelmed with a bunch of requests. Don't expect that we'll be
      overwhelmed. Come up with a dispatching process.
    • Murray: worried about creating something called "DISPATCH" for
      mail. But like the idea "if not other group, can come here -
      this group can decline"
    • Ken: maybe this is cart before horse, but would SMTP have to be
      moved into WIT? Murray: no, not web.
    • Alexey: devil's advocate, if people say "want to register my
      header field thing" - do we really want to deal with it in
      rechartered extra? Murray: what are rules for that registry?
      Standards action.

      • No, permanant and provisional, provisional doesn't require
    • Murray: being clear about that bar is what's missing.

      • Alexey, never kick things out, just dies and rots
    • Ben: maybe concrete - where would it go for "edit or delete
      email after I send it"

      • Alexey: depends, might be here if Expires and Supersedes
      • Murray: would be "do you have a draft", how baked is the
      • Bron and Murray 1pm tomorrow.
    • John Levine: two things in the hopper. Expires header, feedback

    • dkg in SECDISPATCH proposed STSish thing for message signing.
      Their action was "refer to ART". Alexey: or LAMPs.

ACTION: Bron on Murray to work on proposed EXTRA/MAILMAN charter.

In Last Call:

  • imap-jmapaccess - 5 min

  • Arnt:

    • No issues
    • Removed DEBUGGING - was a magnet for misunderstanding.
    • Accidentally removed the remaining sentence from security
    • Believe there's a review.
    • Murray: security considerations being missing is not allowed.

      • There SHOULD be a sentence.
    • Ken: will do a review on the list. Read it again last week.

ACTION: Arnt publish a new draft imap-jmapaccess with security
considerations re-added

Existing drafts:

  • imap-uidonly - 5 min
    • Alexey: One small update since last IETF. Add UIDREQUIRED
    • Made the document experimental
    • Ken: don't forget the issue about what happens if the client
      only asks for UID.
      • can do in WGLC

ACTION: Bron to WGLC imap-uidonly

  • sieve-processimip - 5 min
    • Ken: name was changed from processimip to processcalendar
      because we can support public messages.
    • Forgot about "PUBLIC and PUBLISH"
    • Renamed cancelled to two 'l's.
    • Neil:
      • Multiple parts with calendar data - if they are the same
        UID, then identical, pick one.
      • If more than one and different, don't auto-process.
      • Ken: report as error or no action?
      • Alexey: e.g. multipart digest.
      • Neil: could be multipart or a calendar with multiple events.
      • Ken: should we discuss inline attachments? Security
      • Alexey has external list extension - would it be useful to
        specify a list of addresses that you will only accept
        invitations from?
      • Ken: you can check headers, but not organizers. Could make
        it optional.

ACTION: Ken to revise sieve-processcalendar
ACTION: All to review sieve-processcalendar

  • imap-list-metadata - 5 min
    • Ken: very short doc - way to fetch annotations as part of list.
      Matches myrights.

ACTION: Bron to WGLC imap-list-metadata

  • imap-inprogress - 5 min
    • Marco: no slides
    • Document has had changes since last meeting
    • Only thing to mention is that the document gives count and
      total. If some information is not available, can give hey I've
      done this much; but don't know when I'll finish.
    • e.g. if you have mutiple different operations going. Internally
      debated "just give percentage".
    • Bron: am against percent symbol in syntax.
      • Marco: it's a way to show that it's a percentage.
      • Bron: client will display same either way.

ACTION: let WGLC finish - update draft if needed.

  • imap-messagelimit - 5 min

    • Alexey: various clarifications

      • Discovered yesterday realised search behaviour didn't map.
    • Bron: when testing I'd want a low limit.

      • Alexey: it's a SHOULD, ok with that?
    • Barry:

      • Had some comments on this previously, these changes address
        my comments.

ACTION: Bron to WGLC imap-messagelimit

Other work:

  • imap-utf8-bis - 5 min

    • Nobody implements RFC6855 correctly.
    • Problem is that it says "clients SHOULD tell the server" that
      the message uses UTF-8 addresses, most clients don't, one does
    • Most messages in the store will have come via other paths.
    • However to kill it, need to do more. Have done an individual
    • Pete: trying to get my head around "what did the servers do?" -
      servers appending with UTF-8 in the header.

      • Arnt: most clients just don't set this flag and it works.
      • Clients written in Python set the flag if the IMAPlib has
        seen that the server supports it, independent of what's in
        the message.
      • Pete: so getting it both ways, errors in both directions.
      • Arnt: so far haven't seen any server do anything at all with
        this flag.
      • Pete: do the servers support UTF-8 addresses?
      • Arnt: a couple do, but don't use this flag.
    • Alexey:

      • This is all a big mess. Point of the flag is that server can
        use a different parser - if client says UTF-8, then can
        parse; otherwise reject.
      • A lot of spam uses UTF-8. If server tries to guess.
      • Arnt: not relevant, spam arrives via LMTP, not via IMAP.
        Sure Spammers would love to use IMAP append!
      • Hans-Joerg: there are ISPs which spam-check IMAP.
    • Daniel:

      • I think all the IMAP-UTF8 is a big mess because email is
        supposed to be 7 bit clean. Already a mess having non-7bit
        clean stuff in headers.
      • If you're a client, you just have a message blob - the code
        doesn't know if there's UTF-8 in the header or not. Don't
        think this makes sense. The UTF-8 stuff is weird already.
      • Don't think we would ever support this flag or set it to a
        correct value!
    • John Levine:

      • seems to me that when you upload the message, server looks
        at header.
      • Arnt: this only concerns UTF-8 in local parts or domains in
        localpart of domain in addresses!
      • John: when I hacked this into qmail - it's a "if high bit in
        headers at all, it's all UTF-8". Flag is useless, server
        needs to look at header to see if flag is right, by then it
        doesn't need the flag.
    • Ken:

      • Clients not using this flag, are they using literal8 or
        plain literal?
      • Arnt: clients I've seen construct IMAP command without the
        flag, look at blob and use literal8 or not.
      • Daniel: problem is not NULL, it's 8 bits.
    • Pete:

      • My understanding was "reason this is here in the first
        place" is that if you got UTF-8, and dealing with a non-EAI
        client, you would have to translate.
      • Issue with Daniel's comment is that it sounds like "I don't
        want to implement EAI".
      • Once you have to reply, ends up in SMTP, it's a mess.
    • Daniel:

      • It doesn't matter if you support EAI, if there are emails
        with UTF-8 addresses in the headers, so as the client you
        have to support it anyway, so append-utf8 doesn't help.
      • When you see these emails come in through SMTP, the client
        telling the server "I know this email has EAI" you'll have
        to solve it anyway. Append UTF-8 is just weird.
      • If you set the bit, the server can check, but other clients
        won't see that bit when they pull down the message.
    • Ben:

      • Everything that Daniel said
    • Alexey:

      • I think what Daniel was saying is "if you get an EAI
        message, it's either arrived through SMTP with EAI
        extension, but client might not be the one that handled it
        in the first place", but doesn't know how to convert it
      • So - getting to garbage in, garbage out.
      • Pete; can I suggest a lunch discussion? today.
    • Arnt - perfect.

ACTION: lunch discussion then Arnt to email list regarding imap-utf8-bis

  • sasl-passkey - 5 min

    • Ben claps
    • Who's currently happy with SASL2?
    • I like passkeys, apple and google are pushing them.
    • Should have support, or bridge. That's this WG.
    • Daniel:

      • Passkeys are nice.
      • One problem with this is that - generally tied to biometric
        authentication, and usually want your IMAP thing to run in
        the background; if IMAP uses passkeys then you can't do
      • Alexey: does it require human present? Daniel: e.g. Yubikey
        needs a person to touch.
      • Arnt: passkeys on the web are used to set a cookie with
        short expiry, would set a 4 hour token; 1 day token etc.
        Solves problem with background, and problem with user
        changing from mobile to wlan. Can't ask user to touch phone
        just because that.
    • Neil:

      • Passkeys are great, love them - way to make this work is
        with OAuth - that how we'll get widespread adoption. Tied to
        a domain, have to exchange for a token, this is the already
        defined stuff.
      • Been talking with email vendors about this; can make this
        work - web login gets you passkeys, other things that are
        nice. Track stolen account etc. Don't think putting directly
        into IMAP is the right solution.
      • Arnt: Obviously not in IMAP, in SASL.
    • Alexey:

      • We talked about this last week, think this is wrong working
        group, in scope for KITTEN.
      • Murray: are they still going?
      • Alexey: I'm a chair! They're still going.
      • Documents discussed and not adopted in KITTEN. Would like
        this discussion, doesn't belong here.
    • Jim Fenton:

      • Passkeys are getting a lot of press right now, promising for
        consumer applications.
      • One of MANY authentication; e.g. enterprise might want
        better smartcard support.
      • Specifically calling out passkeys for IMAP is too specific.
        Generalised support for multi-factor.
    • Ben:

      • OAuth and mail is a whole topic of its own.
      • Want token that lasts longer (12 months etc) - one that just
        does check.
    • Arnt:

      • Be general for smartcards, etc as part of discussion.

ACTION: Arnt to discuss sasl-passkeys in KITTEN.

  • draft-bucksch-autoconfig - 5 min

    • Ben:

      • Want to document things, specify this first
    • Jim Fenton:

      • Is there an option to only use part of it?
    • Neil:

      • We definitely need an autoconfig document like this - had a
        meeting last week with many email vendors, looking at
        working flow.
      • Places you look - where thunderbird looks is interesting,
        but should put in RFC.
      • Security considerations: guessing locations; you're about to
        send email.
      • If we're recomending: .well-known and DNS SRV record should
        be it.
      • XML vs JSON, don't care. Implemented already is better.
      • Not sure about version 2. Would people implement?
      • If the format supports what we need, then we should take it.
    • Ben:

      • responding to "how to find"; there's format specification
        and how do I get it.
      • That's part of the protocol
    • Neil:

      • That's not what we should recommend. We should only recomend
        security recommended parts.
      • Missing a DNS SRV way to find it.
    • Alexey:

      • When we talked earlier - document what Thunderbird and
        others are doing is a good idea anyway, don't know if
        informational and standards track makes sense.
      • Ben: if change to JSON?
      • Alexey: reduce locations is fine.
      • Need to decide if one document or two stages.
      • Ben: if compatible with existing deployments, find to make
    • Hans-Joerg:

      • Auto-discovery Enthusiast.
      • Been digging into both this AND Microsoft version.
      • Also activity in CalConnect (draft from Cyrus Daboo from
        2013) - should not be just for email.
      • Would also include webdav, file storage. People want all to
        work, not different process for multiple discoveeries.
      • Ben: agree, it's all in the draft!
      • Very much like Apple's config profiles - way to distribute
        this as a file for enterprise; something that should be
    • Murray:

      • My knowledge of Autoconfiguration may be stale - HTTPBIS may
        have strong opinions.
      • How is ISPDB kept reliable? It's a fallback.
      • Not sure this fits in charter here.
    • Ben:

      • regarding database, I see your point - it wasn't that much
        work, but of course it's some work. It's just a fallback. If
        ISP doesn't have something, most people using just a few.

we ran out of time; Murray unsure if in charter

ACTION: Bron to follow up with Ben and help him find a home for this

  • draft-melnikov-email-big-files - 5 min
    • Alexey: just quickly! We're over time
      • Bron presented this last year, the problem statement at
      • We posted a draft the other day.

ACTION: Wait for recharter to see if in scope.

EXTRA AOB - 5 min

EAI dicussion lunch - meet at rego desk 11:45.

EXTRA Milestone Review - 5 min

we ran out of time, this was not done during the meeting.