# JMAP and EXTRA at IETF118 {#jmap-and-extra-at-ietf118} Tuesday 2023-11-07 09:30 CET (08:30 UTC) ## Intro and notewell 5 min {#intro-and-notewell-5-min} * Bron and Jim did intro ## JMAP {#jmap} ### In WG Last Call: (5 min total) {#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: {#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: {#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 {#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 {#jmap-milestone-review---5-min} * done ## Friends of Email Dinner {#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 {#extra} ### Agenda Bashing {#agenda-bashing} * Murray: IETF extra-jmapaccess - security considerations section vanished. ### Rechartering: 10 min {#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: {#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: {#existing-drafts-1} * 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: {#other-work-1} * 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 {#extra-aob---5-min} EAI dicussion lunch - meet at rego desk 11:45. ### EXTRA Milestone Review - 5 min {#extra-milestone-review---5-min} we ran out of time, this was not done during the meeting.