JMAP and EXTRA at IETF118

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

Intro and notewell 5 min

• Bron and Jim did intro

JMAP

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
IETF.

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
    object.

  • 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

EXTRA

Agenda Bashing

• Murray: IETF extra-jmapaccess - security considerations section
  vanished.

Rechartering: 10 min

• https://notes.ietf.org/extra-charter-bis
• 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
      RFC.

  • 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
      fields.
    • Murray: would be "do you have a draft", how baked is the
      idea.
    • Bron and Murray 1pm tomorrow.

  • John Levine: two things in the hopper. Expires header, feedback
    loop.

  • 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
    considerations.
  • 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
    response
  • 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
      considerations.
    • 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
    incorrectly.
  • Most messages in the store will have come via other paths.
  • However to kill it, need to do more. Have done an individual
    draft.

  • 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
      anyway.
    • 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
      that.
    • 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
      changes.

  • 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
      configured.

  • 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
work.

• draft-melnikov-email-big-files - 5 min
  • Alexey: just quickly! We're over time
    • Bron presented this last year, the problem statement at
      DISPATCH
    • 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.